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

David Mazieres <> Sun, 23 August 2015 21:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1EB4E1B2F30 for <>; Sun, 23 Aug 2015 14:33:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.49
X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 DMWr28ovGH40 for <>; Sun, 23 Aug 2015 14:33:33 -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 1159A1B2F2D for <>; Sun, 23 Aug 2015 14:33:33 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id t7NLXVkb026292; Sun, 23 Aug 2015 14:33:31 -0700 (PDT)
Received: (from dm@localhost) by (8.14.7/8.14.7/Submit) id t7NLXVwp005254; Sun, 23 Aug 2015 14:33:31 -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 14:33:30 -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
List-Id: "Discussion list for adding encryption to TCP." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 23 Aug 2015 21:33:34 -0000

Watson Ladd <> writes:

>> Such a linear ordering would be very hard to achieve, given that
>> different parts of the world trust/mistrust different crypto algorithms.
>> Even among cipher suites discussed so far, how would we order
>> P-256/AES-128 vs. Curve25519/Chacha/Poly1305.  The former set is better
>> is the sense that it is more established.  The latter is better in the
>> sense that it is newer, potentially more efficient, and (for the
>> paranoid) less tainted by government involvement.  I think realistically
>> the preference has to be left to the individual host configuration
>> rather than the IETF.
> Let's consider what this actually means. Hosts that implement 1 of two
> options because they don't trust the other one to provide adequate
> security will not talk to the ones that make the wrong choice. Hosts
> that implement both would be fine picking just one, in fact prefer it
> as it reduces the amount of work they have to do.
> But by having ranking preferences, we're in fact saying "you would be
> fine with picking one for improved interop, but we're going to force
> you to make a choice that complicates your implementation, because we
> assume you are an expert in cryptanalysis research and we are not".
> Picking one suite that's widely acceptable is far better than
> providing a smorgasbord.

Well, hypothetically, say the US prefers spec X and the EU prefers spec
Y.  The goal is that two hosts in the US would always choose spec X and
two hosts in the EU would always chose spec Y.  But when a host in the
US communicates with a host in the EU, we don't really care as
much--they could choose X or Y, so we might as well base it on the
preferences of the passive opener.  However, hard-coding the spec
rankings risks delaying standardization to argue over which specs should
take priority.