Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[David Mazieres <[e-mail]>]

Watson Ladd <[e-mail]> writes:

>> Actually, people have *very* strong opinions about crypto and are
>> willing to lobby pretty hard for particular algorithms and protocols.
>> We should ensure such lobbying is directed towards OS vendors *after*
>> TCP-ENO is standardized, not towards the working group beforehand (where
>> it will further slow us down undermine TCP-ENO's goal of breaking the
>> working group deadlock).
>
> Who are people?

For example, the Russians vs. the US.  The Russians require that banks
and any products purchased by the government employ the GOST cipher.  In
the US, AES is effectively required.  According to wikipedia, the best
known attacks on the two are roughly comparable, though GOST is easier
to misuse (by setting bad S-boxes) and has only a 64-bit block size.

Now if I go visit a Russian bank (e.g., https://www.sberbank.ru), my
browser (which doesn't support GOST) happily chooses AES as the cipher.
Similarly, I'm sure Russian bank employees get AES when talking to US
institutions.  But according to the amended "presidential decree number
334," it seems the banks have to use GOST internally because the
Russians don't trust our crypto (which at the time of the decree was
DES, and at the time it was amended was AES).  Of course, if you are
paranoid maybe you think the Russian government can break GOST and/or
the US government can break AES.

> Certainly not the people willing to use the alternative algorithm if
> they have to.

Yes the people willing to use the alternative algorithms, as evidenced
by Russian web sites willing to use AES with me.

> The problem is with the existence of sites where only one algorithm
> must be used, and the OS is configured accordingly.

Hard-coding global cipher priority is likely to exacerbate this problem.
If the only way to prefer GOST is to disable AES entirely, well, then
Russian institutions will disable AES.

>> The fact that we have way too many encryption options floating around
>> does not mean all ciphersuites can be strictly ordered by security, for
>> the simple reason that nobody can predict the future.  Cryptanalysis may
>> alter the relative security of different algorithms at any time.  Or
>> some NIST scandal might erupt casting doubt on the design methodology of
>> P-512 compared to the nominally weaker Curve25519.  At such points, OS
>> vendors need the ability to re-prioritize cipher suites without breaking
>> backwards compatibility.
>
> Am I proposing a fixed, static ordering?

It certainly sounds like it.

> No. I'm proposing that in response to cryptanalysis we have a
> functional migration plan, and the negotiation mechanism to support
> it. We start with version 1, when that becomes untenable move to
> version 2. This has eliminated SSHv1 from the Internet. The
> alternative plan has never eliminated any cipher completely.

But SSH has had the same kind of mix-and-match crypto you have been
decrying.  In context, that was a good thing.  For years SSH shipped a
broken stream cipher mode that used the same key in both directions.  A
lot of people used SSH'S ARC4 mode because it was super fast.
Fortunately, when it was found insecure, vendors simply removed support
for that mode and security was restored where either endpoint had an
upgraded SSH.  If people had disabled other modes to prefer ARC4,
obviously the upgrade path would have been much harder, as SSH would
have been unusable during the transition.

The upgrade from SSH version 1 to version 2 was not primarily about
upgrading the encryption, was not in response to cryptanalysis, and did
not eliminate any cipher from the Internet.  We could, of course,
imagine using TCP-ENO to select between the equivalent of SSH 1 and SSH
2, with cipher negotiation handled at a different layer.  But if we want
just a few good cipher suite options, then these should simply be tied
to ENO suboptions, in which case the IETF cannot prioritize these.

David