On 10/15/10 1:51 PM, MH Michael Hammer (5304) wrote: > > > > On Friday, October 15, 2010 11:59 AM, Bill Oxley wrote: To: > > dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: > > [ietf-dkim] detecting header mutations after signing > > > > Well a broken signature is morally equivalent to unsigned so Im > > not sure of the potential harm... > > And this is where I angst. In all the discussions of a broken > signature being morally equivalent to unsigned, the thrust has been > that it was likely broken in transit. We failed to have the > discussion of it being intentionally broken in transit as an attempt > to game the system. For header mutations after signing (which are > likely to be a malicious attempt in the specific cases we have been > discussing) I feel that treating it as simply the same as unsigned is > ignoring the potential maliciousness. > > I recognize what Murray and Dave have said on this point but it > grates. The reason we are going through the exercise of creating a > stable identifier associated with a signing domain is because we > perceive some value whether it be policy associated with the stable > identifier or reputation associated with the stable identifier. > > To simply ignore this and say it is the same as if it wasn't signed > is kind of like saying 0=1.
Agreed. Having the specification suggest multiple From header fields should not report a valid signature is not enough. It will be years before software will reliably deal with the resulting exploits. The best method to handle DKIM related exploits at the MTA would be to recommend message refusal. It is hard to understand the reluctance in having a SHOULD refuse. Citing a layer violation makes little sense. With DKIM, the message body does not stand on its own. DKIM binds elements related to the RFC5322 header fields with the message body, for the purpose of extending favorable message handling, such as white-listing. Since DKIM has this property, citing layer violations lacks any basis. The h=from:from is also not an effective solution, as this only deals with one mode of exploitation! There are two. John and Mark are right. It is wrong to consider the DKIM signature some type of academic exercise devoid of how DKIM might be exploited. The WG should step up and deal with this assumed compliance vulnerability. Without DKIM, this vulnerability would not exist. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html