Re: [Ietf-dkim] DKIM key rotation best practice

[Jon Callas <[e-mail]>]

> On Aug 6, 2020, at 3:42 PM, Shana Bagherian <[e-mail]> wrote:
> 
> I was looking over rfc 4871 and emailed Eric who suggested I ask the question of you all on this DL.  So, I was wondering if any of the RCSs related to DKIM list a best practice, or if some other authority has given a best practice, regarding how often the keys should be changed?  It seems that best practice is
> every 6 months, but it would be nice for an authority to state so.  Of course, an acceptable answer is ‘it depends’ upon the security needs to the organization, but is if that is the answer – it depends – is there a minimum time frame for generating new keys?
>  

I apologize for being late to this party. As another of the authors of 4871 -- and one who is known to have opinions on key lifetimes -- I feel I should chime in.

DKIM protects an email in transit. Once it's been delivered, the key/signature's job is complete. Typically, this is a matter of seconds or minutes. If retries are needed, most servers stop after four or five days. If we wave our hands and say two weeks, that would cover nearly everything.

Moreover, if a DKIM key vanishes, then the receiver is supposed to process it like it would without DKIM, and typically that is that the content-based spam filtering would kick in. Thus, there's no real need to keep one around for two weeks, and if you then made it be thirty days, it's utter overkill.

If I were building an infrastructure for DKIM, my first approximation would be that there would be a key per day. I'd have a job make sure that there's a key for seven days in the future and delete keys older than 14 days ago. I'd see what my stakeholders said. I would object to keeping them around longer than fourteen days, but would only argue a little bit about thirty days. I'd be adamant it would not be longer than sixty. As Mark Delany pointed out, the Web PKI people are replacing keys for TLS every ninety days, and there's utterly no reason for longer than that. As Dave Crocker points out, DKIM is not data at rest and so it doesn't need anything fancy. 

Summarizing, some job should make sure there are keys for seven days in the future, N days in the past, with 14 being a really good value of N, 30 being meh, and anything longer than 60 utterly overkill.

An alternate strategy would be a Key Of The Month, and do one month ahead and one behind.

Lastly, I'm a huge fan of Michael Specter's paper, and would love it if someone implemented that -- it's a better solution to key retirement for DKIM than gonzo things I've suggested. It's also not germane to your issue.

	Jon