1368 straw-poll : (was: Re: [ietf-dkim] Deployment Non-Scenario 7: Cryptographic Upgrade and Downgrade Attacks)

[Douglas Otis]

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