Okay, we could put policy back in and state a malformed signature cannot pass and assign a weight higher than an unsigned message. Then the problem remains the same, is it error or malice. A dkim verifier is the wrong tool to do that particular job On Oct 15, 2010, at 7:12 PM, Hector Santos wrote:
> MH Michael Hammer (5304) wrote: > >> 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. >> > > I view this from a Fault Analysis standpoint and the first thing to > establish are your boundary conditions and it is difficult to have > boundary conditions without a policy framework (or process expectations). > > Part of the modeling do include invalid signatures and we have shown > that you can fold many of these invalid signature conditions into a > single "never signed" condition. > > This why I continue to have a problem with the 4871 "policy" of > transforming an invalid state point to never signed state point. It > was fine when POLICY was still part of the framework. When we insisted > on separating the two, that 4871 inherent policy should of been removed. > > This is not the first time, but I would love to re-issue the > suggestion to remove that statement from 4871 iff we want to continue > to separate policy into another layer. In that case, the higher layer > needs all trace information available. > > The difference is that there is higher weight with deterministic > boundary conditions when there is no real signature vs the > indeterminate conditions with failed signatures. But depending on the > domain expectation, these failed conditions can be folder to the no > signature condition. > > I always come back to an image of an old patented idea of using a > perfect circle to represent the optimal boundary conditions for a > process. When that circle is skewed, you are off the optimal plane. > It may not represent an emergency, but there is a "shape" or limits > that tells you something is not right and alerts need to be signaled. > > For DKIM, we can only do this with Domain Expectations to help > verifiers and local policy be molded. > > -- > Hector Santos, CTO > http://www.santronics.com > http://santronics.blogspot.com > > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
