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:dotis(_at_)mail-abuse(_dot_)org]
Sent: Monday, October 23, 2006 2:20 PM
To: Hallam-Baker, Phillip
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
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