| Network Working Group | A. Bittau |
| Internet-Draft | D. Boneh |
| Intended status: Experimental | D. Giffin |
| Expires: January 31, 2016 | Stanford University |
| M. Handley | |
| University College London | |
| D. Mazieres | |
| Stanford University | |
| E. Smith | |
| Kestrel Institute | |
| July 30, 2015 |
TCP-ENO: Encryption Negotiation Option
draft-bittau-tcpinc-tcpeno-00
Despite growing adoption of TLS [RFC5246], 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 http://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 January 31, 2016.
Copyright (c) 2015 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 (http://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.
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:
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:
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. A companion document, the tcpcrypt encryption spec [I-D.bittau-tcpinc-tcpcrypt], addresses question 2. Tcpcrypt enables TCP-level traffic encryption today. TCP-ENO ensures that the effort invested to deploy tcpcrypt today 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:
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 integrating encryption with authentication as discussed in Section 5.
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, as shown in Figure 1. In non-SYN segments, ENO MUST take the minimal form illustrated in Figure 2. The minimal form merely conveys one bit of information, namely an acknowledgment that the sender received the ENO option in the other host's SYN segment. A minimal ENO option requires only two bytes; any additional bytes are ignored by TCP-ENO, but MAY be used by encryption specs. In accordance with TCP [RFC0793], 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 |
+-----+-----+-----+-----+--...--+-----+----...----+
Figure 1: TCP-ENO option in SYN segment (MUST contain at least one suboption)
Byte 0 1 0 1 2 N-1
+-----+-----+ +-----+-----+-----...----+
|Kind=|Len= | |Kind=|Len= | ignored |
| ENO | 2 | OR | ENO | N | by TCP-ENO |
+-----+-----+ +-----+-----+-----...----+
Figure 2: Minimal TCP-ENO option in non-SYN segment
Each ENO suboption either specifies general parameters (discussed in Section 2.2) or indicates the willingness to use a specific encryption spec detailed in a separate document. There are two types of suboption: one-byte suboptions, numbered 0x00-0x7f, and variable-length suboptions, numbered 0x80-0xff. One-byte suboptions are further subdivided into general suboptions, which apply across all encryption specs, and spec identifiers, offering to follow a specific encryption spec for the connection. Variable-length suboptions are always spec identifiers and contain additional data as described in the corresponding spec. Possible uses of suboption data include session caching, early cipher suite negotiation in SYN segments, or even key agreement.
All but the last suboption of an ENO option MUST be one-byte suboptions (below 0x80). The last suboption MAY be a variable-length suboption. Its length is determined by the total length of the TCP option. In Figure 1, Opt_i is the variable-length option; its total size is N-(2+i) bytes--one byte for the spec identifier Opt_i itself, and N-(3+i) bytes for data. Multiple variable-length suboptions may be included in a single TCP segment by repeating the ENO option.
Table 1 shows initially assigned suboptions. Future specs will ascribe meaning to additional values, requiring updated versions of this table. Implementations MUST ignore all unknown suboptions.
| Suboption | Meaning |
|---|---|
| 0x00-0x0f | General options (see Section 2.2) |
| 0x10-0x1f | Reserved for possible use by future general options |
| 0x20 | Specified by TCP-CS1 spec |
| 0x22-0x23 | Specified by tcpcrypt spec |
| 0x24-0x25 | Specified by TLS working group |
| 0xa0 | Specified by TCP-CS1 spec |
| 0xa2-0xa3 | Specified by tcpcrypt spec |
| 0xa4-0xa5 | Specified by TLS working group |
The TCP-ENO option is intended for use during TCP connection establishment. To enable incremental deployment, a host must ensure both that the other host supports TCP-ENO and that middleboxes have not stripped the ENO option from TCP segments. In the event that either of these conditions does not hold, implementations MUST immediately cease sending TCP-ENO options and MUST gracefully fall back to unencrypted TCP.
More precisely, for negotiation to succeed, the TCP-ENO option MUST be present in the first 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 opener (where the application called connect) or a passive opener (where the application called listen and accept), the first ACK segment may or may not be the same as the first SYN segment. Specifically:
A spec identifier in a passive opener's SYN segment is valid if it is compatible with one of the suboptions in the active opener's ENO option. Two suboptions are compatible when they are allocated to the same encryption spec and the spec defines their combined use. Generally, two suboptions will be compatible when they are equal and incompatible when they are not. However, specs that have been allocated multiple suboptions MAY deviate from this behavior to pair a one-byte suboption with a variable-length suboption or to use the low bit of the spec identifier as an additional signaling mechanism.
Once the two sides have exchanged SYN segments, the negotiated spec is the first valid spec identifier in the passive opener's SYN segment. To handle simultaneous open (which has no passive opener), TCP-ENO introduces a notion of virtual passive opener. More precisely, then, the negotiated spec as the first valid spec identifier in the virtual passive opener's SYN segment. In other words, the order of suboptions in the virtual passive opener's SYN segment determines spec priority, while the order of suboptions in the other SYN segment has no effect. Hosts must disable TCP-ENO if the virtual passive opener's SYN segment contains no valid encryption specs.
When possible, passive openers SHOULD send only one spec identifier (suboption in the range 0x20-0xff), and SHOULD ensure this option is valid. However, sending a single valid spec identifier is not required, because doing so could be impractical in several cases, including simultaneous open or role reversal by means of the p bit discussed in Section 2.2, or library-level implementations that must provide the TCP-ENO option contents to the kernel as a static byte array.
A host MUST disable ENO if any of the following conditions holds:
After disabling ENO, a host MUST NOT transmit any further ENO options and MUST fall back to unencrypted TCP.
Conversely, if a host receives an ACK segment containing an ENO option, then encryption MUST be enabled. From this point the host 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.
Under simultaneous open, both hosts behave like active openers, with each sending two ENO options as described above. Nonetheless, it is necessary to break the symmetry of simultaneous open and select one host as the virtual passive opener for the purposes of determining the negotiated spec. The virtual passive opener role is negotiated by means of the p bit described in Section 2.2.
(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]
Figure 3: Three-way handshake with successful TCP-ENO negotiation.
Figure 3 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]
Figure 4: Three-way handshake with failed TCP-ENO negotiation.
Figure 4 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:
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]
Figure 5: Failed TCP-ENO negotiation because of network filtering.
Figure 5 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 minimal ENO option in its first ACK segment. The lack ENO in its 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<X,Y> (2) B -> A: SYN ENO<0x01,Z,Y,X> (3) A -> B: ACK ENO<> (4) B -> A: ACK ENO<> [rest of connection encrypted according to spec for Y]
Figure 6: Simultaneous open with successful TCP-ENO negotiation.
Figure 6 shows a successful TCP-ENO negotiation with simultaneous open. Here the first four segments MUST contain an ENO option (the first SYN and first ACK from each host). Note the use of general suboption 0x01 selects B as the virtual passive opener, as discussed in Section 2.2. Unless exactly one host can be designated the virtual passive opener, TCP-ENO MUST fail and fall back to unencrypted TCP.
Suboptions 0x00-0x0f are used for general conditions that apply regardless of the negotiated encryption spec. A TCP segment MUST include at most one suboption whose high nibble is 0. The value of the low nibble is interpreted as a bitmask, illustrated in Figure 7.
bit 7 6 5 4 3 2 1 0
+---+---+---+---+---+-------+---+
| 0 0 0 0 z aa p |
+---+---+---+---+---+-------+---+
z - Zero bit (reserved for future use)
aa - Application-aware bits
p - Virtual passive opener bit
Figure 7: Format of the general option byte
The fields of the bitmask are interpreted as follows:
| Value | Meaning |
|---|---|
| 00 | Application is not aware of TCP-ENO |
| 01 | Application is aware of TCP-ENO |
| 10 | Application is aware of TCP-ENO |
| 11 | Application awareness is mandatory for use of TCP-ENO |
If a general suboption is not present in either host's TCP SYN segment, then the general suboption is implicitly 0x00 for a SYN-only segment and 0x01 for a SYN-ACK segment. If exactly one host includes an explicit general suboption in its SYN segment, then the other SYN segment implicitly has a general suboption in which z = 0, aa = 00, and p is the complement of the other SYN segment's p bit.
We refer to the host with a p bit of 1 (in either an explicit or implicit general option) as the virtual passive opener. Conversely, we call the host sending a p bit of 0 the virtual active opener. The defaults were selected such that the virtual passive and active openers are the same as the actual passive and active openers in the absence of applications changing the p bit. Encryption specs SHOULD refer to TCP-ENO's virtual active opener and virtual passive opener when they need to break symmetry in their protocols.
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:
Note that 2 and 4 merely serve as delimiters to separate the two hosts' options from each other and from any data that follows the transcript. Even when the minimal ENO option contains ignored data, this data does not appear in the transcript. Because SYN segments MUST NOT contain minimal ENO options, this encoding is unique.
For the transcript to be well defined, hosts MUST NOT alter ENO options in retransmitted segments, except that an active opener MAY remove the ENO option altogether from a retransmitted SYN segment and disable TCP-ENO. Such removal could be useful if middleboxes are dropping segments with the ENO option.
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 from application writers, all encryption specs claiming ENO suboption numbers MUST satisfy the following properties.
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, such as the one discussed in Section 4. Applications that are aware of TCP-ENO SHOULD incorporate the session ID value 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 first valid spec identifier in the virtual passive opener's SYN segment. For variable-length suboptions, only the one-byte suboption is included, not the associated data. Figure 8 shows the resulting format.
Byte 0 1 2 N-1 N
+-----+------------...------------+
| sub-| collision-resistant hash |
| opt | of connection information |
+-----+------------...------------+
Figure 8: Format of a session ID
Though the specs retain considerable flexibility in their definitions of the session ID, all session IDs MUST meet certain minimum requirements. In particular:
This draft specifically prohibits ENO options from appearing in any segments other than the initial SYN and ACK segments of a connection. This means any use of the ENO option kind in subsequent segments 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 TCP handshake.
Implementations SHOULD provide a few API extensions through which applications can query and configure the behavior of TCP-ENO and associated specs. Operating systems with a Berkeley-sockets-like API SHOULD implement these extensions via the getsockopt and setsockopt system calls at level IPPROTO_TCP. Other operating systems SHOULD provide some equivalent mechanism.
Table 3 summarizes the options that SHOULD be made available to applications, along with whether they are read-only (R) or read-write (RW), and the type of the option's value. Except for TCPENO_VPASSIVE, read-write options, when read, always return the previously successfully written value or the default if they have not been written. Options of type bytes consist of a variable-length array of bytes, while options of type int consist of a small one- or two-bit positive integer. Below we discuss each option in more detail.
| Option | RW | Type |
|---|---|---|
| TCPENO_SESSID | R | bytes |
| TCPENO_SPECS | RW | bytes |
| TCPENO_SELF_AWARE | RW | int |
| TCPENO_PEER_AWARE | R | int |
| TCPENO_VPASSIVE | RW | int |
| TCPENO_RAW | RW | bytes |
| TCPENO_TRANSCRIPT | R | bytes |
In addition to these per-socket options, implementations SHOULD provide a mechanism, such as sysctl, by which an administrator can set a system-wide default for TCPENO_SPECS.
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 make use of the application-aware bits, and use application awareness to fold the session ID into authentication mechanisms. An example would be using a secret cookie to compute and exchange a message authentication code of the session ID.
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.
The following numbers need assignment by IANA:
In addition, going forward IANA will maintain a registry of ENO suboptions. The suboption registry will reflect new specs that claim particular suboption numbers, and will therefore supersede Table 1 of this document.
This work was funded by DARPA CRASH under contract #N66001-10-2-4088.
| [I-D.bittau-tcpinc-tcpcrypt] | Bittau, A., Boneh, D., Giffin, D., Hamburg, M., Handley, M., Mazieres, D. and Q. Slack, "Cryptographic protection of TCP Streams (tcpcrypt)", Internet-Draft draft-bittau-tcpinc-tcpcrypt-03, July 2015. |
| [RFC0793] | Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981. |
| [I-D.briscoe-tcpm-inspace-mode-tcpbis] | Briscoe, B., "Inner Space for all TCP Options (Kitchen Sink Draft - to be Split Up)", Internet-Draft draft-briscoe-tcpm-inspace-mode-tcpbis-00, March 2015. |
| [I-D.ietf-tcpm-tcp-edo] | Touch, J. and W. Eddy, "TCP Extended Data Offset Option", Internet-Draft draft-ietf-tcpm-tcp-edo-03, April 2015. |
| [I-D.ietf-tls-tls13] | Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Internet-Draft draft-ietf-tls-tls13-07, July 2015. |
| [I-D.touch-tcpm-tcp-syn-ext-opt] | Touch, J. and T. Faber, "TCP SYN Extended Option Space Using an Out-of-Band Segment", Internet-Draft draft-touch-tcpm-tcp-syn-ext-opt-02, April 2015. |
| [RFC3493] | Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003. |
| [RFC5246] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008. |
| [RFC6394] | Barnes, R., "Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)", RFC 6394, DOI 10.17487/RFC6394, October 2011. |
| [RFC7413] | Cheng, Y., Chu, J., Radhakrishnan, S. and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014. |