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

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(_dot_)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(_dot_)org
> > [mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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

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