ietf-dkim
[Top] [All Lists]

[ietf-dkim] Fwd: Re: THIS IS A MULTIPLE 5322.FROM MESSAGE

2010-10-08 09:40:08
On Thu, 07 Oct 2010 17:09:14 +0100, Michael Thomas <mike(_at_)mtcc(_dot_)com> 
wrote:

I'm with Steve on this one. Forcing implementations of DKIM to
determine whether a message is compliant is a pretty high bar. ...

How can you claim it is a "high bar" when clearly it isn't.? All that the
implementor of a verifier has to do is:

1: Construct a list of all the RFC5322 headers which can occur at most
once. FYI, that is Orig-Date, From, Sender, Reply-To, To, Cc, Bcc,
Nessage-ID, In-Reply-To and References. For good measure, add the
once-only headers defined in all the other RFCs that you can locate (which
would give you, for a start, MIME-Version, Content-Type and
Content-Transfer-Encoding).

2. Your implementation already needs to scan all the headers in order to
identify the ones it needs to hash in order to verify the signature. It is
a pretty trivial addition to count the occurrences of each one mentioned
in the "h=" tag as part of your scan, and to check whether any of the ones
in the list have occured twice.

... I for one wouldn't be in any particular big hurry to add a batch of
code to insure that that MUST was fulfilled. I doubt anyone else
would be either. The net effect of this MUST would be to make a
lot of compliant DKIM implementations non-compliant. And for what?

Yes, existing verifiers will become non-compliant, but that will not cause
the sky to fall in overnight. They will still continue to verify as at
present, but they will also remain vulnerable to the scam that has been
identified, which should be a pretty good incentive to get them fixed ASAP.

I'd say that it would be better to just say that if you sign a
non-compliant 5322 message that its verification is undefined,
and move on. That at least matches reality, and hasn't hurt
anything that I'm aware of.

And that indicates that you have not realised the nature or the
significance of this scam. Let me describe it again.

1. A phisher creates a throwaway domain, e.g. ebay.phish.com.

2. He creates a signing key for his domain, and advertises the key in the
usual manner.

3. For good measure, he might also create an ADSP discardable policy for
his domain, just to give an added air of respectability.

4. He then creates and sends emails of the following form:

     From: info(_at_)ebay(_dot_)com
     Subject: Your ebay account is about to expire
     DKIM-Signature: d=ebay.phish.com; h=From,Subject,...; ........
     From: info(_at_)ebay(_dot_)phish(_dot_)com
     .........

     Typical phish requesting Password, etc.

5. Note that the phisher signs it with his own key (and it is the 2nd From
that gets hashed). All current verifiers that are strictly compliant with
RFC4871 will report the signature as valid (except for the few that have
already been patched by people aware of the scam).

6. Many, if not most, current MUAs will show only the first signature
     From: info(_at_)ebay(_dot_)com

7. The email never goes anywhere near ebay, so their signing practices are
irrelevant. There is absolutely nothing that ebay can do to prevent it.



-- 
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

<Prev in Thread] Current Thread [Next in Thread>