> On Aug 6, 2020, at 3:42 PM, Shana Bagherian <[email protected]>
> 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
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
