ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] detecting header mutations after signing

2010-10-15 18:15:57
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

<Prev in Thread] Current Thread [Next in Thread>