[ietf-dkim] suspicious and SUSPICIOUS

[Michael Thomas]

Jim Fenton wrote:
> Finally getting a little caught up...
>
> Michael Thomas wrote:
>   
>> Charles Lindsey wrote:
>>     
>>> Now the ultimate recipients see A's signature (no longer good), plus
>>> A's policy. So the message is on the face of it "suspicious". So what
>>> is the recipient supposed to do? He is a member of the list, and is
>>> happy to trust the list maintainer, and can check the 2nd signature.
>>> But he is still receiving conflicting advice.
>>>       
> A message where A's (the author's) signature is broken isn't
> automatically Suspicious if A's SSP record says "all".  It is only
> Suspicious if there is no other signature there that the verifier is
> willing to accept.  One might expect that the verifier is willing to
> accept signatures from mailing lists it knows about.
>   
>> This is something that I also took away from the draft. "strict" +
>> broken/missing
>> signature is much more suspicious than "all" + broken/missing
>> signature. My
>> suggestion would be to tie the "suspicion" to the expectation: eg
>> suspicious/strict
>> and suspicious/all.
>>     
>
> The SSP draft does not attempt to set levels of suspicion.  Either a
> message is Suspicious or it is not, for the purposes of the draft.
>
> You're right, though, that the difference between "all" and "strict" is
> an expectation, as defined in section 5.3 of SSP Requirements.  There
> was a design choice between having independent practice and expectation
> flags in SSP and having a single flag.  We opted to combine practice and
> expectation into a single flag with the three values {unknown, all,
> strict} since the fourth value, "I don't sign everything but you should
> expect a valid signature anyway", doesn't make any sense and it seemed
> like it removed a potential source of misconfiguration if it is not
> possible to express that combination.
>   

I think I see what the problem is here. In the draft, you're trying to 
have a single
word summary that something is wrong ("suspicious"). The problem is that 
that
summary is just a single bit. I scanned through the draft and it doesn't 
a priori look
like it would be too difficult to just say what you mean ("strict 
failure") rather than
having the less precise summary ("suspicious"). The thing I'm *very* 
concerned
about is implementations treating "all" failure the same as "strict" 
failure. They
are not even close to the same semantics.

       Mike