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. Sorting or display selection exploits can occur whenever handling is based upon valid DKIM signatures by trusted domains.
By not confirming singleton header fields have not pre-pended an existing header field, especially a From header field, this creates an exploit exposure. DKIM normally uses a bottom-up selection process that mistakenly presumed RFC5322 compliance. Avoiding exploitation of a valid DKIM signature MUST ensure against pre-pended singleton header fields, since most subsequent processing will use top-down header field selections. 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. 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. 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. 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. It is not reasonable to presume the transport will exclude these messages. Ensuring against a valid DKIM result when there are multiple singleton header fields is not the same as enforcing RFC5322 compliance. This only ensures against DKIM's mistaken presumption of RFC5322 compliance. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html