Domain Keys for email sender authentication

Last week, this page described Sender Policy Framework (SPF) and some of its shortcomings. A different technique with similar goals is Domain Keys (DK) which appears to be gaining support. This week, DK will be examined along with the related Domain Keys Identified Mail (DKIM) proposal.

DK was proposed by Yahoo as a way to authenticate the sender of an email. Essentially, the email is signed using a public key cryptographic signature. A receiving Mail Transfer Agent (MTA) or Mail User Agent (MUA) can look up the public key in the DNS record for the sending domain and compute the signature. If it matches the entry in the DomainKey-Signature header, the email has been verified to have come from that domain.

The DK header can specify which other headers are signed and the email body is always included. The domain in the "From:" (or, in some cases, "Sender:") header must always match the domain in the DK header and that provides the linkage that verifies the sender. Because of the way the signature algorithm works, any modification to the signed parts will result in a signature mismatch -- this provides some email integrity protection.

Domains and subdomains will maintain public keys as TXT records in their DNS entries. DK uses a standard section of a domain's DNS space to contain the public keys for that domain. In addition, a selector is specified in the DK header which can be used to restrict keys to specific organizations and to revoke keys periodically. To retrieve a key, one queries for the TXT record associated with selector._domainkey.example.com.

DK has been adopted by two of the larger email providers: Yahoo and Gmail. Banks and other financial institutions are also starting to adopt it because it provides very good phishing protection for their customers. It allows customers the opportunity to verify that the mail is authentic. Unfortunately, the support for DK checking in MTAs and MUAs has not been widely deployed yet, but the early adopters appear to be betting that it will be.

There are several issues with DK, but they do not fundamentally break the store and forward nature of email as SPF does. The main problem is that users will need to use an SMTP server associated with the domain that they are sending from or their MUA will need to generate a DK signature using a personal private key (that is listed appropriately in the domain's DNS). Another issue is that the signing of the body only works if the body is not modified after the signing. Unfortunately some mailing lists and other software (virus scanners for example) tack on a few lines to the body and this will cause the signature check to fail.

A potentially bigger problem is that DK is covered by patents held by Yahoo. Microsoft's Sender ID proposal never gained any traction in the free software world because of patent issues, but it appears that Yahoo's liberal licensing terms have removed that issue, at least for free software. Yahoo licenses the patents under either the GPL or their own license agreement. A patent peace provision and a notice that acknowledges Yahoo's intellectual property are all that are required for those who do not wish to license under the GPL.

Shortly after Yahoo released the Domain Keys specification, Cisco proposed Identified Internet Email. The two are similar in many respects and have since been merged into a proposal called Domain Keys Identified Mail (DKIM). The IETF has formed a DKIM working group that plans to guide the proposal towards adoption as an internet standard. Depending on whose opinion you believe, that could happen within the next year or two. It remains to be seen whether there is widespread adoption and conversion from Domain Keys if and when DKIM becomes a standard.

Index entries for this article
GuestArticles	Edge, Jake

---

to post comments

DKIM shortcomings

Posted Jun 22, 2006 11:03 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link] (1 responses)

DKIM is in principle the right solution. Signing the entire mail and not just the headers or some of them allows to actually check for good or bad content.

The problem is that they try to invent the wheel from scratch. Instead of using established and well matured digital signing protocols like S/MIME or OpenPGP they came up with an entire new protocol. This DKIM protocol needs to go a long way until it will be useful and can't be abused.

