[ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade and Downgrade Attacks

[Douglas Otis]

On Feb 26, 2007, at 7:19 AM, Michael Thomas wrote:

> I'm still not seeing what the problem is with things as they stand  
> now.

The DKIM WG would not have not provided a reasonable solution if  
there were known easily exploitable weaknesses.  Avoiding a downgrade  
attack considers what might be needed to accommodate a transition in  
algorithms.  Currently, there are no reasonable mechanism for doing so.

> We've already been through a transition with sha1 and sha256. The  
> solution was to make both signatures in the transition and set the  
> h=sha1|sha256; in the selector.

Those changes are possible during the initial definition of an  
algorithm.  Once widely deployed and heavily depended upon, such  
changes without a transition scheme would be impossible to achieve.

> All you do when you're ready to completely transition is only sign  
> with the new algorithm and set h=sha256; in the selector.

There are many algorithms involved with DKIM.  Canonicalization,  
hash, crypto, header strategies, signature associations and more must  
be considered representing possible weaknesses which might require  
some future change.   Few can predict what might become problematic.

> This is exactly the kind of case we wanted to get right for -base  
> and as far as I can tell it worked exactly as intended.

No one is claiming that base is broken from a security standpoint,  
but it might be in the future.  When defining signer policy, a  
critical aspect relates to what is being used, and what has been  
deprecated.  The concept of deprecated _is_ broken in the base draft.

-Doug