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

[Watson Ladd <[e-mail]>]

On Mon, Aug 24, 2015 at 6:33 AM, David Mazieres
<[e-mail]> wrote:
> 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.

Let's look at an actual Russian bank website, and see which
ciphersuites are enabled.
https://www.ssllabs.com/ssltest/analyze.html?d=http%3A%2F%2Fwww.sberbank.ru%2F

Please point out the GOST ciphersuite being used. Even if internal
tools (which won't rely on easily disabled tcp encryption) used GOST,
clearly this isn't actually applying to the website.

>
>> 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.

This is a misreading: I'm proposing that at any time there is only one
suite that everyone uses, and versioning is just for transitions.

>
>> 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.

No, I'm proposing introducing a new version done correctly in
response. RC4 should never have been used in the first place. This
migration hasn't taken place in SSL, despite a similar negotiation
mechanism.

>
> 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



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.