In general, I agree with Phill that this is a requirement. Please do
not take my disagreements below as negating the need for the section
and for the policy language to be able to express signing algorithm
usage.
At 10:54 AM -0800 2/23/07, Hallam-Baker, Phillip wrote:
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.
+1 to all the above.
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'.
This would be better worded as: In order to twart the attack, the
policy language must be sufficiently expressive to allow the sender
to describe their actual signature policy, such as 'I sign only with
algorithm A' or 'I sign with both algorithm A and 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.
This is unnecessary here; there are other ways for a sender to group
their keys. We are only talking about the policy statements in this
document.
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.
+1
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.
These two paragraphs are quite important, and should be in the
introduction of the document, not in this section.
Further the attack becomes possible as soon as the legitimate sender
advertises a record for the new algorithm.
Yes.
What this means is that as soon as the legitimate sender advertises
the record for algorithm B their policy record becomes vulnerable to
attack.
No. The policy record is not vulnerable: the messages are.
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.
Predicting what a sender will or will not do when faced with multiple
signing algorithms is silly and does not belong in this document.
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.
Correct.
--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html