From: Stephen Farrell
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
Hallam-Baker, Phillip wrote:
Your restatement of my point misses the point entirely:
IF there is a signature that the recipient can use
I think you mean "IF there was ever a ..."
THEN the recpient should know that there is such a signature
and s/is such a/was ever such a/
But why? The consensus we have now is that the recipient
alone is able to figure what signatures it can use and that
that's enough. You've not explained why this is insufficient
(or I'm just even dumber than usual;-).
Stephen,
The missing use case here is that we decide to add to the set of algorithms
used by DKIM. Let us imagine that we are proposing a new canonicalization
algorithm. We need to have a use case describing this scenario in the
requirements document and a statement of the architectural and design
requirements that supporting this use case entails. Otherwise we will end up
yet again with another IETF specification that requires us to wait for the
entire installed base to change before we can deploy.
Consider the following two policies:
X: "Every email has at least one signature"
Y: "Every email has a signature of type A and a signature of type B"
Now consider a recipient that only supports verification of signature type A.
Consider the following attack:
Bogus message with signature of type B.
This message is consistent with policy X, it is not consistent with policy Y.
This means that if our policy language can only express policy X it will not be
possible to tell the recipient the information it needs to know in order to
determine that the message is bogus.
Furthermore as presently specified SSP means that if there is any key record in
the domain that specifies a signature algorithm that may not be supported by
every recipient it is possible to send forged messages.
The point is that the current policy language does not provide sufficient power
to allow a recipient to determine whether there should be a verifiable
signature present.
The solution is to adopt the selector contraint mechanism I propose. This
allows signers to develop an orderly transition from one algorithm to another
whether it be canonicalization, hash or signature without the need to put any
information of that type into the policy record.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html