ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] suspicious and SUSPICIOUS

2007-10-08 08:16:43
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
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html