On 10/15/10 1:51 PM, MH Michael Hammer (5304) wrote:
On Friday, October 15, 2010 11:59 AM, Bill Oxley wrote: To:
dcrocker(_at_)bbiw(_dot_)net Cc: ietf-dkim(_at_)mipassoc(_dot_)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