On 01/Nov/10 22:56, Douglas Otis wrote: > On 10/30/10 3:05 AM, Alessandro Vesely wrote: >> On 28/Oct/10 03:36, Douglas Otis wrote: >>> I'll repeat the example given previously. The multiple listing of a >>> header in the h= parameter can not mitigate exploitation of DKIM PASS >>> results where a valuable domain is prefixed to that of large domain. >>> The large domain is unlikely concerned by possible presence of a >>> pre-pended header field, where their decision not to include multiple >>> listing for a message clearly not compliant with RFC5322. In other >>> words, this leaves DKIM results open to exploitation. >>> >>> From: accou...@big-bank.com >>> From: some...@big-isp.com >>> DKIM-Signature: h=from, d=big-isp.com, ... >> Besides RFC 5322 compliance, how is this different from a traditional >> unsigned spoofed "From: accou...@big-bank.com"? Having just a >> signature doesn't mean much, and spelling how to match signature and >> From field is ADSP's job, even in corner cases.
> [...] > ADSP compliance only requires a valid DKIM signature by the Author > Domain, as currently defined by DKIM. This does not protect against > pre-pended singleton header fields containing a domain that may have a > restricted ADSP assertion, even one that always signs with multiple > singleton header fields listed in the h= parameter. If big-bank.com asserts a restrictive policy, the relevant author address should make that message fail ADSP verification, since no author domain signature can be found. Apparently, RFC 5617 already provides for multiple author addresses. Section 3 reads If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. > Multiple listings of singleton header fields in the h= parameter is > an ugly and wasteful hack that offers an incomplete remedy for > these selection conflicts. Why "ugly hack"? You mean from an aesthetic POV? Yes, some bytes are wasted, as usual. Whenever we'll recycle we should fix that. (MIME compliance and UTF-8 header would be valid reasons for v=2, IMHO.) Since it addresses precisely this issue, it is not incomplete in that respect. > Note: > RFC5322 defines the following singleton header fields: > orig-date, from, sender, reply-to, to, cc, message-id, in-reply-to, > references, and subject. > In the example, a domain being targeted by attacks may assert ADSP > discardable and sign with the h= parameter listing multiple singleton > header fields. A victim might accept information based upon a valid > DKIM signature, only to then be misled by different selections used by > the display or sort process. DKIM fails to mitigate the exploitation of > a DKIM signature inappropriately considered valid when multiple > singleton header fields exist. If ADSP verification is thorough, the exploit can only succeed when big-bank.com asserts no restrictive ADSP. In such case, yes, the exemplified message may verify. Blame poor signing practices at big-isp.com. > Only by ensuring DKIM never asserts a valid signature for messages > having multiple singleton header fields, can exploitation of a valid > DKIM signature status be avoided. Not quite. Big-isp.com may delegate responsibility for the From field to the relevant author, as it seems common practice. Then, one doesn't even need to infringe RFC 5322 to produce a DKIM-valid bait. For the "only by" part, unaesthetic signing practices _can_ avoid the singleton exploit. If big-isp.com carefully validates the From field, it should also include it twice in the h= tag. Possibly, one might even derive from there a criterion for guessing what kind of signing practices have been applied. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
