On Wed, 29 Jun 2011 05:46:06 +0100, Pete Resnick
<presnick(_at_)qualcomm(_dot_)com>
wrote:
32. Section 8.14: This is a complete mischaracterization of the problem.
This is absolutely not an attack vector. If a signer wishes to prevent
additional *known* header fields from being verified, it can simply use
the technique outlined in 8.15. If the signer chooses not to do that, it
is expressing the intent that it considers messages valid that have
additional header fields added. *That's* the security consideration:
Signers should know that failing to include, e.g., "h=...:from:from:..."
on messages with one "From:" header field are leaving themselves open to
this attack. The attack is not on the verifier. Additionally:
Note that the technique for using "h=...:from:from:...", described in
Section 8.15 below, is of no effect in the case of an attacker that
is also the signer.
That sentence is utter nonsense. The signer *can't* be the attacker for
purposes of DKIM when it comes to the header fields it's willing to
sign. The Introduction (section 1) makes it absolutely clear that DKIM
is about transmitting information from a signer to a verifier.
Section 8.14 needs to be completely rewritten. It is nonsensical as it
stands.
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
Ebay signature is irrelevant for the signing process (so even if Ebay has
declared a "Discardable" ADSP policy it will not be invoked). 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.
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.
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.
There are clearly related attacks, possibly involving duplications of
other headers (including some MIME headers), and there are similar attacks
involving replays and men-in-the-middle and which are covered under 8.15.
But the one I have shown is the real killer IMHO.
--
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