Home / Blogs

Searching for Truth in DKIM: Part 2 of 5

J.D. Falk

In part 1, we explained that the DKIM "d=" value identifies the domain name which signed the message, which may be a different domain name from the author of the message.

Tying the signing and author domains together will require an additional standard: Author Domain Signing Practices (ADSP). In IETF parlance, the "author domain" is the domain name in the From: header, so ADSP is a way for the author domain to publish a statement specifying whether any other domain name should ever sign a message purporting to be From: that author domain.

So with ADSP, Return Path (my employer) could publish a policy stating that only returnpath.net will ever sign messages from returnpath.net — in other words, valid messages From: addresses @returnpath.net will only have DKIM signatures signed by (d=) returnpath.net. Anyone receiving a message with a different d= value would be likely to reject it, or view it suspiciously.

For some domains, such as banks and other common phishing targets that carefully control who sends mail on their behalf, a strong ADSP statement is imperative to prevent spoofing and fraud. For others, such as ISPs or corporate domains with a lot of Blackberry users who relay mail through their mobile provider's SMTP servers, ADSP probably isn't a good idea. But that's okay, because it's optional.

ADSP isn't required to determine whether to trust a message. An untrustworthy domain could make a strong ADSP assertion as easily as a trustworthy domain. But when a trustworthy domain says "don't trust messages that look like they are from me unless I sign them," that provides a level of security which has never before been possible in email.

There isn't currently any way for the author domain to say "oh, by the way, you can also trust messages that look like they're from me if they're signed by my friend over here" — where the "friend" is an ESP, or a similar service. This is often called "third party signing."

It would be fairly easy (from a standards perspective) for an author domain to hand over a special key (designated by a selector, the s= value) so that their ESP can sign as the author domain, saying "trust this signer as if they were me" — because from a DKIM verification perspective, it is them. ADSP still works. The author domain can even revoke that key, rendering it invalid, whenever they please.

In part 3, we'll dive deeper into the concept of "trust" as it applies to DKIM.

(This article was originally published by Return Path)

By J.D. Falk, Internet Standards and Governance
Follow CircleID on
Related topics: Cybersecurity, Domain Names, Email, Spam
SHARE THIS POST

If you are pressed for time ...

... this is for you. More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Vinton Cerf, Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Share your comments

Not quite what ADSP means John Levine  –  Mar 13, 2009 7:10 AM PST

ADSP says (give or take some minor theological arguments currently underway) that all mail from foo.com is signed by d=foo.com, which suggests that mail without that signature is likely to be bogus.  It doesn't say anything about other signatures; if a message is signed both by d=foo.com and by d=bar.com, that's fine, and arguably if a message is only signed by bar.com and you have experience that tells you that all of bar's signed mail is good, you might well accept it regardless of foo's ADSP.

I think we agree that authentication and reputation are surprisingly subtle.

To post comments, please login or create an account.

Related

Topics

DNS Security

Sponsored byAfilias

IP Addressing

Sponsored byAvenue4 LLC

Cybersecurity

Sponsored byVerisign

New TLDs

Sponsored byAfilias

Domain Names

Sponsored byVerisign