[ietf-dkim] Pete's review of 4871bis
presnick at qualcomm.com
Wed Jun 29 11:49:27 PDT 2011
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
> it. He then sends messages of the following form:
> To: some.sucker at anywhere.example
> From: eBay<ebay at 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 at 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:
> 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.
> 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.
> 3.8 says "verifiers SHOULD take reasonable steps to ensure that the
> they are processing are valid according to [RFC5322] ... ". But gives no
> guidance as to what "reasonable" means (and full RFC5322 compliance
> 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
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
More information about the ietf-dkim