DKIM Key Rotation

Several people have asked me about how to rotate DKIM keys in the past few days (as if you’re modifying anything to mitigate replay attacks, you need to invalidate the signatures of all the mail you sent before you made those changes).
 

 [icon name=”key” class=”2x spin”]

You really, really should be rotating your DKIM keys on a regular basis (monthly, weekly, quarterly?) in an automated way, so you shouldn’t need to be special-casing a change like this. Lots of people don’t, though, so here’s a quick summary of how to change your DKIM signing keys:

  1. Pick a new selector – either one that you’ve never used before, or (if you’re using ping-pong selectors) one that you’ve not used in the past week
  2. Generate a new key pair
  3. Add the new public key to your DNS servers
  4. Check that the new public key is visible on each of your public DNS servers
  5. Start signing outgoing mail with your new selector and new private key
  6. Wait 24 hours
  7. Delete the old public key from your DNS servers

DNS negative caching can cause some minor problems, if you’re not careful – if a DNS resolver queries for your public key before you’ve published it then it will cache that the key doesn’t exist for a short time. There are a few things to do to avoid that.
First, if you’re reusing a selector that you’ve ever used in the past then you should wait 24 hours after publishing the new public key before you start signing with the new private key. That will avoid having the nonexistent key cached at remote ISPs who happen to look it up based on an old message which used the same selector as your new keys.
Second, you shouldn’t manually look up the new public key in DNS before you know it’s published, so as to avoid you caching the nonexistent key in your own DNS caching resolver. That’ll cause mail you send to yourself or to other people at your company / ISP to fail DKIM validation, which is likely not a bad problem, but can make diagnosing signature failures difficult.
If you need to look for the key in DNS before it’s published (for example, to make sure that changes have published to your external DNS servers) you can avoid that by querying the authoritative servers directly (e.g. using @your.name.server with dig, or “host -t txt foo._domainkey.example.com your.name.server” with host).
You should probably avoid using web-based lookup tools to check your key records before they’re published too, for the same reason – but you can safely use our validation tools (as they only cache results for a maximum of sixty seconds).
Happy rotating!
 

 [icon name=”key” class=”2x spin”]

 

Related Posts

DKIM and DomainKeys, Spam and Ham

I’ve been preaching “DKIM is great! DomainKeys is obsolete, get rid of it!” for several years now. I thought I’d take a look at my mailbox and see who was using authentication.
I’ve divided this into “Ham” and “Spam”. Spam is, well, all the spam I’ve received over the past couple of years. Ham is the non-spam mail in my inbox, whether personal, business, bulk or transactional. I’ve excluded most of the discussion mailing lists I’m on (not least because many of them consist of people in the email industry or are email standards development mailing lists, so have email authentication levels that are way outside the norm).

Read More

DKIM replay attacks

Replay attacks on DKIM signed messages
When you receive an email validly signed with DKIM by example.com that might not mean that example.com sent the email to you, or that they even sent this email at all.
What it does tell you is that at some point in the past, example.com signed an email with exactly the same headers and body and sent it to someone. That’s often close enough to the same thing. But if that original recipient were to resend the email to you completely unchanged then the DKIM signature would still validate when you received it. That’s not a bug; it’s one of the design features of DKIM that it typically survives mail forwarding.
That original recipient could also forward the exact same email to a million of their closest friends, and the DKIM signature would validate at each of those million recipients ISPs. This is one form of a replay attack, and it isn’t something DKIM prevents.
DKIM doesn’t prevent replay, but does mitigate it
Completely eliminating replay attacks over SMTP is difficult – it’s inherently a store-and-forward protocol, so there’s no way to have the sender and recipient do any sort of handshake to ensure that a particular signature is only used once. It’s not unheard of for email to be delayed for days, and delays of hours aren’t unusual, so allowing a signature to be valid for only a few seconds after it’s sent won’t work. And the design requirement that DKIM signature survive forwarding means that it has to survive the final recipient’s email address not being the same as the email address the mail was originally sent to so you can’t include the envelope recipient in the signature.
So what does DKIM do to mitigate replay attacks? The answer to that is surprising – almost everything DKIM does is there to mitigate them. The DKIM signature depends on the body of the message, the subject line and the content of any other headers the sender chooses to include; changing any of that will invalidate the signature. That means that while anyone can grab a copy of an email sent by, for example, paypal and forward it on to someone else, if they modify the content at all it will no longer have paypal’s signature. So an attacker can’t just grab someone else’s signed email and replace it with modified content – and if they can’t do that, where’s the benefit to a spammer or phisher to replay a message?
But all that work is for naught if you allow the attacker to choose the content before you sign the message. There are several ways an attacker can do that, but one example that’s particularly relevant today is ESP trial accounts.
I’m stealing your reputation
If you allow anonymous signups for trial accounts that let a potential customer try out your system you’ll want to put very tight limits on how it can be used, so as to avoid spammers signing up and spamming through your servers. Maybe you’ll limit the number of email addresses the trial user can upload, or the number of emails they can send. At the most extreme you might even limit the trial account to sending mail solely to the trial users own (confirmed) email address.
But if an attacker can send even one piece of email they create through your trial account to themselves, and you sign that email, they can take it and send it to a million recipients – and it’ll still have your DKIM signature on it so it’ll use your reputation to avoid filters and end up in the recipients inbox. And then the recipients will report it as spam, and all that spam will be counted against the reputation associated with your DKIM identifier. If you share a DKIM identifier (“d=”) across all your customers that could cause all your customer mail to start being rejected or sent to the spam folder. (Even if you don’t it could still affect your delivery negatively, as spam filtering systems – both automated and human – sometimes aren’t entirely rational or predictable).
Spam that’s sent like this will be a little “off”, compared to legitimate email – the To: field won’t have the email address of the recipient, for instance, and there’ll be no personalization in the Subject or body of the message. It’s no worse than most spam, and it’s more than balanced out by being able to hijack someone else’s reputation.
So if you provide any way for unvetted non-customers to send email through your systems you should consider adding some DKIM limitations to the constraints you already have on that mail path. Not signing with DKIM at all avoids the problem altogether, but also means you can’t demonstrate your DKIM prowess to legitimate potential customers. You might want to sign with a DKIM d= domain that’s different to your production signatures, perhaps even a completely different top level domain to avoid any risk of confusion (but don’t try and hide that it’s your domain – that’s what spammers do).
Other operational mistakes
There are some grubby corners of the email and DKIM specs that sometimes interact to cause other holes that this sort of reputation hijacker can exploit. I’ll talk about header duplication tomorrow.

Read More

Hotmail moves to SPF authentication

Hotmail has recently stopped using Sender ID for email authentication and switched to authenticating with SPF. The protocol differences between SenderID and SPF were subtle and most senders who were getting a pass at Hotmail were already publishing SPF records.
From an email in my inbox from September:

Read More