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 Abstract 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. Status of This Memo 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. Bittau, et al. Expires January 31, 2016 [Page 1] Internet-Draft tcpeno July 2015 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The TCP-ENO option . . . . . . . . . . . . . . . . . . . . . 4 2.1. TCP-ENO handshake . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Handshake examples . . . . . . . . . . . . . . . . . 8 2.2. General suboptions . . . . . . . . . . . . . . . . . . . 9 2.3. Negotiation transcript . . . . . . . . . . . . . . . . . 11 3. Requirements for encryption specs . . . . . . . . . . . . . . 12 3.1. Session IDs . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Option kind sharing . . . . . . . . . . . . . . . . . . . 14 4. API extensions . . . . . . . . . . . . . . . . . . . . . . . 14 5. Security considerations . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Many applications and protocols running on top of TCP today do not encrypt traffic. This failure to encrypt lowers the bar for certain attacks, harming both user privacy and system security. Counteracting the problem demands a minimally intrusive, backward- compatible mechanism for incrementally deploying encryption. The TCP Encryption Negotiation Option (TCP-ENO) specified in this document provides such a mechanism. 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: Bittau, et al. Expires January 31, 2016 [Page 2] Internet-Draft tcpeno July 2015 o Increased option space in TCP [I-D.ietf-tcpm-tcp-edo][I-D.briscoe- tcpm-inspace-mode-tcpbis][I-D.touch-tcpm-tcp-syn-ext-opt] could reduce round trip times and simplify protocols. o API revisions to socket interfaces [RFC3493] could benefit from integration with TCP-level encryption, particularly if combined with technologies such as DANE [RFC6394]. o The forthcoming TLS 1.3 [I-D.ietf-tls-tls13] standard could reach more applications given an out-of-band, backward-compatible mechanism for enabling encryption. o TCP fast open [RFC7413], as it gains more widespread adoption and middlebox acceptance, could potentially benefit from tailored encryption support. o 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: 1. How to negotiate the use of encryption at the TCP layer, and 2. 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. 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: 1. Enable endpoints to negotiate the use of a separately specified encryption _spec_. Bittau, et al. Expires January 31, 2016 [Page 3] Internet-Draft tcpeno July 2015 2. Transparently fall back to unencrypted TCP when not supported by both endpoints. 3. Provide signaling through which applications can better take advantage of TCP-level encryption (for instance by improving authentication mechanisms to reference a session ID). 4. Provide a standard negotiation transcript through which specs can defend against tampering with TCP-ENO. 5. Make parsimonious use of TCP option space. 6. Allow role negotiation during simultaneous open. 2. The TCP-ENO option 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) Bittau, et al. Expires January 31, 2016 [Page 4] Internet-Draft tcpeno July 2015 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 | +-----------+-----------------------------------------------------+ Table 1: TCP-ENO suboptions (options >= 0x80 are variable-length) Bittau, et al. Expires January 31, 2016 [Page 5] Internet-Draft tcpeno July 2015 2.1. TCP-ENO handshake 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: o An active opener 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 Figure 1. If ENO succeeds, the active opener's first ACK segment MUST subsequently contain a minimal ENO option, as pictured in Figure 2. o A passive opener's first transmitted segment has both the SYN and ACK flags set. Therefore, a passive opener MUST restrict ENO options to the single SYN-ACK segment it sends. 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 Bittau, et al. Expires January 31, 2016 [Page 6] Internet-Draft tcpeno July 2015 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: 1. The host receives a SYN segment without an ENO option, 2. The host receives a SYN segment for which it accepts none of the encryption spec suboptions, 3. 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 4. 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, 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. Bittau, et al. Expires January 31, 2016 [Page 7] Internet-Draft tcpeno July 2015 2.1.1. Handshake examples (1) A -> B: SYN ENO (2) B -> A: SYN-ACK ENO (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 (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: 1. The passive opener (B) does not support TCP-ENO, 2. B supports TCP-ENO, but does not support suboptions X or Y, so does not reply with an ENO option, or 3. 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 (2) B -> A: SYN-ACK ENO [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 Bittau, et al. Expires January 31, 2016 [Page 8] Internet-Draft tcpeno July 2015 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 (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. 2.2. General suboptions 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: z 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. aa The two application-aware bits are used to 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 Table 2. The default, when applications have not been modified to take advantage of TCP- Bittau, et al. Expires January 31, 2016 [Page 9] Internet-Draft tcpeno July 2015 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 values 01 and 10 (binary) indicate that the application is aware of TCP-ENO. The distinction between 01 and 10 is left to the application. 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. 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 | +-------+-------------------------------------------------------+ | 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 | +-------+-------------------------------------------------------+ Table 2: Meaning of the two application-aware bits p The "p" bit indicates that, for the purposes of encryption, the sender will play the role of virtual passive opener. If a passive opener sends a general option in a SYN-ACK segment, the "p" bit MUST be 1 by default. An active opener sending a general suboption MUST set the bit to 0 by default. However, implementations SHOULD provide an API by which applications can explicitly change the value of this bit so as to break the symmetry of simultaneous open or reverse the virtual active/ passive opener roles. If both ends of a connection specify the same value of "p", ENO fails and the connection MUST fall back to unencrypted TCP. One consequence is that an application employing TCP simultaneous open will always fall back to unencrypted TCP unless the application is modified to request a "p" bit of 1 at exactly one host. 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. Bittau, et al. Expires January 31, 2016 [Page 10] Internet-Draft tcpeno July 2015 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. 2.3. Negotiation transcript 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: 1. Every TCP-ENO option in the virtual active opener's SYN segment, in the order they appeared in that SYN segment. 2. A minimal two-byte ENO option, as shown in Figure 2. 3. Every TCP-ENO option in the virtual passive opener's SYN segment, in the order they appeared in that SYN segment. 4. A minimal two-byte ENO option, as shown in Figure 2. 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. Bittau, et al. Expires January 31, 2016 [Page 11] Internet-Draft tcpeno July 2015 3. Requirements for encryption specs 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. o Specs MUST always cryptographically protect both the integrity and confidentiality of TCP data streams. o 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. Section 3.1 describes the requirements of the session ID in more detail. o Specs MUST NOT permit the negotiation of any encryption algorithms with weaker than 128-bit security. o 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.) o Specs MUST NOT allow the negotiation of encryption modes that do not provide forward secrecy. o 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 with errors. o 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. 3.1. Session IDs 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 Bittau, et al. Expires January 31, 2016 [Page 12] Internet-Draft tcpeno July 2015 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: o The session ID MUST be at least 33 bytes (including the one-byte suboption), though specs may choose longer session IDs. o The session ID MUST depend in a collision-resistant way on fresh data contributed by both sides of the connection. o The session ID MUST depend in a collision-resistant way on any public keys, public Diffie-Hellman parameters, or other 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. o The session ID MUST NOT contain any confidential data (such as data permitting the derivation of session keys). o The session ID MUST depend on the negotiation transcript specified in Section 2.3 in a collision-resistant way. Bittau, et al. Expires January 31, 2016 [Page 13] Internet-Draft tcpeno July 2015 3.2. Option kind sharing 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. 4. API extensions 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 | +-------------------+----+-------+ Table 3: Suggested new IPPROTO_TCP socket options TCPENO_SESSID Returns the session ID of the connection, as defined by the encryption spec in use. The first byte can be used to determine which encryption spec is in use. This option MUST return an error if encryption is disabled, the connection is not yet established, or the transport layer does not implement the negotiated spec. Bittau, et al. Expires January 31, 2016 [Page 14] Internet-Draft tcpeno July 2015 TCPENO_SPECS Allows the application to specify an ordered list of encryption specs different from the system default list. If the list is empty, TCP-ENO is disabled for the connection. Each byte in the list specifies one suboption type from 0x20-0xff as listed in Table 1. The list contains no suboption data for variable- length suboptions, only the one-byte spec identifier. The order of the list matters only for the virtual passive opener. Implementations MUST return an error if an application attempts to set this option after the SYN segment has been sent. Implementations SHOULD return an error if any of the bytes are below 0x20 or are not implemented by the TCP stack. TCPENO_SELF_AWARE The value is an integer from 0-3, allowing applications to specify the "aa" bits in the general suboption sent by the host (see Section 2.2). Implementations MUST return an error if an application attempts to set this option after a SYN segment has been sent. TCPENO_PEER_AWARE The value is an integer from 0-3 reporting the "aa" bits in the general suboption of the peer's segment. Implementations MUST return an error if an application attempts to read this value before the connection is established. TCPENO_VPASSIVE The value is an integer from 0-1, specifying the "p" bit to set in the host's general suboption. Implementations MUST return an error if applications attempt to set this option after the SYN segment has been sent. Note that when a host does not send a general suboption, its implicit "p" bit may depend on the other suboption. Hence, when this option is read after the connection is established, it should return 1 if and only if the local host is the virtual passive opener. TCPENO_RAW This option is for use by library-level implementations of encryption specs. It allows applications to make use of the TCP-ENO option, potentially including encryption specs not supported by the transport layer, and then entirely bypass any TCP-level encryption so as to encrypt above the transport layer. The default value of this option is a 0-byte vector, which disables RAW mode. If the option is set to any other value, it disables all other socket options described in this section except for TCPENO_TRANSCRIPT. The value of the option is a raw ENO option contents (without the kind and length) to be included in the host's SYN segment. In raw mode, the TCP layer considers negotiation successful when there is an encryption spec that appears in both SYN segments. For an active opener in raw mode, the TCP layer automatically sends a two-byte minimal ENO option when negotiation is successful. Raw Bittau, et al. Expires January 31, 2016 [Page 15] Internet-Draft tcpeno July 2015 mode does not provide the full flexibility of implementing compatible but different suboptions, but nonetheless allows encryption spec authors to facilitate user-mode implementations by simply requiring identical one-byte suboptions to appear in both SYN segments. TCPENO_TRANSCRIPT Returns the negotiation transcript as specified in Section 2.3. Implementations MUST return an error if negotiation failed or has not yet completed. 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. 5. Security considerations 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. 6. IANA Considerations The following numbers need assignment by IANA: o A new TCP option kind number for ENO 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. Bittau, et al. Expires January 31, 2016 [Page 16] Internet-Draft tcpeno July 2015 7. Acknowledgments This work was funded by DARPA CRASH under contract #N66001-10-2-4088. 8. References 8.1. Normative References [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)", draft-bittau-tcpinc- tcpcrypt-03 (work in progress), July 2015. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . 8.2. Informative References [I-D.briscoe-tcpm-inspace-mode-tcpbis] Briscoe, B., "Inner Space for all TCP Options (Kitchen Sink Draft - to be Split Up)", draft-briscoe-tcpm-inspace- mode-tcpbis-00 (work in progress), March 2015. [I-D.ietf-tcpm-tcp-edo] Touch, J. and W. Eddy, "TCP Extended Data Offset Option", draft-ietf-tcpm-tcp-edo-03 (work in progress), April 2015. [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-07 (work in progress), 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", draft-touch-tcpm-tcp-syn- ext-opt-02 (work in progress), 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, . Bittau, et al. Expires January 31, 2016 [Page 17] Internet-Draft tcpeno July 2015 [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, . Authors' Addresses Andrea Bittau Stanford University 353 Serra Mall, Room 288 Stanford, CA 94305 US Email: bittau@cs.stanford.edu Dan Boneh Stanford University 353 Serra Mall, Room 475 Stanford, CA 94305 US Email: dabo@cs.stanford.edu Daniel B. Giffin Stanford University 353 Serra Mall, Room 288 Stanford, CA 94305 US Email: dbg@scs.stanford.edu Mark Handley University College London Gower St. London WC1E 6BT UK Email: M.Handley@cs.ucl.ac.uk Bittau, et al. Expires January 31, 2016 [Page 18] Internet-Draft tcpeno July 2015 David Mazieres Stanford University 353 Serra Mall, Room 290 Stanford, CA 94305 US Email: dm@uun.org Eric W. Smith Kestrel Institute 3260 Hillview Avenue Palo Alto, CA 94304 US Email: eric.smith@kestrel.edu Bittau, et al. Expires January 31, 2016 [Page 19]