On Feb 28, 2007, at 4:41 PM, Arvel Hathcock wrote:
This protection depends upon a means for the signer to assert
which algorithm is deprecated, and what shiny new algorithm is
being offered.
That doesn't follow at all. The *receiver* will decide what
algorithms are and are not sufficient and when to act on that
decision.
For sake of argument, imagine a new canonicalization algorithm has
been created that handles EAI style addresses. EAI defines twin UTF8
email addresses which might be modified, but are not yet fully
accommodated by DKIM. Left to verifier heroics, some poor choice
results in some implementations. Messages may appear to be unsigned
leaving recipients exposed to spoofing, or results in a possible
exploit. One can claim verifiers should not attempt heroics, but
implementers are dealing with an unforeseen situation not covered in
the initial specifications.
Rather than not signing with just the now problematic widely
supported signature algorithm, the signer decides to add two
signatures to the message. Rather than overlapping signatures which
might introduce unexpected problems when other signatures are also
added, a deprecation mechanism is defined and placed within the key
of the now deprecated signature. This mechanism simply defines which
tags and parameters must be found in the companion signature. This
approach can be used to deprecate _any_ of the signature related
algorithms, although such is not likely needed for hash and signature
algorithms.
The *verifier* should attempt to find the strongest mutually
supported algorithm supported by the *signer* and not just any
supported algorithm. Only the *signer* can offer a choice. Some
mechanism is need to prevent a bad actor from removing an option in a
manner not detected by the *verifier*. Overlapping signatures might
be a poor choice when defending against this type of problem. Header
order should not be assumed and can become even more confusing when
multiple domains are involved with twin email address header
assurances. Don't forget about the 'i=' limitation.
And besides, the means by which a *sender* can assert which
algorithm they like is to just stop signing with the one(s) they
don't. Whether and when to do that is a decision the sender will
have to make. I don't see how policy plays a role in any of this.
Suddenly dropping a widely deployed algorithm will cause most of
there messages appear to be unsigned. This is likely to be a worse
outcome than that of some exploit that might be problematic with some
vendors. By having a deprecation mechanism available, the signer
does not need to make the choice between a rock and a hard place. A
deprecation mechanism also allows broad protection once the new
algorithm is embraced by major providers, even when stragglers may
take years to upgrade.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
