[ietf-dkim] Issue 1386 and downgrade attacks

[Hallam-Baker, Phillip]

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
>