TCP-ENO: Encryption Negotiation Option

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

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: How to negotiate the use of encryption at the TCP layer, and 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 one among multiple possible TCP encryption protocols or 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.

TCP-ENO was designed to achieve the following goals: Enable endpoints to negotiate the use of a separately specified TCP encryption protocol or TEP. Transparently fall back to unencrypted TCP when not supported by both endpoints. 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). Provide a standard negotiation transcript through which TEPs can defend against tampering with TCP-ENO. Make parsimonious use of TCP option space. 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.

We define the following terms, which are used throughout this document: A TCP segment in which the SYN flag is set A TCP segment in which the ACK flag is set (which includes most segments other than an initial SYN segment) A TCP segment in which the SYN flag is clear A TCP segment in which the SYN flag is set but the ACK flag is clear A TCP segment in which the SYN and ACK flags are both set 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. 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. 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 can be used for NAT traversal by peer-to-peer applications . A TCP encryption protocol intended for use with TCP-ENO and specified in a separate document. A unique 7-bit value in the range 0x20-0x7f that IANA has assigned to a TEP. The single TEP governing a TCP connection, determined by use of the TCP ENO option specified in this document.

TCP-ENO extends TCP connection establishment to enable encryption opportunistically. It uses a new TCP option kind to negotiate one among multiple possible TCP encryption protocols or 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: A negotiated TEP, represented by a unique 7-bit TEP identifier, A few extra bytes of suboption data from each host, if needed by the TEP, A negotiation transcript with which to mitigate attacks on the negotiation itself, Role assignments designating one endpoint "host A" and the other endpoint "host B", and A bit indicating whether or not the application at each end knows it is using TCP-ENO. 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.

TCP-ENO employs an option in the TCP header . There are two equivalent kinds of ENO option, shown in . specifies which of the two kinds is permissible and/or preferred.

byte 0 1 2 N+1 (N+2 bytes total) +-----+-----+-----+--....--+-----+ |Kind=|Len= | | | TBD | N+2 | contents (N bytes) | +-----+-----+-----+--....--+-----+ byte 0 1 2 3 4 N+3 (N+4 bytes total) +-----+-----+-----+-----+-----+--....--+-----+ |Kind=|Len= | ExID | | | 253 | N+4 | 69 | 78 | contents (N bytes) | +-----+-----+-----+-----+-----+--....--+-----+ The contents of an ENO option can take one of two forms. A SYN form, illustrated in , appears only in SYN segments. A non-SYN form, illustrated in , appears only in non-SYN segments. The SYN form of ENO acts as a container for one or more suboptions, labeled Opt_0, Opt_1, ... in . The non-SYN form, 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 ENO options. When a negotiated TEP does not assign such meaning, the contents of a non-SYN ENO option SHOULD be zero bytes.

byte 0 1 2 3 ... N+1 +-----+-----+-----+-----+--...--+-----+----...----+ |Kind=|Len= |Opt_0|Opt_1| |Opt_i| Opt_i | | TBD | N+2 | | | | | data | +-----+-----+-----+-----+--...--+-----+----...----+ byte 0 1 2 3 4 5 ... N+3 +-----+-----+-----+-----+-----+-----+--...--+-----+----...----+ |Kind=|Len= | ExID |Opt_0|Opt_1| |Opt_i| Opt_i | | 253 | N+4 | 69 | 78 | | | | | data | +-----+-----+-----+-----+-----+-----+--...--+-----+----...----+

