Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Sun, 05 February 2017 13:26 UTC
Return-Path: <dm-list-tcpcrypt@scs.stanford.edu>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38DA12955F; Sun, 5 Feb 2017 05:26:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yRkRA8Faig9; Sun, 5 Feb 2017 05:26:48 -0800 (PST)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D01129422; Sun, 5 Feb 2017 05:26:48 -0800 (PST)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v15DQkE6000552; Sun, 5 Feb 2017 05:26:46 -0800 (PST)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v15DQjXE017739; Sun, 5 Feb 2017 05:26:45 -0800 (PST)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, "Holland, Jake" <jholland@akamai.com>, "tcpinc@ietf.org" <tcpinc@ietf.org>
In-Reply-To: <655C07320163294895BBADA28372AF5D48D1DE65@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <D668D28F-42BB-40A4-81D1-1FF2D3D95ECB@akamai.com> <87fujvonza.fsf@ta.scs.stanford.edu> <1FD85C9B-BE52-4E9F-A6D9-54BAD0425C8A@akamai.com> <655C07320163294895BBADA28372AF5D48D1DE65@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Date: Sun, 05 Feb 2017 05:26:42 -0800
Message-ID: <87zii0ydil.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/wt5WgU0W3XcEARm0mcRnHQ6AKbk>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: David Mazieres expires 2017-05-06 PDT <mazieres-pkmdzkf62nfmb5xbagc254xup6@temporary-address.scs.stanford.edu>
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Feb 2017 13:26:50 -0000
"Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com> writes: > While TCPM discusses large SYN options (for a long time already), all > known solutions have downsides. I do not believe that a non-TCPM > document should speculate on the feasibility solutions. Michael, what do you think of the new proposed wording? Various proposals exist to increase the maximum space for options in the TCP header. Though these proposals are highly experimental-- particularly those that apply to SYN segments--TCP-layer encryption could significantly benefit from the availability of increased SYN option space. In particular, if future TEPs can perform key agreement by embedding public keys or Diffie-Hellman parameters within suboption data, it will simplify protocols and reduce the number of round trips required for connection setup. With large options, the 32-byte limit on length bytes could prove insufficient. This draft intentionally aborts TCP-ENO if a length byte is followed by an octet in the range 0x00-0x9f. Any document updating TCP's option size limit can also define the format of larger suboptions by updating this draft to assign meaning to such currently undefined byte sequences. Our goal is not to second-guess TCPM, but rather to provide TCPM with a data point that they have a "customer" for large SYN options in the unlikely event that some proposal is ever deemed realistic. I could make the wording even stronger, as in: These proposals are highly experimental--with those that apply to SYN segments particularly unlikely to be adopted any time soon--but TCP-layer encryption could significantly benefit from the availability of increased SYN option space. But that could be seen as second-guessing TCPM in the other direction--telling TCPM we *don't* expect them to standardize large SYN options anytime soon. (Of course, it's true that I don't expect them to do that, but it might not be my place to say so in an RFC unless you sign off on the language...) As always, concrete suggestions on wording are appreciated. Thanks, David
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Holland, Jake
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno David Mazieres
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Holland, Jake
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno David Mazieres
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Holland, Jake
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno David Mazieres
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Scharf, Michael (Nokia - DE)
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno David Mazieres
- Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tc… Joe Touch
- Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tc… Joe Touch
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Holland, Jake
- Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tc… Scharf, Michael (Nokia - DE)
- Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tc… Black, David