From: Paul Hoffman
[mailto:paul(_dot_)hoffman(_at_)domain-assurance(_dot_)org]
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'.
s/twart/thwart/ otherwise good.
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.
I was not so much proposing language for the draft as wanting to provide some
additional explanation, it should probably have been in the notes. The point I
am trying to make here is that I can achieve the effect of saying 'I sign with
both algorithm A and algorithm B' without having to define any means of
describing this in the SSP document. We can achieve the necessary effect
through an interaction between SSP and DKIM-BASE.
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.
OK their policy record becomes useless as a discriminator against 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.
Predicting what a sender will or will not do when faced with
multiple signing algorithms is silly and does not belong in
this document.
I don't see that. I think it is pretty clear that a sender is not likely to
take a decision to deploy algorithm B as an early adopter if doing so is going
to degrade security in the short term
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html