DKIM: Useless or just disappointing?

DKIM: Useless or just disappointing?

Summary: Now that DKIM is established as the leading method for sender authentication, it's clear that it doesn't really claim to do all that much, and fails even at that.

SHARE:

Spam is perhaps the oldest of security problems affecting Internet users widely. A lot of effort has been put into fighting it, and yet it persists. Even the most advanced of standards for combating spam fails in the face of a simple spoofing attack. There's probably nothing that standards bodies can do that will make a real difference.

The original designers of SMTP neglected to include any method for authenticating the sender of an email message. By the time it became clear something had to be done, SMTP was so widely deployed that changes became difficult. Any mandatory change would break existing mail software, so it would have to be optional.

A lot of work was done on this problem 5 to 10 years ago and one standard emerged as the gold standard: DKIM (DomainKeys Identified Mail), a synthesis of standards from Yahoo! and Cisco, both motivated to improve on the popular, but very limited SPF standard. A newer standard, DMARC, attempts to synthesize both SPF and DKIM into a set of consistent procedures in order to facilitate interoperability.

DKIM attempts to allow a recipient to verify that the domain from which the message is purported to originate is in fact the sender of that message. The sending domain digitally signs the message and specified parts of the message envelope using a private key, and puts the signature into a "DKIM-Signature" field. The recipient reads this field, which includes the name of the purported sending domain, and retrieves that domain's public key from the DNS. It uses this to verify the signature against the contents of the message. This proves both that the message was in fact sent by the domain which claims to have sent it and that the signed parts of the message were not modified in transit.

Dave Rand and Doug Otis of Trend Micro argue that a weakness in the specification means that end-users can be effectively spoofed by messages that pass all the tests in DKIM. If you "prepend" a second From: field in the header, the user may see that one.

By default, under the spec, DKIM doesn't sign or check signatures on most parts of the envelope (i.e. message header elements like these), but the sender can specify that they are signed with (for example) an 'h=From:;' in the DKIM-Signatures header. Consider this scrap of message header:

Date: Thu, 8 Aug 2013 21:44:28 -0700 (PDT)
From: Barack Obama <barack@whitehouse.gov>
From: Random Spammer <rndmspmr_098435@yahoo.com>
Reply-To: Random Spammer <rndmspmr_098435@yahoo.com>
Subject: Awarded a Pulizer for "DKIM is Harmful"
To: "Joseph Shmoe" <joe.shmoe@gmail.com>

