[ietf-dkim] New Issue: 512 too short?
stephen.farrell at cs.tcd.ie
Thu Mar 16 07:42:12 PST 2006
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?
More information about the ietf-dkim