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

[Douglas Otis]

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