ietf-dkim
[Top] [All Lists]

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

2010-11-03 07:00:53
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