[ietf-dkim] detecting header mutations after signing

[Hector Santos]

Bill,

First, lets kill this seed, I wasn't suggesting to put policy back into
the DKIM spec.

What I speak of is that before you can do any DKIM Fault Analysis you must
first establish the DKIM boundary conditions for 100% failure and 100% 
success.

That has to do done first and if we can't do that, then it will be 
very difficult to get a payoff for DKIM.

-- 
HLS

Bill.Oxley at cox.com wrote:
> 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
>