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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 28 Feb 2007 16:37:47 -0800

We are not proposing infrastructure to deal with a catastrophic failure. Dave has again missed the point.

The purpose here is to allow an orderly transition to a new algorithm over the space of five years or more.

Without it no transition is practical and the only option would be to wait for the catastrophic failure.  

> -----Original Message-----
> From: Eric Allman [mailto:[email-masked]] 
> Sent: Wednesday, February 28, 2007 4:29 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]; IETF DKIM WG
> Subject: 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" 
> <[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.
> >
> >
> >> -----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