| Network Working Group | A. Bittau |
| Internet-Draft | |
| Intended status: Experimental | D. Giffin |
| Expires: May 21, 2018 | Stanford University |
| M. Handley | |
| University College London | |
| D. Mazieres | |
| Stanford University | |
| E. Smith | |
| Kestrel Institute | |
| November 17, 2017 |
TCP-ENO: Encryption Negotiation Option
draft-ietf-tcpinc-tcpeno-17
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, making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded, requiring 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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 21, 2018.
Copyright (c) 2017 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.
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.
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:
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.
TCP-ENO was designed to achieve the following goals:
Throughout this document, we use the following terms, several of which have more detailed normative descriptions in [RFC0793]:
TCP-ENO extends TCP connection establishment to enable encryption opportunistically. It uses a new TCP option-kind [RFC0793] 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:
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 [RFC0793]. Figure 1 illustrates the high-level format of this option.
byte 0 1 2 N+1 (N+2 bytes total)
+-----+-----+-----+--....--+-----+
|Kind=|Len= | |
| TBD | 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, illustrated in Figure 2, appears only in SYN segments. A non-SYN form, illustrated in Figure 3, appears only in non-SYN segments. The SYN form of ENO acts as a container for zero or more suboptions, labeled Opt_0, Opt_1, ... in Figure 2. 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 MUST be zero bytes 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 |
| TBD | N+2 | | | | | data |
+-----+-----+-----+-----+--...--+-----+----...----+
Figure 2: SYN form of ENO
byte 0 1 2 N+1
+-----+-----+-----...----+
|Kind=|Len= | ignored |
| TBD | N+2 | by TCP-ENO |
+-----+-----+-----...----+
Figure 3: Non-SYN form of ENO, 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, may take on various meanings, as defined below:
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, 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 a 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 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 |
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 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 bitmask, 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 bitmask are interpreted as follows:
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 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.
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 sub option 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. As an example, in Figure 2, 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:
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, however. Hence, 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.
A TEP identifier glt (with glt >= 0x20) is valid for a connection when:
A passive opener (which is always host B) sees the remote host's SYN segment before constructing its own SYN-ACK segment. 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.
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.
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:
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 hence 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.
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:
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 may 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 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.
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:
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.
Each TEP MUST define a session ID that is computable by both endpoints and uniquely identifies each encrypted TCP connection. Implementations MUST expose the session ID to applications via an API extension. The API extension MUST return an error when no session ID is available because ENO has failed to negotiate encryption or because no connection is yet established. Applications that are aware of TCP-ENO SHOULD, when practical, authenticate the TCP endpoints by incorporating the values of the session ID and TCP-ENO role (A or B) into higher-layer authentication mechanisms.
In order to avoid replay attacks and prevent authenticated session IDs from being used out of context, session IDs MUST be unique over all time with high probability. This uniqueness property MUST hold even if one end of a connection maliciously manipulates the protocol in an effort to create duplicate session IDs. In other words, it MUST be infeasible for a host, even by violating the TEP specification, to establish two TCP connections with the same session ID to remote hosts properly implementing the TEP.
To prevent session IDs from being confused across TEPs, all session IDs begin with the negotiated TEP identifier--that is, the last valid TEP identifier in host B's SYN segment. Furthermore, this initial byte has bit v set to the same value that accompanied the negotiated TEP identifier in B's SYN segment. However, only this single byte is included, not any suboption data. Figure 8 shows the resulting format. This format is designed for TEPs to compute unique identifiers; it is not intended for application authors to pick apart session IDs. Applications SHOULD treat session IDs as monolithic opaque values and SHOULD NOT discard the first byte to shorten identifiers. (An exception is for non-security-relevant purposes, such as gathering statistics about negotiated TEPs.)
byte 0 1 2 N-1 N
+-----+------------...------------+
| sub-| collision-resistant hash |
| opt | of connection information |
+-----+------------...------------+
Figure 8: Format of a session ID
Though TEP specifications retain considerable flexibility in their definitions of the session ID, all session IDs MUST meet the following normative list of requirements:
This subsection illustrates the TCP-ENO handshake with a few non-normative examples.
(1) A -> B: SYN ENO<X,Y> (2) B -> A: SYN-ACK ENO<b=1,Y> (3) A -> B: ACK ENO<> [rest of connection encrypted according to TEP Y]
Figure 9: Three-way handshake with successful TCP-ENO negotiation
Figure 9 shows a three-way handshake with a successful TCP-ENO negotiation. Host A includes two ENO suboptions with TEP identifiers X and Y. Host A does not include an explicit global suboption, which means it has an implicit global suboption 0x00 conveying passive role bit b = 0. The two sides agree to follow the TEP identified by suboption Y.
(1) A -> B: SYN ENO<X,Y> (2) B -> A: SYN-ACK (3) A -> B: ACK [rest of connection unencrypted legacy TCP]
Figure 10: Three-way handshake with failed TCP-ENO negotiation
Figure 10 shows a failed TCP-ENO negotiation. The active opener (A) indicates support for TEPs corresponding to suboptions X and Y. Unfortunately, at this point one of several things occurs:
Whichever of the above applies, the connection transparently falls back to unencrypted TCP.
(1) A -> B: SYN ENO<X,Y> (2) B -> A: SYN-ACK ENO<b=1,X> [ENO stripped by middlebox] (3) A -> B: ACK [rest of connection unencrypted legacy TCP]
Figure 11: Failed TCP-ENO negotiation because of option stripping
Figure 11 Shows another handshake with a failed encryption negotiation. In this case, the passive opener B receives an ENO option from A and replies. However, the reverse network path from B to A strips ENO options. Hence, A does not receive an ENO option from B, disables ENO, and does not include a non-SYN-form ENO option in segment 3 when ACKing B's SYN. Had A not disabled encryption, Section 4.6 would have required it to include a non-SYN ENO option in segment 3. The omission of this option informs B that encryption negotiation has failed, after which the two hosts proceed with unencrypted TCP.
(1) A -> B: SYN ENO<Y,X> (2) B -> A: SYN ENO<b=1,X,Y,Z> (3) A -> B: SYN-ACK ENO<Y,X> (4) B -> A: SYN-ACK ENO<b=1,X,Y,Z> [rest of connection encrypted according to TEP Y]
Figure 12: Simultaneous open with successful TCP-ENO negotiation
Figure 12 shows a successful TCP-ENO negotiation with simultaneous open. Here the first four segments contain a SYN-form ENO option, as each side sends both a SYN-only and a SYN-ACK segment. The ENO 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.
TCP-ENO is designed to capitalize on future developments that could alter trade-offs and change the best approach to TCP-level encryption (beyond introducing new cipher suites). By way of example, we discuss a few such possible developments.
Various proposals exist to increase the maximum space for options in the TCP header. These proposals are highly experimental--particularly those that apply to SYN segments. Hence, future TEPs are unlikely to benefit from extended SYN option space. In the unlikely event that SYN option space is one day extended, however, future TEPs could benefit by embedding key agreement messages directly in SYN segments. Under such usage, the 32-byte limit on length bytes could prove insufficient. This draft intentionally aborts TCP-ENO if a length byte is followed by an octet in the range 0x00-0x9f. If necessary, a future update to this document can define a format for larger suboptions by assigning meaning to such currently undefined byte sequences.
New revisions to socket interfaces [RFC3493] could involve library calls that simultaneously have access to hostname information and an underlying TCP connection. Such an API enables the possibility of authenticating servers transparently to the application, particularly in conjunction with technologies such as DANE [RFC6394]. An update to TCP-ENO can adopt one of the z bits in the global suboption to negotiate the use of an endpoint authentication protocol before any application use of the TCP connection. Over time, the consequences of failed or missing endpoint authentication can gradually be increased from issuing log messages to aborting the connection if some as yet unspecified DNS record indicates authentication is mandatory. Through shared library updates, such endpoint authentication can potentially be added transparently to legacy applications without recompilation.
TLS can currently only be added to legacy applications whose protocols accommodate a STARTTLS command or equivalent. TCP-ENO, because it provides out-of-band signaling, opens the possibility of future TLS revisions being generically applicable to any TCP application.
This section describes some of the design rationale behind TCP-ENO.
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 needs to know not just that the peer supports encryption, but that the peer has received an ENO option. To this end, ENO disables encryption unless it receives an ACK segment bearing an ENO option. To stay robust in the face of dropped segments, hosts continue to include non-SYN form ENO options in segments until 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, Section 4.8 specifies that host A's ENO option comes before host B's in the negotiation transcript. As another example, an application might need to authenticate one end of a TCP connection with a digital signature. To ensure the signed message cannot 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 explicitly configure b = 1. An alternate design might automatically break the symmetry to avoid this need for explicit configuration. However, all such designs we considered either lacked robustness or consumed precious bytes of SYN option space even in the absence of simultaneous open. (One complicating factor is that TCP does not know it is participating in a simultaneous open until after it has sent a SYN segment. Moreover, with packet loss, one host might never learn it has participated in a simultaneous open.)
Applications developed before TCP-ENO can potentially evolve to take advantage of TCP-level encryption. For instance, an application designed to run only on trusted networks might leverage TCP-ENO to run on untrusted networks, but, importantly, needs to authenticate endpoints and session IDs to do so. In addition to user-visible changes such as requesting credentials, this kind of authentication functionality requires application-layer protocol changes. Some protocols can accommodate the requisite changes--for instance by introducing a new verb analogous to STARTTLS--while others cannot do so in a backwards-compatible manner.
The application-aware bit a in the the global suboption provides a means of incrementally deploying TCP-ENO-specific enhancements to application-layer protocols that would otherwise lack the necessary extensibility. Software implementing the enhancement always sets a = 1 in its own global suboption, but only activates the new behavior when the other end of the connection also sets a = 1.
A related issue is that an application might leverage TCP-ENO as a replacement for legacy application-layer encryption. In this scenario, if both endpoints support TCP-ENO, then application-layer encryption can be disabled in favor of simply authenticating the TCP-ENO session ID. On the other hand, if one endpoint is not aware of the new TCP-ENO-specific mode of operation, there is little benefit to performing redundant encryption at the TCP layer; data is already encrypted once at the application layer, and authentication is only with respect to this application-layer encryption. The mandatory application-aware mode lets applications avoid double encryption in this case: the mode sets a = 1 in the local host's global suboption, but also disables TCP-ENO entirely in the event that the other side has not also set a = 1.
Note that the application-aware bit is not needed by applications that already support adequate higher-layer encryption, such as provided by TLS [RFC5246] or SSH [RFC4253]. To avoid double-encryption in such cases, it suffices to disable TCP-ENO by configuration on any ports with known secure protocols.
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 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.
Section 5.1 specifies that all but the first (TEP identifier) byte of a session ID MUST be computationally indistinguishable from random bytes to a network eavesdropper. This property is easy to ensure under standard assumptions about cryptographic hash functions. Such unpredictability helps security in a broad range of cases. For example, it makes it possible for applications to use a session ID from one connection to authenticate a session ID from another, thereby tying the two connections together. It furthermore helps ensure that TEPs do not trivially subvert the 33-byte minimum length requirement for session IDs by padding shorter session IDs with zeros.
This document has experimental status because TCP-ENO's viability depends on middlebox behavior that can only be determined a posteriori. Specifically, we need to determine to what extent middleboxes will permit the use of TCP-ENO. Once TCP-ENO is deployed, we will be in a better position to gather data on two types of failure:
Type-1 failures are tolerable, since TCP-ENO is designed for incremental deployment anyway. Type-2 failures are more problematic, and, if prevalent, will require the development of techniques to avoid and recover from such failures. The experiment will succeed so long as we can avoid type-2 failures and find sufficient use cases that avoid type-1 failures (possibly along with a gradual path for further reducing type-1 failures).
In addition to the question of basic viability, deploying TCP-ENO will allow us to identify and address other potential corner cases or relaxations. For example, does the slight decrease in effective TCP segment payload pose a problem to any applications, requiring restrictions on how TEPs interpret socket buffer sizes? Conversely, can we relax the prohibition on default TEPs that disable urgent data?
A final important metric, related to the pace of deployment and incidence of Type-1 failures, will be the extent to which applications adopt TCP-ENO-specific enhancements for endpoint authentication.
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 provides a property known as opportunistic security [RFC7435], which protects against undetectable large-scale eavesdropping. However, it does not protect against detectable large-scale eavesdropping (for instance, if ISPs terminate TCP connections and proxy them, or simply downgrade connections to unencrypted). Moreover, opportunistic encryption emphatically does not protect against targeted attacks that employ trivial spoofing to redirect a specific high-value connection to a man-in-the-middle attacker. Hence, the mere presence of TEP-indicated encryption does not suffice for an application to represent a connection as "secure" to the user.
Achieving stronger security with TCP-ENO requires verifying session IDs. Any application relying on ENO for communications security MUST incorporate session IDs into its endpoint authentication. By way of example, an authentication mechanism based on keyed digests (such as Digest Access Authentication [RFC7616]) can be extended to include the role and session ID in the input of the keyed digest. Higher-layer protocols MAY use the application-aware a bit to negotiate the inclusion of session IDs in authentication even when there is no in-band way to carry out such a negotiation. Because there is only one a bit, however, a protocol extension that specifies use of the a bit will likely require a built-in versioning or negotiation mechanism to accommodate crypto agility and future updates.
Because TCP-ENO enables multiple different TEPs to coexist, security could potentially be only as strong as the weakest available TEP. In particular, if TEPs use a weak hash function to incorporate the TCP-ENO transcript into session IDs, then an attacker can undetectably tamper with ENO options to force negotiation of a deprecated and vulnerable TEP. To avoid such problems, security reviewers of new TEPs SHOULD pay particular attention to the collision resistance of hash functions used for session IDs (including the state of cryptanalysis and research into possible attacks). Even if other parts of a TEP rely on more esoteric cryptography that turns out to be vulnerable, it ought nonetheless to be intractable for an attacker to induce identical session IDs at both ends after tampering with ENO contents in SYN segments.
Implementations MUST NOT send ENO options unless they have access to an adequate source of randomness [RFC4086]. Without secret unpredictable data at both ends of a connection, it is impossible for TEPs to achieve confidentiality and forward secrecy. Because systems typically have very little entropy on bootup, implementations might need to disable TCP-ENO until after system initialization.
With a regular three-way handshake (meaning no simultaneous open), the non-SYN form ENO option in an active opener's first ACK segment MAY contain N > 0 bytes of TEP-specific data, as shown in Figure 3. Such data is not part of the TCP-ENO negotiation transcript, and hence MUST be separately authenticated by the TEP.
[RFC-editor: please replace TBD in this section, in Section 4.1, and in Section 8.5 with the assigned option-kind number. Please also replace RFC-TBD with this document's final RFC number.]
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 |
|---|---|---|---|
| TBD | N | Encryption 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 [RFC6994] with 16-bit ExID 0x454E. Current and new implementations of TCP-ENO MUST use option TBD, while any legacy implementations MUST migrate to option TBD. Note in particular that Section 4.1 requires at most one SYN-form ENO option per segment, which means hosts MUST NOT not include both option TBD and option 253 with ExID 0x454E in the same TCP segment.
[IANA is also requested to update the entry for TCP-ENO in the TCP Experimental Option Experiment Identifiers (TCP ExIDs) sub-registry to reflect the guidance of the previous paragraph by adding a note saying "current and new implementations MUST use option TDB." RFC-editor: please remove this comment.]
This document defines a 7-bit glt field in the range of 0x20-0x7f, for which IANA is to create and maintain a new registry entitled "TCP encryption protocol identifiers" under the "Transmission Control Protocol (TCP) Parameters" registry. The initial contents of the TCP encryption protocol identifier registry is shown in Table 2. This document allocates one TEP identifier (0x20) for experimental use. In case the TEP identifier space proves too small, identifiers in the range 0x70-0x7f are reserved to enable a future update to this document to define extended identifier values. Future assignments are to be made upon satisfying either of two policies defined in [RFC8126]: "IETF Review" or (for non-IETF stream specifications) "Expert Review with RFC Required." IANA will furthermore provide early allocation [RFC7120] to facilitate testing before RFCs are finalized.
| Value | Meaning | Reference |
|---|---|---|
| 0x20 | Experimental Use | [RFC-TBD] |
| 0x70-0x7f | Reserved for extended values | [RFC-TBD] |
We are grateful for contributions, help, discussions, and feedback from the IETF and its TCPINC working group, including Marcelo Bagnulo, David Black, Bob Briscoe, Benoit Claise, Spencer Dawkins, Jake Holland, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Watson Ladd, Kathleen Moriarty, Yoav Nir, Christoph Paasch, Eric Rescorla, Adam Roach, Kyle Rose, Michael Scharf, Joe Touch, and Eric Vyncke. This work was partially funded by DARPA CRASH and the Stanford Secure Internet of Things Project.
Dan Boneh was a co-author of the draft that became this document.
| [RFC0793] | Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4086] | Eastlake 3rd, D., Schiller, J. and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005. |
| [RFC7120] | Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014. |
| [RFC8126] | Cotton, M., Leiba, B. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [SP800-57part1] | Barker, E., "Recommendation for Key Management, Part 1: General", NIST Special Publication 800-57 Part 1, Revision 4, January 2016. |