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

Watson Ladd <> Sun, 23 August 2015 23:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 202AE1B2DFA for <>; Sun, 23 Aug 2015 16:46:05 -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 nbRZjpUvEN1m for <>; Sun, 23 Aug 2015 16:46:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 542AF1B2DFB for <>; Sun, 23 Aug 2015 16:46:03 -0700 (PDT)
Received: by wijp15 with SMTP id p15so62282855wij.0 for <>; Sun, 23 Aug 2015 16:46:01 -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=ir9xY1/TDLeEVOcMhk1Kh26ahT/HhhWhbWEb+7dx5FY=; b=WebpjYqexrcbhTduqlNwXsNdXLhV5HeH88JApOobgYcdn76SDIew6sGYlfS6p6royg diAYMJP71PFqL3MyWNa+WXy37dVZxMw1cOBvH11os4sJvRS8tpvBTmqL1qc+2Jx+dHOk VrEvXu2D6u/x+K8iFX6B1XliGq2uqL+ZJLhP/Ul7GKpp2YXjMUAHg8JEQzawB5Yl8Ni+ j1WoqjhvCZ6VmOctfRz8qXSiYtLP9iH99Hox4n/+mciYJHTff2ErxT2NiW5apHtY4HRZ zvH1F5kgeltBl6sCjCWSeZbLtdvJgi6AOJzJr3lqOnUCJBg503p9a0aMsJmHWmOlhqDp F6qQ==
MIME-Version: 1.0
X-Received: by with SMTP id t7mr35398883wjq.45.1440373561250; Sun, 23 Aug 2015 16:46:01 -0700 (PDT)
Received: by with HTTP; Sun, 23 Aug 2015 16:46:01 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Sun, 23 Aug 2015 16:46:01 -0700
Message-ID: <>
From: Watson Ladd <>
To: David Mazieres <>
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: Sun, 23 Aug 2015 23:46:05 -0000

On Sun, Aug 23, 2015 at 2:33 PM, David Mazieres
<> wrote:
> 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.

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

> David

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