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

Watson Ladd <> Tue, 25 August 2015 14:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 24FA61B2CC4 for <>; Tue, 25 Aug 2015 07:43:19 -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 Lnu6qOl_jEzu for <>; Tue, 25 Aug 2015 07:43:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3FDF1AC41C for <>; Tue, 25 Aug 2015 07:43:16 -0700 (PDT)
Received: by wicxr16 with SMTP id xr16so2558031wic.2 for <>; Tue, 25 Aug 2015 07:43:15 -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=JOLXqAEGEnqQ5VD4DDJvBGP53lTaKbjFz3fiKjPaRlw=; b=OzHo8OHJAmx+wNDVAI/H/cCwbYSiNRSsM2QArLhroHCPbgYXf3iR2ywzEcoEh40jMn GxUyBy/wkm97QiBKD+hzsQUi7npi8LmaKmYIKkL1aq6JWKeLcnYRgpCQE8oAcMTSZtq2 pbTs8Mpzd0df1xEqHFBp+mJdo3J6J2ABc5kFH1c+LFT6sksTyzd5xozNBwcCkKcSZsCe 7pVXhDsdA7NP2nd+mlP+iHloU/WU1gFelmx3qw70JB2j8CKXMjza9vZY/c397ZLxwq3T R74hWF9EyNkyMJoZLRCfPNuOt2qzIat2U7V55Js+ivB3f9z8GUpZ1nsTf7qsUCZj5KCE ZGcw==
MIME-Version: 1.0
X-Received: by with SMTP id t8mr5324968wix.18.1440513795634; Tue, 25 Aug 2015 07:43:15 -0700 (PDT)
Received: by with HTTP; Tue, 25 Aug 2015 07:43:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 25 Aug 2015 07:43:15 -0700
Message-ID: <>
From: Watson Ladd <>
To: Stephen Kent <>
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: Tue, 25 Aug 2015 14:43:19 -0000

On Tue, Aug 25, 2015 at 7:06 AM, Stephen Kent <> wrote:
> Watson,
> On 8/24/15 4:37 PM, Watson Ladd wrote:
> On Mon, Aug 24, 2015 at 1:08 PM, Stephen Kent <> wrote:
> Watson,
> based on many years of experience dealin wit this sort of issue
> I suggest that the relative merits (strength, etc.) of cipher suites
> form a lattice, not a total order.
> Every lattice has a compatible total order
> more properly, a total order can be imposed on a lattice.

I don't see the difference between these two statements, and I don't
see the relevance.
> , and preferences are
> expressed as total orders.
> The issue here is that reasonable people can disagree about
> the total order imposed on the lattice.
> Could you explain how your supposed insight
> "supposed insight" seems rather pejorative; better watch out for the
> IETF mail list PC police

Earlier people raised examples of ciphersuites with no comparison
between them. Why does what you are saying matter more? What's the
connection between being a lattice, and picking just one ranking not a
good idea.

> into the reality of comparing ciphersuites justifies exposing all
> possible ciphersuites, and permitting specifying arbitrary preferences
> among them?
> The preferences of others are "arbitrary" but yours are not?

Of course it's an arbitrary choice! My question is why is it not a
good idea to pick a single nothing-else-is better suite. and have a
mechanism designed to support migration if weaknesses are discovered?
So far as I can tell the argument has been that people have different
orderings, and should be allowed to express them. But this doesn't
actually get to the fundamental issue: how much more secure are people
if they will use X instead of Y if the other side wants it, then if
they prefer Y instead of X?

What happens in practice is that we end up with copypasta in config
files. And then when we do need to have a migration, instead of the
next version of the software automatically prefering the new thing,
configurations need to be changed. Of course you can always wash your
hands of this by saying software could have expressed the preferences
differently. But if software is going to do that, then we might as
well chop down on what the mechanism needs to express. There are real
benefits from shrinking code and reducing the complexity of the
versioning mechanism.

Downthread David Menzies is saying we only need three ciphersuites,
with one explicitly as a backup for the other. So what's gained from
being able to reverse that ordering? I do think we can't actually
specify a backup until the primary is weak: remember when RC4 was the
solution for Bard's attack on TLS 1.0?

Watson Ladd
> Steve
> _______________________________________________
> Tcpinc mailing list

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