Comments inline > -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Dave CROCKER > Sent: Tuesday, October 05, 2010 8:45 AM > To: Ian Eiloart > Cc: Tim Polk; ietf-dkim@mipassoc.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
