Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

Joe Touch <> Thu, 16 February 2017 06:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF9DB129991 for <>; Wed, 15 Feb 2017 22:37:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mryA7UD_P1f6 for <>; Wed, 15 Feb 2017 22:37:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2AD45127078 for <>; Wed, 15 Feb 2017 22:37:52 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v1G6bRHu025581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Feb 2017 22:37:29 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-39A9D657-5CF0-4C3B-A536-4550A8EE26E3"
Mime-Version: 1.0 (1.0)
From: Joe Touch <>
X-Mailer: iPad Mail (14D27)
In-Reply-To: <>
Date: Wed, 15 Feb 2017 22:37:27 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <>
To: Wesley Eddy <>
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Feb 2017 06:37:54 -0000

> On Feb 15, 2017, at 8:33 PM, Wesley Eddy <> wrote:
> I haven't been following the WG discussions closely, so apologize in advance if this has been beat to death ... In reviewing the present draft, section 4.7 seems awkward to me.
> I think the WG should consider taking a position that data-on-SYN for TEPs should only be permitted to be sent if you have some prior indication that ENO is understood by the other end (e.g. via a cache entry from a previous connection, or other means).
FWIW, I don't much care what TCPINC decides, but the decision has consequences...
> While the draft correctly says that discarding data on SYNs may already be a common practice, it seems to me that there could be two issues, including:
> 1) edge cases where you're communicating with non-ENO hosts, that do not discard data on SYNs (for whatever reason), and may pollute the data stream delivered to the application, breaking the goals of TCPINC to work without impacting the application's TCP mapping
> 2) cases where other TCP extensions (perhaps yet to-be-defined) do something in conflict with that data
> I think it goes along with being 'conservative in what you send' to only include TEP data on the SYN if ENO is highly likely to be supported by the other side.
I'd prefer to be explicit:

- if non-data info is included in the TCP SYN payload, then this mechanism MUST abort SYN-ACKs that do not confirm TCPINC participation (i.e., fallback by aborting the current connection), which defeats transparent downgrade to legacy listeners.

That rule applies to all TCP extensions, and is discussed in draft-touch-tcpm-tcp-syn-ext-opt. 

The potential for other TCP options to have conflicting interpretations for that data would need to be dealt with in each such option in the context of options defined up to that point, but that seems like an unnecessary swamp to enter.


>> On 1/23/2017 6:15 PM, Kyle Rose wrote:
>> This is a working group last call for the "TCP-ENO: Encryption Negotiation Option" draft available at Please review the document and send your comments to the list by 2017-February-15.
>> -Kyle and David
>> _______________________________________________
>> Tcpinc mailing list
> _______________________________________________
> Tcpinc mailing list