Email is a complex service and email abuse adds confusing deceptions. Worse, like postal mail and even telephone service, Internet mail is inherently open, flexible and even anonymous, making things much easier for abusers. Bad actors hide their true identity and their true purpose. Most other communication tools for users also are also quite open, and problems with email are being replicated elsewhere, such as instant messaging and social media. Attackers are clever and extremely adaptable. Tools for protection often are expensive and specialized, and they often take a long time to deploy.

All of this creates an extra burden on anti-abuse workers to be extremely careful when discussing issues, facts and proposals. A recent corporate blog by TrendLabs demonstrates this need, by failing to satisfy it:

Possible Phishing with DKIM – TrendLabs Malware Blog

The blog concerns DomainKeys Identified Mail (DKIM), which uses cryptographic authentication technology for an unusual purpose. Unlike other services that use similar digital signing techniques, such as OpenPGP and S/MIME, DKIM does not “validate” a message or the message’s author, as listed in the From: header field. [RFC5322] Rather:

[It] permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. [RFC4871bis]

That is, DKIM’s sole job is to attach an identifier that can be believed, specifically a domain name that can be unrelated to any other identifier in the message. That domain name is used for associating the reputation of the domain owner with the message. The name is carried inside a DKIM-specific header field and can be attached by any handler of the message. Multiple signatures and signatures for different domains are all entirely legal; in fact, the aggregation of signatures and reputations can aid in evaluating how to process the message.

Also, note the qualifier in the quoted text: the owner of the name takes only some responsibility for the message. The nature and degree of that responsibility are unstated, because different actors in the handling of message have very different responsibilities. DKIM does not differentiate among those. The standardized semantics of DKIM mean that the verifier knows merely that the signer is asserting involvement. The verifier then chooses how to use that information, such as consulting a compiled listing of reputations for email handlers.

Digital signature technology uses hashing, to create a unique, short “description” of the data being signed. If the message is modified in transit, the receiver will compute a different hash that will not match the original. Hence as a side-effect of doing authentication, DKIM provides some data integrity protection between the time of signing and the time of verifying. However data integrity does not mean data validity. DKIM makes no statement about the validity of any data in the message, except the signature itself and the domain name it used.

DKIM is an enabling service. It’s direct benefit is small, but it provides an essential foundation for the development of trust-based mechanisms, as well as possibly being useful for mechanisms that can detect some types of deceptive messages. One such value-added mechanism is ADSP, which does link the DKIM identifier to the author From: field, with the primary goal of finding messages from sources not authorized to use the domain name in the From: field. However these additional mechanisms are value-added enhancements and are outside the scope of the core DKIM signing mechanism. DKIM, itself, solely specifies how to sign a message and then how to verify a signed message, and it defines the modest meaning of the signature.

To the extent that signers and verifiers wish to have a signature based on semantics that are different from DKIM, they need a different signing specification. The core innovations of DKIM are its use of the DNS to store public keys (associated with the domain name) and its placing signature information in a header field, rather than inline with the data, as done by OpenPGP and S/MIME. This means that receivers not supporting the signature do not have to deal with it, since header fields that are not recognized are ignored. In an effort to encourage creation of such parallel signature mechanisms, DKIM’s core technology has been extracted into a specification “library” called DOSETA (DOmain SEcurity TAgging.)

An IETF working group is revising the DKIM signing specification, for the next stage of standardization. The TrendLabs blog criticizes the working group for not adding a mechanism to counteract a problem that is entirely outside the scope of DKIM’s purview:

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’s description of the facts, its premise about the requirements, and its apparent understanding of DKIM’s functionality all suffer from basic flaws. The DKIM specification mandates that input to DKIM must be valid according to RFC5322. In requiring this, it is placing a burden on the containing system to ensure that a message is well-formed. It is not DKIM’s job to do the basic message validation; it’s the job of the requesting software.

Again, from the TrendLabs blog:

The details are simple and the original goals were good. DKIM was intended to authenticate domain relationships with an email message bound at a minimum to that of the From header field.