byte 0 1 2 N+1 +-----+-----+-----...----+ |Kind=|Len= | ignored | | TBD | N+2 | by TCP-ENO | +-----+-----+-----...----+ byte 0 1 2 3 4 N+3 +-----+-----+-----+-----+-----...----+ |Kind=|Len= | ExID | ignored | | 253 | N+4 | 69 | 78 | by TCP-ENO | +-----+-----+-----+-----+-----...----+ Every suboption starts with a byte of the form illustrated in . 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 7-bit value cs expresses one of: Global configuration data (discussed in ), Suboption data length for the next suboption (discussed in ), or 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 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, the initial suboption byte constitutes the entirety of the suboption and all information is expressed by the 7-bit glt value, which can be either a global suboption or TEP identifier. When v = 1, it indicates a suboption with variable-length suboption data. Only TEP identifiers may have suboption data, not global suboptions. Hence, 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 identifer). 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-0x1f0Global suboption () 0x00-0x1f1Length byte () 0x20-0x7f0TEP identifier without suboption data 0x20-0x7f1TEP identifier followed by suboption data 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.

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 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 bitmask, illustrated in .

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) The fields of the bitmask are interpreted as follows: The passive role bit MUST be 1 for all passive openers. For active openers, it MUST default to 0, but implementations SHOULD provide an API through which an application can set b = 1 before initiating an active open. (Manual configuration of b is necessary for simultaneous open.) The application-aware bit a is an out-of-band signal indicating that the application on the sending host is aware of TCP-ENO and has been extended to alter its behavior in the presence of encrypted TCP. Implementations MUST set this bit to 0 by default, and SHOULD 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 SHOULD furthermore support a mandatory application-aware mode in which TCP-ENO is automatically disabled if the remote host does not set a = 1. 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.

TCP-ENO uses abstract roles 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. If both sides of a connection set b = 1 (which can happen if the active opener misconfigures b before calling connect), or both sides set b = 0 (which can happen with simultaneous open), then TCP-ENO MUST be disabled and the connection MUST 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 A and B roles, respectively, in a connection.

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 ). By default, suboption data 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. As an example, in , the last suboption, Opt_i, has suboption data and thus requires v = 1; however, the suboption data length can be 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 preceding the suboption with a length byte, depicted in . 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) A suboption preceded by a length byte MUST be a TEP identifier (glt >= 0x20) and MUST have v = 1. 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 A host MUST ignore an ENO option in a SYN segment and MUST disable encryption if either: A length byte indicates that suboption data would extend beyond the end of the TCP ENO option, or 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. The TCP header itself can only accommodate a maximum of 40 bytes of options per segment, however, so regardless of the length byte could not fit more than one suboption over 32 bytes. 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.

A TEP identifier glt (with glt >= 0x20) is valid for a connection when: Each side has sent a suboption for glt in its SYN-form ENO option, Any suboption data in these glt suboptions is valid according to the TEP specification and satisfies any runtime constraints, and If an ENO option contains multiple suboptions with glt, then such repetition is well-defined by the TEP specification. The negotiated TEP is 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. A passive opener (which is always host B) sees the remote host's SYN segment before constructing its own SYN-ACK. Hence, 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.

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. A host MUST disable encryption, refrain from sending any further ENO options, and fall back to unencrypted TCP if any of the following occurs: Any segment it receives up to and including the first received ACK segment does not contain a ENO option (or contains an ill-formed SYN-form ENO option), The SYN segment it receives does not contain a valid TEP identifier, or 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 be useful if middleboxes are dropping segments with the ENO option.) 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 negotiated TEP.

A SYN segment containing an ENO option MUST NOT include a TCP Fast Open (TFO) option . However, TEPs MAY specify the use of data in SYN segments to achieve similar benefits to TFO. The last TEP identifier suboption in host A's SYN segment is the SYN TEP. The SYN TEP governs the use of data in A's SYN segment. If the SYN TEP's specification does not define the use of such data, then host A's SYN segment MUST NOT contain data and host B MUST discard any such data. Host B must also discard data in A's SYN segment if either the SYN TEP differs from the negotiated TEP or host B disables encryption. The use of data in B's SYN-ACK segment is governed by the negotiated TEP. If the negotiated TEP's specification does not define the use of such data, then host B's SYN-ACK segment MUST NOT contain data and host A MUST discard any such data. Host A MUST also discard any received SYN data if it disables encryption. When a host discards SYN data, it MUST NOT acknowledge the sequence number of the discarded data. Rather, it MUST acknowledge the other host's initial sequence number as if the received SYN segment contained no data. Regardless of the SYN TEP and negotiated TEP, host A MUST NOT include data in a SYN-only segment when in mandatory application-aware mode. Moreover, in the event that host B is an active opener (because of simultaneous open), host B's SYN-only segment MUST NOT include data. Using data in SYN segments deviates from TCP semantics and can cause problems with middleboxes or non-compliant TCP hosts. Hence, all TEPs SHOULD support a normal mode of operation that does not make use of data in SYN segments. Moreover, implementations SHOULD employ SYN data only if explicitly requested by the application or in cases where such use is highly unlikely to pose problems.

