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. While the need for encryption is immediate, future developments could alter trade-offs and change the best approach to TCP-level encryption (beyond introducing new cipher suites). For example: Increased option space in TCP could reduce round trip times and simplify protocols. API revisions to socket interfaces could benefit from integration with TCP-level encryption, particularly if combined with technologies such as DANE . The forthcoming TLS 1.3 standard could reach more applications given an out-of-band, backward-compatible mechanism for enabling encryption. TCP fast open , as it gains more widespread adoption and middlebox acceptance, could potentially benefit from tailored encryption support. Cryptographic developments that either shorten or lengthen the minimal key exchange messages required could affect how such messages are best encoded in TCP segments. Introducing TCP options, extending operating system interfaces to support TCP-level encryption, and extending applications to take advantage of TCP-level encryption will all require effort. To the greatest extent possible, this effort ought to remain applicable if the need arises 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 option called TCP-ENO. TCP-ENO provides a framework in which two endpoints can agree on one among multiple possible TCP encryption specs. For future compatibility, encryption specs can vary widely in terms of wire format, use of TCP option space, and integration with the TCP header and segmentation; however, such changes will ideally be transparent to applications that take advantage of TCP-level encryption. A companion document, the TCPINC encryption spec, addresses question 2. TCPINC enables TCP-level traffic encryption today. TCP-ENO ensures that the effort invested to deploy TCPINC can benefit future encryption specs should a different approach at some point be preferable. At a lower level, TCP-ENO was designed to achieve the following goals: Enable endpoints to negotiate the use of a separately specified encryption spec. Transparently fall back to unencrypted TCP when not supported by both endpoints. Provide signaling through which applications can better take advantage of TCP-level encryption (for instance by improving authentication mechanisms in the presence of TCP-level encryption). Provide a standard negotiation transcript through which specs 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.

TCP-ENO is a TCP option used during connection establishment to negotiate how to encrypt traffic. As an option, TCP-ENO can be deployed incrementally. Legacy hosts unaware of the option simply ignore it and never send it, causing traffic to fall back to unencrypted TCP. Similarly, middleboxes that strip out unknown options including TCP-ENO will downgrade connections to plaintext without breaking them. Of course, downgrading makes TCP-ENO vulnerable to active attackers, but appropriately modified applications can protect themselves by considering the state of TCP-level encryption during authentication, as discussed in . The ENO option takes two forms. In TCP segments with the SYN flag set, it acts as a container for a series of one or more suboptions, labeled Opt_0, Opt_1, ... in . In non-SYN segments, ENO conveys only a single bit of information, namely an acknowledgment that the sender received an ENO option in the other host's SYN segment. (Such acknowledgments enable graceful fallback to unencrypted TCP in the event that a middlebox strips ENO options in one direction.) illustrates the non-SYN form of the ENO option. Encryption specs MAY include extra bytes in a non-SYN ENO option, but TCP-ENO itself MUST ignore them. In accordance with TCP , the first two bytes of the ENO option always consist of the kind (ENO) and the total length of the option.

byte 0 1 2 3 2+i 3+i ... N-1 +-----+-----+-----+-----+--...--+-----+----...----+ |Kind=|Len= |Opt_0|Opt_1| |Opt_i| Opt_i | | ENO | N | | | | | data | +-----+-----+-----+-----+--...--+-----+----...----+

byte 0 1 0 1 2 N-1 +-----+-----+ +-----+-----+-----...----+ |Kind=|Len= | |Kind=|Len= | ignored | | ENO | 2 | or | ENO | N | by TCP-ENO | +-----+-----+ +-----+-----+-----...----+ Every suboption starts with a byte of the form illustrated in . The seven-bit value cs specifies the meaning of the suboption. Each value of cs specifies general parameters (discussed in ), provides information about suboption length (discussed in ), or indicates the willingness to use a specific encryption spec detailed in a separate document.

