ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] detecting header mutations after signing

2010-10-13 13:33:45
On Wed, Oct 13, 2010 at 12:54 PM, 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.

If we can extract DKIM from the equation entirely and the problem remains, 
how is it a DKIM problem?


I agree with this.

And even if there was a DKIM signature, it is the BAD GUY'S signature,
which should cause it to go into the SPAM folder, with a large
phishing warning.

<rant>
Count me as one of those who was confused early on about what DKIM
provides. DKIM seems to make assurances to message integrity. But it
doesn't. I think the reason why many think it does is because of the
body hash. It is trying to do to much. It should just provide an
identifier that can be verified. Instead of using the body for
hashing, use the Message-ID header along with the Date header and just
hash that. That way most folks would understand DKIM is just providing
an Identifier.
</rant>



-- 
Jeff Macdonald
Ayer, MA

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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