Subject: RE: [ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade andDowngrade Attacks

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 27 Feb 2007 19:32:08 -0800

No, that is not what I am proposing.
 
The discussion here is about a REQUIREMENT. How the requirement is achieved is not the issue at this point.
 
Of course since everyone seems to skip straight to the implementation, think up a daft way to do it and then object to the complexity of the scheme I am not proposing we have spent six months discussing what is the most trivial, easy to implement scheme you can imagine that actually works.
 
The policy record does not directly reference the signing algorithm, all that information remains in the key record. All that you get in the policy record is a statement 'there is always a key record that has a selector that looks like this' or 'there is always one like this and one like that'.
 
Lets hold off on the implementation though as Steve will no doubt remind us is the basic idea at this point. This means that we only discuss whether it is a valid requirement. The cost of implementation is not the issue at this point.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Fenton
	Sent: Tuesday, February 27, 2007 6:19 PM
	To: John Levine
	Cc: [email-masked]; [email-masked]
	Subject: Re: [ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade andDowngrade Attacks

	If you mean to just require that and not actually list the algorithms, the verifier would have no way of determining what algorithms the signer uses, without a list of all its selector names.
	
	If you mean to list the algorithms, isn't that what Phill is proposing?
	
	-Jim
	
	John Levine wrote: 

			Every protocol with algorithm agility but not a fixed list of "MUST
			implement" algorithms has this issue.

		Is there any reason that SSP couldn't require that anyone who makes a
		statement that he signs messages must sign with all the signature algs
		he supports?
		
		This would be an SSP MUST, not a DKIM MUST.
		
		R's,
		John
		_______________________________________________
		NOTE WELL: This list operates according to 
		http://mipassoc.org/dkim/ietf-list-rules.html

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

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 Feb 2007 09:19:34 -0500

Hallam-Baker, Phillip wrote:

> Of course since everyone seems to skip straight to the implementation,

That is what happens in a mixed discipline environment. :-) Plus there 
is 100s if not 1000s of man-years experience here - foreseeing 
implementing is not to be unexpected with all the knowledge here.  I for 
one see implementation issues with some of the proposal provisions so 
you expect it to be mentioned.

> The policy record does not directly reference the signing algorithm, all 
> that information remains in the key record. All that you get in the 
> policy record is a statement 'there is always a key record that has a 
> selector that looks like this' or 'there is always one like this and one 
> like that'.

I don't understand why.  The ultimate selector is the one in the 
DKIM-Signature heeader.

> Lets hold off on the implementation though as Steve will no doubt remind 
> us is the basic idea at this point. This means that we only discuss 
> whether it is a valid requirement. The cost of implementation is not the 
> issue at this point.

Of course, implementation doesn't mean "coding."  It is about the 
process model.  You must have some insight into this to have an 
understanding of the problem and possible solution.

The ideal situation is:

      "Having all the information one needs to make a decision."

The total process DATA pool is:

    - DKIM Message
    - KEY information
    - SSP information

or

    VALIDATION = VERIFY(MESSAGE, KEY, SSP)

or as some will want that to be:

    VALIDATION = VERIFY(MESSAGE, KEY[, SSP])

with an optional SSP.

So the question is, can an OPTIONAL SSP or a DELAYED SSP implementation 
be used to address all the concerns?

 From my standpoint you have these design points:

   - Is mail expected is this a valid condition?
   - The mail is signed, is this a valid condition?
   - The mail is unsigned, is this a valid condition?

For that all you need is

   a) SSP record, or
   b) for no mail or no signatures, all you need is no KEY record.

So as you can see, the decisions dictates how the process modeling will 
be done.

Beyond that, we are trying to KLUDGE a solution into "Signature Failure 
Fixing" and to me, that will be exploited.

Maybe it will help if we define what kind of failures are worth "fixing."

--
HLS