> -----Original Message----- > From: [email protected] [mailto:ietf-dkim- > [email protected]] On Behalf Of Murray S. Kucherawy > Sent: Monday, October 18, 2010 2:26 PM > To: [email protected] > Subject: Re: [ietf-dkim] Data integrity claims > > > -----Original Message----- > > From: [email protected] [mailto:ietf-dkim- > [email protected]] On Behalf Of Mark Delany > > Sent: Sunday, October 17, 2010 6:23 PM > > To: [email protected] > > Subject: Re: [ietf-dkim] Data integrity claims > > > > By DKIM process, I would include anything cognizant of DKIM upto but > > not including the MUA. Mike's secret sauce would count here, eg. > > Current implementations, especially the two library ones that are > referenced most often in here, haven't the functionality to cause header > fields to be removed, prefixed, reordered, modified, etc. This change > would require them to be overhauled to extend their reach into what the > MTA can do. That expansion of scope of "DKIM process" to me requires a > recycle at Proposed Standard. >
Assuming that is the consensus solution to the perceived problem. > > As others have said, there is nothing between DKIM and the MUA that > > prevent DKIM exploitation so who is going to solve that problem if not > > us? > > 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. 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. This leaves it to the MUAs to implement based on the DKIM output but it addresses the DKIM related case. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
