Re: [tcpinc] draft-bittau-tcpinc-tcpeno-02

David Mazieres <> Sun, 20 September 2015 19:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 037541A92EB for <>; Sun, 20 Sep 2015 12:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.91
X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c8dOxJFLghWl for <>; Sun, 20 Sep 2015 12:58:22 -0700 (PDT)
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 488C61A914F for <>; Sun, 20 Sep 2015 12:58:22 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id t8KJwHNb028895; Sun, 20 Sep 2015 12:58:17 -0700 (PDT)
Received: (from dm@localhost) by (8.14.7/8.14.7/Submit) id t8KJwHR7031851; Sun, 20 Sep 2015 12:58:17 -0700 (PDT)
X-Authentication-Warning: dm set sender to using -f
From: David Mazieres <>
To: "Scharf\, Michael \(Michael\)" <>, tcpinc <>
In-Reply-To: <>
References: <>
Date: Sun, 20 Sep 2015 12:58:17 -0700
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [tcpinc] draft-bittau-tcpinc-tcpeno-02
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: David Mazieres expires 2015-12-19 PST <>
List-Id: "Discussion list for adding encryption to TCP." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 20 Sep 2015 19:58:25 -0000

"Scharf, Michael (Michael)" <> writes:

> I have read draft-bittau-tcpinc-tcpeno-02, given that the topic seems
> related to other TCP modifications. Below are a couple of comments;
> some could be more major than others. Disclaimer: I don't have much
> cycles to look into tcpinc, i.e., I apologize if some aspects been
> discussed already.

Thanks for the detailed feedback.  I believe we can address many of your
comments pretty easily.  Most of the others would depend on WG
consensus, but the draft could be adopted either way.  There's only one
suggestion I think would be problematic to adopt, which is in your
comments on section 4.  I'll go through each point.

> * Abstract, page 1: The abstract confuses me. Should the sentence "The
> TCP Encryption Negotiation Option (TCP-ENO) addresses both of these
> problems" imply that this document shall finally also specify the
> encryption within the transport layer, being the second problem? Why
> doesn't the abstract simply focus on negotiation and mention that it
> specifies an option limited to the TCP three-way-handshake to solve
> the negotiation problem?

The abstract here is just trying to give motivation.  So by addresses we
didn't mean solves.  TCP-ENO does not solve either of those problems
without an encryption spec, but is motivated by both.  Would it help if
instead of "addresses" we said "is motivated by"?

> * Section 2, page 3: To me, the whole text on page 2 includes too much
> hand-having. Some examples: The relation between this document and EDO
> is unclear and not further detailed later. The socket interface is not
> owned by the IETF, and RFC 3493 is an informational document for IPv6
> only. It is not clear how TFO (RFC 7413) would be used together with
> this option, and, if so, if stack vendors would be interested in
> deploying both options together. Basically, I think page 2 could be
> removed entirely without affecting the content of the document.

Removing this text seems fine.  It's partly there just to provide some
context/motivation for the working group, so perhaps this is the sort of
thing we could remove after adoption.  There's a longer argument to be
made for each of these points, but it doesn't really belong in the
TCP-ENO document itself, so killing the text might be a reasonable way

> * Section 2, page 4: "Provide signaling through which applications can
> better take advantage of TCP-level encryption (for instance by
> improving authentication mechanisms in the presence of TCP-level
> encryption)." Since authentication is listed here: How does this
> option interact with TCP-AO? For instance, I think this document could
> perhaps discuss what a receiver may do if a SYN segment both with
> TCP-ENO and TCP-AO options is received. This is a question much closer
> to the SYN handshake negotiation mechanics than various other sections
> of the document.

The higher-layer authentication taking advantage of TCP-level encryption
is at a higher layer than TCP-AO.  In particular, it would take place by
exchanging bytes over the TCP connection itself.  Hence, I see only one
reasonable approach:  First check TCP-AO.  If TCP-AO discards the
packet, then TCP-ENO is irrelevant.  Otherwise, proceed as usual with

Does that make sense to you?  And is it worth detailing in the document?

