Thanks Phill,
That is a clear statement of what you see as the problem.
Hallam-Baker, Phillip wrote:
OK here is a more compact description of the problem with algorithm transitions:
In order to perform a transition to algorithms that are not part of the
original base there will be a period in which messages are signed using both
the old algorithm and the new, stronger one. The three value SSP policy
proposed is negated by any party that attempts this transition.
Example:
Alice prepares to support XXX, this might be a cannonicalization algorithm,
digest algorithm or signature algorithm. Since XXX is not part of the original
specification it is only supported by a small minority (5%) of recipients.
Alice publishes
1 The policy statement 'I always sign'
2 A key record for algorithm XXX.
At this point Alice has lost 95% of the value the policy record is intended to
provide.
Mallet can produce a forgery of a message by Alice that is 95% certain to be
considered to be in compliance with Alice's sending policy. All he needs to do
is to create a bogus header that refers to the selector for the XXX algorithm.
95% of recipients will be unable to check the message and determine that it is
out of compliance.
Note that this is a security requirement. 'This is too complex' is not a valid
rebuttal, nor is claiming not to understand policy.
The requirement here is that it must be possible to specify a key record for an
algorithm that is not widely supported without compromising the value of the
policy record.
My issue with this is that I don't see why this is much different
from:
Everyone supports rsa-sha256
Alice publishes:
1. The policy statement 'I always sign'
2. A key record for algorithm rsa-sha256
Mallet can produce a forgery of a message by Alice that is 100%
certain to be considered in compliance with policy - the signature
value just won't verify.
But we don't need to decide anything about this until after
reqs-00 is out.
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html