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. _______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