> * Section 3, page 5: Regarding the sentence "Encryption specs MAY
> include extra bytes in a non-SYN ENO option, but TCP-ENO itself MUST
> ignore them." and Figure 2: I suggest to keep this document entirely
> self-contained, which to me means something like: "If a non-SYN
> options contains extra bytes, TCP-ENO itself MUST ignore them." If a
> protocol negotiated by TCP-ENO indeed needs further TCP option space,
> this should be documented in the corresponding protocol specification.

I'm going to lump this together with your next comment.

>   - Option kind sharing: For this spec, it is sufficient to specify
>   how the option is used within this specification. This section can
>   thus be removed entirely.

I agree that how to do option kind sharing is a property of encryption
specs, not TCP-ENO.  However, the fact that TCP-ENO is amenable to such
sharing is an attractive property.  So it seemed useful somewhere to
record the fact that this property isn't just an accident.  If someday
somebody proposes an encryption spec that shares ENO's option kind, we
don't want them to meet resistance on the grounds that they are
squatting on a different RFC's option kind.

So basically the intent of section 4.2 is A) to serve as a reminder not
to mess up this sharability property as we edit the draft, B) to avoid
resistance for specs that do such sharing, and C) to serve as a strong
suggestion to any future TCP-ENO revisions to confine themselves to SYN
segments.  Would you be happier if we moved it to an appendix?  Or maybe
we could leave it in as a reminder while the document is being edited,
and then take it out at the last minute?

> * Section 3.2, page 7: I am confused by some RFC 2119 language in this
> section. Examples:
>   - "More precisely, for negotiation to succeed, the TCP-ENO option
>   MUST be present in the SYN segment sent by each host" =>
>   lower-capital or (better) reword to required implementation behavior
>   - "Additionally, the ENO option MUST be present in the first ACK segment sent by each host, so as to indicate that no
>    middlebox stripped the ENO option from the ACKed SYN." => lower-capital or (better) reword to required implementation behavior
>   - ... (several further examples of the same form)

I see.  Is the issue that the MUST isn't really associated with an
action on the part of an endpoint?  So would an informal description
("TCP-ENO can't work unless A, B, C"), followed be a more active
"implementations MUST disable encryption if..." be better?

> * Section 3.2, page 7: "An active opener begins with a SYN-only
> segment, and hence must send two segments containing ENO options."
> That "must" would be a candidate for RFC 2119, but in fact I think the
> sentence is actually even wrong, given that an active opener "must"
> only send ENO options in the first segment for the fallback case.

Indeed, good catch.

> * Section 3.2, page 7: The protocol specification has to correctly
> specify the behavior for retransmitted segments with SYN flag. The
> requirement stated on page 12 probably belongs here.

That should be pretty easy to address.

> * Section 3.2, page 9: "... and MUST NOT present raw TCP payload data
> to the application." Please specify the behavior for payload data in
> SYN segments, or explicitly mark it as in-scope of a protocol
> specification using this option. TFO (RFC 7413) could be relevant in
> this context.

Really the point is just that you want to make sure you don't end up
with one side encrypting, and the other side not encrypting.  What we
mean to say is that receiving an ACK segment with an ENO option is the
point of no return.  That implies that whatever is in TCP's payload
isn't what the application is writing.  But I agree talking about key
agreement and such may be too specific here.  It would probably be
clearer just to talk this in terms of enabled/disabled encryption.

> * Section 3.3, page 10: Protocol stacks on top of TCP can be complex
> and consist of multiple layers, libraries, etc. "application" is not
> well-defined in this case, and whether an application indeed can be
> aware of TCP stack internals, or not, is a relatively complex
> question. The concept of "application-awareness" in a multi-layer
> stack seems fuzzy to me, with lots of open questions. As a simple
> remedy, instead of "application-aware", the document could perhaps use
> a term like "upper layer protocol aware".

Yup, that sounds like a good suggestion.  (In fact, the companion
tcpinc-api informational document tries to shed some light on this, and
the suggested API changes are right on top of the socket layer, so very
low level.)

