On Feb 26, 2007, at 11:56 PM, John R Levine wrote:
This protection depends upon a means for the signer to assert
which algorithm is deprecated, and what shiny new algorithm is
being offered.
Wearing, as usual, my receiver hat, I still don't see any reason to
be interested in random senders' opinions about the relative merits
of various algorithms.
Like I said before, let's say someone publishes SSP saying sha256
is deprecated and rot13 is shiny and new. What should I do with
that info?
Why validate a signature from a domain you do not trust? Validating
signatures indicates the defeat of protections placed ahead of the
verification process.
If your verifier performs rot13, and you too believe it to be
stronger than sha256, then this information immediately protects an
upgraded verification process from a possible downgrade vulnerability
that might last years otherwise.
The hash algorithm is an unlikely cause for a problem, but following
your unlikely example:
You receive a message where the key for sha256 requests rot13 be used
instead. When the rot13 signature is missing, essentially the signer
has requested sha256 to then be considered invalid. If you do not
know anything about rot13, then continue to use sha256.
When the message is only signed with rot13 and the policy indicates
messages are always signed, but you don't know anything about rot13,
then consider the message to be outside the signer's policy. By
applying both sha256 and rot13 signatures, compliance with the policy
is retained. By defining a "please use" field in the sha256 key, a
possible downgrade attack can be avoided can be avoided without _any_
added transactions. : )
Assuming we agree that it's stupid and I should ignore it, how am I
supposed to tell stupid deprecation advice from non-stupid
deprecation advice?
You have exactly the same problem with _any_ signature. If you do
not trust domain foo, then no matter what signature is applied, you
still will not trust domain foo.
When you trust domain foo and you also want to avoid problem X as
soon as possible, then you'll also want to known when you can safely
refuse messages having problem X without disrupting a large
percentage of your email. Not allowing or ignoring information that
protects verifiers from a downgrade attack seems foolish. But then
again, why validate DKIM signatures when the signer is not trusted?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
