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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 24 Oct 2006 11:07:08 -0700

> From: Stephen Farrell [mailto:[email-masked]] 

> > 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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Oct 2006 20:30:38 +0100

> No, that does not work. The issue here is whether there is a policy violation or not.

 From the verifier perspective: there is no policy violation. They've
just gotten an unsigned message and treat that however they want.
(I suspect we're talking at cross purposes?)

> If you treat messages signed with an algorithm you do not understand as policy violations you are going to reject legitimate messages.

Since I don't agree that the premise applies, the rest is moot.

> 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 me…

I don't agree with either the conclusion or the language.

> The goal of policy is to allow conclusions to be drawn from the absence of a verifiable signature.

Sure. And we're discussing which conclusions are required.
And we disagree about that, but that's ok.

>                  There was a deprecated signature that verified correctly (DEPREC-SIG)

Is *any* of that in base? I don't think so. Base actually only talks
about PERMFAIL and TEMPFAIL, so I think you're making assumptions
about how you'd implement - they may be reasonable assumptions, but
equally there may be other, conflicting, but just as reasonable, ways
to do things.

> NOT-COMPLIANT  - The message is not in compliance with the specified policy

I think we could argue there, but you're delving into design now, not
requirements IMO.

Stephen.