1

From RFC6376 #page-29, it says:

In hash step 1, the Signer/Verifier MUST hash the message body, canonicalized using the body canonicalization algorithm specified in the "c=" tag and then truncated to the length specified in the "l=" tag.

From Wikipedia DomainKeys Identified Mail, it says:

Both header and body contribute to the signature. First, the message body is hashed, always from the beginning, possibly truncated at a given length (which may be zero)...

  1. What's the default value of the l= tag? Does the whole message body get hashed? If not the whole body message get hashed, then may an attacker modify the unhashed part of the body message and pass DKIM check?

From Wikipedia DomainKeys Identified Mail:

....No data integrity is implied.

From RFC6376 #section-1.5:

Verifying the signature asserts that the hashed content has not changed since it was signed and asserts nothing else about "protecting" the end-to-end integrity of the message.

  1. Why is it saying that DKIM doesn't ensure data integrity? Isn't "hashed content has not changed" == "data integrity"?
3

There is no default value of length. As the RFC explains, the length is calculated by an algorithm.

The reason why there is a defined length is that email servers in the relay chain may add to the body. If the entire body was signed and an email server added to the body, then the signature check would fail.

So, the signing process protects the original message (up to the calculated length) but not the final message received. That's why it is not seen as an integrity-protecting measure.

  • Oh, great! Then my 2 questions can be well explained based on your answer. So DKIM eventually does not protect the content right?(Because I've read so many articles saying that it protects the content :( ). – Rick Jun 17 at 9:32
  • 1
    It can protect the original content, not the received content. – schroeder Jun 17 at 9:33
  • But only the original content (up to the calculated length) like you said ? An attacker may modify uncalculated part and pass DKIM check. – Rick Jun 17 at 9:35
  • If DKIM can't protect data intergrity (so now it can only be used to prevent From headers spoofing), what's its advantage compared to SPF? I mean, SPF check + DMARC is already enough, why need DKIM + DMARC ? – Rick Jun 17 at 9:43
  • 2
    @Rick: DKIM is more robust against typical mail forwarding. This usually tries to keep the senders MAIL FROM but changes the senders IP, which then causes SPF to fail. DKIM has other problems (like with message recoding on the way due to no 8BITMIME). That's why DMARC says either DKIM or SPF, but does not have any preference nor requires both. – Steffen Ullrich Jun 17 at 11:06
0

The l parameter on DKIM is a design error of the protocol, if your MTA receives messages with the l parameter you better reject that messages because you can not verify the integrity. Imagine a l=1 for example, verify just one byte? have no sense, if you want to check the integrity of a file for example, you check all the file, you don't guarantee just half of the file. You can think in a DKIM header with an l=1 and inserted a virus on the message just after that byte specified on the l parameter, the verification will pass and you will get at message with a virus on it for example.

  • 1
    I agree that l is a design error. But rejecting any message which has l is wrong too - especially since this attribute is used by several relevant companies like DHL or Cisco. And note that the attribute is part of the DKIM signature, so an attacker cannot simply change it to something he likes. Apart from that - I know of a domain which uses l=10 on all mails, no matter what size the mail has. This can be definitely abused. – Steffen Ullrich Jun 17 at 11:12
  • Messages that are using l=X are candidates to be modified in transit, so basically breaking DKIM integrity, and allow attackers to get the message and add to them any type of malicious content. The decision of reject the messages depends also in other factors and depends of course of the source as you mention. – camp0 Jun 17 at 12:10
  • It might be more wise to strip everything after the part included by the body hash when displaying the message. Apart from that the integrity is usually broken anyway since 99% of the DKIM signatures I analyzed allow changing or adding critical headers like Content-Transfer-Encoding, Content-Type, Subject ... which might result in a different message displayed than intended. See my research at noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html for more. – Steffen Ullrich Jun 17 at 12:15
  • Nice doc Steffen thanks! Remove the content that is not part of the DKIM signature by using the l is a solution, you can always have the doubt if the l is due to a miss configuration or intentional. – camp0 Jun 17 at 12:19
  • @SteffenUllrich Wow, I read your research and it helps clarifying some doubts of mine. I didn't know email headers can be used in a way like this to fool a client. And indeed, like what you said, DKIM doesn't ensure the content is trustable. Danke schon ;-) – Rick Jun 17 at 15:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.