Note the two From: fields. If such a message is sent to DKIM with 'h=From:', both fields may be included in the signature (the standard isn't clear on the matter), and the end user may see the first one. In other words, the recipient (Joe Shmoe) may see a DKIM-verified message coming from barack@whitehouse.gov. Incidentally, you can also insert multiple To: or Subject: fields and these may also result in misleading behavior.

But it's worse than that. Because DKIM only signs the specified parts of the message, the message can be forwarded on by an intermediary that inserts the extra fields, and the signature will still match. This is called a replay attack.

The importance of this replay attack is hard to understate. Because it can be done, not only may the user be fooled by the spoofed From: address, but the DKIM engine is fooled by the signature. In the above example, GMail receives the signed message with a signature from Yahoo! that will match when GMail checks it. But the message wasn't actually sent by Yahoo; it was resent by some other domain controlled by a spammer which pre-pended other fields. So even the domain authentication isn't what it claims to be.

Otis and Rand's objections haven't impressed the DKIM standards bodies. Their response is that checking for multiple header fields is not a test properly done by DKIM, but at some other level of the email software stack. It's also worth pointing out that messages with multiple From: or other such fields may or may not be legal under the "Internet Message Format" standard (RFC 5322) set as a prerequisite by DKIM. Dave Crocker of Brandenburg InternetWorking, an author of many of the DKIM specs, tells me that it is not compliant, but it's not clear to me from the spec whether it's not compliant or just not addressed.

Otis raised these objections 2 years ago at an early stage of the DKIM Working Group's deliberations on the standard for DKIM signatures.. You can see how it went in this blog post by Otis and the comments below it, including one from Crocker. This dispute re-emerged recently when the IETF accepted RFC 6376 (DomainKeys Identified Mail (DKIM) Signatures) as an Internet Standard. Otis and Rand appealed the elevation of RFC 6376, laying out their arguments in this document: DKIM is Harmful as Specified. The IESG (Internet Engineering Steering Group) rejected the appeal for essentially the same reasons the DKIM working group rejected it.

Otis and Rand argued un their appeal that a one-line change to the spec, requiring a check for multiple headers, would solve the problem. DKIM software already has to read and check all the headers anyway, so it wouldn't be much of a burden on the implementation. The DKIM standards bodies were not moved.

If you read the various discussions on the matter, especially those outside of formal standards documents, you can see that the participants get really worked up. The raised voices come through clearly, even without the use of caps lock. Rand tells me that the influence of large e-mail senders, whose interests might not coincide with those of recipients, is too great in this debate. The big mass-mailers certainly want to be able to get their messages through without any problems, so they would prefer a simple, lenient standard.

I'm uncomfortable thinking of Crocker and some of the others on the DKIM WG as flunkies for mass-mailers. In fact, all of the people I've spoken to about this have long histories volunteering time to work on Internet standards for the benefit of all of us and I don't believe for a second that any of them are selling out. 

On the other hand, both sides can't be right. When it comes to facts on the ground (or in the cloud), Otis and Rand have a really good point. Whether the IETF is correct that From: header checking doesn't belong in the DKIM spec or not, the fact remains that you can easily spoof the From: field in a fully-compliant DKIM-signed message that passes all the tests. 

So how can this be? Wasn't DKIM supposed to stop this sort of thing? No, it wasn't.

When the efforts to create sender authentication began about 10 years ago we all expected a lot more from it. As the years wore on and the true complexity of the task became clear, the scope of what DKIM actually does narrowed considerably. Here's what it tries to do: To validate that the domain which purports to send the message actually sent it.

That's it. This is information designed for back-end server processes, not end users. End users can assume *nothing* based on whether an individual email was validated under DKIM. The message could easily be a phishing attack or contain a malicious attachment or have a malformed header designed to spoof the identity presented to the end users. None of this is DKIM's problem.

You might think that a message which fails DKIM checks is clearly a problem; in fact, RFC 5863, DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations states that '…messages with invalid signatures need to be treated no better and no worse than those with no signature at all'. A message with no DKIM signature would seem to be one which is harder to assess by back-end analysis engines. Even by design, a single message which passes DKIM tests provides no useful information about the reputation of the sender or safety or accuracy of the message content.

Early on, some mail clients, especially web mail clients, displayed a little shield or something similar as a 'trust marker' when a message passed DKIM. The ones I've checked don't do that anymore, and for good reason: End users can't do anything with that information other than to make too much of it.

You might be thinking that DKIM sounds kind of useless, but perhaps we're just expecting too much of it. If we just lower our expectations and look on DKIM as a tool use by other back-end analysis engines to judge the reputation of sending domains, perhaps it could be useful. If you look at a lot of email over time that DKIM has validated as coming from that domain, the idea is that you can be sure that it really is from that domain and judge the domain's reputation. This would be helpful input for an email analysis engine if you really could trust the domain authentication, but the replay attack above shows that you can't.

IETF documents don't even tell administrators to be careful with the results of DKIM checks. They say to whitelist whole domains based on reputation and to judge whether a message has come from that domain based on DKIM. Section 5.4 of the aforementioned Development, Deployment and Operations document states:

DKIM is frequently employed in a mail filtering strategy to avoid performing content analysis on email originating from trusted sources.  Messages that carry a valid DKIM signature from a trusted source can be whitelisted, avoiding the need to perform computation and hence energy-intensive content analysis to determine the disposition of the message.
Mail sources can be determined to be trusted by means of previously observed behavior and/or reference to external reputation or accreditation services.  The precise means by which this is accomplished is outside the scope of DKIM.

And this is what large sites are doing today: They are whitelisting certain other large sites which they decide are trusted and then letting messages pass through unscrutinized if they contain a valid DKIM signature from one of the whitelisted sites. This leaves open the possibility of retrospective analysis of those messages that might affect the domain's reputation, but it still doesn't make sense. With the replay attack, the domain specified in the DKIM signature is an innocent bystander, and there's no sense in diminishing its reputation.

This is why Otis and Rand go beyond calling DKIM 'useless' and use words like 'harmful'. Trend Micro is a major provider of email security services and they say they are seeing messages performing exactly this sort of abuse out in the wild.

Even if DKIM performed as advertised, with the modest claim of sender domain authentication, I'd have to call it disappointing and of speculative value. But it doesn't perform as advertised, and when administrators follow the guidance in the Development, Deployment and Operations document it can be far worse than disappointing.

Clearly the problems which cause DKIM to be unreliable aren't addressed in any Internet standard and they probably can't be. Only proprietary implementations of email security products can look for things like double From: headers. Standards, and especially sender authentication standards, have failed us.

Topics: Security, Enterprise Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

30 comments
Log in or register to join the discussion
  • DKIM does its job quite nicely, thank you.

    The headline for the article is more disappointing than DKIM. DKIM does its job. It performs a simple, basic task: It affixes a valid identifier to a message; with this, mail receiving sites can build a reliable reputation assessment for the owner of the identifier. This permits their filtering engines to make reliable choices for handling the stream of mail with that identifier.

    The major failing of DKIM is in the misalignment of people's expectations for it, thinking that it validates the message content or its author. It doesn't seek to perform such validation, so no surprise is doesn't 'succeed'. (DMARC, on the other hand, does certify a portion of the From field, but DMARC works for only specific scenarios.)

    Other misalignments dominate discussions of online abuse. A common example is thinking that email (SMTP) should have been developed with the requirement that the author always be validated. This does not match any other form of human communication -- not postal and not telephonic, for example. We need to stop assuming that there are simplistic technical solutions to these complex, social misbehaviors.

    As for the Otis/Rand concern, there is a bottom-line approach to considering their persistent efforts: MANY different (and entirely independent) technicians have repeatedly reviewed their concern and found it wanting. That they choose to resort to claims of big-company conspiracy emphasizes the weakness of their concern's technical merits.

    As for details in the article, there are a number of mis-steps, but the biggest is the technical assertion: "The importance of this replay attack is hard to understate." In fact the importance is far too easy to overstate. If the DKIM identifier is affixed to the message properly, then basic modifications to the signed portions will break the signature. If they are not broken, that content is unchanged. Re-sending the message will either break the signature or will retain the validity. Concerns about replay are based on a misunderstanding of what DKIM is doing: it's giving the filtering engine a reliable identifier. The replay doesn't change that, unless it then breaks the signature.

    d/
    davecrocker
    • You don't have to break the signature to replay it

      You can add a second From: header and it will still pass the signature test. Doug Otis demonstrated this to me.
      larry@...
      • One more time

        Repeating the same point does not make it relevant. Once again: DKIM doesn't certify the correctness of the From field. Having more than one that might be incorrect is no worse than having one that might be incorrect.

        Your response to Murray continues to miss the very basic point that DKIM is not certifying the content, any more than SSL is certifying the content, yet you are somehow holding DKIM accountable for problematic message content.

        Worse, your comment "fool DKIM into validating some domain" means you are misunderstanding, in spite of your article's correctly noting the DKIM-Signature field. That's where the validated identifier is taken from. If the identifier in the DKIM field validates, then it is valid, whether the note has been forwarded (re-sent, replayed, whatever) or not. If it doesn't validate, then any supposed fraud attempt has failed, hasn't it?
        davecrocker
        • not From:, but d=

          When I say it certifies a domain, i don't mean the From: field, but the d= field in the DKIM-Signature header. If DKIM doesn't actually certify that, then it certifies nothing. And yet, the replay attack makes it possible that the actual sender is not the domain in the d= field. I do say this in the story.
          larry@...
          • Valid validation

            OK. So yes, we are all talking about DKIM's d= value and not the From field. However your statement "makes it possible that the actual sender is not the domain in the d= field" highlights the disconnect: DKIM NEVER ASSERTS THE VALIDITY OF THE FROM FIELD. What you've written seems to indicate that your use of "sender" here means the author or their organization.

            While those folk are certainly allowed to sign, they aren't the only ones who can (and do) sign, and the semantics of a DKIM signature don't mean "author or author's organization". My own preference is to avoid using the word 'sender' because it's meaning has become so confused. For DKIM, perhaps a more useful term is "handling agent", that is anyone who touches the message along the path. DKIM provides reliable accountability for a handling agent.

            To your concern about replay: if the signature remains valid, then the replay essentially means that the signed message has been sent to an additional addressee? Since DKIM doesn't validate the address list, this doesn't render the meaning of the signature invalid.

            As for your comment "DKIM Deployment... instructs users to whitelist messages... of sufficiently high reputation", the document says "can", not should or must. That is, it notes an option available, rather than directing its use. And to be less linguistically picky, I'll note that giving preferential treatment to content deemed to be associated with good actors is rather the point of this whole exercise. So I'm not understanding your concern.

            If an actor of good reputation has signed the message, why wouldn't you want to give the message better treatment?

            If the argument is that it as "replayed" to a different addressee than it was originally sent, then the real issue here isn't with DKIM but with author/recipient combinations evaluated by the filtering engine. And that is far, far beyond the scope of DKIM.

            d/
            davecrocker
          • Unprotected trust in DKIM

            We have one of the worlds largest spam repositories and see a bit more than others. Two hacks introduced to DKIM were double listing of singleton header fields as “signed” and the recommendation for subsequent header stack validation. These hacks are not being implemented to any extent. As a result, message spoofing remains easy and puts at risk ANY DKIM trust that is unseen when it happens.
            Currently, DKIM offers a token for white-listing trusted domains to ensure inbox placement as defined in RFC5863. While a popular “working” function, this can be exploited to have phishing messages delivered to inboxes by bypassing content filtering. This content might include injected clickable Subject or misleading From header fields. All too often, trust is placed in domains considered too large to block as a means to counter bayesian poisoning issues. This “working” mechanism creates a fairly wide-spread vulnerability placing millions of users at risk!
            Dave Crocker said: “I'll note that giving preferential treatment to content deemed to be associated with good actors is rather the point of this whole exercise. So I'm not understanding your concern.”
            To clarify, the described exploit is able to take advantage of the desired preferential treatment by injecting content that does not affect DKIM signatures and is yet normally allowed by most implementations. In other words, DKIM fails to safeguard preferential treatment that it permits. It is also disingenuous to then claim some other protocol is somehow responsible which is never named or defined. DKIM’s promotion to Internet Standard should have included a review of the implementation or the omissions of these needed hacks. This check was ignored so on paper everything looks okay. It is not.
            Douglas Otis
          • Internet Standard

            >> These hacks are not being implemented to any extent.

            I suppose that means that there is no evidence that it's necessary. Perhaps the wide-scale whitelisting being claimed isn't happening after all, because operators are smarter than that.

            >> DKIM’s promotion to Internet Standard should have included a review of the implementation or the omissions of these needed hacks. This check was ignored so on paper everything looks okay. It is not.

            For the record, Mr. Otis appealed the advancement of DKIM to the status of "Internet Standard" based on the complaints he has with the protocol, of which he appears to have convinced Mr. Seltzer. The IESG, as a result, conducted a careful review of both the new and old material Mr. Otis presented both in his appeal and back in the working group days, and heard feedback from the community as well. The result of this appeal is a matter of public record (see https://www.ietf.org/iesg/appeal.html), and I find it stunning that he can make this "should have included" claim when in fact the review was quite obviously thorough, if not tedious.
            msk2
  • This again?

    As someone who was involved with DKIM's development roughly since its inception, I found this pretty hard to read. There's a lot of information provided here that's simply wrong. I'm a little amazed that this is the case given that you spoke to Mr. Crocker who was also around since the beginning.

    I'm not sure where to start. I think perhaps the biggest missed fact here is that the working group that developed DKIM never claimed that the double-From issue was not a concern. Rather, they were "not moved" because changing DKIM to deal with it is quite simply the wrong place to fix the problem. It would make as much sense as saying the SSL (transport-level encryption) code should also check to make sure that web page content you're receiving is properly formed before agreeing to decrypt the content. I would hope you and your readers realize that's nonsense.

    Mr. Otis brought his concerns about this issue to the DKIM working group, which understood the concern but disagreed with his proposed fix. Instead, it added a lengthy subsection to the standard under Security Considerations that explained the risk and proposed one possible mitigation. So in the end, we were "not moved" to solve the problem his way, but the issue was not ignored. The real problem lies in the fact that the system attempting to do DKIM validation is careless about what it accepts. Thus, the right fix lies in that segment of the system.

    The article also makes several claims that DKIM confirms that the content of a message came from whoever signed it. This isn't the case. Anyone can sign anything. DKIM, in that sense, is akin to a postmark indicating the post office(s) through which a message traveled. It may be the case that a DKIM signer was the same domain owner as the author of the message, but it might not be. But this is a remarkable thing: Given that there's no actual authentication of any part of the content of an email message in conventional SMTP, DKIM adds an identifier (a domain name) to a message that's actually verified somehow. We haven't had that since email's inception decades ago. It is this that cannot be understated.

    As to the claims that it is not useful, this too is false. There has been some work on correlating DKIM signatures with spam or phishing content (not whether it was signed, but specifically who signed it). It has led to some experimental but promising reputation-based filtering systems. Imagine if you could see the path all of your postal mail takes to get to you, and observe that all of the mail you really want tends to arrive via a few specific postal facilities or delivery services. You could sort your reading based on this information, giving you the good stuff first, and be more cautious about how you handle the rest. This R&D is ongoing, but without DKIM, it can't happen.

    Unchecked whitelisting of anything carries inherent risks. I find it hard to believe, then, that large scale email operators (since I work with many of them) are plainly passing messages signed by the big domains like "gmail.com" directly to user inboxes. I would believe that they undergo less scrutiny, but I can't accept that they actually receive none as is claimed here.

    These criticisms of DKIM have been discussed for years now and routinely end at the same place: They're not valid. It's a shame that they continue to receive any kind of audience.
    msk2
  • Yes, again

    Your SSL counter-example is not apt; malformed content in the message doesn't defeat the purpose of SSL, as a double From: header does with DKIM.

    As for gathering reputation on the validated domain, you can't do that reliably if replay attacks can fool DKIM into validating some domain other than the actual sender. Clearly this is possible and Otis says that Trend Micro's systems are detecting this technique in the real world.

    >>The article also makes several claims that DKIM confirms that the content of a message came from whoever signed it.

    Where did I say that?

    >>I find it hard to believe, then, that large scale email operators (since I work with many of them) are plainly passing messages signed by the big domains like "gmail.com" directly to user inboxes.

    Maybe they're doing it because the DKIM Deployment, Development and Operations document instructs them to.
    larry@...
    • FUD

      >> Your SSL counter-example is not apt; malformed content in the message doesn't defeat the purpose of SSL, as a double From: header does with DKIM.

      As I stated (and Dave did as well), that isn't the purpose of DKIM.

      DKIM allows a recipient to verify that the domain in the signature handled the message. It also confirms that between signing and verifying, the signed part of the message was not altered. DKIM itself has nothing whatsoever to do with confirming the purported sender. They are sometimes (maybe often) the same, but not always. That's a leap of logic that isn't in the document defining DKIM.

      Mailing lists sign their content. The DKIM signing domain and the From: domain will almost always be different in that case. Does that mean DKIM is useless in that application?

      Now, it may very well be the case that some of the informational material to which you refer, now a few years old, is no longer in line with the best current practices in terms of DKIM use. If that's the case, I agree that the community should look at updating it. But this is decidedly not the same as claiming the protocol is broken or disappointing. Quite the contrary: It has been shown to provide useful signal to abuse filters.

      But back to the SSL analogy: SSL can validate a client as easily as it can validate the server. You could, therefore, use it to confirm that a message was encrypted with my key, even if the actual content claims something else entirely. Do you also claim, then, that SSL is useless or disappointing?

      >> As for gathering reputation on the validated domain, you can't do that reliably if replay attacks can fool DKIM into validating some domain other than the actual sender. Clearly this is possible and Otis says that Trend Micro's systems are detecting this technique in the real world.

      DKIM doesn't validate senders as you're using the term. In your double-From example, it validates neither field, except to assert that the second (original) one was not altered in transit. DKIM doesn't say anything about the "truth" of what's in that field.

      There's an experimental existence proof against your claim about reputation. More generally, the point of such a system is not to confirm anything about the actual sender, but rather to observe and then estimate the quality of messages normally associated with that domain's signature (or, indeed, the absence of a signature).

      When Mr. Otis made his claim that this is a live attack, I began collecting my own data. I haven't observed a single instance of this as an attack in the wild. Rather, a double-From is invariably the result of something broken, not something malicious, and is exceedingly rare. I don't claim to have a sensor network anything like what Trend Micro does, but don't you think I should be able to see it at least once in the last couple of years?

      >>> The article also makes several claims that DKIM confirms that the content of a message came from whoever signed it.

      >> Where did I say that?

      You said, "DKIM attempts to allow a recipient to verify that the domain from which the message is purported to originate is in fact the sender of that message."

      It does no such thing. It's clear by now that that's what everyone wishes it did, but that isn't the case.

      >> Maybe they're doing it because the DKIM Deployment, Development and Operations document instructs them to.

      Given that most of the large receivers I can think of were also in the room as we were developing DMARC, and are thus very aware of what DKIM does and does not accomplish, I have some doubt that there's any truth to this claim, at least among that set. Have you confirmed independently that any large email receiver is using a valid DKIM signature as an instant go-ahead to inbox delivery?
      msk2
      • d= in DKIM-Signature

        No, it doesn't. Correct me if I'm wrong, but you're talking about the d= field in the DKIM-Signature header, and even that is not reliable.

        >>Have you confirmed independently that any large email receiver is using a valid DKIM signature as an instant go-ahead to inbox delivery?

        Independently, no I haven't and without seeing their actual policies I don't know how I could. I will ask them, not that I expect a response. None of this changes the fact that the DKIM Deployment, Development and Operations document instructs users to whitelist messages based on verification that the DKIM signature matches a domain of sufficiently high reputation.
        larry@...
        • Google's response

          I asked Google if they "whitelist messages which have a DKIM signature that matches that of a domain with sufficiently high reputation".

          Their response: "DKIM reputation is just one of a number of factors we take into account when whitelisting."

          This sounds like "no" although I think it's technically ambiguous.

          I also asked Yahoo and haven't gotten a response yet
          larry@...
          • Whitelisting

            I'm reasonably certain that Facebook doesn't whitelist either. Their answer is very likely the same as Google's; it's one of several inputs to the ultimate verdict about the message.

            The most popular open source implementation of DKIM adds a header field to the message indicating the DKIM status, and lets internal components decide what to do with the message based on that. Once again, just one of several inputs.
            msk2
      • DKIM at the very minimum must sign the From header field and nothing else

        Unlike Larry, I am more confident DKIM can be salvaged provided it does not remain handicapped by ill considered concerns of propriety overriding protections. RFC3439 update of Architectural Principles of the Internet, section 2.1clearly states the End-To-End argument. Since DKIM depends on a valid header field structure, it should not expect message validation a property of some underlying transport. In addition, SMTP RFC5321 clearly indicates it should not reject messages based on message structure.
        When the issue of spoofing with prefixed From/Subject/Date/Reply-To/To/CC/Message-ID/In-Rely-To headers was raised as an issue, the WG offered a kludgy hack where non-existing header fields were to be optionally listed as being part of the signature so as not to change the DKIM specification that would have reset the wait for standardization. Unfortunately, this hack does not offer protection as it depends on ALL "trusted" domains adopting this practice since DKIM signatures are not visible. Few domains ever will implement the hack where double listing is seen as unnecessary overhead.
        DKIM results can not be used in conjunction with reputation without re-evaluation of the message which is another hack added to DKIM. Another hack not likely adopted. It is absurd to claim spoofing does not or will not occur and therefore concerns about this gap in protection is simply FUD. Our data destroys that illusion and we see this abuse growing.
        Douglas Otis
        • FUD indeed.

          There's a number of things wrong in here. More FUD.

          1) DKIM depends on a valid header structure. That's correct. However, it sits atop mail transport, and that's the layer where bogus header structure is more appropriately detected. The architecturally better decision is to spot bogus structure there and not even bother invoking the DKIM validation code. Requiring DKIM to enforce the rules of layers below it is simply a poor design choice.

          2) SMTP rejection of an invalid message format is not proscribed outright by RFC5321 (the end of Section 3.3, to be precise). The text is "SHOULD NOT", which is IETF parlance for "unless you have a very good reason for doing so." If the danger of this "hole" in DKIM is as enormous as is being claimed, then it strikes me that receivers do indeed have a very good reason.

          3) I think advice about a "kludgy hack", which actually has been demonstrated to solve the claimed problem, is far better than an architecturally wrong solution. (And, if it's not obvious already, I disagree with that characterization.)

          4) I don't understand the claim that all "trusted" domains have to adopt this practice. If a signer is worried about this attack, it uses the technique described, and that's it.

          5) The "unnecessary overhead" amounts to a flag in a library call, and five additional bytes passed to the hash algorithm. This claim is just hyperbole.

          6) Reputation with DKIM works fine, at least experimentally.
          msk2
          • The security hole is caused by DKIM

            RFC3439 offers better advice on architectural strategies. The transport is NOT the place for message content validation! It is wrong to assume the SMTP transport ensures an evolving message structure. To be robust DKIM and not the transport depends upon proper message structure anyway. This structural dependence protects provenance of extended message handling based on DKIM’s signed message fragments. Many large providers managed by seasoned professionals are making the same misguided assumption. Since DKIM claims message structure must be valid, it seems many assume when a DKIM signature is annotated valid, so must the message structure. Unfortunately, this represents a dangerous and likely invalid assumption placing many large providers at risk.
            Since DKIM must process the entire header field stack from top to bottom and then from the bottom up, many may expect the DKIM verification process concludes when an invalid header field stack is detected. This is how DKIM should have been specified instead of the seldom used RFC6376 section 8.15 hacks. The security hole is caused by DKIM and should be handled by DKIM.
            It is foolish to debate politics. The mistake was to suggest seldom employed optional hacks. This provides recipients virtually no protection from simple exploitation enabled by DKIM’s preferential handling. Since recipients are unaware when special handling occurs, any “trusted” domain may place any singleton header field that purports to be of any domain at risk. Since few domains bother to ensure message structure via 8.15 hacks, this option places all DKIM trust at risk.
            Douglas Otis
          • Still not right

            >> Since DKIM must process the entire header field stack from top to bottom and then from the bottom up, many may expect the DKIM verification process concludes when an invalid header field stack is detected. This is how DKIM should have been specified [...]

            That is how DKIM was specified. Section 3.8 says:

            "Accordingly, DKIM's design is predicated on valid input. Therefore, Signers and Verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322], [RFC2045], and any other relevant message format standards."

            This is indeed a foolish debate, but it's not about politics.
            msk2
  • d= in DKIM-Signature

    >>DKIM allows a recipient to verify that the domain in the signature handled the message.

    No, it doesn't. Correct me if I'm wrong, but you're talking about the d= field in the DKIM-Signature header, and even that is not reliable.

    >>Have you confirmed independently that any large email receiver is using a valid DKIM signature as an instant go-ahead to inbox delivery?

    Independently, no I haven't and without seeing their actual policies I don't know how I could. I will ask them, not that I expect a response. None of this changes the fact that the DKIM Deployment, Development and Operations document instructs users to whitelist messages based on verification that the DKIM signature matches a domain of sufficiently high reputation.
    larry@...
    • Large email receiver chiming in...

      I'll save you some of the trouble of reaching out.

      We employ DKIM on the inbound side and do whitelist certain entities. The purpose of this is to ensure that legitimate traffic from highly phished organizations like banks, eBay, paypal make it through while the targeted phishing stuff does not. By whitelisting these entities and their d= domain our spam/phishing filters can go to 11 to combat the phishing threat because we have a reasonable expectation that the legit stuff will get through.

      Do we whitelist everyone with a valid DKIM signature? No way. It's not appropriate to whitelist a DKIM signer who does not have control over their outbound email flow like gmail or other customer email service providers. They'd have a low reputation as all/most of their outbound traffic is user generated.

      But, that goes to the point of what the DKIM Deployment, Development and Operations document says, that the DKIM signature matches a domain of sufficiently high reputation. It's not saying whitelist all the things, it's saying whitelist ones with a high reputation.

      Where this does fall short though in my opinion is that currently there is no one that I'm aware of that is building an independent DKIM domain reputation database like spamhaus has done for IPv4 addresses. So, it's up to the individual large email receiver to assign reputation to the traffic they see. But, that's a solvable problem and not a fundamental issue with how DKIM is implemented.

      Oh, and were we seeing illegitimate stuff get through because of the multiple from issue (we're not) we'd likely reject the message outright as while it might be technically legal from the SMTP RFC standpoint (again, unclear) it's suspicious as hell and there's no real legitimate use case.

      Anyways, we find it quite useful for it's intended purpose.
      spaceherpes
      • DKIM as defined can not be safely used with reputation

        This goes to the root of the problem. We started the first email reputation service. We _can not_ create one for DKIM as it exists today. There is simply no way to trust the d= field in the DKIM signature.

        We can not use it for positive reputation. We can not use it for negative reputation. We can not use it.

        Because it can be trivially exploited and replayed billions of times, any analysis of the d= field is so cluttered with noise as to be unusable. A "good" reputation domain can be hammered by a spammer replaying their signed content with a pre-pended clickable Subject: header field (for example).

        Again, this is fixable. But it depends on DKIM actually taking "bad input" into account, and rendering a "DKIM fail", rather than "DKIM pass".

        Giving this problem to "some other" (un-named, un-designed, and un-deployed) software is just wrong. Definitely it is wrong to assume message validation is done by the transport. See RFC1958 and RFC5321.
        Douglas Otis