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: 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.
[...]
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