Issue 1386:
Deployment Scenario 7: Cryptographic Upgrade and Downgrade Attacks
In the case that a signer advertises key records for multiple signature
algorithms this may allow an attacker to circumvent an insufficiently
expressive signature policy.
Example:
Legitimate sender advertises key records A, B. Record A describes a signature
key for a widely supported signature algorithm. Record B describes a signature
key for a signature algorithm that is not generally supported. The senders
signature policy says 'I always sign every message'. The sender always signs
messages with algorithm A (whether algorithm B is used by the legitimate sender
as an additional algorithm or not does not affect the success of the attack).
[Such a situation will inevitably arise any time that there is a transition
from one signature algorithm to another. If policy is to have any utility it
must be possible to complete such a transition without negating the value of
the policy during the transition]
Mallet creates an entirely bogus message M and creates a false signature using
only algorithm B.
A recipient of the message that supports algorithm B is capable of determining
that the message signature is false and that the message is not in compliance
with the signature policy.
A message recipient that only supports algorithm A is unable to verify the
signature and determine that it is fake. The recipient is thus unable to
determine that the message is in compliance even though the recipient is
perfectly capable of checking the signature on every legitimate message sent.
In order to twart the attack the policy language must be sufficiently
expressive to allow the sender to describe their actual signature policy 'I
always sign with algorithm A and with algorithm B'.
Since we would like to confine considerations such as signature,
canonicalization algorithms to the key records the natural mechanism for
expressing this policy is to state restrictions on the key selectors. The
sender organizes key records into groups such as xxx.alg-a.example.com and
xxx.alg-b.example.com.
NOTES
The statement that 'invalid signatures are treated as unsigned' still applies
when policy is advertised. The purpose of policy is to allow a recipient to
draw inferences from the lack of a signature. So it is incorrect to say that
the attack does not matter because invalid is the same as unsigned. The point
here is that by ADDING a bogus signature the attacker is able to ensure that
their message is considered to be compliant with the signature policy when it
is not.
The outcomes for DKIM without policy are 'VALID SIGNATURE' and 'NO VALID
SIGNATURE' where the latter includes no signature at all and an invalid
signature.
The point of policy is to allow the legitimate sender to divide the 'NO VALID
SIGNATURE' outcome into 'CONSISTENT' and 'INCONSISTENT'. There is no value to
deploying policy unless you can reliably discriminate between more actionable
outcomes than you can without policy.
Further the attack becomes possible as soon as the legitimate sender advertises
a record for the new algorithm. What this means is that as soon as the
legitimate sender advertises the record for algorithm B their policy record
becomes vulnerable to attack. It is higly unlikely that the legitimate sender
is going to ever migrate algorithms under these circumstances and thus as far
as I am concerned policy does not meet the requirement for algorithm agility
unless it is possible for a recipient to determine that even though the signer
supports other algorithms there is a signature that can be checked.
There is also a downgrade attack using essentially the same principle except
that in this case algorithm A is actually broken and Algorithm B has a
sunstantial amount of deployment. Instead of creating a nonsense signature that
will fail validation the attacker forges a valid signature for the
untrustworthy algorithm.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html