[ietf-dkim] detecting header mutations after signing
hsantos at isdg.net
Fri Oct 15 16:55:55 PDT 2010
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%
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.
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
>>> 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
More information about the ietf-dkim