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

[Douglas Otis]

On Feb 26, 2007, at 7:32 AM, John Levine wrote:

>> Unless John, Jon, Dave, and Mike can assure the WG that current  
>> algorithms will always be sufficiently strong, and that a  
>> transition sufficiently swift, then a means for the _signer_ to  
>> apply different algorithms where one is "deprecated" should be  
>> possible.
>
> Let's say I am a signer, you are a receiver.  I publish a policy  
> that says "don't trust that old fashioned sha256 signature, just  
> the new rot13 one."  What should you do with that policy record?   
> Why should you do anything other than ignore it because it's stupid?

You receive a message where the signer has indicated that sha256 has  
been deprecated, or perhaps the original signature association scheme  
has been deprecated, or perhaps the canonicalization algorithm has  
been deprecated.  To permit a graceful transition, both the  
deprecated algorithm (whatever that might be) and some shiny new  
algorithm must now be included with the message.  Once your verifier  
adopts the shiny new algorithm, both you and the sender have obtained  
a higher level of protection not vulnerable to downgrade attack.   
This protection depends upon a means for the signer to assert which  
algorithm is deprecated, and what shiny new algorithm is being offered.

> More generally, I hear an implicit assumption in all of this that  
> senders know more about crypto than receivers do.  Why would that  
> be so?

SMTP is a store and forward protocol.  As such it is impossible to  
negotiate between signer and verifier the highest supported  
algorithm.  It is not possible for the verifier to assert what is  
deprecated.  This is where DKIM base is very much conceptually in  
error.  The verifier can only assert which algorithms are obsolete,  
but the signer is able to assert which algorithms are deprecated.   
The signer must lead the transition by providing an improved option.   
It is not possible for the verifier to offer an improved option.   
There is no method to negotiate such a verifier option.

>   Why shouldn't receivers use their own best judgement about what  
> hashes are adequately strong, and why should they believe  
> statements from random spammers about relative strengths of crypto  
> algorithms?

Without a means for the signer to assert which algorithms are  
deprecated, until the problematic algorithm can be obsoleted, a  
downgrade vulnerability will exist.  This period of this  
vulnerability will likely be measured in years.  Defining a way  
forward does not need to alter existing structures, but instead  
simply define how the signer can make the assertions when they are  
needed.

-Doug