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-autoresp...@isdg.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