On 8/4/2013 4:35 PM, Pawel Lesnikowski wrote:
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?
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 dkim-autorespond(_at_)isdg(_dot_)net. 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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html