RFC 8547
TCP-ENO: Encryption Negotiation Option
Pages: 31
Experimental
Experimental
Part 1 of 2 – Pages 1 to 16
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 OptionAbstract
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.
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.
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
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.
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
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,
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
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.
+-----------+---+-------------------------------------------+ | 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
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.
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.
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.
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).
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.
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.
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)