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

Watson Ladd <> Sun, 23 August 2015 16:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A30D71AD049 for <>; Sun, 23 Aug 2015 09:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.7
X-Spam-Level: *
X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rxa4LDq6wLVd for <>; Sun, 23 Aug 2015 09:43:00 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65FF91AD01E for <>; Sun, 23 Aug 2015 09:43:00 -0700 (PDT)
Received: by widdq5 with SMTP id dq5so52754063wid.0 for <>; Sun, 23 Aug 2015 09:42:59 -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=xHggwLg9E1c+kkx0Zyf13sPtzMKxojXeXlqpBkJYdyA=; b=D1GuqBa9tBoDEneQydpPoAnmet9h+GVEZVTnaNeVOqZ6GCiaMgeb49etJ/9bIRIbaM 89kiwd7QFkbYVn4JFdq5TpasIp38AeigPXrgAA01XFLv70HmWpsFVYZtfb+PNPUSeVJi nfWG1y532vQdVXud6fw1Eig7hfFYMCqhHBGTVdguOEvkUZZ7vlZBFQy4wiAqdshcJDmz +NwgwYPd5wz5eF3P7Li7pZgxR+B9Jc4X89oeAu5RmpD7OWkRJdGeShBqT67UzHt5XKmN 5RFm36+eFTlW3+GE6U5wPvgoLY6vZg9+WbdH0WVTtyATDf1GJsBIkaCggWIpeqBP5uG2 f4mg==
MIME-Version: 1.0
X-Received: by with SMTP id r10mr21692505wix.18.1440348179044; Sun, 23 Aug 2015 09:42:59 -0700 (PDT)
Received: by with HTTP; Sun, 23 Aug 2015 09:42:58 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Sun, 23 Aug 2015 09:42:58 -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 16:43:01 -0000

On Sun, Aug 23, 2015 at 9:38 AM, David Mazieres
<> wrote:
> Watson Ladd <> writes:
>> So 50% of the time, encryption fails between two parties both
>> supporting the spec, when using simultaneous open. Why not impose a
>> fixed ordering on all possible options and use the best mutually
>> supported option, aka versioning?
> No, encryption fails 100% of the time, because the b bit defaults to 0.
> As currently written, TCP-ENO requires application involvement to enable
> encryption under simultaneous open.

Ok, I got confused about what b was doing. I thought it was
disambiguating and picked randomly.

> The fixed ordering seems potentially harmful, because it might
> prioritize weak protocols over newer strong ones.  But maybe we could
> have some kind of combination, like assign all suboptions consecutive
> numbers in each SYN, and take set of suboptions which have the maximum
> value of the sum of the two numbers in the two SYN segments, and then
> apply the fixed ordering based on that?  (Maximum will favor
> variable-length options.)  We're definitely open to suggestions, but I
> worry this can get kind of complicated pretty quickly.

Think of this "fixed ordering" as versioning, like HTTP/0.9, 1.0, 1.1,
2.0, etc. The idea is that we'd only introduce new versions when we
knew they were stronger than the old ones.

>> My question is as follows: If we're willing to add half an RTT of
>> latency because we can't put key material in the first flight,
>> we can do the following exchange in the following manner
>> A->B "I can speak X,Y,Z"
>> B->A: "X, and here is my key share"
>> A->B: "here is my key share".
> That's certainly the kind of thing TCP-ENO is designed to allow.
> However, we don't completely rule out doing the key exchange in the SYN,
> as that may turn out to be a useful encryption spec down the line.
>> In the simultaneous case we can do: (using ; as sequencing mark)
>> A->B: "I speak X, Y, Z"
>> B->A: "I speak X,Y,Z";
>> A->B: "My key"
>> B->A "My key"
>> A and B both know that X, Y, Z are ordered, and so can agree.
>> Now, both kinds of message are completely different, and so shouldn't
>> be variations on the same kind to avoid attacks based on confusing SYN
>> with SYN-ACK.
> Something like this might be viable.  Please spec it out in a bit more
> detail.

Will do sometime.
> David

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