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
