How a Google Headhunter's E-Mail Revealed Massive Misuse of DKIM 115
concealment writes with a tale of how an email sent to a mathematician led to him discovering that dozens of high profile companies were using easily crackable keys to authenticate mail sent from their domains. From the article: "The problem lay with the DKIM key (DomainKeys Identified Mail) Google used for its google.com e-mails. DKIM involves a cryptographic key that domains use to sign e-mail originating from them – or passing through them – to validate to a recipient that the header information on an e-mail is correct and that the correspondence indeed came from the stated domain. When e-mail arrives at its destination, the receiving server can look up the public key through the sender's DNS records and verify the validity of the signature. Harris wasn't interested in the job at Google, but he decided to crack the key and send an e-mail to Google founders Brin and Page, as each other, just to show them that he was onto their game."
There was no misuse (Score:5, Insightful)
This was not a misuse of DKIM, or perhaps it was his own misuse in that he thinks DKIM validates the sender of an email. All it does is validate that the email originated from Google's mail servers, but it doesn't neccessarily mean that the address in the From: header wasn't spoofed before it was signed.
In any case, he found that Google (and others) are using an easily cracked 512 bit key, which they silently fixed with a 1024 bit key after he reported it to them by spoofing an email to appear as though it originated at Google.
There was no misuse, 512 bit keys are allowable under the DKIM spec, though they aren't recommended for long-lived keys.
The Reality (Score:5, Insightful)
So the reality is that, on top of being useless as an anti-spam mechanism, it now turns out to be even worse, and in fact vulnerable to malicious attacks. In other words, it's useless and uselesser.
I was heavily involved in a lot of the discussions surrounding SPF, DKIM and related "solutions" back in the early 2000s, and about the most that we could say about these "solutions" was that you could add a positive number to the score of an email in a weighting system if things checked out, but other than that, there was little to recommend them.
Re:This just in... (Score:4, Insightful)
If it's easy to misuse, doesn't that make it broken?
Sigh (Score:5, Insightful)
If you, you know, actually read the standard, or even the Wikipedia page, you'll see that DKIM is not intended to be used as a signature mechanism in the same way as S/MIME or PGP. Rather, it's a means to assert responsibility for sending the message, it's done at the domain rather than user level, and verification results are intended to be used for message filtering, not for asserting that so-and-so actually signed the message.
Sure, the underlying technology is based on hashes, signatures, signature verification, and so on but that's because there's no other way to do it. The fact that DKIM allows for the application of relaxed interpretation of both message header and body data kinda tells you it's not intended to be used to provide an absolute assurance that what you got is authentic in every way.
DKIM is also not intended to be the ultimate source of information for filtering. Rather, DKIM results are supposed to be combined with other metrics to form an overall assessment of message validity. And that's a very good thing, since I get all sorts of spammy stuff that makes it through Google, including getting a legitimate DKIN signature attached. Other filtering mechanisms are needed to block such crap.
All that said, it's very disappointing to see yet another case where Google has seen fit to play fast and loose with standards. This is happening much too often.
Re:This just in... (Score:5, Insightful)
Re:The Reality (Score:3, Insightful)
DKIM is intended to allow mail sent through any server to be shown to be originally from a specific domain, thus preventing spoofing which is the basis of most spamming. SPF just allows server(s) to be identified as valid mailers for a domain, it doesn't work if you forward mail through other undesignated systems (which is still pretty significant, and covers most legitimate use cases).
If you're not checking SPFv1 on incoming mail, you're not a competent email admin. If you're not publishing SPFv1 for your domain you're not a competent DNS admin. This is just basic stuff nowadays; claiming otherwise is like claiming surgeons don't need to know about anatomy.
DKIM requires significant effort by comparison to SPF, and you can still be forgiven (for a little while) for not checking it or generating it.
Re:This just in... (Score:5, Insightful)
The DKIM spec itself (RFC6376) says: "Signers MUST use RSA keys of at least 1024 bits for long-lived keys."
Keep in mind that RFC 6376 was issued in September of 2011. Prior versions did allow 512-bit keys, though they cautioned against them.
It's pretty unequivocal. Google just misconfigured their mailserver.
More likely, I think, is that Google failed to reconfigure their server. When Google started using DKIM, cracking 512-bit keys was significantly harder than it is now. The change is less due to increases in computing power (though that has helped) than it is to the availability of cloud-based compute clusters. Granted that it was always a little risky to use such small keys, it was much more reasonable than it is today.
So my guess is that it went down like this: A few years ago when Google implemented DKIM someone looked at RFC 4871's discussion of key sizes, which says:
... and thought "yeah, we can use 512-bit keys and change them occasionally, that will provide higher performance for less CPU load, and as the RFC says the security goals here really aren't that high". I imagine that the decision to implement DKIM at all may have been a tad controversial given the additional load it was going to place on the servers, so that 512-bit key usage may even have been an important design point. Then the "change them occasionally" bit got dropped on the floor.
Fast-forward a few years, the problem is discovered and fixed -- but this time the engineers decided to make sure it doesn't happen again and jumped to 2048-bit keys even if it required provisioning more capacity.
(Disclaimer: I work for Google, and do cryptographic security stuff for Google, but I don't have any more information than the rest of you about how all of this happened. The above is pure speculation based on my 15 years as a security consultant before joining Google. I saw lots of stuff just like it from the few companies I worked with who were actually quite good about security. And even more insanely stupid stuff from all the rest.)
Re:This just in... (Score:4, Insightful)
Yup, all of that is likely what happened.
A critical part of DKIM is selector-based key rotation (as even the 2048 bit key won't help you at all when an ex-employee or a contractor walks off with the private key, while key rotation will reduce the window of exposure from that sort of event). Google aren't the only ones to have missed that.
(Many of the original - and current - examples of how to set up DKIM suggest using a date as part of the selector, so as to make it clear that the key was supposed to be fairly transient. That leads to the lovely situation that you can look at a lot of peoples DKIM setups and see that they created their key pair once, several years ago, using the current date and haven't changed it since - their failure to rotate keys is self-documenting.)
There are many reasons why DKIM doesn't need to be "really strong crypto" - it's intended just for someone to assert that they're responsible for an email message, that they're prepared to accept complaints about the mail they send, and that you should pay attention to their previous behaviour when deciding whether or not to deliver a message. Stealing someones DKIM private key lets you piggy back on their good reputation to get spam or phishing emails into an inbox rather than a spam folder for a short time period, and that's about it. It's nowhere near as high value a target as anything like TLS certificates.
Googles reputation is certainly worth more than the estimated $75 it would cost to crack their short key, so it's good they've fixed that. And even though much of the media coverage of this has been tech-tabloid drivel it's a good thing if it gets other companies to look at key length and rotation frequency.
(Disclaimer: I've been working with the DKIM spec since the early days of DomainKeys. http://dkimcore.org/ [dkimcore.org] is me.)