To defend against attacks on encryption negotiation itself, TEPs need a way to reference a transcript of TCP-ENO's negotiation. In particular, a TEP MUST with high probability fail to reach key agreement between two honest endpoints if the TEP's selection resulted from tampering with the contents of SYN-form ENO options. (Of course, in the absence of endpoint authentication, two honest endpoints can still each end up talking to a man-in-the-middle attacker rather than to each other.) 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, TCP option length byte, and, for option kind 253, the bytes 69 and 78 as illustrated in ). The transcript is constructed from the following, in order: The TCP-ENO option in host A's SYN segment, including the kind and length bytes. 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.

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. TEPs MUST protect TCP data streams with authenticated encryption. 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. describes the requirements of the session ID in more detail. TEPs MUST NOT permit the negotiation of any encryption algorithms with significantly less than 128-bit security. 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.) TEPs MUST NOT depend on long-lived secrets for data confidentiality, as implementations SHOULD provide forward secrecy some bounded, short time after the close of a TCP connection. TEPs MUST protect and authenticate the end-of-file marker traditionally conveyed by TCP's FIN flag when the remote application calls close or shutdown. However, end-of-file MAY be conveyed though a mechanism other than TCP FIN. Moreover, TEPs MAY permit attacks that cause TCP connections to abort, but such an abort MUST raise an error that is distinct from an end-of-file condition. TEPs MAY disallow the use of TCP urgent data by applications, but MUST NOT allow attackers to manipulate the URG flag and urgent pointer in ways that are visible to applications.

Each TEP MUST define a session ID that uniquely identifies each encrypted TCP connection and that is computable by both endpoints of the connection. Implementations SHOULD expose the session ID to applications via an API extension. Applications that are aware of TCP-ENO SHOULD 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. If the v bit was 1 in host B's SYN segment, then it is also 1 in the session ID. However, only the first byte is included, not the suboption data. 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.

byte 0 1 2 N-1 N +-----+------------...------------+ | sub-| collision-resistant hash | | opt | of connection information | +-----+------------...------------+ Though TEP specifications retain considerable flexibility in their definitions of the session ID, all session IDs MUST meet the following normative list of requirements: The session ID MUST be at least 33 bytes (including the one-byte suboption), though TEPs may choose longer session IDs. 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, and The negotiation transcript specified in . 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. 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).

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] shows a three-way handshake with a successful TCP-ENO negotiation. 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] 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: The passive opener (B) does not support TCP-ENO, B supports TCP-ENO, but supports neither of TEPs X and Y, and so does not reply with an ENO option, B supports TCP-ENO, but has the connection configured in mandatory application-aware mode and thus disables ENO because A's SYN segment does not set the application-aware bit, or 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] 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. Hence, A does not receive an ENO option from B, disables ENO, and does not include a non-SYN form ENO option when ACKing B's SYN segment. The lack of ENO in A's ACK segment signals to B that the connection will not be encrypted. At this point, the two hosts proceed with an unencrypted TCP connection.

(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] shows a successful TCP-ENO negotiation with simultaneous open. Here the first four segments MUST contain a SYN-form ENO option, as each side sends both a SYN-only and a SYN-ACK segment. The ENO 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.

This section describes some of the design rationale behind TCP-ENO.

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 option space in TCP . If SYN segments gain large options, it becomes possible to fit public keys or Diffie-Hellman parameters into SYN segments. Future TEPs can take advantage of this by performing key agreement directly within suboption data, both simplifying protocols and reducing the number of round trips required for connection setup. If TCP gains large SYN option support, the 32-byte limit on length bytes may prove problematic. This draft intentionally aborts TCP-ENO if a length byte is followed by an octet in the range 0x00-0x9f. Any document updating TCP's option size limit can also enable larger suboptions by updating this draft to assign meaning to such currently undefined byte sequences. New revisions to socket interfaces 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 DANE . An update to TCP-ENO can adopt one of the z bits in the global suboption to negotiate 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.

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 may drop ENO options in one direction only, a host must 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 must continue to include non-SYN form ENO options in segments until such point as 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.

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.

