DKIM is a protocol that uses digital signatures to attach a confirmed domain name to an email message (see part 7, in particular). DKIM started from a simple place, with a simple problem statement and a simple goal:

Email messages have many addresses associated with them, but none are authenticated, so none can be relied on.

Bad actors — spammers and phishers — take advantage of that to pretend they are sending mail from a place (a domain name) the recipient might trust, in an attempt to fool the recipient.

If we can provide an authenticated domain name, something that’s confirmed and that a sender can’t fake, then that information can be used as part of the delivery system, as part of deciding how to handle incoming mail.

It’s important to note that mail signed with DKIM isn’t necessarily good mail, nor even mail from a good place. All we know is that mail signed with DKIM was digitally signed by a specified domain. We can then use other information we have about that domain as part of the decision to deliver the message to the user’s inbox, to put it in junk mail, to subject it to further analysis or to skip that analysis, and so on.

Domain example.com signed this message, is just one of many pieces of information that might help decide what to do.

But some people — even some who have worked on the development of the DKIM protocol — miss the point, and put DKIM in a higher position than it should be. Or, perhaps more accurately, they give it a different place in the email delivery system than it should have.

In a recently concluded discussion by the [DKIM Working Group], some of those involved have decided to disregard phishing-related threats common in today’s effective social engineering attacks. Rather than validating DKIM’s input and not relying upon specialized handling of DKIM results, some members deemed it a protocol layer violation to examine elements that may result in highly deceptive messages when accepted on the basis of DKIM signatures.

The blog post describes an attack that takes a legitimately signed message, alters it in a way that does not invalidate the DKIM signature (taking advantage of some intentional flexibility in DKIM), and re-sends the message as spam or phishing. The attacker can add a second from address, and appear to the user to be from a trusted domain, though the DKIM signature is not.

The attack sounds bad, but it really isn’t, and the Trend Micro blog’s conclusion that failure to absolutely block this makes DKIM an EVIL protocol (their words) is not just overstated, but laughable and ridiculous. It completely undermines Trend Micro’s credibility.

Here’s why the attack is overstated:

It relies on the sender’s ability to get a DKIM signature on a phishing message, and assumes the message will be treated as credible by the delivery system.

It ignores the facts that delivery systems use other factors in deciding how to handle incoming messages and that they will downgrade the reputation score of a domain that’s seen to sign these sorts of things.

It ignores the fact that high-value domains, with strong reputations, will not allow the attackers to use them for signing.

The attack creates a message with two from lines, and such messages are not valid. It ignores the fact that delivery systems will take that into account as they score the message and make their decisions.

Apart from that, the blog insists that the right way to handle this attack would be to have DKIM go far beyond what it’s designed to do. Rather than just attaching a confirmed domain name to the message, DKIM would, Trend Micro says, now have to check the validity of messages during signature validation. Yes, that is a layer violation. Validity checking is an important part of the analysis of incoming email, but it is a separate function that’s not a part of DKIM. All messages, whether DKIM is in use or not, should be checked for being well-formed, and deviations from correct form should increase the spam score of a message. That has nothing to do with DKIM.

In fact, the updated DKIM specification does address this attack, and suggests things that delivery systems might do in light of it. But however good that advice might be, it’s not mandated by the DKIM protocol, because it belongs in a separate part of the analysis of the message.

Others have also posted rebuttals of the Trend Micro blog post. You can find one here, at CircleID, and look in the comments there for pointers to others.

A view DKIM should not check for pre-pended From header fields severely reduces any value offered by DKIM signature reputations.

Don't overlook the fact a high value domain has no control over which DKIM signature might be used to spoof their From header field. ADSP (RFC5617) & Auth-Results (RFC5451) did not consider the pre-pended From header threat either. They relied on DKIM results and assumed a single a From header field. But which one? When the DKIM signature is from a "too big to block" domain. Game over as reputation can't help in this case.

Why must DKIM depend on some other undefined protocol layer? How will this make anyone safer?

I am a computer software engineer/architect, and I may sometimes write about things related to the work that I do. Notwithstanding that, whatever company I'm working for at the time has no connection to this web log or the writing herein, and what I say, no matter the topic, comes from me alone and does not represent the opinions or policies of my employer.

Comment previewing
I use comment moderation to avoid comment-spam and nastiness, not to filter opinions. I intend to publish all reasonable comments, whether or not they agree with me. I will not publish any comment that is unduly flaming or that uses foul language, whether or not it agrees with me. You may contact me about an entry by making a comment and telling me that it is a private comment, in which case I will not publish it. If you want a response, include your email address. For privacy reasons I won’t publish a comment that contains someone’s email address.

Unfortunately, because of comment spam I am no longer accepting anonymous comments. You may use a Google account or OpenID with a pseudonym, but you will have to log in to comment. I would rather not do this, but... blame the spammers.