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

From: Shana Bagherian <[email-masked]>
Date: Thu, 6 Aug 2020 22:42:00 +0000

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?

Shana Bagherian 
CISSP, MBA, MCSE
Senior Infrastructure/Security Architect, 
Triden Group
"Where Security Protects Innovation"                                
9823 Pacific Heights Blvd Suite H, San Diego, CA 92121
[email-masked]
www.tridengroup.com

Note: This e-mail message including any attachments of any type are covered by the Electronic Communications Privacy Act, is confidential and may include legally protected information. if you are not the intended recipient or you have received this e-mail message by mistake, please notify the sender you have received this e-mail by mistake and delete all information contained in and attached to this email. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. v20190718

---

From: "Mark Delany" <[email-masked]>
Date: 7 Aug 2020 00:16:55 +0000

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.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 6 Aug 2020 19:23:31 -0700

On 8/6/2020 3:42 PM, Shana Bagherian wrote:
> 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?

M3AAWG DKIM Key Rotation Best Common Practices
(revised March 2019)

https://www.m3aawg.org/DKIMKeyRotation

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Mark Delany" <[email-masked]>
Date: 7 Aug 2020 03:53:23 +0000

> https://www.m3aawg.org/DKIMKeyRotation

Luckily the tl;dr is in the first line. Phew! Quite the read :-)

It seems that both Maawg and letsencrypt are both pro-automation. I think that's the
biggest take-away for the OP.

Mark.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 7 Aug 2020 11:11:10 +0200

> Luckily the tl;dr is in the first line. Phew! Quite the read :-)

Section 5.1.3 "Rotating Keys" is also worth reading, as it discusses
setting an empty p=.

> It seems that both Maawg and letsencrypt are both pro-automation. I
> think that's the biggest take-away for the OP.

That paper doesn't mention publishing the private key some time after
public key revocation.  Someone suggested to do so to avoid the
Clinton effect.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Sat, 8 Aug 2020 08:05:52 -0700

> public key revocation.  Someone suggested to do so to avoid the

dkim is meant for use with data in transit, not data at rest.  long-term 
recovery mechanisms aren't needed for it.

d/

---

From: Brandon Long <[email-masked]>
Date: Mon, 10 Aug 2020 15:36:01 -0700

> recovery mechanisms aren't needed for it.

Isn't publishing the private key the opposite of recovery?

Ie, it's basically a mechanism for plausible deniability.

"The key is public, anyone could have made that message."

Brandon

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Aug 2020 00:06:31 +0100

> "The key is public, anyone could have made that message."

Yep. And for DKIM, it's a mechanism I'd myself like to see
well-defined and used.

Cheers,
S.

---

From: [email-masked]
Date: Mon, 10 Aug 2020 19:27:13 -0400

Funny you all should ask! I coauthored a paper about exactly this earlier this year:

https://eprint.iacr.org/2019/390

==Mike

> On Aug 10, 2020, at 7:06 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 
> <0x5AB2FAF17B172BEA.asc>
> _______________________________________________
> Ietf-dkim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-dkim

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Aug 2020 00:35:58 +0100

Hiya,

> https://eprint.iacr.org/2019/390

I recall reading that, and must look at it again
because I don't recall why it was better than just
publishing private keys when one is finished with
'em (plus a bit).

S.

---

From: [email-masked]
Date: Mon, 10 Aug 2020 19:38:43 -0400

Short answer: fast key rotation (on the order of 15 minutes if necessary), minimizes the amount of private key material needed to be kept around, and no need for an admin to update the key material in dns.

==Mike

> On Aug 10, 2020, at 7:36 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
>

---

From: [email-masked]
Date: Mon, 10 Aug 2020 19:41:52 -0400

Also! If you have questions/ feedback I’d love to chat! I really do believe that this is a better solution than what is currently happening, but I’m sure that there’s more I can do to make it better. 

==Mike

---

From: Jon Callas <[email-masked]>
Date: Tue, 11 Aug 2020 15:25:51 -0700

> On Aug 6, 2020, at 3:42 PM, Shana Bagherian <[email-masked]> wrote:
> 
> 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

---

From: Shana Bagherian <[email-masked]>
Date: Tue, 11 Aug 2020 22:32:18 +0000

thx!

Shana Bagherian, MBA MCSE CISSP

Sent from my iPad
Please excuse the brevity, typos (auto-correct is disabled because it never recognizes IT lingo!), and lack of capitalization (is it really necessary? unlike punctuation which is needed)

Shana Bagherian 
CISSP, MBA, MCSE

On Aug 11, 2020, at 3:25 PM, Jon Callas <[email-masked]> wrote:

** WARNING: This email originated outside of Triden Group. Do not click links or open attachments unless you recognize the sender and know the content is safe. **

       Jon

NOTICE: This e-mail message including any attachments of any type are covered by the Electronic Communications Privacy Act, is confidential and may include legally protected information. If you are not the intended recipient or you have received this e-mail message by mistake. Please notify the sender you have received this e-mail by mistake and delete all information contained in and attached to this email.