Subject: [ietf-dkim] Key rotation

From: Steve Atkins <[email-masked]>
Date: Sat, 4 Sep 2010 13:41:41 -0700

Do we have any thoughts on 1. how often keys might sensibly be rotated and 2. how long public keys should remain visible after the private key has been rotated out?

Cheers,
  Steve

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Mark Delany" <[email-masked]>
Date: 4 Sep 2010 14:55:23 -0700

On Sat, Sep 04, 2010 at 01:41:41PM -0700, Steve Atkins allegedly wrote:

> Do we have any thoughts on 1. how often keys might sensibly be
> rotated and 2. how long public keys should remain visible after the
> private key has been rotated out?

I believe the general thrust is that DKIM keys are ephemeral so no one
should rely on there long-term presence. Your verifying MTA should
annotate inbound mail appropriately so that subsequent reliance on the
public key is not needed. Authentication-Results header being a good
place to store what is needed here.

(I know you know this, Steve. I'm just setting the stage).

In that light, I would expect that a public key only needs to stay
around as long as an email can remain in-transit plus some
fudge. Maybe seven days or thereabouts?

Turning the question back to you. Is there any motive for removing
public keys rapidly apart from when they've been compromised? I can't
think of any obvious reason why you'd want to do this, so I'm curious
to hear of any use-cases you have in mind that warrant rapid removal.

Mark.

---

From: Steve Atkins <[email-masked]>
Date: Sat, 4 Sep 2010 18:31:19 -0700

> (I know you know this, Steve. I'm just setting the stage).

Yup. Phrased more simply, the public key should be available when
the email hits the recipients final MX, but shouldn't be needed after
that.

> fudge. Maybe seven days or thereabouts?

Funny you should say that. I'm using 8 days, based on "If mail hasn't
been delivered in 7 days, it probably won't be" plus a one day fudge
factor.

> to hear of any use-cases you have in mind that warrant rapid removal.

The whole point of rotating keys is so that loss of an old private key
isn't a risk. Given that, I think that even if you're fairly sure that a key
pair hasn't been compromised then you should remove the public
key as soon as is reasonable after you stop signing with the private
key - as the private key continues to be a high value target until
the public key is removed.

Eight days is as short as I'm comfortable with, so that's as soon
as is reasonable for me.

If you know that a private key has been compromised then you
probably kill the public key ASAP - the risk of misuse outweighing
the loss of signature of any emails on the wire. Though if I knew
the key had been compromised because I'd just fired a sysadmin,
rather than because I'd seen spam using it, I'd probably rotate the
private key, then leave the public key up for a few hours, as the
vast majority of email will have been delivered, and the public
key checked, in that time.

Lists of email addresses walk out of ESPs all the time, and I'm
expecting DKIM private keys to have a similar level of leakage.
If I were setting policy at an ESP I'd want to rotate keys pretty
regularly, and kill public keys as soon as possible in order
to reduce their value to insiders.

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Sat, 04 Sep 2010 23:13:13 -0400

> fudge. Maybe seven days or thereabouts?

I believe this was the general view when it was this discussed back in 
2006
few years back.

I also wrote an I-D called DKIM-RCVD describing the "time shifting" 
issue and a possible solution to address it using a "DKIM-Received:" 
header idea:

    http://tools.ietf.org/html/draft-santos-dkim-rcvd-00

    A proposal offering partial DKIM verification support to help
    resolve premature DKIM signature expiration and key revocation
    related problems associated with time shifted DKIM verifier
    applications.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Hector Santos <[email-masked]>
Date: Sat, 04 Sep 2010 23:35:14 -0400

> private key has been rotated out?

The WG discussed this around 2006.  The DKIM-RCVD I-D I wrote 
summarizes the "timing issues" from the discussions and also offered a 
way to help resolve this issue:

There are three basic timing points:

     T1 - delivery time
     T2 - MFA (Mail Filtering Agent) process time
     T3 - MUA process/read/view time

T1 is 7 days based on DKIM recommendations and adequately covers the 
SMTP recommendations of 4-5 retry days.  So at a minimum the key 
retention time should be 7 days.

But there is a T2 gap time when the MFA gets it.  This time will 
mostly likely pretty short. And there is a T3 gap between MFA and by 
the time the MUA gets it.  Who knows what T3 is, but it could be 
pretty long, i.e. a user goes on vacation or simply reads his mail 
once per day or whatever.  So T3 is help consider possible MUAs with 
DKIM verification plug-ins.

Since T3 can be low to high time significant, the I-D proposed a 
method whereby the middle ware (DKIM verifier or not) will create/add 
a DKIM-Received with your public key information.  This way by the 
time it is actually needed by a verifier, it will have the old public 
key information in DKIM-Received.

I also suggested that this DKIM-Received header can be used a 
migration idea for those systems not yet ready to sign or verify but 
can get the information and store in the header in case there will be 
a long time-shifted verification period that exceeds the domains key 
expiration.

---

From: Mark Martinec <[email-masked]>
Date: Thu, 9 Sep 2010 18:57:06 +0200

Mark Delany wrote:
> I believe the general thrust is that DKIM keys are ephemeral
> so no one should rely on there long-term presence. [...]

With each key there is an associated selector:domain pair,
so with a key rotation comes the change of a selector.
Such a purpose of a selector is clearly documented in the
DKIM rfc.

Rumor has is that some large players (such as Yahoo!) are
disregarding such ephemeral property of a selector and
are trying to associate a reputation scheme based on both
the domain *and* the selector. If such approach catches up,
it would mean the end of a free choice of domains to roll up
new signing keys periodically.

Are my worries warranted? Is there anything than can be
done about it to prevent such practice?

  Mark

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 9 Sep 2010 13:47:32 -0400

This points up an issue with the use of selectors. 

Some signers use selectors to differentiate streams of mail. This plays
in to what you describe Yahoo! as doing for reputation.

We will be using the approach you describe for key rotation. Given that
my goal is to rotate keys quarterly (more for operational considerations
than security) this would be a problem if Yahoo! is really going this
route.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Mark Martinec
> Sent: Thursday, September 09, 2010 12:57 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Key rotation
> 
> Mark Delany wrote:

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Sep 2010 11:03:44 -0700

> Sent: Thursday, September 09, 2010 9:57 AM

It's not the first time I've heard that presented as a reputation idea.  Off the top of my head, I think the solution to that would probably be the realization by such verifiers that they're needlessly throttling good domains using such a scheme, causing them more headaches than they solve.

---

From: "McDowell, Brett" <[email-masked]>
Date: Thu, 9 Sep 2010 12:12:33 -0600

> Eight days is as short as I'm comfortable with, so that's as soon

...but what would be "as long as I'm comfortable with"?  Have we seen DKIM private keys compromised due in large part to leaving the public keys in rotation for too long... and what was "too long" in those instances.

I'd be surprised to discover many senders are rotating keys every eight days.

-- Brett

---

From: Michael Thomas <[email-masked]>
Date: Thu, 09 Sep 2010 12:01:58 -0700

> I'd be surprised to discover many senders are rotating keys every eight days.

I think he's talking about keeping a key around 8 days after it's been
deprecated so that in-flight mail will still verify.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Thu, 9 Sep 2010 11:26:28 -0700

> ...but what would be "as long as I'm comfortable with"?  Have we seen DKIM private keys compromised due in large part to leaving the public keys in rotation for too long... and what was "too long"…

That question doesn't make any sense.

> I'd be surprised to discover many senders are rotating keys every eight days.

I didn't suggest rotating keys every eight days. Rather, I suggested leaving the public keys in place for 8 days after removing the associated private key.

Cheers,
  Steve

---

From: Steve Atkins <[email-masked]>
Date: Thu, 9 Sep 2010 11:47:11 -0700

On Sep 9, 2010, at 9:57 AM, Mark Martinec wrote:

> the domain *and* the selector.

I don't believe this is true. I think it's being disseminated
by bulk mail folks who don't really understand what a DKIM
selector is for and who love to speculate about the dead
goats and pentagrams used at large consumer ISPs.

There's endless speculation amongst bulk mailers about
the reputation tracking and spam filtering black boxes used
by the big consumer ISPs, and it's amazing how far off
into the weeds it gets ("AOL won't deliver email with a
pink background", "Gmail blocks all email with a facebook
URL", "Yahoo will block your mail if you change your
DKIM selector", ...)

> If such approach catches up,
> Are my worries warranted?

I don't believe so. Without hard data or an official
statement from major ISPs that they're doing something
stupid with DKIM selectors I think you're safe to
ignore the issue.

> Is there anything than can be

Ignore the FUD. Use d= as your reputation key, with 
subdomains for different mail streams. Leave selectors
for key rotation[1] and multiple sender support[2].

Cheers,
  Steve

[1] http://labs.wordtothewise.com/keydancer/

[2] http://dkimcore.org/deployment/esp.html
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Thu, 09 Sep 2010 10:54:50 -0700

> done about it to prevent such practice?

I'm pretty sure that Mark isn't an advocate such a practice, but
let's face reality here: RBL's use IP addresses which are far more
transient yet we somehow cope. And I don't think that one of the worst
problems with RBL's vs. IP addresses (collateral damage when IP addresses
change hands) even applies here.

But if a reputation service isn't prepared for key rollover on selectors,
I'd look for another one because they're incompetent. What else is a DKIM
signer supposed to do if a key compromised? Blast out memory eraser rays?

Mike

Mike

---

From: "McDowell, Brett" <[email-masked]>
Date: Thu, 9 Sep 2010 14:33:46 -0600

> I didn't suggest rotating keys every eight days. Rather, I suggested leaving the public keys in place for 8 days after removing the associated private key.

My apologies, I completely misunderstood what you were suggesting in this thread.  But at least now I know you aren't crazy (at least not for your position on this issue ;-)

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 9 Sep 2010 14:21:55 -0700

> the domain *and* the selector.

That rumour is based on a presentation I gave in 2006 or so, while working at Yahoo!.  Within hours, Dave Crocker had convinced me that tying reputation to the selector was a bad idea.

Please help me quash the rumour, there's enough baseless FUD already.

---

From: Mark Martinec <[email-masked]>
Date: Fri, 10 Sep 2010 00:08:42 +0200

On Thursday September 9 2010 23:21:55 J.D. Falk wrote:
> That rumour is based on a presentation I gave in 2006 or so, while working
> at Yahoo!.  Within hours, Dave Crocker had convinced me that tying
> reputation to the selector was a bad idea.
> 

Thanks! That is what I was hoping to hear!

  Mark

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 10 Sep 2010 09:55:14 -0400

> Please help me quash the rumour, there's enough baseless FUD already.

http://feedbackloop.yahoo.net/

Step 2 doesn't help. (yes, you can put * for all selectors, but asking for
one when it isn't really needed leads to FUD).

-- 
Jeff Macdonald
Ayer, MA

---

From: Alex Soto <[email-masked]>
Date: Fri, 10 Sep 2010 07:49:50 -0700

> one when it isn't really needed leads to FUD).
Yeah, I've always thought this process was a bit odd.  I began to question
if it even mattered to them and, furthermore, how much weight they were
actually putting on Domain vs. IP for reputation.

Alex Soto
[email-masked]

---

From: "Mark Delany" <[email-masked]>
Date: 10 Sep 2010 08:02:23 -0700

> one when it isn't really needed leads to FUD).

A selector can of course be in a sub-domain format, such as
september.dialup._domainkey.example.net

I wonder if they considered letting you enter *.dialup or somesuch?

Obviously, requiring or using a fixed name selector is something no
sensible person should be advocating.

Mark.

---

From: "John R. Levine" <[email-masked]>
Date: 10 Sep 2010 14:45:37 -0400

> I wonder if they considered letting you enter *.dialup or somesuch?

I dunno, but I think the last time something like this came up, we agreed 
that if you want to have two separate reputation streams, they should have 
different d= rather than different selectors.

R's,
John

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 10 Sep 2010 15:02:01 -0700

On Sep 10, 2010, at 6:55 AM, Jeff Macdonald wrote:

> Step 2 doesn't help. (yes, you can put * for all selectors, but asking for one when it isn't really needed leads to FUD).

That's a complaint feedback loop.  Totally separate system.

(Yes, some mailbox providers use complaint feedback loop participation as an input to their whitelisting decisions, but that's not reputation.)