On Wed, Oct 13, 2010 at 12:54 PM, Murray S. Kucherawy
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles
Sent: Wednesday, October 13, 2010 9:12 AM
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:
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
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
NOTE WELL: This list operates according to