From: Stephen Farrell
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
Consider the following two policies:
X: "Every email has at least one signature"
Y: "Every email has a signature of type A and a
signature of type B"
Now consider a recipient that only supports verification of
signature type A.
Consider the following attack:
Bogus message with signature of type B.
This message is consistent with policy X, it is not
consistent with policy Y. This means that if our policy
language can only express policy X it will not be possible to
tell the recipient the information it needs to know in order
to determine that the message is bogus.
Huh? The recipient doesn't support signature type B and will
therefore not consider the message signed.
No, that does not work. The issue here is whether there is a policy violation
or not.
If you treat messages signed with an algorithm you do not understand as policy
violations you are going to reject legitimate messages.
The behavior you describe must be prohibited with a MUST NOT if there is to be
any chance of ever deploying an upgraded algorithm. Otherwise the minute
someone starts signing with just DSS their messages will be tagged as policy
violations.
It is always possible to forge messages. Our job here is to
make it relatively easy to do a good job verifying real ones.
That was base. We are now onto policy.
The goal of policy is to allow conclusions to be drawn from the absence of a
verifiable signature.
The output of the DKIM base is :
NO-VALID-SIG - There was no signature (NO-SIG) OR
There was a signature but its broken (SIG-BROKE) OR
There was a signature that is not (NO-SUPPORT) supported
VALID-SIG - There was an acceptable signature that verified correctly
(ACCEPT-SIG)
There was a deprecated signature that verified correctly
(DEPREC-SIG)
The outcome of DKIM + Policy is different, it is:
COMPLIANT - The message is in compliance with the specified policy
NOT-COMPLIANT - The message is not in compliance with the specified policy
The substates of COMPLIANT/NOT-COMPLIANT map the substates of base differently:
COMPLIANT - There was an acceptable signature that verified correctly
(ACCEPT-SIG)
- There was no policy record (NO-POL) OR a NULL policy record
(NULL-POL)
- The message was consistent with the specified policy record but
the signatures present were all deprecated (DEPREC-SiG)
NOT-COMPLIANT - There was a policy record but the message is not consistent
with
it, AND there is no acceptable signature
The difference between consistent and compliant is driven by the insistence
that the key records trump the policy records.
NON-COMPLIANT means 'assign a high probability to reject'. If a message
authenticates then the non compliance with policy may be worth noting (and even
reporting) but it is not a cause to reject.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html