On 6/29/11 11:20 AM, Charles Lindsey wrote: > I agree that 8.14 is poorly written (and it was even worse a while back). > However, there most certainly IS an attack here, which is NOT the same as > the related attack discussed in 8.15, and cannot be prevented by putting > extra entries in the 'h=' tag. Unfortunately, many WG members have failed > to understand the difference between the two. Here is the attack, > described in plain terms: > > > A phisher obtains a throwaway domain and creates a public/private key pair > for > it. He then sends messages of the following form: > > ------------ > > To: some.sucker@anywhere.example > From: eBay<e...@ebay.co.uk> > Date: Tue, 17 May 2011 13:21:06 +0100 > Subject: Some plausible Ebay subject > <Lots of other normal headers> > From: a.phisher@mythrowayawdomain.example > DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example; > h=from:to:subject:date; ....... b=<valid signature> > > Body of message of typical Phish style. > > ------------- > > A compliant DKIM verifier will report that as a validly signed message. >
The second From field is absolutely irrelevant in the example. The phisher could simply leave out the From field with their address in it and sign the ebay From field. And that's not an attack. The signer signed the message and the signature verifies. *DKIM* has done its job successfully and has not been attacked. DKIM communicates from the signer to the verifier. The signer *can't* attack itself. You *might* characterize this as an attack against 5322 (in that From addresses are not bound in any secure way to the actual author), but DKIM does not even attempt to address that attack, so it's not an attack against DKIM. You go on to say something that is an attack, but again you get the analysis wrong: > The > Ebay signature is irrelevant for the signing process (so even if Ebay has > declared a "Discardable" ADSP policy it will not be invoked). Now *that's* the attack. But it's NOT AN ATTACK ON DKIM! It's an attack on ADSP. If ADSP sees the above message and doesn't discard it, then ADSP has done the wrong thing. If ADSP has a bug where it thinks it ought not discard the above message (with the appropriate policy), then that should be fixed. It should certainly be called out in the security considerations of ADSP. But it's NOT a security consideration for DKIM. > Normal > readers > using current MUAs will see just the From: Ebay header and, believing that > their ISP has done some magical cryptographic checks to prevent bogus Ebay > messages from getting through, will be reassured. > Again, the second From is not required for that to happen. If MUAs believe that some magical crypto thing happens to a message with "d=badguy.example" and "From: ebay" (with no other From's), then they get what they paid for. > The present draft does make some woolly attempts to fix this problem. > Section > 3.8 says "verifiers SHOULD take reasonable steps to ensure that the > messages > they are processing are valid according to [RFC5322] ... ". But gives no > guidance as to what "reasonable" means (and full RFC5322 compliance > checking > is notoriously hard). It now refers to to both 8.14 and 8.15, but leaves > it to the implelemtor to work out what he needs to do. > As this conversation has developed (here and off line), I'm getting convinced that 3.8 is a red herring. DKIM deals perfectly well with the obsolete message format, including multiple From fields. I think the 3.8 admonition is overblown. > In my opinion, there needs to be some REQUIRED action in the verifier which > will result in a PERMFAIL, and which would then catch all attacks of this > nature. But the WG consensus has been against this. > If the WG is against it, it is correct. This is NOT a PERMFAIL condition for DKIM. It is probably a PERMFAIL condition for ADSP, but that's a different document. pr -- Pete Resnick<http://www.qualcomm.com/~presnick/> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
