On Wed, 13 Oct 2010 17:54:23 +0100, Murray S. Kucherawy
<msk(_at_)cloudmark(_dot_)com> wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles
Lindsey
Sent: Wednesday, October 13, 2010 9:12 AM
To: DKIM
Subject: Re: [ietf-dkim] detecting header mutations after signing
The bad guy (the phisher) provides two From headers, but only signs one
which, as DKIM is currently defined, has to be the second one.
His two headers are:
From: info(_at_)ebay(_dot_)com
From: info(_at_)phisher(_dot_)com
BUT many/most MUAs currently display only the first From header if two
are
provided. There is no reason why the verifier at the boundary should
report an invalid signature, so the message gets through to the intended
victim who just sees what his MUA shows him, which apparently is a
message from the genuine ebay address.
This is true if the message is not DKIM-signed at all. The rendering
choice you're highlighting here already exists in many/most MUAs.
But if there is no valid DKIM signature, the verifier will proceed to do
ADSP checks, and will reject the message if it sees that ebay.com is
'discardable'.
Note that RFC5617 is ambiguous as to which of the two From headers it will
use to establish the Author Domain, so we are going to need a 5617-bis to
fix that.
If we can extract DKIM from the equation entirely and the problem
remains, how is it a DKIM problem?
Since the phisher is trying to bypass that ADSP 'discardable' for ebay.com
(and he thinks ADSP checkers might use the first address), it is in his
interest to DKIM-sign the message himself (so that ADSP is never
consulted). And that is why it is a DKIM problem, and why the loophole
must be closed.
--
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