[ietf-dkim] Issue 1386 and downgrade attacks

[Eric Allman]

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" 
<pbaker at verisign.com> 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.
>
>
>> -----Original Message-----
>> From: ietf-dkim-bounces at mipassoc.org
>> [mailto:ietf-dkim-bounces at mipassoc.org] 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
>>
>