ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade andDowngrade Attacks

2007-02-28 17:54:16
We all agree on the transition strategy here.

The question is purely what the policy is capable of expressing. If the 
transition strategy means that you are always going to sign twice once with a 
key selector of each type then that is what the policy must be capable of 
expressing.



-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Arvel Hathcock
Sent: Wednesday, February 28, 2007 7:31 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Deployment Scenario 7: Cryptographic 
Upgrade andDowngrade Attacks

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.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html