TCP-ENO, TEPs, and applications all have asymmetries that require an unambiguous way to identify one of the two connection endpoints. As an example, 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 not 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. 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 manually configure b = 1. An alternate design might automatically break the symmetry to avoid this need for manual 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.)

This draft 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 TBD (or option kind 253 with ExID 0x454E) after the SYN exchange does not conflict with this document. Because in addition ENO guarantees at most one negotiated TEP per connection, TEPs will not conflict with one another or ENO if they use ENO's option kind for out-of-band signaling in non-SYN segments.

This document has experimental status because TCP-ENO's viability depends on middlebox behavior that can only be determined a posteriori. Specifically, we must 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: 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. Middleboxes causing TCP-ENO connections to fail completely. This can happen if applications perform deep packet inspection and start dropping segments that unexpectedly contain ciphertext. The first type of failure is tolerable since TCP-ENO is designed for incremental deployment anyway. The second type of failure is more problematic, and, if prevalent, will require the development of techniques to avoid and recover from such failures.

An obvious use case for TCP-ENO is opportunistic encryption--that is, encrypting some connections, but only where supported and without any kind of endpoint authentication. Opportunistic encryption 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. Achieving stronger security with TCP-ENO requires verifying session IDs. Any application relying on ENO for communications security MUST incorporate session IDs into its endpoint authentication. By way of example, an authentication mechanism based on keyed digests (such Digest Access Authentication ) can be extended to include the role and session ID in the input of the keyed digest. Where necessary for backwards compatibility, applications SHOULD use the application-aware bit to negotiate the inclusion of session IDs in authentication. Because TCP-ENO enables multiple different TEPs to coexist, security could potentially be only as strong as the weakest available TEP. In particular, if session IDs do not depend on the TCP-ENO transcript in a strong way, an attacker can undetectably tamper with ENO options to force negotiation of a deprecated and vulnerable TEP. To avoid such problems, TEPs SHOULD compute session IDs using only well-studied and conservative hash functions. That way, even if other parts of a TEP are vulnerable, it is still 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 . 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 . Such data is not part of the TCP-ENO negotiation transcript, and hence MUST be separately authenticated by the TEP.

This document defines a new TCP option kind for TCP-ENO, assigned a value of TBD from the TCP option space. This value is defined as: Kind Length Meaning Reference TBDNEncryption Negotiation (TCP-ENO)[RFC-TBD] Early implementations of TCP-ENO and a predecessor TCP encryption protocol made unauthorized use of TCP option kind 69. [RFC-editor: please glue the following text to the previous paragraph iff TBD == 69, otherwise delete it.] 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. [RFC-editor: please glue this to the previous paragraph regardless of the value of TBD.] More recent implementations used experimental option 253 per with 16-bit ExID 0x454E, and SHOULD migrate to option TBD by default. This document defines a 7-bit glt field in the range of 0x20-0x7f for which IANA shall maintain a new sub-registry entitled "TCP encryption protocol identifiers" under the "Transmission Control Protocol (TCP) Parameters" registry. The description of this registry should be interpreted with respect to the terminology defined in . The intention is for IANA to grant registration requests for TEP identifiers in anticipation of a published RFC. Hence, a Specification is Required. However, to allow for implementation experience, identifiers should be allocated prior to the RFC being approved for publication. A Designated Expert appointed by the IESG area director shall approve allocations once it seems more likely than not that an RFC will eventually be published. The Designated Expert shall post a request to the TCPINC WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the TCPINC WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation, and in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided. The initial values of the TCP-ENO encryption protocol identifier registry are shown in . Value Meaning Reference 0x20Experimental Use 0x21TCPCRYPT_ECDHE_P256 0x22TCPCRYPT_ECDHE_P521 0x23TCPCRYPT_ECDHE_Curve25519 0x24TCPCRYPT_ECDHE_Curve448 0x30TCP-Use-TLS

We are grateful for contributions, help, discussions, and feedback from the TCPINC working group, including Marcelo Bagnulo, David Black, Bob Briscoe, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Yoav Nir, Christoph Paasch, Eric Rescorla, and Kyle Rose. This work was funded by DARPA CRASH and the Stanford Secure Internet of Things Project.