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.
Also 5.7 talks about hash algorithms which makes it look as if this is the only
concern. A much bigger concern for me is the fast that we are using RSA and we
cannot go beyond 2048 bit keys. So I am more concerned about the need for
agility in the signing algorithm.
Deployment Scenario 7: Cryptographic Upgrade and Downgrade Attacks
In the case where the signer supports multiple cryptographic algorithms,
including algorithm(s) that are regarded as compromised the threat of downgrade
attack MUST be considered. In this attack the attacker makes use of the
compromised algorithm even though the signer always signs using a high security
algorithm.
In the case where a DKIM signature may be created using a cryptographic
algorithm that is not supported by the verifier the threat of an upgrade attack
MUST be considered. In this case the attacker creates a signature that is
consistent with a signature algorithm that the recipient is not expected to be
able to verify.
In each case it is necessary that the signer specify a signature policy that
allows the existence of multiple signatures and multiple signature algorithms
to be specified.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html