Comments inline
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave CROCKER
Sent: Tuesday, October 05, 2010 8:45 AM
To: Ian Eiloart
Cc: Tim Polk; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with
Multiple
5322.From
On 10/5/2010 8:15 AM, Ian Eiloart wrote:
It has been observed by implementations that is it possible to
replay
a message with a 2nd 5322.From header at the top which wouldn't
break
the DKIM signature validity, but would often be displayed by
MUAs to
display the new 5322.From display rather than the signature
bound
5322.From header.
Ouch. That's nasty. But wouldn't it be better to advise MUA vendors
to
display the signed header? Are there really MUA's that will display
the
unsigned headers*and* assert that it was validated? If so, that's
surely a
bug in the implementation of the MUA.
Your comments underscore the importance of being careful about what we
expect
from DKIM. As you note, if software is DKIM-aware, it also needs to
be
DKIM-intelligent.
Agreed.
At a deeper level, there is a continuing problem with casting DKIM as
a
mechanism to "protect" a message. That's something that OpenPGP and
S/Mime do;
it's not something DKIM does. DKIM merely tries to do enough to
ensure
that the
d= is valid, to provide a basis for reputation assessment.
As long as DKIM signs the body and fails to validate on a signed but
modified body then there has to be some presumption that DKIM is a
mechanism (of some sort) that protects the message (to some extent).
Hence, I recommend that this ISSUE be declined and closed.
I'm still cogitating on the appropriate response to this ISSUE.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html