Michael Thomas wrote:
Stephen Farrell wrote:
Michael Thomas wrote:
Stephen Farrell wrote:
Section 3.3.3 includes 512 bit rsa as a MUST. I think that that
might be an error. Is there really any need for anything smaller
than 1024 in any case?
Isn't there something of a calculation which equates effort to
break over time? DKIM lifetimes are normally quite short, so
smaller keys are not implausible, especially given the level
of protection DKIM actually provide (weakest link: DNS).
That's a defensible argument. Just to be clear though - there
are two lifetimes in DKIM - signature lifetime, related to
message transit times, and key lifetime, related to some unknown
management cycle, and its the latter (and presumably longer) one
that's in question here. From painful experience, changing keys
is something that some enterprises are really, really bad at.
Ah, yes, and I agree that key rollover is probably the
larger problem. Is 768 an implausable lower bound? We
could even perhaps go so far as to say SHOULD sign/1024
(where the wiggle room is if you have a good rollover
story, and the performance difference is worthwhile).
That may be ok. But I'm guessing that a "MUST support 768"
(even with caveats) will raise some eyebrows and we'll have
to go over it all a number of times. So I'm not sure if the
CPU cycle improvement is worthwhile here or not.
My gut inclination would be MUST 1024 & 2048 and deprecate
all shorter keys to the extent that the deployed base permits.
If there are deployed 512 domains, one thing that could be done
would be to have a "MUST NOT use 512 after <<date>>" to try
get people to change their shorter keys. Or Mark's suggestion
may be better. Do we have any data on deployed key sizes?
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html