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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html