Subject: Re: [ietf-dkim] Seeking Clarification of the l= Tag

From: Pawel Lesnikowski <[email-masked]>
Date: Sun, 4 Aug 2013 22:35:03 +0200

There are few details I'd like to clarify.

Body hash for this message is correctly computed by the sender.
Entire signature of this message in fact valid - this is why Port25,
Gmail, and Mail.dll validate DKIM signature with 'pass' result.

The only problem is the value of l= parameter of DKIM-Signature header (l=2).
The value is greater than total number of bytes after body
canonicalization (0 bytes).
This is easy to spot and all parsers simply ignore incorrect l= value.
Hash is computed for entire canonicalized body (of length 0).

Now the question is should the validation fail or pass in such case?

--
Best regards,
Pawel Lesnikowski
http://www.limilabs.com
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Sun, 04 Aug 2013 18:18:29 -0400

> Now the question is should the validation fail or pass in such case?

As a general protocol design question, from a security standpoint it 
will always be better to treat ERRORS as a failure. We should not make 
room for "excuses."  Such known software logic kludges and exceptions 
will be exploited if allowed to exist.

<extra input>
I don't think "all parsers simply ignore incorrect l= values" at least I 
don't believe our design implementation doesn't contain such kludges to 
ignore l= values under certain conditions.  So it will be a failure in 
our implementation.

This sounds familiar to me, it was discussed various times regarding 
some implementations or middle ware alterations.  There were/are known 
software situations where legacy <CR><LF> characters are remaining 
during parsing.  There was much adequate testing done over the years by 
many implementators and especially against popular DKIM auto-responders 
such as [email-masked].  So folks were aware of some software 
that needed to be updated.

It will be better perhaps to show specific cases of where there are 
interop problem (e.g., someone has a bug) so it can be possibly 
acknowledged and addressed.  Such was the case I believe with the IETF 
list software which I believed was one of those software with extra 
<CR><LF>. If I recall, one possible explanation was the list software 
was looking for a top text header to possibly import, but if there is 
none or empty it still adds a <CRLF> end of line (EOL) terminator. 
Perhaps it was doing this all in one line:

    NewBody = Import_Text_Header() + Body + Import_Text_Footer()

This is quite possible when reading a text file in "cooked" mode (as 
opposed to raw) and if the file is empty, a EOL can be added during the 
read.  This was the explanation I recall for the l= errors but I 
recently did noticed that this known problem was fixed.
</extra input>

-
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 4 Aug 2013 16:46:42 -0700

> Now the question is should the validation fail or pass in such case?
It's an error.  The RFC says this pretty clearly:

      This value MUST NOT be
      larger than the actual number of octets in the canonicalized
      message body.

You're probably right that most (if not all) parsers simply interpret "l=2"
as "don't feed more than 2 bytes to the hash", but the fewer case gets
silently ignored.  They are wrong.

I'll make sure OpenDKIM has this right and fix it in the next release if
not.

-MSK