bit 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | v | cs | +---+---+---+---+---+---+---+---+ v - non-zero to indicate suboption data is present cs - global configuration option or encryption spec identifier The high bit v in a suboption's first byte plays a role in determining whether a suboption carries additional data, and if so the length of that data. When v = 0, a suboption carries no data and consists simply of the seven-bit value cs. When v = 1 and cs < 0x20, the suboption is a marker byte, specifying the length of the following suboption data, as discussed in . A marker byte MUST be followed by an encryption spec identifier with v = 1 and one or more bytes of suboption data. In the absence of a marker byte, a suboption with v = 1 extends to the end of the TCP option; in that case the length of the suboption data is determined by the total length of the TCP option. This design optimizes the common case that only the last suboption has any data, as no marker byte is needed under such circumstances. In , Opt_i is the only option with data and there are no marker bytes; Opt_i's total size is N-(2+i) bytes--one byte for Opt_i itself and N-(3+i) bytes for additional data. Suboption data MAY be used for session caching, cipher suite negotiation, key exchange, or other purposes, as determined by the value of cs. A TCP SYN segment MUST contain at most one ENO TCP option. If a SYN segment contains multiple TCP options of kind ENO, the receiver MUST behave as though the segment contained no ENO options and disable encryption. summarizes the allocation of values of cs. Values under 0x10 are assigned to general suboptions whose meaning applies across encryption specs, as discussed in , and values from 0x10-0x1f are reserved for possible future use by general suboptions. Values greater than or equal to 0x20 will be assigned to spec identifiers. When v = 1, values in the range 0x00-0x1f become marker bytes while cs values greater than or equal to 0x20 MUST be followed by one or more bytes of suboption data. Implementations MUST ignore all unknown and reserved suboptions. cs Meaning 0x00-0x0fGeneral options () and marker bytes () 0x10-0x1fMarker bytes and future general options 0x20-0x7fUsed to designate encryption specs

TCP-ENO uses abstract roles to distinguish the two ends of a TCP connection: One host plays the "A" role, while the other host plays the "B" role. Following a normal three-way handshake with no special configuration, the active opener plays the A role and the passive opener plays the B role. An active opener is a host that sends a SYN segment without the ACK flag set (after a connect system call on socket-based systems). A passive opener's first SYN segment always contains the ACK flag (and follows a listen call on socket-based systems). Roles are abstracted from the active/passive opener distinction to deal with simultaneous open, in which both hosts are active openers. For simultaneous open, the general suboptions discussed in define a role-override bit b, where the host with b = 1 plays the B role, and the host with b = 0 plays the A role. If two active openers have the same b bit, TCP-ENO fails and reverts to unencrypted TCP. More precisely, the above role assignment can be reduced to comparing a two-bit role priority for each host, shown in . The most significant bit, b, is the role-override bit. The least significant bit, p, is 1 for a passive opener and 0 for an active opener. The host with the lower priority assumes the A role; the host with the higher priority assumes the B role. In the event of a tie, TCP-ENO fails and MUST continue with unencrypted TCP as if the ENO options had not been present in SYN segments.

bit 1 0 +---+---+ | b p | +---+---+ b - b bit from general suboptions sent by host p - 0 for active opener, 1 for passive opener Each host knows its own p bit is 0 if it sent a SYN segment without an ACK flag (a "SYN-only" segment), and is 1 otherwise. Each host estimates the other host's p bit as 0 if it receives a SYN-only segment, and as 1 otherwise. An important subtlety is that because of a lost or delayed SYN-only segment, one of the two hosts in a simultaneous open may incorrectly assume the other host has p set to 1. In the event that the two hosts set different b bits, no harm is done as the b bit overrides the p bit for role selection. In the event that both b bits are the same, both hosts have the same role priority and TCP-ENO MUST be aborted. Fortunately, at least one host will always detect a priority tie before sending a SYN-ACK segment, and hence will force TCP-ENO to abort by sending its SYN-ACK without an ENO option. Encryption specs 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 role A and B respectively in a connection.

