On Tue, 02 Nov 2010 18:47:23 -0000, Alessandro Vesely
<vesely(_at_)tana(_dot_)it>
wrote:
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. ...
But in Doug's example, the verifier (following the letter of RFC4871) will
report only that it saw a valid signature from the domain big-isp.com. It
will not report anything at all (either good or bad) about big-bank.com
since (followng 4871) it was not signed. That is the 4871 hole we are
tying to fix.
... 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.
No, that wording applies to multiple addresses in a single From header. If
there are two From headers, ADSP has nothing to say on which to use, so
the expectation is that its implementations will use the first, when asked
to to an ADSP lookup. The whole point of this scam is that big-isp.com
(the Bad Guy in this case) wants to prevent that lookup from ever
happening. As the two specs (DKIM and ADSP) are currently written, his
scam will succeed.
Even if we fixed the ADSP spec (which is not on our current agenda),
existing ADSP implementations would still get caught. SO we MUST fix it in
DKIM, which IS on our agenda.
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.
Yes it is ugly but, worse, it does not prevent this particular scam.
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.
Big-isp.com is the Bad Guy here. His poor signing practices are quite
deliberate. Which is why only a header-counting verifier can catch him.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html