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

Watson Ladd <> Mon, 24 August 2015 14:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A73D01A00B9 for <>; Mon, 24 Aug 2015 07:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OshnNGtsWed3 for <>; Mon, 24 Aug 2015 07:22:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C6A91A0094 for <>; Mon, 24 Aug 2015 07:22:25 -0700 (PDT)
Received: by wicne3 with SMTP id ne3so73895436wic.0 for <>; Mon, 24 Aug 2015 07:22:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MaqoofPqDPLEm0eziSyY1Oe4XAm4lIoPjUJEBKTbJ88=; b=LBGwc5Grs1UA13uS7SqSj9IcFvkLNFUdu8LH/sSCxncpYUvfjMtaUBAGMsiLSujU4h qOYyoeJeJs2igZ7XFNKxkgt+KV97tvvatRz6dNMGSAnv+9EcNKAoYyUcqCCUb3TnAswz XdREvGwy1rMqF/roXo0Z/old9Rtx/vbh004eYBq8QJJI024nfJoaZ9nq6jGTAl4eMlX8 uf3ESEG4DIL+lokYskU4ffojdb7eoe5fgUzMGWg0vyJOTwSs0lEt5Kzm7NoKSzmNFW6M wvF44fSpqJYmaWbdij3TwA1oxuc03Kh6HsZlqGETR5orOZ+f5OTRE1Y1Tgznnv2epU0E ufig==
MIME-Version: 1.0
X-Received: by with SMTP id mn7mr39528388wjc.64.1440426143772; Mon, 24 Aug 2015 07:22:23 -0700 (PDT)
Received: by with HTTP; Mon, 24 Aug 2015 07:22:23 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Mon, 24 Aug 2015 07:22:23 -0700
Message-ID: <>
From: Watson Ladd <>
To: David Mazieres expires 2015-11-22 PST <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: tcpinc <>
Subject: Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Aug 2015 14:22:29 -0000

On Mon, Aug 24, 2015 at 6:33 AM, David Mazieres
<> wrote:
> Watson Ladd <> 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.,, 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.

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

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