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:eric+dkim(_at_)sendmail(_dot_)org]
Sent: Wednesday, February 28, 2007 4:29 PM
To: Hallam-Baker, Phillip
Cc: dcrocker(_at_)bbiw(_dot_)net; 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"
<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