On 6/29/11 11:49 AM, Pete Resnick wrote: > 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. This is a poor example of a potential problem. The problem may occur whenever email acceptance is predicated upon the signing domain.
When this domain is of sufficient volume where this domain constrains the From to being within the same domain or verified by a ping-back, on that basis their messages should be safe to accept. However when pre-pended From header fields are not precluded from producing valid signatures, (a silent condition) acceptance on the basis of a high volume signature would not be safe, whether or not ADSP is applied. >> 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. Agreed. But then this would not be basing acceptance on the signing domain. >> 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. So much for safe incremental deployment. :^( -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
