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

David Mazieres <> Sun, 05 February 2017 13:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C38DA12955F; Sun, 5 Feb 2017 05:26:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5yRkRA8Faig9; Sun, 5 Feb 2017 05:26:48 -0800 (PST)
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 40D01129422; Sun, 5 Feb 2017 05:26:48 -0800 (PST)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id v15DQkE6000552; Sun, 5 Feb 2017 05:26:46 -0800 (PST)
Received: (from dm@localhost) by (8.15.2/8.15.2/Submit) id v15DQjXE017739; Sun, 5 Feb 2017 05:26:45 -0800 (PST)
From: David Mazieres <>
To: "Scharf, Michael (Nokia - DE)" <>, "Holland, Jake" <>, "" <>
In-Reply-To: <>
References: <> <> <> <>
Date: Sun, 05 Feb 2017 05:26:42 -0800
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Cc: "" <>
Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: David Mazieres expires 2017-05-06 PDT <>
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: Sun, 05 Feb 2017 13:26:50 -0000

"Scharf, Michael (Nokia - DE)" <> 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.