How long is your DKIM key?

While we were at M3AAWG, Wired published an article talking about how simple it was to crack DKIM keys. I didn’t post about it at the time because it didn’t really seem like news. DKIM keys smaller than 1024 are vulnerable and not secure and the DKIM spec does not recommend using keys smaller than 1024. When I asked the DKIM-people-who-would-know they did tell me that the news was that the keys had been cracked and used in the wild to spoof email.
Fair enough.
If you are signing with DKIM, use a key 1024 or longer. Anything shorter and your risk having the key cracked and your mail fraudulently signed.
This morning M3AAWG published recommendations on keeping DKIM keys secure.

  • Updating to a minimum 1024-bit key length.  Shorter keys can be cracked in 72 hours using inexpensive cloud services
  • Rotating keys quarterly
  • Setting signatures to expire after the current key rotation period and revoking old keys in the DNS
  • Using the key test mode only for a short time period and revoking the test key after the ramp-up
  • Implementing DMARC in monitoring mode and using DNS to monitor how frequently keys are queried. DMARC (Domain-based Message Authentication, Reporting and Conformance) is another standard often used in conjunction with DKIM
  • Using DKIM rather than Domain Keys, which is a depreciated protocol
  • Working with any third parties hired to send a company’s email to ensure they are adhering to these best practices

M3AAWG

Google took a good step in encouraging folks to upgrade to more secure keys. According to Return Path Gmail is currently failing DKIM for any key 512 and shorter. Keys between 512 and 1024 are still validating, but Gmail will start failing any keys smaller than 1024 in the near future.
 

Related Posts

Gmail shows authentication data to the recipient

Yesterday Gmail rolled out some changes to their interface. One of the changes is that they are now showing end users authentication results in the user screen.
It’s really the next step in email authentication, showing the results to the end user.
So how does Google do this? Google is checking both SPF and DKIM. If mail is authenticated and the authentication matches the from address then they display the email as:
mail from steve to me
If we click on “details” for that message, we find more specific information.
full details of message showing signing domain and spf domainIn this case the mail went through our outgoing mailserver to gmail.
Mailed-by indicates that the message passed SPF and that the IP address is a valid source of mail from wordtothewise.com.
Signed-by shows the domain in the DKIM d=. In this case, we signed with the subdomain dt.wordtothewise.com. That’s what happens when you sign using the domain in the From address (or a subdomain of it).
For a lot of bulk senders, though, their mail is signed using their ESP’s domain instead.  In that case Gmail shows who signed the mail as well as the from address.

And when we click on “details” for that message we see:
3rd party signature detailsThis is an email from a sender using Madmimi as an ESP. Madmimi is handling both the SPF authentication and the DKIM authentication.
As an aside, this particular  sender has a high enough reputation that Gmail is offering me an unsubscribe option in their interface.
Gmail is distinguishing between first party and third party signatures in authentication. If the mail is authenticated, but the authentication appears to be handled by a separate entity, then Gmail is alerting recipients to that fact.
What does this mean for bulk senders?
For senders that are signing with a domain that matches their From: domain, there is no change. Recipients will not see any mention of your ESP in the headers.
However, if you are using an ESP that is signing your mail with a domain they own, then your recipients will see that information displayed in the email interface. If you don’t want this to be displayed by Gmail, then you will need to move to first party signing. Talk to your ESP about this. If they’re unsure of how to manage it, you can point them to DKIM Core for an Email Service Provider.
Gmail blogpost about the changes
Gmail help page about authentication results

Read More

Gmail and the bulk folder

Earlier this week Gmail announced they were providing reasons for why they delivered a particular mail to the bulk folder. I’m sure a lot of senders are rejoicing over the clear feedback. After all this is exactly what they’ve been asking for “tell us why you’re filtering our mail and we’ll fix it.”
I am not sure, however, that this is going to help the majority of senders seeing mail going to the bulk folder. On the Gmail support pages, they list a number of the explanations they’re be providing.

Read More

Return Path partners with Symantec

Today Return Path announced a partnership with Symantec to improve their anti-phishing product. Return Path is incorporating the Symantec Trusted Domain List into their authentication and filtering product to help customers protect their brands. Press Release
Phishing scams affect everyone, and having a brand that is used in phishing can reduce consumer trust in that brand. Protecting brands in email has been one of the more difficult challenges facing the email community. With the adoption of DKIM and DMARC by major brands and ISPs it has become easier to track and address phishing.

Read More