Tech-invite   3GPPspecs   RFCs   Search in Tech-invite

868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100IETF‑orgGroupsStats
in Index   Prev   Next

RFC 8547

TCP-ENO: Encryption Negotiation Option

Pages: 31
Group: TCPINC
Experimental
Part 1 of 2 – Pages 1 to 16
None   None   Next

Top   ToC   RFC8547 - Page 1
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.
Top   ToC   RFC8547 - Page 2
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.
Top   ToC   RFC8547 - Page 3
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
Top   ToC   RFC8547 - Page 4
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.
Top   ToC   RFC8547 - Page 5
   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
Top   ToC   RFC8547 - Page 6
   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,
Top   ToC   RFC8547 - Page 7
   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
Top   ToC   RFC8547 - Page 8
                      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.
Top   ToC   RFC8547 - Page 9
       +-----------+---+-------------------------------------------+
       | 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
Top   ToC   RFC8547 - Page 10
      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.
Top   ToC   RFC8547 - Page 11
   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.
Top   ToC   RFC8547 - Page 12
       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.
Top   ToC   RFC8547 - Page 13
   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).
Top   ToC   RFC8547 - Page 14
   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.
Top   ToC   RFC8547 - Page 15
   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.
Top   ToC   RFC8547 - Page 16
   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.



(page 16 continued on part 2)

Next Section