Subject: RE: [ietf-dkim] Issue 1386 and downgrade attacks

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 28 Feb 2007 13:18:14 -0800

We have avoided catastrophic failures in the past by designing our systems in such a way that gradual transition is possible.

For example in 2010 the Server Gated Crypto roots will expire and it will no longer be possible for a user of a Windows 98 machine with the 40-bit export encryption stack to visit their bank using 128-bit cryptography.

If we had a situation where nobody could securely use 128 bit security until every bank in the world had upgraded to support 128 bits we would today be in a really bad mess.

The argument Dave appears to be making here is that because we have never succeeded in the past lets plan to make sure we fail this tim by ignoring an issue we can solve today. I don't accept the premise and I don't accept the argument. The conclusion is also wrong.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Crocker
> Sent: Wednesday, February 28, 2007 1:48 PM
> To: Eric Allman
> Cc: IETF DKIM WG
> Subject: Re: [ietf-dkim] Issue 1386 and downgrade attacks
> 
> 
> 
> Eric Allman wrote:
> > [By the way, there was also some confusion about whether 
> transitions 
> > are
> > O(years) or O(days).  Changing selector records is O(days), 
> whether or 
> > not those selectors change algorithms, but changing algorithms 
> > requires software updates and hence is O(years).]
> 
> Important distinction.  Thanks.
> 
> It's probably worth noting that a catastrophe with a deployed 
> algorithm, so that a rapid transition is required, has no 
> precedent in the large-scale, open Internet, and probably 
> would take considerably more effort and mechanism than 
> anything we are discussing here.
> 
> As such, building in anything designed a) to deal with highly 
> problematic, systemic failures, and b) incurring overhead for 
> most/much regular traffic in anticipation of that catastrophe 
> is probably not such a good idea.
> 
> As we have seen in other such algorithm transitions for 
> mechanisms in end-points -- rather than infrastructure -- 
> they tend to have a distinctive
> characteristic:
> 
>       While it is O(years) to achieve very broad adoption, it 
> can be O(months or even weeks) to gain a useful degree of 
> adoption, within smaller communities of interchange.
> 
> In general, this means that slower algorithm transitions are 
> acceptable and can be handled in the same way as we handle 
> other transitions on the Internet. 
>   None of them include a publication mechanism.
> 
> 
> d/
> -- 
> 
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net
> 
> _______________________________________________
> 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

---

From: Eric Allman <[email-masked]>
Date: Wed, 28 Feb 2007 13:29:20 -0800

I'm not seeing Dave saying that at all.  So far as I can tell, he and 
everyone else believes in gradual transitions such as the one you 
cite.

I think he *is* saying that we have no experience with a nightmare 
scenario where some basic algorithm such as RSA is cracked --- not 
theoretically or in unlikely cases, such as with SHA-1 --- but really 
really dead in the water cracked.  If we had to switch from 40-bit to 
128-bit in a matter of a couple of days it wouldn't go smoothly.  And 
I agree that building in something to handle this sort of scenario 
almost certainly isn't worth it.

eric

--On February 28, 2007 1:18:14 PM -0800 "Hallam-Baker, Phillip" 
<[email-masked]> wrote:

> We have avoided catastrophic failures in the past by designing our
> systems in such a way that gradual transition is possible.
>
> For example in 2010 the Server Gated Crypto roots will expire and
> it will no longer be possible for a user of a Windows 98 machine
> with the 40-bit export encryption stack to visit their bank using
> 128-bit cryptography.
>
>
> If we had a situation where nobody could securely use 128 bit
> security until every bank in the world had upgraded to support 128
> bits we would today be in a really bad mess.
>
> The argument Dave appears to be making here is that because we have
> never succeeded in the past lets plan to make sure we fail this tim
> by ignoring an issue we can solve today. I don't accept the premise
> and I don't accept the argument. The conclusion is also wrong.
>
>