The TCP-ENO option is intended for use during TCP connection establishment. To enable incremental deployment, a host needs to ensure both that the other host supports TCP-ENO and that no middlebox has stripped the ENO option from its own TCP segments. In the event that either of these conditions does not hold, implementations MUST immediately cease sending TCP-ENO options and MUST continue with unencrypted TCP as if the ENO option had not been present. More precisely, for negotiation to succeed, the TCP-ENO option MUST be present in the SYN segment sent by each host, so as to indicate support for TCP-ENO. Additionally, the ENO option MUST be present in the first ACK segment sent by each host, so as to indicate that no middlebox stripped the ENO option from the ACKed SYN. Depending on whether a host is an active or a passive opener, the first ACK segment may or may not be the same as the SYN segment. Specifically: An active opener in a three-way handshake begins with a SYN-only segment, and hence must send two segments containing ENO options. The initial SYN-only segment MUST contain an ENO option with at least one suboption, as pictured in . If ENO succeeds, the active opener's first ACK segment MUST subsequently contain a non-SYN ENO option, as pictured in . A passive opener's first transmitted segment has both the SYN and ACK flags set. Therefore, a passive opener sends an ENO option of the type shown in in its single SYN-ACK segment and does not need to send a non-SYN ENO option. Under simultaneous open, each host sends both a SYN-only segment and a SYN-ACK segment. In this case, if negotiation succeeds, ENO options must be identical in each hosts's SYN-only and SYN-ACK segment. If negotiation fails (for instance because of a tie in role priority), then a host detecting this failure MUST send a SYN-ACK segment without an ENO option. A spec identifier in one host's SYN segment is valid if it is compatible with a suboption in the other host's SYN segment. Two suboptions are compatible when they have the same cs value (>= 0x20) and when the contents or lack of suboption data in the two SYN segments is well-defined by the corresponding encryption spec. Specs MAY require, allow, or disallow suboption data in each of the two SYN segments. Once the two sides have exchanged SYN segments, the negotiated spec is the last valid spec identifier in the SYN segment of host B (that is, the passive opener in the absence of simultaneous open). In other words, the order of suboptions in host B's SYN segment determines spec priority, while the order of suboptions in host A's SYN segment has no effect. Hosts must disable TCP-ENO if there is no valid spec in host B's SYN segment. Note that negotiation prioritizes the last rather than the first valid suboption because it is most space efficient to place a variable-length suboption at the end of a TCP-ENO option. When using this optimization, favoring the last suboption favors the spec with suboption data. When possible, host B SHOULD send only one spec identifier (suboption with cs in the range 0x20-0x7f), and SHOULD ensure this option is valid. However, sending a single valid spec identifier is not required, as doing so could be impractical in some cases, such as simultaneous open or library-level implementations that can only provide a static TCP-ENO option to the kernel. A host MUST disable ENO if any of the following conditions holds: The host receives a SYN segment without an ENO option, The host receives a SYN segment that contains no valid encryption specs when paired with the SYN segment that the host has already sent or would otherwise have sent, The host receives a SYN segment containing general suboptions that are incompatible with the SYN segment that it has already sent or would otherwise have sent, or The first ACK segment received by a host does not contain an ENO option. After disabling ENO, a host MUST NOT transmit any further ENO options and MUST fall back to unencrypted TCP. Conversely, 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 encryption protocol of the negotiated spec and MUST NOT present raw TCP payload data to the application. In particular, data segments MUST contain ciphertext or key agreement messages as determined by the negotiated spec, and MUST NOT contain plaintext application data. Note that with a regular three-way handshake (meaning no simultaneous open), the mandatory ENO option in an active opener's first ACK segment MAY contain spec-specific data, as shown on the right in . Such data is not part of the TCP-ENO negotiation transcript. Hence, an encryption spec MUST take steps to authenticate any data it embeds in non-SYN ENO options.

(1) A -> B: SYN ENO<X,Y> (2) B -> A: SYN-ACK ENO<Y> (3) A -> B: ACK ENO<> [rest of connection encrypted according to spec for Y] shows a three-way handshake with a successful TCP-ENO negotiation. The two sides agree to follow the encryption spec 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 specs corresponding to suboptions X and Y. Unfortunately, at this point one of thee things occurs: The passive opener (B) does not support TCP-ENO, B supports TCP-ENO, but supports neither of specs X and Y, and so does not reply with an ENO option, 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<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 the required non-SYN ENO option when ACKing the other host'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<0x01,X,Y,Z> (3) A -> B: SYN-ACK ENO<Y,X> (4) B -> A: SYN-ACK ENO<0x01,X,Y,Z> [rest of connection encrypted according to spec for Y] shows a successful TCP-ENO negotiation with simultaneous open. Here the first four segments MUST contain an ENO option, as each side sends both a SYN-only and a SYN-ACK segment. The ENO option in each hosts'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. Note the use of the role-override bit in general suboption 0x01 assigns B its role, as discussed in . The last valid spec in B's ENO option is Y, so Y is the negotiated spec.

Suboptions 0x00-0x0f are used for general conditions that apply regardless of the negotiated encryption spec. A TCP segment MUST include at most one ENO suboption whose high nibble is 0. The value of the low nibble is interpreted as a bitmask, illustrated in . A receiver SHOULD disable TCP-ENO upon receipt of a SYN segment with multiple general suboptions.

