[ietf-dkim] New Issue: 512 too short?

[Stephen Farrell]

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.