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

David Mazieres <> Sun, 23 August 2015 16:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3CFCF1ACF55 for <>; Sun, 23 Aug 2015 09:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.79
X-Spam-Level: **
X-Spam-Status: No, score=2.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_SUMOF=1, 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 G2uw7J49yabD for <>; Sun, 23 Aug 2015 09:38:31 -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 740C01A92E2 for <>; Sun, 23 Aug 2015 09:38:31 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id t7NGcTv6003092; Sun, 23 Aug 2015 09:38:29 -0700 (PDT)
Received: (from dm@localhost) by (8.14.7/8.14.7/Submit) id t7NGcTHv003612; Sun, 23 Aug 2015 09:38:29 -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 09:38:28 -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 16:38:32 -0000

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.

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.

> 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