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: accounts(_at_)big-bank(_dot_)com
From: someone(_at_)big-isp(_dot_)com
DKIM-Signature: h=from, d=big-isp.com, ...
Besides RFC 5322 compliance, how is this different from a traditional
unsigned spoofed "From: accounts(_at_)big-bank(_dot_)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