For example, their canonicalization rules are very complicated. As they stand now, they allow to modify the mail by injecting new content and changing the existing MIME content invisible. It will be easy for spammers to take existing valid signed DKIM messages as template, insert their cruft and resend them to the world. Verification according to DKIM rules will show a valid and authentic message :-(.

FWIW, with gpg1.4.3 we are experimenting with a system called PKA which does exactly the same as DKIM but uses OpenPGP and may also be used for S/MIME.

DKIM shortcomings

Posted Jun 23, 2006 21:35 UTC (Fri) by pimlott (guest, #1535) [Link]

Your message is right on--if Domain Keys were simply a key management mechanism and not a new message format, we'd be a lot closer to practical email authentication. Good luck with PKA.

Domain Keys for email sender authentication

Posted Jun 22, 2006 13:37 UTC (Thu) by job (guest, #670) [Link] (8 responses)

What problem exactly are they trying to solve?

If I wanted authenticated e-mail I'd be running pgp/gpg by now. There are several implemenations and easy to use plugins that anybody can use. So this sort of smells like yet another misguided attempt against spam.

When we all get properly authenticated spam, then what?

Domain Keys for email sender authentication

Posted Jun 22, 2006 14:34 UTC (Thu) by proski (guest, #104) [Link] (3 responses)

PGP signatures certify that the message was signed by a certain person. Domain keys certify that the message was sent from a certain domain. So if you get a DK-authenticated message from foo@yahoo.com, you know that foo is actually a Yahoo user.

DK-authenticated spam can be reported to the domain name owners and (if they seem to be spammers) to their ISPs. Non-authenticated spam is reported to the owners of the IP block where the SMTP server was located. It could be argued that the former is more effective.

Domain Keys for email sender authentication

Posted Jun 23, 2006 20:08 UTC (Fri) by pjones (subscriber, #31722) [Link] (2 responses)

DK-authenticated spam can be reported to the domain name owners and (if they seem to be spammers) to their ISPs.

This just doesn't mesh with reality. These days, there are two types of spammers. The first are large spamming operations, generally operating from spam-friendly countries. Generally their ISPs don't care (because they're providing net-neutral bandwidth), and the police absolutely don't care. The second kind are virus software. These are starting to become incredibly sophisticated. They know about smarthosts, and they'll know as much about using DKIM to talk to their ISP (and thus send mail the rest of the world will see as legitimate) as MS Outlook does. They may well even use Outlook's libraries to do it.

Calling NetZero and telling them that you got spam from one of their customers is essentially the same as calling them up and telling them their customers are running windows. They may put forth legitimate and concerned effort to stop the spamming, but having it signed isn't going to make it any easier.

Domain Keys for email sender authentication

Posted Jun 24, 2006 2:00 UTC (Sat) by grouch (guest, #27289) [Link] (1 responses)

There is a 3rd group of spammers: Online retailers. Remember that spam is unsolicited, commercial email. A lot of online retailers seem to believe that if you dare order from them, it is then acceptable for them to send you email advertisements you never requested.

Domain Keys for email sender authentication

Posted Jun 26, 2006 23:46 UTC (Mon) by dlang (guest, #313) [Link]

if this was all I had to deal with life would be good and very few people would care about spam.

while this type of mail is mildly annoying it's nowhere near the danger and hassle of the other 90+% of the spam which is from people you have never dealt with before.

Domain Keys for email sender authentication

Posted Jun 23, 2006 17:12 UTC (Fri) by shane (subscriber, #3335) [Link] (3 responses)

When we all get properly authenticated spam, then what?

Then the police go to the domain registrar and ask for the contact details of the owner of the domain. They then pay a friendly visit.

Or not so friendly. But living in a police state is okay as long as nobody tries to sell me Viagra, right?

Domain Keys for email sender authentication

Posted Jun 23, 2006 23:14 UTC (Fri) by giraffedata (guest, #1954) [Link] (2 responses)

I think spam already tells you where it came from, via received: headers and IP packet source addresses. I don't see that spammers are managing to spoof IP addresses, and when a received: header is forged, I think it's pretty easy to find out, if you're at the police investigation stage.

So what does DKIM add for spam prevention?

Domain Keys for email sender authentication

Posted Jun 23, 2006 23:42 UTC (Fri) by caitlinbestler (guest, #32532) [Link] (1 responses)

You need to think whitelist, not blacklist.

Authentication of the source allows you to confidently whitelist known sources, such as your own domain, without having annoying spammers forge headers just to get past your filters.

Domain Keys for email sender authentication

Posted Jun 24, 2006 2:30 UTC (Sat) by giraffedata (guest, #1954) [Link]

I was going to say that (but in a different sub-thread, because this one was about DKIM being useful for blacklists), but then I realized that out of 13,000 spams a month I get, only about 1 is "from" someone in my whitelist of a few thousand email addresses (everyone from whom I've received real mail or to whom I've sent mail in the past few years). So it's not a problem worth fixing.

As for whitelisting the originating server, I don't think that would help me personally, except in the case of your example -- mail from the local domain. And I do that today, based on the Received: header, because mail from the local domain would pass through only trusted mail servers to me.

I guess I do have a few more fake whitelist "froms" than what I said -- e.g. service@paypal.com, but I discard those with some other rules before checking the whitelist (I know it didn't come from Paypal, because Received: says the server that sent it isn't *.paypal.com). DKIM would be useful there, but still probably not worth the effort. For me, only 3 domains are a problem (paypal.com, ebay.com, chase.com).