> * Section 4: I don't understand why any of the content in the whole
> section 4 is needed for interoperable implementations of a TCP option
> in SYNs. Specifically:
>   - Requirement list: In the IETF, requirement lists are typically
>   useful during WG operation, but they can easily become outdated,
>   e.g., by trends in the market. There has always been lots of
>   research innovation in TCP, and I could imagine that the TCP-ENO
>   negotiation option could find future interesting use outside of what
>   is known today.
>   - Session ID: To me, the definition of session IDs, if at all, has
>   to be done in specification of the encryption spec. I don't
>   understand why this section is needed for building interoperable
>   implementations of TCP-ENO, in particular, if not even the length is
>   defined (and that length definition does not belong in this
>   document, IMHO).

I think this is the one area where it would be harder to incorporate
your feedback.  The reason is that the main value of TCP-ENO is that it
can abstract away the differences between different TCP-layer encryption
schemes for applications.  So if I write an application that uses TCPINC
today, and tomorrow there's some new spec that takes advantage of TFO or
something, my application should still work unmodified TCP with the new
encryption spec.  This is only possible if there are certain standards
for how a TCP-ENO spec behaves.

To make this concrete, suppose a spec behaves as currently described in
the TCP-ENO draft, and an application starts digitally signing the
Session ID to authenticate the client to the server.  That's a perfectly
reasonable use of Session IDs as we envision them.  Now say a later spec
allows the client to determine the session ID.  That means all these
signed messages from past authentications are now effectively "blank
checks" that servers can use to impersonate clients to other servers.

> * Section 5: So far, the IETF has only rather limited credibility in
> specifying TCP API extensions, at least in my experience. Given that,
> this section could e.g. be moved to an appendix (see e.g. RFC 7413).

Well, RFC7413 actually specifies the API changes in the appendix.  In
our case, following the TCPINC charter, we don't even want to put the
suggested changes in the experimental RFC, but rather an informational
one.  We've proposed a draft for that informational document here:

So given that there will exist a separate informational document with an
example API, a reasonable question would be whether to mention this at
all in the ENO spec.  I think it's nice to remind implementers that they
SHOULD provide some sort of API (even if not the example one), but I
don't feel very strongly about it.  My preference might be to leave it
in, but if the WG wants to remove it, then that's fine, too.  It's just
a couple of sentences that won't otherwise affect anything the draft.

> * Section 6: Further topics to be considered here:
>   - Considerations of the space limitation in SYNs. Since this
>   document allows in principle an arbitrarily long TCP option,
>   discussion and guidance on that seems useful.
>   - Compatibility with other TCP extensions. Unless sorted out in this
>   document, potential interactions and/or incompatibility with TCP-AO,
>   MPTCP, TCP Fast Open, etc. should at least be mentioned as open
>   issue.

These are good points to mention.

> * Section 8: The IANA registration procedure for "cs" values has to be
> specified, and I could imagine different variants, which should
> probably be discussed relatively early.

Any suggestions or examples of other RFCs whose lead you think TCP-ENO
should follow?

> * Section 8: Why does TCP-ENO not allocate an TCP Experimental Option
> Experiment Identifier according to RFC 6994? That would be an easy
> solution to enable experiments with multiple interoperable
> implementations over the Internet, prior to assignment of a TCP option
> kind number. Keep in mind that an experimental document requires an
> explicit IESG action for TCP option kind assignment. In the past, TSV
> has asked for this IESG action several times. In those cases, there
> has been very strong consensus in the corresponding working group
> regarding the codepoint assignment, backed by reasonable interest by
> TCP stack vendors in the protocol.

The WG has debated this point before, and there didn't seem to be
consensus.  Some favor experimental option kinds.  Others believe this
will cause problems when we switch from experimental to regular.  (If I
recall, an example of that problem was NAT-T.)

The reality is that we've been using option kinds 69 and 70 in the wild
for encryption for many years, in software that's available for several
OS distros.  Before that, options 16 and 17 were allocated to encryption
and could safely be reused given that the old encryption scheme is no
longer or was never in use.  IANA has marked 69-70 as "Reserved (known
unauthorized use without proper IANA assignment)."  Realistically, at
this point the main danger is that our use of 69-70 annoys people, not
that we collide with other users in the wild.  (Plus, TCP-ENO's option
kind sharing means only one kind is required, not two.)

I hope that the lack of consensus on this this point doesn't stand in
the way of adopting the draft.  We could certainly adapt TCP-ENO either