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

Wesley Eddy <> Thu, 16 February 2017 04:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F642129437 for <>; Wed, 15 Feb 2017 20:34:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GVV77Ccxyhrk for <>; Wed, 15 Feb 2017 20:34:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D94B61288B8 for <>; Wed, 15 Feb 2017 20:34:01 -0800 (PST)
Received: by with SMTP id p22so5848302qka.0 for <>; Wed, 15 Feb 2017 20:34:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=u8auIzDCt/3IxieybhD2RhM3GkusM0JV/rJ8SIT0FpA=; b=z/HGuRpKeLNAF8qVQe3PjZOWduypdZaz8YWh/kb4J3FhJP2V/iG+lUlqVQJyWVaWEy Hy+ePr0PvoMV4FvcScjASl1ULJZw24KTU1q9QTdnWm8wsJTDW5IZVE3mS+X82iWRRmZ8 gyMwr97pnLIfbXONtE3a0pm3VeBamG6dSENcq52CpSXwInSrnw8k8nDcN5WNciJmL/hX IGwuTBdUpSye0qu+XfpXTBzFLXD1Nwjc63P4svXKegtn8yCW8aimexcb8t4qVHvDY2vy au81Btch5bfOu1sNhbWSQXOYipVpQ2Z5W3whpodGFNF+mzQCsnv97t4S8yw8zccQevDP YxMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=u8auIzDCt/3IxieybhD2RhM3GkusM0JV/rJ8SIT0FpA=; b=YlDEwh8IuigniSW93n8WGEgl402UAQuuMR0QTWV39nSZUsTVbmXzGcKz+QEdL5Cos/ 1UP8oiUpE0mfNYhsZsoOqQKbUOlVX7TVmfk4cgCCjvwJ15H6AxK7HXcxNJonVCIxPGgz HyqpHssQxBBJuqvSy0j41yc1Fy+/FVOmwpYCZ0ITQIC+5vAoZI7ez7Yqc9d59KdlojvM USEC1qF3FlQqh7J4mbhNpm6NK7NY3XzBmDk0cC1O1rbnAGAITGLcoeUe6OS5PkbIXzd4 RoiDOlHY0IjsDN+S3+synoSokdoTNtJK7FHlPbecAeBMJfEsy0Ye54SIR6wMl2QNrK0M rshw==
X-Gm-Message-State: AMke39k578hTNd3mD55fNqMk6CgZVJ8Ikuue3jo4OMOeGIZGtchi9QN/EmITPiZrqWKCUw==
X-Received: by with SMTP id 2mr296573qkh.228.1487219640550; Wed, 15 Feb 2017 20:34:00 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id c195sm1649234qke.55.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 20:34:00 -0800 (PST)
References: <>
From: Wesley Eddy <>
Message-ID: <>
Date: Wed, 15 Feb 2017 23:33:55 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------B4690E6082D3AF2714962777"
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 04:34:03 -0000

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).

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, 

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.

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