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

Joe Touch <> Mon, 06 February 2017 16:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50AEF12943A; Mon, 6 Feb 2017 08:35:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TpxUOemyrLPQ; Mon, 6 Feb 2017 08:35:16 -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 E90DA129417; Mon, 6 Feb 2017 08:35:15 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v16GYW5v000331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Feb 2017 08:34:34 -0800 (PST)
To: David Mazieres expires 2017-05-06 PDT <>, "Scharf, Michael (Nokia - DE)" <>, "Holland, Jake" <>, "" <>
References: <> <> <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Mon, 06 Feb 2017 08:34:33 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Cc: "" <>
Subject: Re: [tcpinc] [tcpm] 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: Mon, 06 Feb 2017 16:35:17 -0000


On 2/5/2017 5:26 AM, David Mazieres wrote:
> "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--
The non-SYN extension is currently a WG document and intended for
>    particularly those that apply to SYN segments
The SYN extension proposals all have significant known issues and are
both highly experimental and difficult to deploy.

> --TCP-layer encryption
>    could significantly benefit from the availability of increased SYN
>    option space.
It might be useful to differentiate between the potential use of non-SYN
vs. SYN space.

You should be more explicit that "Although this protocol could benefit
from extended SYN space, e.g., to support in-band key coordination,
future TEPs should expect to use only the currently available space."

IMO, the following is speculative and not useful:

>   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.
The following appears to direct TCPM docs to update this doc, which is
not appropriate. If there is a SYN extension, it is much more likely to
be a stand-alone doc to update RFC793 and other docs would individually
update protocols that might benefit from that space.

>   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.
Actually, the above is much more useful (IMO), but most of the rest of
the paragraph can be omitted.


> 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
> _______________________________________________
> tcpm mailing list