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