Re: [Tcpcrypt] Initial questions

[Tero Kivinen <[e-mail]>]

ianG writes:
> > I can say that failure to accommodate alg agility will almost
> > certainly cause the IESG to reject this as a standard, based on
> > precedents for some time.
> 
> Interesting point!  Probably worth reaching out to those folk and asking
> whether they are serious about enforced alg agility.

I at least think that we do need algorithm agility. We do not need to
deploy multiple algorithms, but we need option to be able to implement
multiple algorithms and select common one between peers. 

> And why they care so much in the context of TCPcrypt, which is
> opportunistic anyway, and as such provides not much of a guarantee.

To provide upgrade path. 

> > recall that AES has 256-bit keys as an option as a counter to possible
> > quantum computing attacks. Why rule out that option?
> 
> Because this is TCPcrypt.  The enemy is the unavailability of any
> encryption at at all, not the QC bogeyman.
> 
> If we deploy TCPcrypt to 99% of all nodes, and they're all vulnerable to
> QC, we still win.
> 
> (Because, to spell it out, we can always upgrade later on when the
> bogeyman starts deploying QC in the mega-scale, and meanwhile we won
> against everyone else.)

So you seem to prefer algorithm agility yourself, by saying "we can
always upgrade later". To be able to upgrade later do require
algorithm agility.

When we need to do upgrade that will take YEARS, or DECADES, as we
need to update every single implementation in the world. This means
that upgrade is never done completely, there will most likely always
be old devices which have not been updated, thus future devices need
to be able to talk to old and new devices both, thus requiring
algorithm agility.

IKEv1 was obsoleted 2005 and replaced with IKEv2. Still lots of
implementations only support IKEv1, even when it is quite broken (and
I know Dan will disagree with me about this, but in my personal
opinion IKEv1 is quite broken, there is no point of arguing it here,
IKEv2 is much better protocol), and even those which support IKEv1 and
IKEv2 still use IKEv1 as default because the IKEv1 didn't have good
enough algorithm agility, i.e. there was lots of implementations who
just drop all packets whose version number is not 1.0 causing timeout
if you start out with IKEv2. Also lots of people when they comment
about IKE list the problems in the IKEv1 which were already fixed in
IKEv2.

Another example is that SSL 3.0 is still used in some implementations
even when newer versions of TLS have been out for some time. If you
now go and only allow connections using TLS 1.2 there will lots of
clients who cannot connect to you anymore, and TLS 1.2 came out 2008.

With these examples about IKEv2 and TLS 1.2, I am trying to tell you
that upgrading protocols takes lots of time, especially if there is
new protocol version involved. Its much easier to implement new
ciphers etc with old protocol than to deploy completely new protocol.
Thus algorithm agility is important feature, and it needs to be there
from the beginning, otherwise we are stuck with the first version for
long time.
-- 
[e-mail]