ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal for new text about multiple header issues

2010-11-01 17:36:04
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

<Prev in Thread] Current Thread [Next in Thread>