[ietf-dkim] Accidental versus malicous error

[Hector Santos]

Douglas Otis wrote:

> Once SMTP clients find they might be blocked for having issued too many 
> invalid DKIM signatures, they might remove invalid DKIM signatures 
> beforehand.  Although this is in conflict with the base specification, 
> at least this measure ensures SMTP clients are not associated with bad 
> behaviours related to bogus DKIM signatures.

Not so.

If the SMTP client is going to strip signatures, then the verifier is 
now in the 100% non-repudiated state of NO signature and will label the 
message SUSPICIOUS for DKIM=ALL/STRICT policies.

The question is how or when can this happen.

Well, of course, this is not an original source because if a SMTP client 
is seeing bad signatures, you are assuming it itself did not honor 
DKIM-BASE or SSP when it first received the message and decided to 
redistribute or relay the mail.

So all you really highlighting here is the need for the middle ware to 
be protocol consistent as well.

For example, if Mailman is ignorant of SSP and the domain's strict 
policy, and it strips the signatures, then the final verifier will have 
no problem marking this transaction as SUSPICIOUS per SSP-01.

On the other hand, if Mailman left it alone, the verifier will be left 
in a limbo state which can only be rectified with a HARD requirement 
that STRICT means STRICT and broken also means the message is 
SUSPICIOUS.  DKIM-BASE will justified this hard SSP requirement because 
of its broken to no-signature promotion mandate.

> If, or when, DKIM signature hygiene does becomes a common practice, as 
> perhaps it should, then any invalid DKIM signature would be fairly 
> indicative of either older systems already listed as being DKIM 
> unfriendly, or newer and perhaps questionable systems behaving badly.  

So who is at fault here?

1) The user who didn't follow company policy and use a
    company property outside its business interest?

2) Mailman or any other similar middle-ware who may not be
    DKIM and/or DKIM/SSP compliant and allowed the user
    to submit unauthorized messages?

3) Mailman or any other similar middleware who will strip
    and/or strip/replace a redistribution because it has
    altered the mail integrity?


> Weighing an invalid DKIM signature as 'implying' a message is likely to 
> have originated from some domain invites bad behaviour that wastes 
> valuable resources.  

No dispute there. I always said that.

> Although an invalid signature should be considered 
> equal to no signature (as also specified in the base specification), 
> from the responses on this list, expect many will bet on initial 
> statistics and get this wrong.  

I find this funny because I do seem to recall that you and others were 
against restrictive policies because it was believe will restrict and 
promote false positives in valid roaming users situations.

The problem as I see it that these same people did not want to give SSP 
the light of day in lieu of using A/R heuristics to address the issue of 
valid vs broken signatures.

 > This does not bode well, and could
> represent a sizeable loss of receiver resources.

Your point is clear and for me, it was well long understood as a problem.

But you need to see SSP is not the problem here.  It is DKIM-BASE with 
its broken signature semantics.   SSP is fine when following the 
DKIM-BASE broken signature to No Signature status. But you do introduce 
FALSE POSITIVES into SSP because of it.   As the SSP boundary table 
showed, the GREY area is when the signature is DKIM-BASE signature is 
truly broken.

These can be a GOOD or BAD intention message.

Some systems may want to take the high road and clearly label these as 
bad and outright reject them and it will justified by the DKIM-BASE bad 
to no signature mandate.

Some system may just wish to pass it on to a A/R concept.

Some system may just REJECT them for a TRUE no signature, and pass on 
the bad signature to a A/R concept to learn more about it.

The problem is this:

Talking for myself here,  I don't want to implement something that will 
have a history of high false positives.  I want something that is 100% 
deterministic and believe SSP does that in the non gray DKIM-BASE areas. 


It is conceivable we can have a switch that says:

      [X] Promote Bad Signatures to No Signatures (default)

If this turns out be a high false positive area, then something has go 
to give.  We might add additional sub-options:

      [X] Promote Bad Signatures to No Signatures (default)
          [X] For ALL and STRICT policies only.

And this might help in minimizing the issue because as we all know, a 
major problem with DKIM is its optional and relax provisions and in this 
case, we might treat it just like any other message.  That might suggest 
that in a broken signature situation where a domain might have an 
optional signing policy (DKIM=UNKNOWN), "filters" might not want to 
ignore the fact that it was a broken signature so it can be used to 
learn from.

I don't have a problem with true no-signatures and I don't have a 
problem with "virtual" no-signature as well when the domain policy is 
restrictive.

Also remember the domain has the HANDLING= option so, overall, it might 
not be an issue for restrictive setups.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com