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

David Mazieres <> Thu, 27 August 2015 17:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 46A3E1B37B2 for <>; Thu, 27 Aug 2015 10:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.078
X-Spam-Level: ***
X-Spam-Status: No, score=3.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, 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 lFf53ZeXXQPr for <>; Thu, 27 Aug 2015 10:32:49 -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 957401B341D for <>; Thu, 27 Aug 2015 10:32:49 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id t7RHWnhd008772; Thu, 27 Aug 2015 10:32:49 -0700 (PDT)
Received: (from dm@localhost) by (8.14.7/8.14.7/Submit) id t7RHWmMj022473; Thu, 27 Aug 2015 10:32:48 -0700 (PDT)
X-Authentication-Warning: dm set sender to using -f
From: David Mazieres <>
To: Kyle Rose <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 27 Aug 2015 10:32:48 -0700
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Cc: Eric Rescorla <>, Mirja Kühlewind <>, tcpinc <>
Subject: Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: David Mazieres expires 2015-11-25 PST <>
List-Id: "Discussion list for adding encryption to TCP." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Aug 2015 17:32:50 -0000

Kyle Rose <> writes:

> I think maybe what Mirja is implying is that it's okay to break TCP
> (i.e., not fall back to unencrypted) if the two peers explicitly set
> their roles locally to the same thing. TCP-ENO-aware applications that
> set the role are assumed to get it right and not set both to A or both
> to B.
> Question re: the WG goals: is it in fact okay not to always fall back
> to unencrypted TCP if the applications themselves are aware of TCPINC
> and relying on TCPINC-specific API calls?

So to be pedantic here, we are now assuming a design with three local
states for each side, let's call them NULL, A, and B.  If both sides of
a simultaneous open are NULL (the default) you get unencrypted TCP.  If
one side is A and the other is B, you get TCP-ENO.  In the other 6
permutations, you get complete connection failure.

I don't particularly love that or foresee getting a WG consensus behind
it, but I guess I could live with it.  Moreover, it doesn't really
address any of the "hot" TCP-SO questions at this point, which are:

 1. Does TCP-SO really exist in the wild, and if so under what
    circumstances (NAT, no NAT, etc.)?

 2. If applications of TCP-SO exist, must TCPINC support them
    unmodified, or is it okay to disable encryption in the absence of a
    setsockopt on at least one end of the connection?

 3. If we require a setsockopt to encrypt a TCP-SO connection, is it
    okay to ask applications to break the tie as well?

For my part, I'm beginning to have doubts about 1, but answer YES to 2
and 3.