On Monday, May 11, 2015 12:04:19 PM Douglas Otis wrote:
On 5/11/15 10:06 AM, Scott Kitterman wrote:
RFC 6376 (which I think is the latest) includes:
3.3.3. Key Sizes
Selecting appropriate key sizes is a trade-off between cost,
performance, and risk. Since short RSA keys more easily succumb to
off-line attacks, Signers MUST use RSA keys of at least 1024 bits for
long-lived keys. Verifiers MUST be able to validate signatures with
keys ranging from 512 bits to 2048 bits, and they MAY be able to
validate signatures with larger keys. Verifier policies may use the
length of the signing key as one metric for determining whether a
signature is acceptable.
Since receivers have no good way of knowing what keys are long-lived,
there's no way on the receiver side to reliably determine if a key
shorter than 1024 bits is being appropriately used or not. I think it's
time to kill keys shorter than 1024 bits dead. It's not like the risks
associated with them are new [1].
I propose a short draft that updates 6376 to say MUST use at least 1024
bits and setting that as the minimum size verifiers must be able to
validate. I'm volunteering to write it if people agree it's appropriate.
Scott K
[1] http://www.wired.com/2012/10/dkim-vulnerability-widespread/
Dear Scott,
Signatures normally offer options not easily supported by
DKIM. One being use of a binary keys, rather than base64.
Indeed shorter keys were a mistake. What other mistakes
should be corrected? I can name a few.
I'm not particularly interested in a comprehensive update to DKIM. Time has
passed. Moore's Law has operated. It's time to change the minimum key size
(past time, IMO). I'd much rather get that done as I don't think it will be
controversial rather than get into a broader debate that might get bogged
down.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html