ietf-dkim
[Top] [All Lists]

[ietf-dkim] How SSP will assist DKIM-BASE

2007-12-14 09:53:54
A few years ago I illustrated the boundary conditions of DKIM-BASE and how SSP-00 policies were applicable.

With SSP-01, I updated the boundary conditions to reflect to current DKIM-BASE protocol consistency model.

Legend:

SSP-01 Policies:

    DKIM=unknown      (Signature Optional
    DKIM=all          (Signature Required, Any party)
    DKIM=strict       (Signature Required, 1st party only)

DKIM-BASE Verify Results:

NONE     - No signature in mail
PASS     - Good Signature, Original Address Signer
PASS 3P3 - Good Signature, 3rd party Signer
FAIL     - Bad Signature, Original Address Signer
FAIL 3P3 - Bad Signature, 3rd party Signer


Table 1.0 - DKIM Verification States illustrates all possible
            outcomes for signature verification against SSP.

               +----------------------------+
               |   Sender Signing Policy    |
   +-----------+----------------------------|
   | DKIM-BASE |         |        |         |
   | RESULT    | UNKNOWN |  ALL   | STRICT  |
   +========================================+
   | NONE      |  +1     |   -1   |   -1    |
   |-----------+---------+--------+---------+
   | PASS      |  +1     |   +1   |   +1    |
   |-----------+---------+--------+---------+
   | PASS 3PS  |  +1     |   +1   |   -1    |
   |-----------+---------+--------+---------+
   | FAIL      |  ?      |   ?    |   ?     |
   |-----------+---------+--------+---------+
   | FAIL 3PS  |  ?      |   ?    |   -1    |
   +-----------------------------------------

The following nomenclature was used to represent the result of each state:

   +1  -> 0% false positive non-repudiated state
   -1  -> 0% false positive non-repudiated state
    ?  -> Something Failed - Indeterminate

How a system reacts is implementation and local policy based.

However, in order to fundamentally analyze the consistency of the DKIM-BASE protocol, we need to recognize the known set of boundary conditions based on the DKIM-BASE specifications. There are only five possible outcomes for DKIM-BASE: none, pass, fail and 1st party and 3rd party versions of pass and fail.

These can not be escaped as they all present the real possibilities for DKIM-BASE outcomes.

As part of the non-repudiation process, the verifier must be aware of the true non-repudiated expected conditions by the domain DKIM-BASE signature or lack of one.

Therefore given the possible boundary conditions that may exist, the
above chart represents the non-repudiated or repudiated states based on the SSP-01 policies of UNKNOWN, ALL and STRICT.

The +/- 1 states are 100% protocol and non-repudiation consistent and
will eliminate a vast major of the current security threats.

Why is there failures?

There are million reasons. Body and/or Header integrity munging is one. Overall, the signature has failed.

I am of the opinion, other layers (such as A/R considerations) may
assist in determining the final outcome.

Some may desire, as in the strict case, that a FAIL should also be
non-repudiated with a -1 outcome, or as well in the ALL case, for a 1st
party signature, a fail should be non-repudiated condition.  The
proposed handling= can assist this determination if so desired by the
domain.

But overall, I hope this analysis shows that there is no reputation here. It is purely 100% focusing on protocol consistency to illustrate the importance of SSP in assisting in the non-repudiation process.

Finally, the table also shows how the "bad guys" can exploit the failure states. If verifiers have no guidance, this can promote this type of abuse where FAILURE is forced by the bad guys.

One of the reasons I have a problem with the DKIM-BASE inherent policy of:

         "Invalid signature must be viewed as unsigned"

is because it can create false positives/negatives.

If inherent DKIM-BASE mandate is followed, then these indeterminate states fold into the DKIM-BASE NONE state which you can see above has an unrealistic +1 outcome for an UNKNOWN policy and a -1 for the ALL and STRICT policies.

--
Sincerely

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

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html