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

David Mazieres <> Mon, 24 August 2015 02:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B71D11B2EC5 for <>; Sun, 23 Aug 2015 19:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.989
X-Spam-Status: No, score=0.989 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IJmRxhA08W_9 for <>; Sun, 23 Aug 2015 19:28:16 -0700 (PDT)
Received: from ( [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 024331B2EBC for <>; Sun, 23 Aug 2015 19:28:15 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id t7O2SELr014486; Sun, 23 Aug 2015 19:28:14 -0700 (PDT)
Received: (from dm@localhost) by (8.14.7/8.14.7/Submit) id t7O2SDhX028560; Sun, 23 Aug 2015 19:28:13 -0700 (PDT)
X-Authentication-Warning: dm set sender to using -f
From: David Mazieres <>
To: Watson Ladd <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Sun, 23 Aug 2015 19:28:13 -0700
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Cc: tcpinc <>
Subject: Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: David Mazieres expires 2015-11-21 PST <>
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 02:28:16 -0000

Watson Ladd <> writes:

> Suppose everyone behaves the way you suggest. How unhappy are they
> with using X or Y? Clearly not very much: they were willing to use it
> if the other side didn't want their preference.

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

> The result of wanting to support every possible combination of
> preferences and admin interface is having dead options linger forever
> as the sysadmins keep copypasta in config files alive forever. I'd
> rather order my crypto from McSorley's.

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.