[ietf-dkim] Comments on draft-ietf-dkim-ssp-requirements-02.txt

[Hallam-Baker, Phillip]

> From: Stephen Farrell [mailto:stephen.farrell at cs.tcd.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.