> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy > Sent: Monday, October 18, 2010 2:51 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Data integrity claims > > > -----Original Message----- > > From: MH Michael Hammer (5304) [mailto:mham...@ag.com] > > Sent: Monday, October 18, 2010 11:44 AM > > To: Murray S. Kucherawy; ietf-dkim@mipassoc.org > > Subject: RE: [ietf-dkim] Data integrity claims > > > > > There's nothing between an MTA and an MUA that prevents this attack in > the > > > non-DKIM case at all. Whose place is it to fix that? > > > > > > I can't get my head around how that case is irrelevant here. This is > not > > > a new problem, but somehow we're being called upon to deal with it. > > > > The non-DKIM case makes no assertion with regard to authentication (I > > exclude PGP and S/MIME from the non-DKIM case I think you refer to). If > > DKIM made no assertion regarding validation of headers + the body length > > hash then we would almost certainly not be having this discussion in the > > first place. To the extent that DKIM makes such claims then it is a > > different case and needs to be considered separately from the non-DKIM > > case. > > DKIM doesn't claim the value in From: was valid, only that it was > unchanged. >
I said validation, not valid. That is in line with the 4871 text that uses "validate" or some variation 22 times. That is, what was signed is what was validated on the receiving/verifying side. > If the MUA is DKIM-aware, then it will render the From: field covered by > the signature, even though the value that field could be completely bogus. > If the MUA is DKIM-ignorant, it renders the "first" one, for some search > order. > > In neither case is there an assertion of validity of the content. > See above. This leads me to believe that you might be amenable to informative text rather than normative text. > > I'm going to go back to the question I asked Wietse... Do we see double > > headers (one signed and one unsigned one added later) in the normal > > course of things in the wild? If not then rather than getting into the > > MUA territory and fixing it, I say let's fix DKIM. If we only see this > > type of behavior where there is potential non-good activity (I was > > going to use malicious), we output a "warn" addition to a > pass/fail/none. It's > > not a huge check to look for the double headers and we aren't boiling > > the ocean. > > If we can output a "warn" bit in addition to pass/fail/none, we're also > presuming the MUAs will adapt to consume it. But then the MUAs can just > as easily adapt to show you what parts of the message were signed and > which were not, and that is in fact the more complete solution. > > This is no more presumptuous than expecting that MUAs will adapt to consume the output of DKIM as it stands now. The question is the value equation. I'm not in a position to answer that question. Perhaps we should try to get some of the MUA folks to join the conversation. It may be that some of the well known ones go... "hey, never thought about this issue and yeah, we will look into fixing it based on the wider scope". On the other hand they might inquire if we are smoking crack (Just trying to give the two extremes of responses). Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
