ietf-dkim
[Top] [All Lists]

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

2007-12-14 17:01:33
The problem I have is that folding of FAIL to NONE when the policy is
ALL.

If there was "truly" no signature, then this can be repudiated with a
DKIM=ALL. All parties (signer and receiver) agrees what is known to be true.

However, if there is a failure, like in a Mailing List environment or ESP for a domain using DKIM=ALL, then we have false positive situations. DKIM can be repudiated. If we fold this failure to none, then someone is not going to be happy.

Of course, if this is what the domain owner wanted, then we are all satisfied. If this is not want the domain wanted, then he really shouldn't be using a DKIM=ALL policy. This can only be valid if there is a special relationship between the domain, the signer and the receiver.

--
Sincerely

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



Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
Hector,
The boundary conditions outlined are good but treating broken=unsigned is best 
case description of a failure. It gives the receiver knowledge and weight 
without mandating a practice.
thanks,
Bill Oxley


-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Hector Santos
Sent: Fri 12/14/2007 11:40 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: [ietf-dkim] How SSP will assist DKIM-BASE
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.




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