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<ebay(_at_)ebay(_dot_)co(_dot_)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