doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc8547.txt b/doc/rfc/rfc8547.txt
new file mode 100644
index 0000000..1b8beaf
--- /dev/null
+++ b/doc/rfc/rfc8547.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Bittau
+Request for Comments: 8547                                        Google
+Category: Experimental                                         D. Giffin
+ISSN: 2070-1721                                      Stanford University
+                                                              M. Handley
+                                               University College London
+                                                             D. Mazieres
+                                                     Stanford University
+                                                                E. Smith
+                                                       Kestrel Institute
+                                                                May 2019
+
+
+                 TCP-ENO: Encryption Negotiation Option
+
+Abstract
+
+   Despite growing adoption of TLS, a significant fraction of TCP
+   traffic on the Internet remains unencrypted.  The persistence of
+   unencrypted traffic can be attributed to at least two factors.
+   First, some legacy protocols lack a signaling mechanism (such as a
+   STARTTLS command) by which to convey support for encryption, thus
+   making incremental deployment impossible.  Second, legacy
+   applications themselves cannot always be upgraded and therefore
+   require a way to implement encryption transparently entirely within
+   the transport layer.  The TCP Encryption Negotiation Option (TCP-ENO)
+   addresses both of these problems through a new TCP option kind
+   providing out-of-band, fully backward-compatible negotiation of
+   encryption.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are candidates for any level of
+   Internet Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8547.
+
+
+
+
+Bittau, et al.                Experimental                      [Page 1]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+Copyright Notice
+
+   Copyright (c) 2019 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bittau, et al.                Experimental                      [Page 2]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+     1.1.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   5
+   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   4.  TCP-ENO Specification . . . . . . . . . . . . . . . . . . . .   6
+     4.1.  ENO Option  . . . . . . . . . . . . . . . . . . . . . . .   7
+     4.2.  The Global Suboption  . . . . . . . . . . . . . . . . . .   9
+     4.3.  TCP-ENO Roles . . . . . . . . . . . . . . . . . . . . . .  10
+     4.4.  Specifying Suboption Data Length  . . . . . . . . . . . .  11
+     4.5.  The Negotiated TEP  . . . . . . . . . . . . . . . . . . .  12
+     4.6.  TCP-ENO Handshake . . . . . . . . . . . . . . . . . . . .  13
+     4.7.  Data in SYN Segments  . . . . . . . . . . . . . . . . . .  14
+     4.8.  Negotiation Transcript  . . . . . . . . . . . . . . . . .  16
+   5.  Requirements for TEPs . . . . . . . . . . . . . . . . . . . .  16
+     5.1.  Session IDs . . . . . . . . . . . . . . . . . . . . . . .  18
+   6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
+   7.  Future Developments . . . . . . . . . . . . . . . . . . . . .  21
+   8.  Design Rationale  . . . . . . . . . . . . . . . . . . . . . .  22
+     8.1.  Handshake Robustness  . . . . . . . . . . . . . . . . . .  22
+     8.2.  Suboption Data  . . . . . . . . . . . . . . . . . . . . .  22
+     8.3.  Passive Role Bit  . . . . . . . . . . . . . . . . . . . .  22
+     8.4.  Application-Aware Bit . . . . . . . . . . . . . . . . . .  23
+     8.5.  Use of ENO Option Kind by TEPs  . . . . . . . . . . . . .  24
+     8.6.  Unpredictability of Session IDs . . . . . . . . . . . . .  24
+   9.  Experiments . . . . . . . . . . . . . . . . . . . . . . . . .  24
+   10. Security Considerations . . . . . . . . . . . . . . . . . . .  25
+   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
+   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
+     12.1.  Normative References . . . . . . . . . . . . . . . . . .  28
+     12.2.  Informative References . . . . . . . . . . . . . . . . .  29
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  30
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  30
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bittau, et al.                Experimental                      [Page 3]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+1.  Introduction
+
+   Many applications and protocols running on top of TCP today do not
+   encrypt traffic.  This failure to encrypt lowers the bar for certain
+   attacks, harming both user privacy and system security.
+   Counteracting the problem demands a minimally intrusive, backward-
+   compatible mechanism for incrementally deploying encryption.  The TCP
+   Encryption Negotiation Option (TCP-ENO) specified in this document
+   provides such a mechanism.
+
+   Introducing TCP options, extending operating system interfaces to
+   support TCP-level encryption, and extending applications to take
+   advantage of TCP-level encryption all require effort.  To the
+   greatest extent possible, the effort invested in realizing TCP-level
+   encryption today needs to remain applicable in the future should the
+   need arise to change encryption strategies.  To this end, it is
+   useful to consider two questions separately:
+
+   1.  How to negotiate the use of encryption at the TCP layer
+
+   2.  How to perform encryption at the TCP layer
+
+   This document addresses question 1 with a new TCP option, ENO.
+   TCP-ENO provides a framework in which two endpoints can agree on a
+   TCP encryption protocol (TEP) out of multiple possible TEPs.  For
+   future compatibility, TEPs can vary widely in terms of wire format,
+   use of TCP option space, and integration with the TCP header and
+   segmentation.  However, ENO abstracts these differences to ensure the
+   introduction of new TEPs can be transparent to applications taking
+   advantage of TCP-level encryption.
+
+   Question 2 is addressed by one or more companion TEP specification
+   documents.  While current TEPs enable TCP-level traffic encryption
+   today, TCP-ENO ensures that the effort invested to deploy today's
+   TEPs will additionally benefit future ones.
+
+1.1.  Design Goals
+
+   TCP-ENO was designed to achieve the following goals:
+
+   1.  Enable endpoints to negotiate the use of a separately specified
+       TCP encryption protocol (TEP) suitable for either opportunistic
+       security [RFC7435] of arbitrary TCP communications or stronger
+       security of applications willing to perform endpoint
+       authentication.
+
+
+
+
+
+
+Bittau, et al.                Experimental                      [Page 4]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   2.  Transparently fall back to unencrypted TCP when not supported by
+       both endpoints.
+
+   3.  Provide out-of-band 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).
+
+   4.  Define a standard negotiation transcript that TEPs can use to
+       defend against tampering with TCP-ENO.
+
+   5.  Make parsimonious use of TCP option space.
+
+   6.  Define roles for the two ends of a TCP connection, so as to name
+       each end of a connection for encryption or authentication
+       purposes even following a symmetric simultaneous open.
+
+2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Terminology
+
+   Throughout this document, we use the following terms, several of
+   which have more detailed normative descriptions in [RFC793]:
+
+   SYN segment
+      A TCP segment in which the SYN flag is set
+
+   ACK segment
+      A TCP segment in which the ACK flag is set (which includes most
+      segments other than an initial SYN segment)
+
+   Non-SYN segment
+      A TCP segment in which the SYN flag is clear
+
+   SYN-only segment
+      A TCP segment in which the SYN flag is set but the ACK flag is
+      clear
+
+   SYN-ACK segment
+      A TCP segment in which the SYN and ACK flags are both set
+
+
+
+
+
+Bittau, et al.                Experimental                      [Page 5]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   Active opener
+      A host that initiates a connection by sending a SYN-only segment.
+      With the BSD socket API, an active opener calls "connect".  In
+      client-server configurations, active openers are typically
+      clients.
+
+   Passive opener
+      A host that does not send a SYN-only segment but responds to one
+      with a SYN-ACK segment.  With the BSD socket API, passive openers
+      call "listen" and "accept", rather than "connect".  In client-
+      server configurations, passive openers are typically servers.
+
+   Simultaneous open
+      The act of symmetrically establishing a TCP connection between two
+      active openers (both of which call "connect" with BSD sockets).
+      Each host of a simultaneous open sends both a SYN-only and a SYN-
+      ACK segment.  Simultaneous open is less common than asymmetric
+      open with one active and one passive opener, but it can be used
+      for NAT traversal by peer-to-peer applications [RFC5382].
+
+   TEP
+      A TCP encryption protocol intended for use with TCP-ENO and
+      specified in a separate document
+
+   TEP identifier
+      A unique 7-bit value in the range 0x20-0x7f that IANA has assigned
+      to a TEP
+
+   Negotiated TEP
+      The single TEP governing a TCP connection, determined by use of
+      the TCP ENO option specified in this document
+
+4.  TCP-ENO Specification
+
+   TCP-ENO extends TCP connection establishment to enable encryption
+   opportunistically.  It uses a new TCP option kind [RFC793] to
+   negotiate one among multiple possible TCP encryption protocols
+   (TEPs).  The negotiation involves hosts exchanging sets of supported
+   TEPs, where each TEP is represented by a suboption within a larger
+   TCP ENO option in the offering host's SYN segment.
+
+   If TCP-ENO succeeds, it yields the following information:
+
+   o  a negotiated TEP represented by a unique 7-bit TEP identifier,
+
+   o  a few extra bytes of suboption data from each host, if needed by
+      the TEP,
+
+
+
+
+Bittau, et al.                Experimental                      [Page 6]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   o  a negotiation transcript with which to mitigate attacks on the
+      negotiation itself,
+
+   o  role assignments designating one endpoint "host A" and the other
+      endpoint "host B", and
+
+   o  a bit available to higher-layer protocols at each endpoint for
+      out-of-band negotiation of updated behavior in the presence of TCP
+      encryption.
+
+   If TCP-ENO fails, encryption is disabled and the connection falls
+   back to traditional unencrypted TCP.
+
+   The remainder of this section provides the normative description of
+   the TCP ENO option and handshake protocol.
+
+4.1.  ENO Option
+
+   TCP-ENO employs an option in the TCP header [RFC793].  Figure 1
+   illustrates the high-level format of this option.
+
+         byte    0     1     2             N+1   (N+2 bytes total)
+              +-----+-----+-----+--....--+-----+
+              |Kind=|Len= |                    |
+              |  69 | N+2 | contents (N bytes) |
+              +-----+-----+-----+--....--+-----+
+
+                       Figure 1: The TCP-ENO Option
+
+   The contents of an ENO option can take one of two forms.  A SYN-form
+   ENO option, illustrated in Figure 2, appears only in SYN segments.  A
+   non-SYN-form ENO option, illustrated in Figure 3, appears only in
+   non-SYN segments.  The SYN-form ENO option acts as a container for
+   zero or more suboptions, labeled "Opt_0", "Opt_1", ... in Figure 2.
+   The non-SYN-form ENO option, by its presence, acts as a one-bit
+   acknowledgment, with the actual contents ignored by ENO.  Particular
+   TEPs MAY assign additional meaning to the contents of non-SYN-form
+   ENO options.  When a negotiated TEP does not assign such meaning, the
+   contents of a non-SYN-form ENO option MUST be zero bytes (i.e.,
+   N = 0) in sent segments and MUST be ignored in received segments.
+
+         byte    0     1     2     3                     ... N+1
+              +-----+-----+-----+-----+--...--+-----+----...----+
+              |Kind=|Len= |Opt_0|Opt_1|       |Opt_i|   Opt_i   |
+              |  69 | N+2 |     |     |       |     |   data    |
+              +-----+-----+-----+-----+--...--+-----+----...----+
+
+                       Figure 2: SYN-Form ENO Option
+
+
+
+Bittau, et al.                Experimental                      [Page 7]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+                      byte   0     1     2     N+1
+                          +-----+-----+-----...----+
+                          |Kind=|Len= |  ignored   |
+                          |  69 | N+2 | by TCP-ENO |
+                          +-----+-----+-----...----+
+
+            Figure 3: Non-SYN-Form ENO option, Where N MAY Be 0
+
+   Every suboption starts with a byte of the form illustrated in
+   Figure 4.  The high bit "v", when set, introduces suboptions with
+   variable-length data.  When v = 0, the byte itself constitutes the
+   entirety of the suboption.  The remaining 7-bit value, called "glt",
+   takes on various meanings as defined below:
+
+   o  Global configuration data (discussed in Section 4.2)
+
+   o  Suboption data length for the next suboption (discussed in
+      Section 4.4)
+
+   o  An offer to use a particular TEP defined in a separate TEP
+      specification document
+
+      bit   7   6   5   4   3   2   1   0
+          +---+---+---+---+---+---+---+---+
+          | v |            glt            |
+          +---+---+---+---+---+---+---+---+
+
+          v   - non-zero for use with variable-length suboption data
+          glt - Global suboption, Length, or TEP identifier
+
+                Figure 4: Format of Initial Suboption Byte
+
+   Table 1 summarizes the meaning of initial suboption bytes.  Values of
+   glt below 0x20 are used for global suboptions and length information
+   (the "gl" in "glt"), while those greater than or equal to 0x20 are
+   TEP identifiers (the "t").  When v = 0, since the initial suboption
+   byte constitutes the entirety of the suboption, all information is
+   expressed by the 7-bit glt value, which can be either a global
+   suboption or a TEP identifier.  When v = 1, it indicates a suboption
+   with variable-length suboption data.  Only TEP identifiers have
+   suboption data, not global suboptions.  Therefore, bytes with v = 1
+   and glt < 0x20 are not global suboptions but rather length bytes
+   governing the length of the next suboption (which MUST be a TEP
+   identifier).  In the absence of a length byte, a TEP identifier
+   suboption with v = 1 has suboption data extending to the end of the
+   TCP option.
+
+
+
+
+
+Bittau, et al.                Experimental                      [Page 8]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+       +-----------+---+-------------------------------------------+
+       | glt       | v | Meaning                                   |
+       +-----------+---+-------------------------------------------+
+       | 0x00-0x1f | 0 | Global suboption (Section 4.2)            |
+       | 0x00-0x1f | 1 | Length byte (Section 4.4)                 |
+       | 0x20-0x7f | 0 | TEP identifier without suboption data     |
+       | 0x20-0x7f | 1 | TEP identifier followed by suboption data |
+       +-----------+---+-------------------------------------------+
+
+                  Table 1: Initial Suboption Byte Values
+
+   A SYN segment MUST contain at most one TCP ENO option.  If a SYN
+   segment contains more than one ENO option, the receiver MUST behave
+   as though the segment contained no ENO options and disable
+   encryption.  A TEP MAY specify the use of multiple ENO options in a
+   non-SYN segment.  For non-SYN segments, ENO itself only distinguishes
+   between the presence or absence of ENO options; multiple ENO options
+   are interpreted the same as one.
+
+4.2.  The Global Suboption
+
+   Suboptions 0x00-0x1f are used for global configuration that applies
+   regardless of the negotiated TEP.  A TCP SYN segment MUST include at
+   most one ENO suboption in this range.  A receiver MUST ignore all but
+   the first suboption in this range in any given TCP segment so as to
+   anticipate updates to ENO that assign new meaning to bits in
+   subsequent global suboptions.  The value of a global suboption byte
+   is interpreted as a bit mask, illustrated in Figure 5.
+
+               bit   7   6   5   4   3   2   1   0
+                   +---+---+---+---+---+---+---+---+
+                   | 0 | 0 | 0 |z1 |z2 |z3 | a | b |
+                   +---+---+---+---+---+---+---+---+
+
+                   b  - Passive role bit
+                   a  - Application-aware bit
+                   z* - Zero bits (reserved for future use)
+
+               Figure 5: Format of the Global Suboption Byte
+
+   The fields of the bit mask are interpreted as follows:
+
+   b
+      The passive role bit MUST be 1 for all passive openers.  For
+      active openers, it MUST default to 0, but implementations MUST
+      provide an API through which an application can explicitly set b =
+      1 before initiating an active open.  (Manual configuration of "b"
+      is only necessary to enable encryption with a simultaneous open
+
+
+
+Bittau, et al.                Experimental                      [Page 9]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+      and requires prior coordination to ensure exactly one endpoint
+      sets b = 1 before connecting.)  See Section 8.3 for further
+      discussion.
+
+   a
+      Legacy applications can benefit from ENO-specific updates that
+      improve endpoint authentication or avoid double encryption.  The
+      application-aware bit "a" is an out-of-band signal through which
+      higher-layer protocols can enable ENO-specific updates that would
+      otherwise not be backwards compatible.  Implementations MUST set
+      this bit to zero by default, and MUST provide an API through which
+      applications can change the value of the bit as well as examine
+      the value of the bit sent by the remote host.  Implementations
+      MUST furthermore support a mandatory application-aware mode in
+      which TCP-ENO is automatically disabled if the remote host does
+      not set a = 1.  See Section 8.4 for further discussion.
+
+   z1, z2, z3
+      The "z" bits are reserved for future updates to TCP-ENO.  They
+      MUST be set to zero in sent segments and MUST be ignored in
+      received segments.
+
+   A SYN segment without an explicit global suboption has an implicit
+   global suboption of 0x00.  Because passive openers MUST always set
+   b = 1, they cannot rely on this implicit 0x00 byte and MUST include
+   an explicit global suboption in their SYN-ACK segments.
+
+4.3.  TCP-ENO Roles
+
+   TCP-ENO uses abstract roles called "A" and "B" to distinguish the two
+   ends of a TCP connection.  These roles are determined by the "b" bit
+   in the global suboption.  The host that sent an implicit or explicit
+   suboption with b = 0 plays the A role.  The host that sent b = 1
+   plays the B role.  Because a passive opener MUST set b = 1 and an
+   active opener by default has b = 0, the normal case is for the active
+   opener to play role A and the passive opener role B.
+
+   Applications performing a simultaneous open, if they desire TCP-level
+   encryption, need to arrange for exactly one endpoint to set b = 1
+   (despite being an active opener) while the other endpoint keeps the
+   default b = 0.  Otherwise, if both sides use the default b = 0 or if
+   both sides set b = 1, then TCP-ENO will fail and fall back to
+   unencrypted TCP.  Likewise, if an active opener explicitly configures
+   b = 1 and connects to a passive opener (which MUST always have
+   b = 1), then TCP-ENO will fail and fall back to unencrypted TCP.
+
+
+
+
+
+
+Bittau, et al.                Experimental                     [Page 10]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   TEP specifications SHOULD refer to TCP-ENO's A and B roles to specify
+   asymmetric behavior by the two hosts.  For the remainder of this
+   document, we will use the terms "host A" and "host B" to designate
+   the hosts with roles A and B, respectively, in a connection.
+
+4.4.  Specifying Suboption Data Length
+
+   A TEP MAY optionally make use of one or more bytes of suboption data.
+   The presence of such data is indicated by setting v = 1 in the
+   initial suboption byte (see Figure 4).  A suboption introduced by a
+   TEP identifier with v = 1 (i.e., a suboption whose first octet has
+   value 0xa0 or higher) extends to the end of the TCP option.  Hence,
+   if only one suboption requires data, the most compact way to encode
+   it is to place it last in the ENO option, after all other suboptions.
+   In Figure 2, for example, the last suboption, Opt_i, has suboption
+   data and thus requires v = 1.  However, the suboption data length is
+   inferred from the total length of the TCP option.
+
+   When a suboption with data is not last in an ENO option, the sender
+   MUST explicitly specify the suboption data length for the receiver to
+   know where the next suboption starts.  The sender does so by
+   introducing the suboption with a length byte, depicted in Figure 6.
+   The length byte encodes a 5-bit value nnnnn.  Adding one to nnnnn
+   yields the length of the suboption data (not including the length
+   byte or the TEP identifier).  Hence, a length byte can designate
+   anywhere from 1 to 32 bytes of suboption data (inclusive).
+
+               bit   7   6   5   4   3   2   1   0
+                   +---+---+---+-------------------+
+                   | 1   0   0         nnnnn       |
+                   +---+---+---+-------------------+
+
+                   nnnnn - 5-bit value encoding (length - 1)
+
+                     Figure 6: Format of a Length Byte
+
+   A suboption preceded by a length byte MUST be a TEP identifier
+   (glt >= 0x20) and MUST have v = 1.  Figure 7 shows an example of such
+   a suboption.
+
+
+
+
+
+
+
+
+
+
+
+
+Bittau, et al.                Experimental                     [Page 11]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+       byte    0      1       2      nnnnn+2  (nnnnn+3 bytes total)
+            +------+------+-------...-------+
+            |length| TEP  | suboption data  |
+            | byte |ident.| (nnnnn+1 bytes) |
+            +------+------+-------...-------+
+
+            length byte    - specifies nnnnn
+            TEP identifier - MUST have v = 1 and glt >= 0x20
+            suboption data - length specified by nnnnn+1
+
+                   Figure 7: Suboption with Length Byte
+
+   A host MUST ignore an ENO option in a SYN segment and MUST disable
+   encryption if either of the following apply:
+
+   1.  A length byte indicates that suboption data would extend beyond
+       the end of the TCP ENO option.
+
+   2.  A length byte is followed by an octet in the range 0x00-0x9f
+       (meaning the following byte has v = 0 or glt < 0x20).
+
+   Because the last suboption in an ENO option is special-cased to have
+   its length inferred from the 8-bit TCP option length, it MAY contain
+   more than 32 bytes of suboption data.  Other suboptions are limited
+   to 32 bytes by the length byte format.  However, the TCP header
+   itself can only accommodate a maximum of 40 bytes of options.
+   Therefore, regardless of the length byte format, a segment would not
+   be able to contain more than one suboption over 32 bytes in size.
+   That said, TEPs MAY define the use of multiple suboptions with the
+   same TEP identifier in the same SYN segment, providing another way to
+   convey over 32 bytes of suboption data even with length bytes.
+
+4.5.  The Negotiated TEP
+
+   A TEP identifier glt (with glt >= 0x20) is valid for a connection
+   when all of the following hold:
+
+   1.  Each side has sent a suboption for glt in its SYN-form ENO
+       option.
+
+   2.  Any suboption data in these glt suboptions is valid according to
+       the TEP specification and satisfies any runtime constraints.
+
+   3.  If an ENO option contains multiple suboptions with glt, then such
+       repetition is well-defined by the TEP specification.
+
+
+
+
+
+
+Bittau, et al.                Experimental                     [Page 12]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   A passive opener (which is always host B) sees the remote host's SYN
+   segment before constructing its own SYN-ACK segment.  Therefore, a
+   passive opener SHOULD include only one TEP identifier in SYN-ACK
+   segments and SHOULD ensure this TEP identifier is valid.  However,
+   simultaneous open or implementation considerations can prevent host B
+   from offering only one TEP.
+
+   To accommodate scenarios in which host B sends multiple TEP
+   identifiers in the SYN-ACK segment, the negotiated TEP is defined as
+   the last valid TEP identifier in host B's SYN-form ENO option.  This
+   definition means host B specifies TEP suboptions in order of
+   increasing priority, while host A does not influence TEP priority.
+
+4.6.  TCP-ENO Handshake
+
+   A host employing TCP-ENO for a connection MUST include an ENO option
+   in every TCP segment sent until either encryption is disabled or the
+   host receives a non-SYN segment.  In particular, this means an active
+   opener MUST include a non-SYN-form ENO option in the third segment of
+   a three-way handshake.
+
+   A host MUST disable encryption, refrain from sending any further ENO
+   options, and fall back to unencrypted TCP if any of the following
+   occurs:
+
+   1.  Any segment it receives up to and including the first received
+       ACK segment does not contain an ENO option (or contains an ill-
+       formed SYN-form ENO option).
+
+   2.  The SYN segment it receives does not contain a valid TEP
+       identifier.
+
+   3.  It receives a SYN segment with an incompatible global suboption.
+       (Specifically, "incompatible" means the two hosts set the same
+       "b" value, or the connection is in mandatory application-aware
+       mode and the remote host set a = 0.)
+
+   Hosts MUST NOT alter SYN-form ENO options in retransmitted segments,
+   or between the SYN and SYN-ACK segments of a simultaneous open, with
+   two exceptions for an active opener.  First, an active opener MAY
+   unilaterally disable ENO (and thus remove the ENO option) between
+   retransmissions of a SYN-only segment.  (Such removal could enable
+   recovery from middleboxes dropping segments with ENO options.)
+   Second, an active opener performing simultaneous open MAY include no
+   TCP-ENO option in its SYN-ACK if the received SYN caused it to
+   disable encryption according to the above rules (for instance,
+   because role negotiation failed).
+
+
+
+
+Bittau, et al.                Experimental                     [Page 13]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   Once a host has both sent and received an ACK segment containing an
+   ENO option, encryption MUST be enabled.  Once encryption is enabled,
+   hosts MUST follow the specification of the negotiated TEP and MUST
+   NOT present raw TCP payload data to the application.  In particular,
+   data segments MUST NOT contain plaintext application data, but rather
+   ciphertext, key negotiation parameters, or other messages as
+   determined by the negotiated TEP.
+
+   A host MAY send a SYN-form ENO option containing zero TEP identifier
+   suboptions, which we term a "vacuous" ENO option.  If either host's
+   SYN segment contains a vacuous ENO option, it follows that there are
+   no valid TEP identifiers for the connection, and therefore the
+   connection MUST fall back to unencrypted TCP.  Hosts MAY send vacuous
+   ENO options to indicate that ENO is supported but unavailable by
+   configuration, or to probe network paths for robustness to ENO
+   options.  However, a passive opener MUST NOT send a vacuous ENO
+   option in a SYN-ACK segment unless there was an ENO option in the SYN
+   segment it received.  Moreover, a passive opener's SYN-form ENO
+   option MUST still include a global suboption with b = 1 as discussed
+   in Section 4.3.
+
+4.7.  Data in SYN Segments
+
+   TEPs MAY specify the use of data in SYN segments so as to reduce the
+   number of round trips required for connection setup.  The meaning of
+   data in a SYN segment with an ENO option (a SYN+ENO segment) is
+   determined by the last TEP identifier in the ENO option, which we
+   term the segment's "SYN TEP".  A SYN+ENO segment MAY of course
+   include multiple TEP suboptions, but only the SYN TEP (i.e., the last
+   one) specifies how to interpret the SYN segment's data payload.
+
+   A host sending a SYN+ENO segment MUST NOT include data in the segment
+   unless the SYN TEP's specification defines the use of such data.
+   Furthermore, to avoid conflicting interpretations of SYN data, a
+   SYN+ENO segment MUST NOT include a non-empty TCP Fast Open (TFO)
+   option [RFC7413].
+
+   Because a host can send SYN data before knowing which if any TEP the
+   connection will negotiate, hosts implementing ENO are REQUIRED to
+   discard data from SYN+ENO segments when the SYN TEP does not become
+   the negotiated TEP.  Hosts are furthermore REQUIRED to discard SYN
+   data in cases where another Internet standard specifies a conflicting
+   interpretation of SYN data (as would occur when receiving a non-empty
+   TFO option).  This requirement applies to hosts that implement ENO
+   even when ENO has been disabled by configuration.  However, note that
+   discarding SYN data is already common practice [RFC4987] and the new
+   requirement applies only to segments containing ENO options.
+
+
+
+
+Bittau, et al.                Experimental                     [Page 14]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   More specifically, a host that implements ENO MUST discard the data
+   in a received SYN+ENO segment if any of the following applies:
+
+   o  ENO fails and TEP-indicated encryption is disabled for the
+      connection.
+
+   o  The received segment's SYN TEP is not the negotiated TEP.
+
+   o  The negotiated TEP does not define the use of SYN data.
+
+   o  The SYN segment contains a non-empty TFO option or any other TCP
+      option implying a conflicting definition of SYN data.
+
+   A host discarding SYN data in compliance with the above requirement
+   MUST NOT acknowledge the sequence number of the discarded data, but
+   rather MUST acknowledge the other host's initial sequence number as
+   if the received SYN segment contained no data.  Furthermore, after
+   discarding SYN data, such a host MUST NOT assume the SYN data will be
+   identically retransmitted, and MUST process data only from non-SYN
+   segments.
+
+   If a host sends a SYN+ENO segment with data and receives
+   acknowledgment for the data, but the SYN TEP in its transmitted SYN
+   segment is not the negotiated TEP (either because a different TEP was
+   negotiated or because ENO failed to negotiate encryption), then the
+   host MUST abort the TCP connection.  Proceeding in any other fashion
+   risks misinterpreted SYN data.
+
+   If a host sends a SYN-only SYN+ENO segment bearing data and
+   subsequently receives a SYN-ACK segment without an ENO option, that
+   host MUST abort the connection even if the SYN-ACK segment does not
+   acknowledge the SYN data.  The issue is that unacknowledged data
+   could nonetheless have been cached by the receiver; later
+   retransmissions intended to supersede this unacknowledged data could
+   fail to do so if the receiver gives precedence to the cached original
+   data.  Implementations MAY provide an API call for a non-default mode
+   in which unacknowledged SYN data does not cause a connection abort,
+   but applications MUST use this mode only when a higher-layer
+   integrity check would anyway terminate a garbled connection.
+
+   To avoid unexpected connection aborts, ENO implementations MUST
+   disable the use of data in SYN-only segments by default.  Such data
+   MAY be enabled by an API command.  In particular, implementations MAY
+   provide a per-connection mandatory encryption mode that automatically
+   aborts a connection if ENO fails, and they MAY enable SYN data in
+   this mode.
+
+
+
+
+
+Bittau, et al.                Experimental                     [Page 15]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   To satisfy the requirement of the previous paragraph, all TEPs SHOULD
+   support a normal mode of operation that avoids data in SYN-only
+   segments.  An exception is TEPs intended to be disabled by default.
+
+4.8.  Negotiation Transcript
+
+   To defend against attacks on encryption negotiation itself, a TEP
+   MUST, with high probability, fail to establish a working connection
+   between two ENO-compliant hosts when SYN-form ENO options have been
+   altered in transit.  (Of course, in the absence of endpoint
+   authentication, two compliant hosts can each still be connected to a
+   man-in-the-middle attacker.)  To detect SYN-form ENO option
+   tampering, TEPs MUST reference a transcript of TCP-ENO's negotiation.
+
+   TCP-ENO defines its negotiation transcript as a packed data structure
+   consisting of two TCP-ENO options exactly as they appeared in the TCP
+   header (including the TCP option kind and TCP option length byte as
+   illustrated in Figure 1).  The transcript is constructed from the
+   following, in order:
+
+   1.  The TCP-ENO option in host A's SYN segment, including the kind
+       and length bytes
+
+   2.  The TCP-ENO option in host B's SYN segment, including the kind
+       and length bytes
+
+   Note that because the ENO options in the transcript contain length
+   bytes as specified by TCP, the transcript unambiguously delimits A's
+   and B's ENO options.
+
+5.  Requirements for TEPs
+
+   TCP-ENO affords TEP specifications a large amount of design
+   flexibility.  However, to abstract TEP differences away from
+   applications requires fitting them all into a coherent framework.  As
+   such, any TEP claiming an ENO TEP identifier MUST satisfy the
+   following normative list of properties:
+
+   o  TEPs MUST protect TCP data streams with authenticated encryption.
+      (Note that "authenticated encryption" refers only to the form of
+      encryption, such as an Authenticated Encryption with Associated
+      Data (AEAD) algorithm meeting the requirements of [RFC5116]; it
+      does not imply endpoint authentication.)
+
+   o  TEPs MUST define a session ID whose value identifies the TCP
+      connection and, with overwhelming probability, is unique over all
+      time if either host correctly obeys the TEP.  Section 5.1
+      describes the requirements of the session ID in more detail.
+
+
+
+Bittau, et al.                Experimental                     [Page 16]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   o  TEPs MUST NOT make data confidentiality dependent on encryption
+      algorithms with a security strength [NIST-SP-800-57] of less than
+      120 bits.  The number 120 was chosen to accommodate ciphers with
+      128-bit keys that lose a few bits of security either to
+      particularities of the key schedule or to highly theoretical and
+      unrealistic attacks.
+
+   o  TEPs MUST NOT allow the negotiation of null cipher suites, even
+      for debugging purposes.  (Implementations MAY support debugging
+      modes that allow applications to extract their own session keys.)
+
+   o  TEPs MUST guarantee the confidentiality of TCP streams without
+      assuming the security of any long-lived secrets.  Implementations
+      SHOULD provide forward secrecy soon after the close of a TCP
+      connection and SHOULD therefore bound the delay between closing a
+      connection and erasing any relevant cryptographic secrets.
+      (Exceptions to forward secrecy are permissible only at the
+      implementation level and only in response to hardware or
+      architectural constraints -- e.g., storage that cannot be securely
+      erased.)
+
+   o  TEPs MUST protect and authenticate the end-of-file marker conveyed
+      by TCP's FIN flag.  In particular, a receiver MUST, with
+      overwhelming probability, detect a FIN flag that was set or
+      cleared in transit and does not match the sender's intent.  A TEP
+      MAY discard a segment with such a corrupted FIN bit or MAY abort
+      the connection in response to such a segment.  However, any such
+      abort MUST raise an error condition distinct from an authentic
+      end-of-file condition.
+
+   o  TEPs MUST prevent corrupted packets from causing urgent data to be
+      delivered when none has been sent.  There are several ways to do
+      so.  For instance, a TEP MAY cryptographically protect the URG
+      flag and urgent pointer alongside ordinary payload data.
+      Alternatively, a TEP MAY disable urgent data functionality by
+      clearing the URG flag on all received segments and returning
+      errors in response to sender-side urgent-data API calls.
+      Implementations SHOULD avoid negotiating TEPs that disable urgent
+      data by default.  The exception is when applications and protocols
+      are known never to send urgent data.
+
+
+
+
+
+
+
+
+
+
+
+Bittau, et al.                Experimental                     [Page 17]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+5.1.  Session IDs
+
+   Each TEP MUST define a session ID that is computable by both
+   endpoints and uniquely identifies each encrypted TCP connection.
+   Implementations MUST expose the session ID to applications via an API
+   extension.  The API extension MUST return an error when no session ID
+   is available because ENO has failed to negotiate encryption or
+   because no connection is yet established.  Applications that are
+   aware of TCP-ENO SHOULD, when practical, authenticate the TCP
+   endpoints by incorporating the values of the session ID and TCP-ENO
+   role (A or B) into higher-layer authentication mechanisms.
+
+   In order to avoid replay attacks and prevent authenticated session
+   IDs from being used out of context, session IDs MUST be unique over
+   all time with high probability.  This uniqueness property MUST hold
+   even if one end of a connection maliciously manipulates the protocol
+   in an effort to create duplicate session IDs.  In other words, it
+   MUST be infeasible for a host, even by violating the TEP
+   specification, to establish two TCP connections with the same session
+   ID to remote hosts properly implementing the TEP.
+
+   To prevent session IDs from being confused across TEPs, all session
+   IDs begin with the negotiated TEP identifier -- that is, the last
+   valid TEP identifier in host B's SYN segment.  Furthermore, this
+   initial byte has bit "v" set to the same value that accompanied the
+   negotiated TEP identifier in B's SYN segment.  However, only this
+   single byte is included, not any suboption data.  Figure 8 shows the
+   resulting format.  This format is designed for TEPs to compute unique
+   identifiers; it is not intended for application authors to pick apart
+   session IDs.  Applications SHOULD treat session IDs as monolithic
+   opaque values and SHOULD NOT discard the first byte to shorten
+   identifiers.  (An exception is for non-security-relevant purposes,
+   such as gathering statistics about negotiated TEPs.)
+
+                 byte    0     1     2        N-1    N
+                      +-----+------------...------------+
+                      | sub-| collision-resistant hash  |
+                      | opt | of connection information |
+                      +-----+------------...------------+
+
+                     Figure 8: Format of a Session ID
+
+   Though TEP specifications retain considerable flexibility in their
+   definitions of the session ID, all session IDs MUST meet the
+   following normative list of requirements:
+
+   o  The session ID MUST be at least 33 bytes (including the one-byte
+      suboption), though TEPs MAY choose longer session IDs.
+
+
+
+Bittau, et al.                Experimental                     [Page 18]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   o  The session ID MUST depend, in a collision-resistant way, on all
+      of the following (meaning it is computationally infeasible to
+      produce collisions of the session ID derivation function unless
+      all of the following quantities are identical):
+
+      *  Fresh data contributed by both sides of the connection
+
+      *  Any public keys, public Diffie-Hellman parameters, or other
+         public asymmetric cryptographic parameters that are employed by
+         the TEP and have corresponding private data that is known by
+         only one side of the connection
+
+      *  The negotiation transcript specified in Section 4.8
+
+   o  Unless and until applications disclose information about the
+      session ID, all but the first byte MUST be computationally
+      indistinguishable from random bytes to a network eavesdropper.
+
+   o  Applications MAY choose to make session IDs public.  Therefore,
+      TEPs MUST NOT place any confidential data in the session ID (such
+      as data permitting the derivation of session keys).
+
+6.  Examples
+
+   This subsection illustrates the TCP-ENO handshake with a few non-
+   normative examples.
+
+             (1) A -> B:  SYN      ENO<X,Y>
+             (2) B -> A:  SYN-ACK  ENO<b=1,Y>
+             (3) A -> B:  ACK      ENO<>
+             [rest of connection encrypted according to TEP Y]
+
+     Figure 9: Three-Way Handshake with Successful TCP-ENO Negotiation
+
+   Figure 9 shows a three-way handshake with a successful TCP-ENO
+   negotiation.  Host A includes two ENO suboptions with TEP identifiers
+   X and Y.  Host A does not include an explicit global suboption, which
+   means it has an implicit global suboption 0x00 conveying passive role
+   bit b = 0.  The two sides agree to follow the TEP identified by
+   suboption Y.
+
+                (1) A -> B:  SYN      ENO<X,Y>
+                (2) B -> A:  SYN-ACK
+                (3) A -> B:  ACK
+                [rest of connection unencrypted legacy TCP]
+
+      Figure 10: Three-Way Handshake with Failed TCP-ENO Negotiation
+
+
+
+
+Bittau, et al.                Experimental                     [Page 19]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   Figure 10 shows a failed TCP-ENO negotiation.  The active opener (A)
+   indicates support for TEPs corresponding to suboptions X and Y.
+   Unfortunately, at this point, one of several things occurs:
+
+   1.  The passive opener (B) does not support TCP-ENO.
+
+   2.  B supports TCP-ENO but supports neither of the TEPs X and Y, and
+       so it does not reply with an ENO option.
+
+   3.  B supports TCP-ENO but has the connection configured in mandatory
+       application-aware mode and thus disables ENO because A's SYN
+       segment contains an implicit global suboption with a = 0.
+
+   4.  The network stripped the ENO option out of A's SYN segment, so B
+       did not receive it.
+
+   Whichever of the above applies, the connection transparently falls
+   back to unencrypted TCP.
+
+       (1) A -> B:  SYN      ENO<X,Y>
+       (2) B -> A:  SYN-ACK  ENO<b=1,X> [ENO stripped by middlebox]
+       (3) A -> B:  ACK
+       [rest of connection unencrypted legacy TCP]
+
+     Figure 11: Failed TCP-ENO Negotiation Because of Option Stripping
+
+   Figure 11 Shows another handshake with a failed encryption
+   negotiation.  In this case, the passive opener (B) receives an ENO
+   option from A and replies.  However, the reverse network path from B
+   to A strips ENO options.  Therefore, A does not receive an ENO option
+   from B, it disables ENO, and it does not include a non-SYN-form ENO
+   option in segment 3 when ACKing B's SYN.  Had A not disabled
+   encryption, Section 4.6 would have required it to include a non-SYN-
+   form ENO option in segment 3.  The omission of this option informs B
+   that encryption negotiation has failed, after which the two hosts
+   proceed with unencrypted TCP.
+
+             (1) A -> B:  SYN      ENO<Y,X>
+             (2) B -> A:  SYN      ENO<b=1,X,Y,Z>
+             (3) A -> B:  SYN-ACK  ENO<Y,X>
+             (4) B -> A:  SYN-ACK  ENO<b=1,X,Y,Z>
+             [rest of connection encrypted according to TEP Y]
+
+     Figure 12: Simultaneous Open with Successful TCP-ENO Negotiation
+
+   Figure 12 shows a successful TCP-ENO negotiation with simultaneous
+   open.  Here, the first four segments contain a SYN-form ENO option,
+   as each side sends both a SYN-only and a SYN-ACK segment.  The ENO
+
+
+
+Bittau, et al.                Experimental                     [Page 20]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   option in each host's SYN-ACK is identical to the ENO option in its
+   SYN-only segment, as otherwise, connection establishment could not
+   recover from the loss of a SYN segment.  The last valid TEP in host
+   B's ENO option is Y, so Y is the negotiated TEP.
+
+7.  Future Developments
+
+   TCP-ENO is designed to capitalize on future developments that could
+   alter trade-offs and change the best approach to TCP-level encryption
+   (beyond introducing new cipher suites).  By way of example, we
+   discuss a few such possible developments.
+
+   Various proposals exist to increase the maximum space for options in
+   the TCP header.  These proposals are highly experimental --
+   particularly those that apply to SYN segments.  Therefore, future
+   TEPs are unlikely to benefit from extended SYN option space.  In the
+   unlikely event that SYN option space is one day extended, however,
+   future TEPs could benefit by embedding key agreement messages
+   directly in SYN segments.  Under such usage, the 32-byte limit on
+   length bytes could prove insufficient.  This document intentionally
+   aborts TCP-ENO if a length byte is followed by an octet in the range
+   0x00-0x9f.  If necessary, a future update to this document can define
+   a format for larger suboptions by assigning meaning to such currently
+   undefined byte sequences.
+
+   New revisions to socket interfaces [RFC3493] could involve library
+   calls that simultaneously have access to hostname information and an
+   underlying TCP connection.  Such an API enables the possibility of
+   authenticating servers transparently to the application, particularly
+   in conjunction with technologies such as DNS-Based Authentication of
+   Named Entities (DANE) [RFC6394].  An update to TCP-ENO can adopt one
+   of the "z" bits in the global suboption to negotiate the use of an
+   endpoint authentication protocol before any application use of the
+   TCP connection.  Over time, the consequences of failed or missing
+   endpoint authentication can gradually be increased from issuing log
+   messages to aborting the connection if some as yet unspecified DNS
+   record indicates authentication is mandatory.  Through shared library
+   updates, such endpoint authentication can potentially be added
+   transparently to legacy applications without recompilation.
+
+   TLS can currently only be added to legacy applications whose
+   protocols accommodate a STARTTLS command or equivalent.  TCP-ENO,
+   because it provides out-of-band signaling, opens the possibility of
+   future TLS revisions being generically applicable to any TCP
+   application.
+
+
+
+
+
+
+Bittau, et al.                Experimental                     [Page 21]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+8.  Design Rationale
+
+   This section describes some of the design rationale behind TCP-ENO.
+
+8.1.  Handshake Robustness
+
+   Incremental deployment of TCP-ENO depends critically on failure cases
+   devolving to unencrypted TCP rather than causing the entire TCP
+   connection to fail.
+
+   Because a network path might drop ENO options in one direction only,
+   a host needs to know not just that the peer supports encryption, but
+   that the peer has received an ENO option.  To this end, ENO disables
+   encryption unless it receives an ACK segment bearing an ENO option.
+   To stay robust in the face of dropped segments, hosts continue to
+   include non-SYN-form ENO options in segments until the point that
+   they have received a non-SYN segment from the other side.
+
+   One particularly pernicious middlebox behavior found in the wild is
+   load balancers that echo unknown TCP options found in SYN segments
+   back to an active opener.  The passive role bit "b" in global
+   suboptions ensures encryption will always be disabled under such
+   circumstances, as sending back a verbatim copy of an active opener's
+   SYN-form ENO option always causes role negotiation to fail.
+
+8.2.  Suboption Data
+
+   TEPs can employ suboption data for session caching, cipher suite
+   negotiation, or other purposes.  However, TCP currently limits total
+   option space consumed by all options to only 40 bytes, making it
+   impractical to have many suboptions with data.  For this reason, ENO
+   optimizes the case of a single suboption with data by inferring the
+   length of the last suboption from the TCP option length.  Doing so
+   saves one byte.
+
+8.3.  Passive Role Bit
+
+   TCP-ENO, TEPs, and applications all have asymmetries that require an
+   unambiguous way to identify one of the two connection endpoints.  As
+   an example, Section 4.8 specifies that host A's ENO option comes
+   before host B's in the negotiation transcript.  As another example,
+   an application might need to authenticate one end of a TCP connection
+   with a digital signature.  To ensure the signed message cannot be
+   interpreted out of context to authenticate the other end, the signed
+   message would need to include both the session ID and the local role,
+   A or B.
+
+
+
+
+
+Bittau, et al.                Experimental                     [Page 22]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   A normal TCP three-way handshake involves one active and one passive
+   opener.  This asymmetry is captured by the default configuration of
+   the "b" bit in the global suboption.  With simultaneous open, both
+   hosts are active openers, so TCP-ENO requires that one host
+   explicitly configure b = 1.  An alternate design might automatically
+   break the symmetry to avoid this need for explicit configuration.
+   However, all such designs we considered either lacked robustness or
+   consumed precious bytes of SYN option space even in the absence of
+   simultaneous open.  (One complicating factor is that TCP does not
+   know it is participating in a simultaneous open until after it has
+   sent a SYN segment.  Moreover, with packet loss, one host might never
+   learn it has participated in a simultaneous open.)
+
+8.4.  Application-Aware Bit
+
+   Applications developed before TCP-ENO can potentially evolve to take
+   advantage of TCP-level encryption.  For instance, an application
+   designed to run only on trusted networks might leverage TCP-ENO to
+   run on untrusted networks, but, importantly, needs to authenticate
+   endpoints and session IDs to do so.  In addition to user-visible
+   changes such as requesting credentials, this kind of authentication
+   functionality requires application-layer protocol changes.  Some
+   protocols can accommodate the requisite changes -- for instance, by
+   introducing a new verb analogous to STARTTLS, while others cannot do
+   so in a backwards-compatible manner.
+
+   The application-aware bit "a" in the global suboption provides a
+   means of incrementally deploying enhancements specific to TCP-ENO to
+   application-layer protocols that would otherwise lack the necessary
+   extensibility.  Software implementing the enhancement always sets a =
+   1 in its own global suboption, but only activates the new behavior
+   when the other end of the connection also sets a = 1.
+
+   A related issue is that an application might leverage TCP-ENO as a
+   replacement for legacy application-layer encryption.  In this
+   scenario, if both endpoints support TCP-ENO, then application-layer
+   encryption can be disabled in favor of simply authenticating the TCP-
+   ENO session ID.  On the other hand, if one endpoint is not aware of
+   the new mode of operation specific to TCP-ENO, there is little
+   benefit to performing redundant encryption at the TCP layer; data is
+   already encrypted once at the application layer, and authentication
+   only has meaning with respect to this application-layer encryption.
+   The mandatory application-aware mode lets applications avoid double
+   encryption in this case: the mode sets a = 1 in the local host's
+   global suboption but also disables TCP-ENO entirely in the event that
+   the other side has not also set a = 1.
+
+
+
+
+
+Bittau, et al.                Experimental                     [Page 23]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   Note that the application-aware bit is not needed by applications
+   that already support adequate higher-layer encryption such as those
+   provided by TLS [RFC8446] or SSH [RFC4253].  To avoid double
+   encryption in such cases, it suffices to disable TCP-ENO by
+   configuration on any ports with known secure protocols.
+
+8.5.  Use of ENO Option Kind by TEPs
+
+   This document does not specify the use of ENO options beyond the
+   first few segments of a connection.  Moreover, it does not specify
+   the content of ENO options in non-SYN segments, only their presence.
+   As a result, any use of option kind 69 after the SYN exchange does
+   not conflict with this document.  In addition, because ENO guarantees
+   at most one negotiated TEP per connection, TEPs will not conflict
+   with one another or ENO if they use option kind 69 for out-of-band
+   signaling in non-SYN segments.
+
+8.6.  Unpredictability of Session IDs
+
+   Section 5.1 specifies that all but the first (TEP identifier) byte of
+   a session ID MUST be computationally indistinguishable from random
+   bytes to a network eavesdropper.  This property is easy to ensure
+   under standard assumptions about cryptographic hash functions.  Such
+   unpredictability helps security in a broad range of cases.  For
+   example, it makes it possible for applications to use a session ID
+   from one connection to authenticate a session ID from another,
+   thereby tying the two connections together.  It furthermore helps
+   ensure that TEPs do not trivially subvert the 33-byte minimum-length
+   requirement for session IDs by padding shorter session IDs with
+   zeros.
+
+9.  Experiments
+
+   This document has experimental status because TCP-ENO's viability
+   depends on middlebox behavior that can only be determined a
+   posteriori.  Specifically, we need to determine to what extent
+   middleboxes will permit the use of TCP-ENO.  Once TCP-ENO is
+   deployed, we will be in a better position to gather data on two types
+   of failure:
+
+   1.  Middleboxes downgrading TCP-ENO connections to unencrypted TCP.
+       This can happen if middleboxes strip unknown TCP options or if
+       they terminate TCP connections and relay data back and forth.
+
+   2.  Middleboxes causing TCP-ENO connections to fail completely.  This
+       can happen if middleboxes perform deep packet inspection and
+       start dropping segments that unexpectedly contain ciphertext, or
+
+
+
+
+Bittau, et al.                Experimental                     [Page 24]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+       if middleboxes strip ENO options from non-SYN segments after
+       allowing them in SYN segments.
+
+   Type-1 failures are tolerable since TCP-ENO is designed for
+   incremental deployment anyway.  Type-2 failures are more problematic,
+   and, if prevalent, will require the development of techniques to
+   avoid and recover from such failures.  The experiment will succeed so
+   long as we can avoid type-2 failures and find sufficient use cases
+   that avoid type-1 failures (possibly along with a gradual path for
+   further reducing type-1 failures).
+
+   In addition to the question of basic viability, deploying TCP-ENO
+   will allow us to identify and address other potential corner cases or
+   relaxations.  For example, does the slight decrease in effective TCP
+   segment payload pose a problem to any applications, which would
+   require restrictions on how TEPs interpret socket buffer sizes?
+   Conversely, can we relax the prohibition on default TEPs that disable
+   urgent data?
+
+   A final important metric, related to the pace of deployment and
+   incidence of type-1 failures, will be the extent to which
+   applications adopt enhancements specific to TCP-ENO for endpoint
+   authentication.
+
+10.  Security Considerations
+
+   An obvious use case for TCP-ENO is opportunistic encryption, e.g.,
+   encrypting some connections, but only where supported and without any
+   kind of endpoint authentication.  Opportunistic encryption provides a
+   property known as "opportunistic security" [RFC7435], which protects
+   against undetectable large-scale eavesdropping.  However, it does not
+   protect against detectable large-scale eavesdropping (for instance,
+   if ISPs terminate TCP connections and proxy them or simply downgrade
+   connections to unencrypted).  Moreover, opportunistic encryption
+   emphatically does not protect against targeted attacks that employ
+   trivial spoofing to redirect a specific high-value connection to a
+   man-in-the-middle attacker.  Hence, the mere presence of TEP-
+   indicated encryption does not suffice for an application to represent
+   a connection as secure to the user.
+
+   Achieving stronger security with TCP-ENO requires verifying session
+   IDs.  Any application relying on ENO for communication security MUST
+   incorporate session IDs into its endpoint authentication.  By way of
+   example, an authentication mechanism based on keyed digests (such as
+   Digest Access Authentication [RFC7616]) can be extended to include
+   the role and session ID in the input of the keyed digest.
+   Authentication mechanisms with a notion of channel binding (such as
+   Salted Challenge Response Authentication Mechanism (SCRAM) [RFC5802])
+
+
+
+Bittau, et al.                Experimental                     [Page 25]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   can be updated to derive a channel binding from the session ID.
+   Higher-layer protocols MAY use the application-aware "a" bit to
+   negotiate the inclusion of session IDs in authentication even when
+   there is no in-band way to carry out such a negotiation.  Because
+   there is only one "a" bit, however, a protocol extension that
+   specifies use of the "a" bit will likely require a built-in
+   versioning or negotiation mechanism to accommodate crypto agility and
+   future updates.
+
+   Because TCP-ENO enables multiple different TEPs to coexist, security
+   could potentially be only as strong as the weakest available TEP.  In
+   particular, if TEPs use a weak hash function to incorporate the TCP-
+   ENO transcript into session IDs, then an attacker can undetectably
+   tamper with ENO options to force negotiation of a deprecated and
+   vulnerable TEP.  To avoid such problems, security reviewers of new
+   TEPs SHOULD pay particular attention to the collision resistance of
+   hash functions used for session IDs (including the state of
+   cryptanalysis and research into possible attacks).  Even if other
+   parts of a TEP rely on more esoteric cryptography that turns out to
+   be vulnerable, it ought nonetheless to be intractable for an attacker
+   to induce identical session IDs at both ends after tampering with ENO
+   contents in SYN segments.
+
+   Implementations MUST NOT send ENO options unless they have access to
+   an adequate source of randomness [RFC4086].  Without secret
+   unpredictable data at both ends of a connection, it is impossible for
+   TEPs to achieve confidentiality and forward secrecy.  Because systems
+   typically have very little entropy on bootup, implementations might
+   need to disable TCP-ENO until after system initialization.
+
+   With a regular three-way handshake (meaning no simultaneous open),
+   the non-SYN-form ENO option in an active opener's first ACK segment
+   MAY contain N > 0 bytes of TEP-specific data, as shown in Figure 3.
+   Such data is not part of the TCP-ENO negotiation transcript and
+   therefore MUST be separately authenticated by the TEP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bittau, et al.                Experimental                     [Page 26]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+11.  IANA Considerations
+
+   This document defines a new TCP option kind for TCP-ENO, assigned a
+   value of 69 from the TCP option space.  This value is defined as:
+
+     +------+--------+----------------------------------+-----------+
+     | Kind | Length | Meaning                          | Reference |
+     +------+--------+----------------------------------+-----------+
+     | 69   | N      | Encryption Negotiation (TCP-ENO) | RFC 8547  |
+     +------+--------+----------------------------------+-----------+
+
+                     Table 2: TCP Option Kind Numbers
+
+   Early implementations of TCP-ENO and a predecessor TCP encryption
+   protocol made unauthorized use of TCP option kind 69.  These earlier
+   uses of option 69 are not compatible with TCP-ENO and could disable
+   encryption or suffer complete connection failure when interoperating
+   with TCP-ENO-compliant hosts.  Hence, legacy use of option 69 MUST be
+   disabled on hosts that cannot be upgraded to TCP-ENO.  More recent
+   implementations used experimental option 253 per [RFC6994] with
+   16-bit ExID 0x454E.  Current and new implementations of TCP-ENO MUST
+   use option 69, while any legacy implementations MUST migrate to
+   option 69.  Note in particular that Section 4.1 requires at most one
+   SYN-form ENO option per segment, which means hosts MUST NOT include
+   both option 69 and option 253 with ExID 0x454E in the same TCP
+   segment.
+
+   This document defines a 7-bit glt field in the range of 0x20-0x7f.
+   IANA has created and will maintain a new registry titled "TCP
+   Encryption Protocol Identifiers" under the "Transmission Control
+   Protocol (TCP) Parameters" registry.  Table 3 shows the initial
+   contents of this registry.  This document allocates one TEP
+   identifier (0x20) for experimental use.  In case the TEP identifier
+   space proves too small, identifiers in the range 0x70-0x7f are
+   reserved to enable a future update to this document to define
+   extended identifier values.  Future assignments are to be made upon
+   satisfying either of two policies defined in [RFC8126]: "IETF Review"
+   or (for non-IETF stream specifications) "Expert Review with RFC
+   Required".  IANA will furthermore provide early allocation [RFC7120]
+   to facilitate testing before RFCs are finalized.
+
+
+
+
+
+
+
+
+
+
+
+Bittau, et al.                Experimental                     [Page 27]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+         +-----------+------------------------------+-----------+
+         | Value     | Meaning                      | Reference |
+         +-----------+------------------------------+-----------+
+         | 0x20      | Experimental Use             | RFC 8547  |
+         | 0x70-0x7f | Reserved for extended values | RFC 8547  |
+         +-----------+------------------------------+-----------+
+
+               Table 3: TCP Encryption Protocol Identifiers
+
+12.  References
+
+12.1.  Normative References
+
+   [NIST-SP-800-57]
+              National Institute of Standards and Technology,
+              "Recommendation for Key Management - Part 1: General",
+              NIST Special Publication, 800-57, Revision 4,
+              DOI 10.6028/NIST.SP.800-57pt1r4, January 2016,
+              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
+              NIST.SP.800-57pt1r4.pdf>.
+
+   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, DOI 10.17487/RFC0793, September 1981,
+              <https://www.rfc-editor.org/info/rfc793>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <https://www.rfc-editor.org/info/rfc4086>.
+
+   [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
+              Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
+              2014, <https://www.rfc-editor.org/info/rfc7120>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+Bittau, et al.                Experimental                     [Page 28]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+12.2.  Informative References
+
+   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
+              Stevens, "Basic Socket Interface Extensions for IPv6",
+              RFC 3493, DOI 10.17487/RFC3493, February 2003,
+              <https://www.rfc-editor.org/info/rfc3493>.
+
+   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+              Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
+              January 2006, <https://www.rfc-editor.org/info/rfc4253>.
+
+   [RFC4987]  Eddy, W., "TCP SYN Flooding Attacks and Common
+              Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
+              <https://www.rfc-editor.org/info/rfc4987>.
+
+   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
+              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
+              <https://www.rfc-editor.org/info/rfc5116>.
+
+   [RFC5382]  Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
+              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
+              RFC 5382, DOI 10.17487/RFC5382, October 2008,
+              <https://www.rfc-editor.org/info/rfc5382>.
+
+   [RFC5802]  Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
+              "Salted Challenge Response Authentication Mechanism
+              (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
+              DOI 10.17487/RFC5802, July 2010,
+              <https://www.rfc-editor.org/info/rfc5802>.
+
+   [RFC6394]  Barnes, R., "Use Cases and Requirements for DNS-Based
+              Authentication of Named Entities (DANE)", RFC 6394,
+              DOI 10.17487/RFC6394, October 2011,
+              <https://www.rfc-editor.org/info/rfc6394>.
+
+   [RFC6994]  Touch, J., "Shared Use of Experimental TCP Options",
+              RFC 6994, DOI 10.17487/RFC6994, August 2013,
+              <https://www.rfc-editor.org/info/rfc6994>.
+
+   [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
+              Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
+              <https://www.rfc-editor.org/info/rfc7413>.
+
+   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
+              Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
+              December 2014, <https://www.rfc-editor.org/info/rfc7435>.
+
+
+
+
+
+Bittau, et al.                Experimental                     [Page 29]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+   [RFC7616]  Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
+              Digest Access Authentication", RFC 7616,
+              DOI 10.17487/RFC7616, September 2015,
+              <https://www.rfc-editor.org/info/rfc7616>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+Acknowledgments
+
+   We are grateful for contributions, help, discussions, and feedback
+   from the IETF and its TCPINC Working Group, including Marcelo
+   Bagnulo, David Black, Bob Briscoe, Benoit Claise, Spencer Dawkins,
+   Jake Holland, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Watson
+   Ladd, Kathleen Moriarty, Yoav Nir, Christoph Paasch, Eric Rescorla,
+   Adam Roach, Kyle Rose, Michael Scharf, Joe Touch, and Eric Vyncke.
+   This work was partially funded by DARPA CRASH and the Stanford Secure
+   Internet of Things Project.
+
+Contributors
+
+   Dan Boneh was a coauthor of the draft that became this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bittau, et al.                Experimental                     [Page 30]
+
+RFC 8547            TCP Encryption Negotiation Option           May 2019
+
+
+Authors' Addresses
+
+   Andrea Bittau
+   Google
+   345 Spear Street
+   San Francisco, CA  94105
+   United States of America
+
+   Email: bittau@google.com
+
+
+   Daniel B. Giffin
+   Stanford University
+   353 Serra Mall, Room 288
+   Stanford, CA  94305
+   United States of America
+
+   Email: daniel@beech-grove.net
+
+
+   Mark Handley
+   University College London
+   Gower St.
+   London  WC1E 6BT
+   United Kingdom
+
+   Email: M.Handley@cs.ucl.ac.uk
+
+
+   David Mazieres
+   Stanford University
+   353 Serra Mall, Room 290
+   Stanford, CA  94305
+   United States of America
+
+   Email: dm@uun.org
+
+
+   Eric W. Smith
+   Kestrel Institute
+   3260 Hillview Avenue
+   Palo Alto, CA  94304
+   United States of America
+
+   Email: eric.smith@kestrel.edu
+
+
+
+
+
+
+Bittau, et al.                Experimental                     [Page 31]
+