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

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 01 Mar 2007 13:04:31 -0000

On Thu, 01 Mar 2007 00:31:05 -0000, Arvel Hathcock  
<[email-masked]> wrote:

> Mike, this is what I was trying to say in a previous post.  You are  
> exactly right.  We have already faced this situation and it has proven  
> itself in the field to work just fine.
>
> Arvel
>
> Michael Thomas wrote:
>> I'm still not seeing what the problem is with things as they stand now.
>> 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. All you do when you're ready to
>> completely transition is only sign with the new algorithm and set
>> h=sha256; in the selector. 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.
>>  I'm honestly not trying to be obtuse here.

That particular example (change of hash algorithm) may indeed work in the  
selector (though it doesn't make it clear that "h=sha1|sha256" necessarily  
means "we always sign twice, once with each).

But that makes no provision for any of the other parts of the algorithm  
that may change over time, such as the canonicalization of the means of  
accessing those selectors (dns/txt has always been regarded as a temporary  
expedient until the DNS contains some better mechanism).

Hence the proposal to put all this information in the SSP. But putting it  
anywhere where it would work would solve the problem. What will not solve  
the problem is doing nothing.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html