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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 23 Oct 2006 11:53:39 -0700

I agree with Doug that if additional information is to be offered it should be in the key records. In fact the whole point of my proposal is that almost all the policy information lives in the key records. 

The policy record essentially contains one bit of information 'everything is/is not DKIM'. The only parameter that is needed is to allow for specification of the key record prefix so the correct key records can be found.

I disagree that there is a need to state that an algorithm is deprecated in signer generated records though. If there was such a need it should be done through a separate mechanism for distributing the status of cryptographic algorithms and should proceed from an authoritative source like CFRG.

> -----Original Message-----
> From: Douglas Otis [mailto:[email-masked]] 
> Sent: Monday, October 23, 2006 2:20 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Comments on 
> draft-ietf-dkim-ssp-requirements-02.txt
> 
> 
> On Oct 23, 2006, at 10:52 AM, Hallam-Baker, Phillip wrote:
> 
> > The deployment scenarios do not capture the downgrade 
> attack problem 
> > correctly.
> >
> > As has been repeatedly pointed out on the list and never 
> rebutted the 
> > only way you can have a successful transition from a state 
> where the 
> > whole world uses algorithm A to one where the whole world uses 
> > algorithm B without having a period where one group or the other is 
> > unable to achieve their security goals is to:
> >
> > * Sign messages with both algorithms
> > * Have a policy statement that specifies that messages are 
> signed with 
> > both algorithms.
> 
> When more than one algorithm is offered, where the signer is 
> also responding to an attack vector, the following is also desired -
> 
>    * Indicate which of algorithms are deprecated.
> 
> However, this strategy is not to be handled in the initial 
> specifications.
> 
> An optimal location for this information to minimize overhead 
> is within the key records.  There is also a desire to 
> eliminate policy references in various scenarios not 
> compatible with preventing this downgrade concern.
> 
> -Doug
> 
> 
> 
> 
> 

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 23 Oct 2006 15:00:24 -0700

Just to clarify the proposal I have has three independent parts, I believe that each represents a simplification of the current SSP and removes net complexity.

1) Discovery
	Discovery of policy records is effected as at present by means of prefixed TXT records. If no prefixed TXT record is found the verifier looks for a new record PRPTR standing for Prefixed record pointer. This gives a new location at which to look for a PTR.

2) Policy
	The policy record has a meta-syntax of a sequence of tag, value pairs, the value slot is optional. The policy contraints of each and every tag specified must each be met. Defined tags are:

	NULL
	NOMAIL
	DKIM [=selector-constraint]

	The DKIM policy is all or nothing. If present then every message sent has a DKIM header with a selector value that meets the specified selector constraint. 

	The selector constraints are simply a suffix that the selector must have. No regular expressions, matching rules or anything. This allows the sender to create the effect 'must have a sig of type A and a sig of type B'.

3) Null Key Record
	To assist in transitioning from an unsigned to a signed zone it may be useful to state 'every message is signed except for these'. In order to express this constraint we introduce null key records. These specify the null signature algorithm and have no key value. They do however have constraints on the sender value. 

	The sender can thus create exceptions to their 'I sign everything' policy by adding a fixed header referencing the null key record. 

	Null key records do not authenticate the message, their only purpose is to claim an exemption from a blanket signature policy.

In aggregate this proposal has half the number of moving parts as the current SSP proposal and it meets the full set of specified requirements plus the additional requirements that should be stated if we ever want to change the specification such as deploy a new canonicalization algorithm.

> From: Stephen Farrell [mailto:[email-masked]] 
> Sent: Monday, October 23, 2006 5:07 PM
> Hi Phill,
> Before we get into the wording of the latest ssp-reqs, can we 
> try to figure out whether this is really different from the 
> set of similar *closed* issues on base?
> 
> I am not at all clear why such flags are useful in SSP, given 
> that we have rough consensus that they are not needed for base.
> 
> As I see it:
> 
> 1. The current WG consensus for base is that its up to each 
> recipient to decide for itself which algorithms it considers 
> acceptable.
> 
> 2. The current WG consensus (I think) is that SSP need not be 
> used when a signature that the recipient considers "good" is 
> present. (I.e.
> I see no consensus for a position that SSP MUST be used even 
> if what the verifier thinks is a good signature is present.)
> 
> Given 1 & 2 above, I just don't see the point of algorithm 
> transition information in SSP since no-one will read it who 
> might act on it.
> 
> Please also expliticly explain why this is not simply 
> revisiting some *closed* issues on base.
> 
> Thanks,
> Stephen.
> 
> 
> 
>

---

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

> Hallam-Baker, Phillip wrote:

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

Your argument here is the exact opposite of that made by Jim. You are arguing for the default to be one way, he is arguing for the default to be the other way.

Uncovering this type of inconsistency is the purpose of a requirements document.

> > 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
> 
> I think we could argue there, but you're delving into design 
> now, not requirements IMO.

Since when was the specification of Pre and Post conditions for a module not a requirements issue?

I have raised a use case and a set of requirements that result from that use case. That is a requirements issue.

Nobody has objected to the use case. The only argument advanced is that the current spec meets the use case. This being the case the requirements should be accepted into the draft.

When I raised the issue during base I was told to wait till policy. I raised the issue then because I knew that if I did not raise it then I would be told that I should have raised it in base.