3

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"?
Community
  • 1
Rick
  • 1,027
  • 1
  • 8
  • 21

2 Answers2

3

There is a default value of l:

From https://www.rfc-editor.org/rfc/rfc6376#section-3.5 :

l= Body length count (plain-text unsigned decimal integer; OPTIONAL, default is entire body).

Of course the default should be the entire body. Or what else is DKIM protecting? I write an email and DKIM says "OK I only protect half of your email"? And then Gmail receives the email and warns the user "Dear Bob, the first 100 bytes of this email is validated. But for the rest, I can't promise." ?

Again, if the default is not the entire body, then when a user writes an email, how would he know how many characters he should write?

And I disagree with @schroeder 's answer.

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.

If a mail relay or intermediate server change the original email content, the DKIM signature would fail and should fail. And that's why there are other mechanisms invented to get around with this, e.g. ARC (authenticated received chain).

Community
  • 1
Rick
  • 1,027
  • 1
  • 8
  • 21
  • After more digging, I see that `l=` is not dynamically calculated in practice (Exchange does not). So, you are correct on that point, but your thought experiments on the reasons why don't hold water. a) Yes, one of the well-identified weaknesses is that if you set `l`, then only part of it gets signed. b) many MTAs are well-known to add to email bodies, so the default will get the email rejected, meaning that if you set it to `l=0`, which is what Exchange suggests, then the body is not checked at all. to provide *some* body hashing, then, yes, you sign only part. – schroeder Apr 26 '20 at 11:38
  • You don't write the body to the length of `l`, you calculate automatically calculate the canonicalized length to the message body. – schroeder Apr 26 '20 at 11:39
  • So, the default is to protect the body. In practice, that option is often turned off. – schroeder Apr 26 '20 at 11:43
  • @schroeder Yes I totally agree that "*You don't write the body to the length of `l`, you calculate automatically calculate the canonicalized length to the message body.*". Becasue whenever you give a value to `l`, you are giving a **defined value** to `l`, while **the entire body** is not a "defined value" as for the receiver. – Rick Apr 26 '20 at 12:03
  • But I don't understand the `b)` example of your comment. Exchange suggests setting `l=0`? I don't get it. Whatever, I am glad that we get this done.Cheers :P – Rick Apr 26 '20 at 12:07
  • 1
    The problem with DKIM is the MTAs between the sender and recipient. they like to add "stuff" to both the headers and the body (like disclaimers, ads, formatting, etc.). Exchange, and many other experts, suggest simply setting the length to 0 to deal with these situations. – schroeder Apr 26 '20 at 12:16
  • As DKIM should be considered as SPAM prevention mechanism only, not a true digital signature, I think it makes lots of sense to use `l=0` and sign only `Message-Id` and `Date`. That avoids all mail getting broken by old school mailing lists that prefix the subject or body with some list specific text. Spammers would need to re-use `Message-Id` with original `Date` to reuse the signatures. If you want real security, you have to use S/MIME or OpenGPG instead. – Mikko Rantalainen May 09 '22 at 12:00
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 those messages because you can not verify the integrity. Imagine a l=1 for example, verify just one byte? That makes no sense.

If you want to check the integrity of a file for example, you check all of 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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
camp0
  • 2,172
  • 1
  • 10
  • 10
  • 2
    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 '19 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 '19 at 12:10
  • 1
    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 https://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html for more. – Steffen Ullrich Jun 17 '19 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 '19 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 '19 at 15:10