[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of EKR
I'm sure I'm going to regret wading in here, but...
We have two algorithms, A and B. Let's stipulate that B is
stronger than A. Now, the sender can have three policies:
send A (SA) Send B
(SB) and send A+B (SAB). The receiver can similarly have
three policies, accept A (RA), accept B (RB) and accept A or B (RAB).
If you cross these you get the following matrix:
Sender
SA SB SAB
RA A X A
Receiver RB X B B
RAB A B AB
You are conflating the signing policies and the advertisement of key records.
The whole point here is that you can solve the problem by having a signing
policy that is sufficiently expressive to describe what you do. The above
matrix works as you point out.
The matrix that fails is:
S 'I sign everything'
We have cases KA KB KAB for advertises Keys A, B, A and B.
There are three states of interest in the matrix:
V - Receiver is able to verify the signature
? - Receiver is unable to verify the sender's signature
X - Receiver is unable to verify compliance with the signer's policy
despite being able to verify the signer's signature
Sender
S(KA) S(KB) S(KAB)
RA V ? X
Receiver RB ? V X
RAB V V V
The problem is the appearance of the X results as soon as the sender advertises
multiple keys. As soon as the key B is advertised an attacker can create spoof
messages that appear to comply with the policy.
Reiterating arguments that apply to BASE is to miss the point. Policy is not
Base or else it would be in Base. The only reason to do policy is to provide
features that are out of scope for base.
Because implementations are supposed to ignore signatures
they can't verify, the only context in which downgrade
attacks matter is if the sender is implementing SAB and the
receiver is implementing RAB.
The downgrade attacks disappear here because you are assuming that the policy
allows you to say what it needs to say.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html