bit 7 6 5 4 3 2 1 0 +---+---+---+---+---+-------+---+ | 0 0 0 0 z aa b | +---+---+---+---+---+-------+---+ z - Zero bit (reserved for future use) aa - Application-aware bits b - Role-override bit for simultaneous open The fields of the bitmask are interpreted as follows: The z bit is reserved for future revisions of TCP-ENO. Its value MUST be set to zero in sent segments and ignored in received segments. The two application-aware bits indicate 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. There are four possible values, as shown in . The default, when applications have not been modified to take advantage of TCP-ENO, MUST be 00. However, implementations SHOULD provide an API through which applications can set the bits to other values and query for the other host's application-aware bits. The value 01 indicates that the application is aware of TCP-ENO. The value 10 (binary) is reserved for future use. It MUST be interpreted as the application being aware of TCP-ENO, but MUST never be sent. Value 11 (binary) indicates that an application is aware of TCP-ENO and requires application awareness from the other side. If one host sends value 00 and the other host sends 11, then TCP-ENO MUST be disabled and fall back to unencrypted TCP. Any other combination of values (including the reserved 10) is compatible with enabling encryption. A possible use of value 11 is for applications that perform legacy encryption and wish to disable TCP-ENO unless higher-layer encryption can be disabled. Value Meaning 00Application is not aware of TCP-ENO 01Application is aware of TCP-ENO 10Reserved but interpreted as ENO-aware 11Application awareness is mandatory for use of TCP-ENO This is the role-override bit in role priority, discussed in . A SYN segment without an explicit general suboption has an implicit general suboption of 0x00.

When a TCP-ENO option contains multiple suboptions with data, or when a suboption other than the last one has data, it is necessary to specify the length of the suboption so that the receiver knows at what point to start parsing the next suboption. The length of suboption data can be specified by placing a marker byte immediately before a suboption.

bit 7 6 5 4 3 2 1 0 +---+---+---+-------------------+ | 1 0 0 nnnnn | +---+---+---+-------------------+ nnnnn - 5-bit value encodes (length - 1) shows the format of a marker byte. It encodes a 5-bit value nnnnn. Adding one to this value specifies the length of the suboption data. Hence a marker byte can designate a suboption carrying anywhere from 1 to 32 bytes of data (inclusive). Note that the length does not count the marker byte or suboption byte, only suboption data following the suboption byte. For instance, marker byte 0x9f would be followed by a suboption byte and 32 bytes of suboption data, together occupying a total of 34 bytes within an ENO TCP option. The suboption following a marker byte MUST always have v = 1, and must always contain at least one byte of suboption data.

bit 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 1 0 0 mmmmm | 0 | nnnnnnn | +---+---+---+-------------------+---+---------------------------+ mmmmm - 5 most significant bits of 12-bit value (length - 1) nnnnnnn - 7 least significant bits of 12-bit value (length - 1) If the octet following a marker byte has the high bit clear (meaning v = 0), then the marker byte and following octet together are interpreted as a marker word, as shown in . The length thus encoded does not count the marker word or suboption byte, only the suboption data following the suboption byte. Marker words are primarily intended for use in conjunction with future TCP extensions for large options. (Such an extention would need to overcome both TCP's 40-byte option limit and the single-byte TCP option length to make use of all 12 bits of length.) If a marker byte or word in a received SYN segment indicates that a TCP-ENO option would extend beyond the end of the TCP option, the receiver MUST behave as though the received SYN segment contains no TCP-ENO options and fall back to unencrypted TCP.

To defend against attacks on encryption negotiation itself, encryption specs need a way to reference a transcript of TCP-ENO's negotiation. In particular, an encryption spec MUST fail with high probability if its selection resulted from tampering with or forging initial SYN segments. TCP-ENO defines its negotiation transcript as a packed data structure consisting of a series of TCP-ENO options (each including the ENO and length bytes, as they appeared in the TCP header). Specifically, 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, the transcript unambiguously delimits A's and B's ENO options. For the transcript to be well defined, hosts MUST NOT alter 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 remove the ENO option altogether from a retransmitted SYN-only segment and disable TCP-ENO. 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 two hosts' SYN-only segments contain incompatible TCP-ENO options (for instance because role negotiation failed).

TCP-ENO was designed to afford encryption spec authors a large amount of design flexibility. Nonetheless, to fit all encryption specs into a coherent framework and abstract most of the differences away for application writers, all encryption specs claiming ENO cs numbers MUST satisfy the following properties. Specs MUST protect TCP data streams with authenticated encryption. Specs 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 spec. describes the requirements of the session ID in more detail. Specs MUST NOT permit the negotiation of any encryption algorithms with significantly less than 128-bit security. Specs 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.) Specs MUST NOT allow the negotiation of encryption modes that do not provide forward secrecy some bounded, short time after the close of a TCP connection. Specs 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, specs 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. Specs 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 spec MUST define a session ID that uniquely identifies each encrypted TCP connection. Implementations SHOULD expose the session ID to applications via an API extension. Applications that are aware of TCP-ENO SHOULD incorporate the session ID value and TCP-ENO role (A or B) into any authentication mechanisms layered over TCP encryption so as to authenticate actual TCP endpoints. 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 deviating from the encryption spec, to establish two TCP connections with the same session ID to remote hosts obeying the spec. To prevent session IDs from being confused across specs, all session IDs begin with the negotiated spec identifier--that is, the last valid spec 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 spec authors 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 specs retain considerable flexibility in their definitions of the session ID, all session IDs MUST meet certain minimum requirements. In particular: The session ID MUST be at least 33 bytes (including the one-byte suboption), though specs may choose longer session IDs. The session ID MUST depend in a collision-resistant way on fresh data contributed by both sides of the connection. The session ID MUST depend in a collision-resistant way on any public keys, public Diffie-Hellman parameters, or other public asymmetric cryptographic parameters that are employed by the encryption spec and have corresponding private data that is known by only one side of the connection. 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 chose to make session IDs public. Therefore, specs MUST NOT place any confidential data in the session ID (such as data permitting the derivation of session keys). The session ID MUST depend on the negotiation transcript specified in in a collision-resistant way.

