On Mar 3, 2007, at 2:12 PM, John L wrote:
What is at issue is not what the sender thinkg of the algorithm.
All that is at issue is describing what they do
Understood, but since what the sender does in this case has no
effect on how a receiver handles incoming mail, there's still no
point in publishing it.
John,
Imagine there is an improved algorithm for handling a DKIM related
issue now permitting some type of exploit. For the sake of argument,
the issue is not catastrophic, nor related to crypto-graphic signing
or hashing. It could be how headers are associated with signatures,
how multiple email-addresses are handled, how UTF-8 is handled, etc,
etc.
Some percentage of signers will introduce a new strategy that
curtails the foreseen problem. Only when a verifier can easily
confirm whether a signers has upgraded, will it be practical to
detect when a bad actor has downgraded the message. Depending upon
overlapping signatures makes an unfounded assumption. It is likely
that in the presence of difficult to associate multiple signatures,
overlapping may prove fragile. Defining an optional "deprecation"
parameter for the key offers a safe transition that can accommodate
_any_ DKIM related algorithm or service.
Abruptly eliminating a prior algorithm, and introducing a new one
before it achieves broad support will prove highly disruptive.
Achieving broad support may also take years, especially when the
issues affects only a portion of the recipients, as can easily
happen. You can not claim that what a signer does has no effect on
how a verifier handles a message. When you trust the signing domain,
then knowing their strongest option can defeat an exploit once both
the verifier and signer have upgraded. Your approach postpones this
protection until problematic algorithm can be universally obsoleted.
This assumption could prove costly.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
