Is Google failing DKIM keys shorter than 512 bits?

Today’s Wednesday question comes from Andrew B. and got pushed to Thursday so I could check a few more facts.

Have @Gmail yet confirmed the @ReturnPath story that they’ll start failing weak DKIM sigs? RP cites no source: http://goo.gl/Rb5to  @hey4ndr3w

The answer is that no one from Gmail has publicly confirmed that they’re failing to authenticate mail signed with weak DKIM keys. But conversations with various Return Path folks indicate this will happen at some point.
As of the time of this writing, Google is currently marking DKIM mail signed with 512 bit keys with “dkim=pass” and delivering the mail to the inbox. This was confirmed on Twitter Wednesday afternoon.

In case you missed it earlier- there are blog posts circulating about Gmail failing 512 bit DKIM keys, but testing shows 512 bits still pass @evan_burke

I posted earlier about DKIM key lengths and how there are vulnerabilities with shorter signing keys. The most recent revision of the DKIM spec itself states that signers MUST use at least 1024 bits for signing when the keys are intended for long term use. Anyone who is signing with a key less than 1024 and who is not rotating keys regularly is technically not following the DKIM specification.
What does this really mean?
Right now, DKIM authentication lends legitimacy to the signing domain (the d= value). Some ISPs, like Gmail, are using this authentication to present information to the end user about whether or not an email is legitimate. ISPs can trust that the sender of DKIM signed mail is an authorized user of the domain in the d= field because only authorized users have access to the DKIM private key.
When the DKIM key is short (512 bits or less) it can be cracked with a little bit of processing power. The Wired article specifically states that DKIM keys of 512 can be cracked in about 3 days using $75 of Amazon cloud computing. That means that if AnEmailCompany is signing with a DKIM key of 512 bits then a malicious entity could crack that key and send DKIM signed mail spoofing AnEmailCompany. The malicious entity gets the benefit of AnEmailCompany’s domain reputation and AnEmailCompany may see a drop in inbox delivery as the malicious entity sends more spam.
In other words, while the DKIM signature may validate, the mail may not be signed by an authorized entity. It is reasonable for Google, or any other entity checking DKIM signatures, to evaluate the length of a key and the length of time it has been in circulation when deciding to believe authentication results.
In terms of delivery, I expect this means that Google will treat mail signed with insecure keys similarly to mail not signed with DKIM at all.  Delivery decisions (inbox? bulk folder?) will be based on other factors in the email. Positive domain reputation may not help inbox delivery of poor content. And, for some cases, this may result in “via” showing up in the message list for some email.
I don’t believe that “failing DKIM keys shorter than 1024″ means that they’re going to reject or bulk all mail signed with shorter keys. That’s going to hurt an awful lot of wanted mail, and like most mail providers Gmail wants to deliver mail their users want. But they may not trust mail signed with short keys as much as they’ll trust mail signed with secure keys.
===
Have a question you want me to answer? Tweet them to wise_laura or send them to Nov07@contact.wordtothewise.com

Related Posts

DKIM implementation survey: prelim results

First off, I want to thank everyone who participated in the DKIM implementation survey. This week has been pretty hectic so far, so I haven’t had a chance to actually dig down into the data from the survey, but I thought I’d post some preliminary results.
The ESP survey had 45 respondents. 30% of those sent more than 15 million emails a month.
Of all the respondents: 40% are signing with Domain Keys, 51.1% are signing with DKIM.
Of all respondents: 79.5% are signing with Domain Keys and 78.8% are signing with DKIM to access services (whitelists or FBLs) provided by the ISPs.
50% of those not signing with Domain Keys are not doing so because customers have not requested it.  61% of those not signing with DKIM are not doing it because of technical difficulties with deployment.
The ISP survey had 16 respondents, with 37.5% handling less than 500,000 mailboxes and 18.8% handling more than 15 million mailboxes. 75% of respondents said they are not checking Domain Keys on inbound mail. 56% said they are not currently checking DKIM on inbound mail.
Only 10 ISPs answered the question if they plan to check either Domain Keys or DKIM.

Read More

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

DKIM "i=" vs "d=" and Reputation

This really should be part seven of a twelve part series or some such as it deals with an aspect of DKIM that’s really important, but is way down in the details of implementation. (dkim.org is a reasonable place to start for a general overview of DKIM).
There’s an apparently endless thread on the DKIM-SSP spec development mailing list at the moment about the differences between two fields in a DKIM signature that could be used to tie a senders reputation to. Several ESP delivery folks asked me to explain what everyone was talking about, and this post is a first cut at that.
“i=” vs “d=”
There are two possible fields in a DKIM signature that could be used to identify the sender of a message, and so to tie a sender history and reputation record to. They are the so-called “i=” and “d=” field, from the syntax used to include them in the signature.

Read More