Fully agree, but that's not what was being discussed. The
specification should not prevent the verifier from trying other things
to get a signature to verify unless there is a significant security
issue in doing so. We don't have to encourage (or even mention) making
multiple attempts with expected changes on a message, but we should
not prohibit it either.
A specification cannot "prevent" a verifier from trying any crazy (or
sane) thing they want.
However, it CAN distinguish between text that is specifying how to
perform straight verification, versus text explains all sorts of
secondary hacks. The former is precise, reliable and clear. The latter
is whatever folks feel like making it. Mixing the two confuses both.
A specification for processing a message well might suggest use of
heuristics and well might produce very different results, depending
upon where the processing is performed.
Too many softeners in that.
OK.
How about: It is silly (and dangerous) to specify a verification
technique that gives different results depending upon who is doing the
verification.
A verifier that chooses to try heuristic message modifications in
order to get a positive result for verification does not change the
meaning of DKIM at all, unless those modifications can come from an
plausible attack. As I stated in my previous message, given that this
attack would require a preimage attack, it is not plausible.
A protocol that is successful on Internet scale -- large numbers of
independent implementations and large numbers of independent
administrations that interoperate -- is nearly always simple,
mechanical, and predictable.
The use of heuristics in any of the core specifications runs contrary to
this experience. It introduces ambiguities, ie, uncertainties. For some
reason, people deciding to spend the time and money to implement
critical infrastructure services are a tad reticent to pursue standards
that make guesses.
Feel free to proffer examples to the contrary.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html