This draft does not specify the use of ENO options in any segments other than the initial SYN and ACK segments of a connection. Moreover, it does not specify the content of ENO options in an initial ACK segment that has the SYN flag clear. As a result, any use of the ENO option kind after the SYN exchange will not conflict with TCP-ENO. Therefore, encryption specs that require TCP option space MAY re-purpose the ENO option kind for use in segments after the initial SYN.

Implementations SHOULD provide API extensions through which applications can query and configure the behavior of TCP-ENO, including retrieving session IDs, setting and reading application-aware bits, and specifying which specs to negotiate. The specifics of such an API are outside the scope of this document.

This document has experimental status because of several open issues. Some questions about TCP-ENO's viability depend on middlebox behavior that can only be determined a posteriori. Hence, initial deployment of ENO will be an experiment. In addition, a few design questions exists on which consensus is not clear, and hence for which greater discussion and justification of TCP-ENO's design may be helpful.

One of the primary open questions is 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.

Though currently specs must output a single session ID, it might alternatively be useful to define multiple identifiers per connection. As an example, a public session ID might be used to authenticate a connection, while a private session ID could be used as an authentication key to link out-of-band data (such as another TCP connection) to the original connection. Should multiple session IDs be required, it might be necessary to require all encryption specs to provide a feature similar to TLS exporters .

An obvious use case for TCP-ENO is opportunistic encryption. However, if applications do not check and verify the session ID, they will be open to man-in-the-middle attacks as well as simple downgrade attacks in which an attacker strips off the TCP-ENO option. Hence, where possible, applications SHOULD be modified to fold the session ID into authentication mechanisms, and SHOULD employ the application-aware bits as needed to enable such negotiation in a backward-compatible way. Because TCP-ENO enables multiple different encryption specs to coexist, security could potentially be only as strong as the weakest available encryption spec. For this reason, it is crucial for session IDs to depend on the TCP-ENO transcript in a strong way. Hence, encryption specs SHOULD compute session IDs using only well-studied and conservative hash functions. Thus, even if an encryption spec is broken, and even if people deprecate it instead of disabling it, and even if an attacker tampers with ENO options to force negotiation of the broken spec, it should still be intractable for the attacker to induce identical session IDs at both hosts. Implementations MUST not send ENO options unless encryption specs have access to a strong source of randomness or pseudo-randomness. Without secret unpredictable data at both ends of a connection, it is impossible for encryption specs to satisfy the confidentiality and forward secrecy properties required by this document.

A new TCP option kind number needs to be assigned to ENO by IANA. In addition, IANA will need to maintain an ENO suboption registry mapping suboption cs values to encryption specs.

This work was funded by DARPA CRASH under contract #N66001-10-2-4088.