This statement appears to be similar to DKIM’s actual goal, cited above, but it contains an essential error: DKIM does not validate the author From: header field, nor any other identifier in the message, except the one used for signing. This encourages users of DKIM to focus on its role to identify handlers of email, not merely authors. For example, it is perfectly legitimate for a piece of software running a mailing list to sign messages it redistributes. In this case, the signing domain and the domain in the From: field are almost always going to be different. This is perfectly legal with DKIM.

The only “binding” that DKIM has with the From: field is the described one of data integrity, and again, that has nothing to do with validity. The binding that DKIM actually does is between an independent identifier, carried in a DKIM header field, and a hash of (part of) the message.

The blog continues:

The relationship was to provide a basis for message acceptance but failed to offer the intended protections whenever a message contains invalid or fake elements still considered to offer a valid signature. While it would not be a protocol violation to declare such messages with invalid or fake elements to not have a valid signature, there are some who think otherwise.

However DKIM does not make statements of specific “correctness” about messages. It merely attaches a reliable and accurate domain name that can be used for developing a reputation for the signer, with the verifier then applying the reputation to the stream of similarly-signed messages. Concerning the basic message invalidity described in the blog, the actual requirement is to make that declaration before DKIM ever sees the message!

Specifically, the blog’s analysis of the attack sequence is:

Here is how DKIM can be exploited:
...
2. Send yourself a message of a sensitive nature.
3. Prepend any dummy From header field ignored by DKIM to mislead recipients
with regard to the message’s origin.
4. Exploiting DKIM’s replay insensitivity, a malefactor can then resend the
message as a mailing list

That is, start with a valid, signed message and then add a second, bogus From: field and redistribute the bogus message to potential victims. The goal is to have the bogus From: field be displayed rather than the valid one, perhaps alongside some indication that DKIM validation was successful, giving the bogus From: field credibility. However, the email standard, RFC5322, requires one, and only one, From: field. A message with multiple From: fields is not valid, and remember that DKIM requires its input to conform to RFC5322.

So, the exploit that is described quite possibly is an interesting one, but it really has nothing at all to do with DKIM. A message with no DKIM signature can still suffer the basic exploit and handling software needs to look for the exploit whether DKIM is present or not. DKIM is merely one component in a necessary suite of protection mechanisms.

Confusing the different mechanisms is likely to undermine their utility. For example, if this attack were handled by DKIM, rather than elsewhere in the system, there would be no coverage of the exploit for messages lacking a DKIM signature. The TrendLabs blog therefore seems to call for handling the attack in a way that would reduce protection rather than increase it!

Attempting to emphasize relative costs, the blog asserts:

The overhead related to DKIM’s cryptographically based authentication dwarfs the effort of NOT ignoring the presence of multiple From header fields.

What the blog misses is that the problems and complexity created by having the wrong part of a system implement a particular mechanism dwarf the effort to do the implementation. It’s easy to put in a small bit of software to look for something and respond to it. It’s harder to find the right place to put that software into the overall system, so that it works correctly and provides the proper protection.

An odd factual confusion in the blog is:

While SMTP still permits RFC822-compliant messages, DKIM was based on RFC5322, which stipulates the legal number of specific header fields.

Yet RFC822, which was the first standard for Internet mail format, also requires only and exactly one From: field.

The blog also makes some recommendations that DKIM contain controls in the use of Internationalized Domain Names, again seeming to reflect the desire to have DKIM ensure perfect messages.

Ultimately, the view expressed in TrendLab’s blog is a bit like looking for lost keys under the lamppost. It’s so much more convenient to see things there, that it is easy to miss the fact that it’s not the right place to look.

The blog ends with an uncharacteristic bit of hyperbole from a commercial company:

The decision to ignore additional From header fields prepended to an email and yet still return a valid signature result (the only output of DKIM) makes this an EVIL protocol.

Not too many protocols get the honor of such an assessment. Now, if only they had meant the reference to be to the Evil Bit...