Subject: RE: [ietf-dkim] Proposed 1368 wording draft 1

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 2 Mar 2007 08:23:47 -0800

> From: Douglas Otis [mailto:[email-masked]] 

> > Such a mechanism MUST NOT
> >     * Require the verifier to perform any additional DNS lookups.
> >     * Require duplication of configuration data
> >     * In particular not require the policy record to 
> provide for the 
> >       description of any cryptographic or cannonicalization 
> algorithm
> 
> Without being able to specify the critical elements that must 
> be found within a superseding signature, there is no 
> assurance that a spoofed and unsupported signature has not 
> replaced the stronger algorithm.  Spoofing could be 
> accomplished by simply listing a different query mechanism.  

The question is whether the information is expressed in the policy record directly or in some other form.

There have been several objections made to including algorithm information in the policy record. I agree with them. Specifying the same information in two places creates the possibility of inconsistency. It means that the policy language needs to be much more complex etc.

There are several ways in which the restriction can be specified without including the algorithm information in the key record directly. The simplest is to specify a lexical restriction on the set of key selectors as proposed on the list.

Since there is possibly some ambiguity here I suggest ammending the last point to read:

    * In particular not require the policy record to 
          provide for the direct description of any 
          cryptographic or cannonicalization algorithm

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 2 Mar 2007 10:15:53 -0800

On Mar 2, 2007, at 8:23 AM, Hallam-Baker, Phillip wrote:

>> Without being able to specify the critical elements that must be  
>> found within a superseding signature, there is no assurance that a  
>> spoofed and unsupported signature has not replaced the stronger  
>> algorithm.  Spoofing could be accomplished by simply listing a  
>> different query mechanism.
>
> There have been several objections made to including algorithm  
> information in the policy record. I agree with them. Specifying the  
> same information in two places creates the possibility of  
> inconsistency. It means that the policy language needs to be much  
> more complex etc.
>
> There are several ways in which the restriction can be specified  
> without including the algorithm information in the key record  
> directly. The simplest is to specify a lexical restriction on the  
> set of key selectors as proposed on the list.

The suggestion to include the superseded tag/parameter within the  
deprecated key involves roughly the same level of complexity.  This  
could specify d=d/<selector> and accomplish the same thing.  The  
direct specification of the superseded tag/parameter will not depend  
upon the use of DNS either.  This would also leverage the information  
already contained within the deprecated signature.  It would not be  
as onerous as all that.

>           cryptographic or cannonicalization algorithm

I can agree with this statement, but it should not preclude a  
reasonable method for specifying superseding algorithms either.   
There should be less concern for the cryptographic signing and hash  
algorithms, but other algorithms not even be specified within the  
signature header may prove problematic.

-Doug