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

[Mark Delany <[e-mail]>]

On 06Aug20, Shana Bagherian allegedly 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

In the absence of any special risk, it might not be unreasonable to follow the validity
limits being imposed by RFC5280 on TLS server certificates - which is what, just over a
year? They've done the hard yards in determining this value, so why not leverage that?

An alternative might be to use the 90 day life-time set by letsencrypt.org - their
argument being that it encourages automation. Can the systems you have under consideration
automatically generate their DKIM keys?

Having said that, it seems that at least some big-name domains change their keys very
infrequently. E.g. gmail use a selector of s=20161025 which they've been using since early
2017 and Yahoo are still using s=2048 which I first saw in mid-2014!

One suspects that neither of these establishments have automated DKIM systems so if you
have one you'll better off than they are.


> is there a minimum time frame for generating new keys?

Technically there is no minimum time, but it's hard to see much value in rapid key
replacement. Your biggest risk may well be subversion of your generation and distribution
mechanism at that point.

You'll recall the distinction between signing key life-time and verification key
life-time. The latter being how long you advertise a key *after* you've stopped signing
with it. Some argue that maximum email transit-lifetime + fudge is sufficient as good
reasons for re-verifying long after delivery are hard to find.


Mark.