[ietf-dkim] Base-02 //Deprecated Signature Version & New List

[Douglas Otis]

On Jun 22, 2006, at 10:45 AM, Eric Allman wrote:

> There are many reasons I don't like this proposal.  Let me start  
> with the easily fixed ones:
>
> (1) Overloading existing tags to add new functionality is absurd.  
> Adding "d" to the end of the version has nothing to do with the  
> version; this should be a flag.  Similarly, changing the n= tag  
> (which is supposed to be nothing more than human-readable "note"  
> text) to have additional semantics is bizarre; it should be a new tag.

The version of the signature (when something changes that breaks  
compatibility with existing verifiers) is really what is being  
declared deprecated.  It seems modifying version ensures this feature  
remains upwardly compatible, as the intent is to condition use of a  
deprecated version of DKIM.  Modification of the v= and n= could be  
combined with a c= flag that indicates a requirement for a concurrent  
version during a two signature transition.  This could be  
c=<signature version of concurrent key>.  To be more complete, it  
could also cover v= a= q= separated by "|".


> (2) I'm getting a bit tired of seeing new terms used that have  
> never been defined.  What's a VAQ value?  Based on Google it seems  
> to mean "Value Added Quest" (a competition for all West Australian  
> students). Or maybe Soctiabank's "Value Added Quarterly".  It's  
> also a military abbreviation for "Naval Tactical Electronic Warfare  
> Squadron" (derivation unclear).  Oh wait, maybe it means the values  
> of the v=, a=, and q= tags.  Now why not just say that in the first  
> place?

This was described in the suggested text and in the review.  With an  
assurance that all non-compatible changes must cause Version to  
change, then what needs to be exchanged to prevent spoofing would be  
just the next acceptable version.  It seemed safer to assume this may  
not occur in every case, and to ensure non-compatible extensions that  
might be declared via the a= and q= parameters rather than properly  
reflected by the version value.


> And the more basic issue:
>
> (3) Wasn't the issue of downgrade attacks discussed in Dallas and  
> resolved on the list?  In specific, it was issue 1196 (Upgrade  
> indication and protection against downgrade attacks).  As near as I  
> can tell, the exact same issues that Doug is raising were discussed  
> in this issue, and a frankly much more elegant approach was  
> proposed. Why is this issue alive again?

This issue still needs review. This proposal offers a means to ensure  
a transition can occur while minimizing spoofing.  This could be  
changed to simply adding a new key tag that indicates the  
concurrently acceptable version.  This could be defined as a  
indication the signer considers such a signature using a key with  
this tag as deprecated.  You should notice that the base draft is  
using the term deprecated incorrectly.  There still needs to be a way  
to properly handle deprecated signatures without immediately  
declaring them obsolete as is the case in the current draft.

-Doug