ietf-dkim
[Top] [All Lists]

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

2007-02-28 14:20:39
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