< draft-ietf-tcpinc-tcpeno-12.txt   draft-ietf-tcpinc-tcpeno-19.txt >
Network Working Group A. Bittau Network Working Group A. Bittau
Internet-Draft Google Internet-Draft Google
Intended status: Experimental D. Giffin Intended status: Experimental D. Giffin
Expires: April 25, 2018 Stanford University Expires: December 31, 2018 Stanford University
M. Handley M. Handley
University College London University College London
D. Mazieres D. Mazieres
Stanford University Stanford University
E. Smith E. Smith
Kestrel Institute Kestrel Institute
October 22, 2017 June 29, 2018
TCP-ENO: Encryption Negotiation Option TCP-ENO: Encryption Negotiation Option
draft-ietf-tcpinc-tcpeno-12 draft-ietf-tcpinc-tcpeno-19
Abstract Abstract
Despite growing adoption of TLS, a significant fraction of TCP Despite growing adoption of TLS, a significant fraction of TCP
traffic on the Internet remains unencrypted. The persistence of traffic on the Internet remains unencrypted. The persistence of
unencrypted traffic can be attributed to at least two factors. unencrypted traffic can be attributed to at least two factors.
First, some legacy protocols lack a signaling mechanism (such as a First, some legacy protocols lack a signaling mechanism (such as a
"STARTTLS" command) by which to convey support for encryption, making "STARTTLS" command) by which to convey support for encryption, making
incremental deployment impossible. Second, legacy applications incremental deployment impossible. Second, legacy applications
themselves cannot always be upgraded, requiring a way to implement themselves cannot always be upgraded, requiring a way to implement
encryption transparently entirely within the transport layer. The encryption transparently entirely within the transport layer. The
TCP Encryption Negotiation Option (TCP-ENO) addresses both of these TCP Encryption Negotiation Option (TCP-ENO) addresses both of these
problems through a new TCP option kind providing out-of-band, fully problems through a new TCP option-kind providing out-of-band, fully
backward-compatible negotiation of encryption. backward-compatible negotiation of encryption.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2018. This Internet-Draft will expire on December 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Requirements language . . . . . . . . . . . . . . . . . . . . 3 1. Requirements language . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Design goals . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Design goals . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. TCP-ENO Specification . . . . . . . . . . . . . . . . . . . . 5 4. TCP-ENO Specification . . . . . . . . . . . . . . . . . . . . 5
4.1. ENO Option . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. ENO Option . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. The Global Suboption . . . . . . . . . . . . . . . . . . 8 4.2. The Global Suboption . . . . . . . . . . . . . . . . . . 8
4.3. TCP-ENO Roles . . . . . . . . . . . . . . . . . . . . . . 9 4.3. TCP-ENO Roles . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Specifying Suboption Data Length . . . . . . . . . . . . 9 4.4. Specifying Suboption Data Length . . . . . . . . . . . . 10
4.5. The Negotiated Tep . . . . . . . . . . . . . . . . . . . 11 4.5. The Negotiated TEP . . . . . . . . . . . . . . . . . . . 11
4.6. TCP-ENO Handshake . . . . . . . . . . . . . . . . . . . . 11 4.6. TCP-ENO Handshake . . . . . . . . . . . . . . . . . . . . 12
4.7. Data in SYN Segments . . . . . . . . . . . . . . . . . . 13 4.7. Data in SYN Segments . . . . . . . . . . . . . . . . . . 13
4.8. Negotiation Transcript . . . . . . . . . . . . . . . . . 14 4.8. Negotiation Transcript . . . . . . . . . . . . . . . . . 15
5. Requirements for TEPs . . . . . . . . . . . . . . . . . . . . 15 5. Requirements for TEPs . . . . . . . . . . . . . . . . . . . . 15
5.1. Session IDs . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Session IDs . . . . . . . . . . . . . . . . . . . . . . . 16
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Future Developments . . . . . . . . . . . . . . . . . . . . . 19 7. Future Developments . . . . . . . . . . . . . . . . . . . . . 20
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 20 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Handshake Robustness . . . . . . . . . . . . . . . . . . 20 8.1. Handshake Robustness . . . . . . . . . . . . . . . . . . 21
8.2. Suboption Data . . . . . . . . . . . . . . . . . . . . . 20 8.2. Suboption Data . . . . . . . . . . . . . . . . . . . . . 21
8.3. Passive Role Bit . . . . . . . . . . . . . . . . . . . . 21 8.3. Passive Role Bit . . . . . . . . . . . . . . . . . . . . 21
8.4. Use of ENO Option Kind by TEPs . . . . . . . . . . . . . 21 8.4. Application-aware Bit . . . . . . . . . . . . . . . . . . 22
8.5. Unpredictability of Session IDs . . . . . . . . . . . . . 21 8.5. Use of ENO Option Kind by TEPs . . . . . . . . . . . . . 23
9. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.6. Unpredictability of Session IDs . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . 25 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . 25 14.1. Normative References . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Requirements language 1. Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Introduction 2. Introduction
skipping to change at page 3, line 38 skipping to change at page 3, line 38
greatest extent possible, the effort invested in realizing TCP-level greatest extent possible, the effort invested in realizing TCP-level
encryption today needs to remain applicable in the future should the encryption today needs to remain applicable in the future should the
need arise to change encryption strategies. To this end, it is need arise to change encryption strategies. To this end, it is
useful to consider two questions separately: useful to consider two questions separately:
1. How to negotiate the use of encryption at the TCP layer, and 1. How to negotiate the use of encryption at the TCP layer, and
2. How to perform encryption at the TCP layer. 2. How to perform encryption at the TCP layer.
This document addresses question 1 with a new TCP option, ENO. TCP- This document addresses question 1 with a new TCP option, ENO. TCP-
ENO provides a framework in which two endpoints can agree on one ENO provides a framework in which two endpoints can agree on a TCP
among multiple possible TCP encryption protocols or _TEPs_. For encryption protocol (_TEP_) out of multiple possible TEPs. For
future compatibility, TEPs can vary widely in terms of wire format, future compatibility, TEPs can vary widely in terms of wire format,
use of TCP option space, and integration with the TCP header and use of TCP option space, and integration with the TCP header and
segmentation. However, ENO abstracts these differences to ensure the segmentation. However, ENO abstracts these differences to ensure the
introduction of new TEPs can be transparent to applications taking introduction of new TEPs can be transparent to applications taking
advantage of TCP-level encryption. advantage of TCP-level encryption.
Question 2 is addressed by one or more companion TEP specification Question 2 is addressed by one or more companion TEP specification
documents. While current TEPs enable TCP-level traffic encryption documents. While current TEPs enable TCP-level traffic encryption
today, TCP-ENO ensures that the effort invested to deploy today's today, TCP-ENO ensures that the effort invested to deploy today's
TEPs will additionally benefit future ones. TEPs will additionally benefit future ones.
2.1. Design goals 2.1. Design goals
TCP-ENO was designed to achieve the following goals: TCP-ENO was designed to achieve the following goals:
1. Enable endpoints to negotiate the use of a separately specified 1. Enable endpoints to negotiate the use of a separately specified
TCP encryption protocol or _TEP_. TCP encryption protocol (_TEP_) suitable for either opportunistic
security [RFC7435] of arbitrary TCP communications or stronger
security of applications willing to perform endpoint
authentication.
2. Transparently fall back to unencrypted TCP when not supported by 2. Transparently fall back to unencrypted TCP when not supported by
both endpoints. both endpoints.
3. Provide out-of-band signaling through which applications can 3. Provide out-of-band signaling through which applications can
better take advantage of TCP-level encryption (for instance, by better take advantage of TCP-level encryption (for instance, by
improving authentication mechanisms in the presence of TCP-level improving authentication mechanisms in the presence of TCP-level
encryption). encryption).
4. Provide a standard negotiation transcript through which TEPs can 4. Define a standard negotiation transcript that TEPs can use to
defend against tampering with TCP-ENO. defend against tampering with TCP-ENO.
5. Make parsimonious use of TCP option space. 5. Make parsimonious use of TCP option space.
6. Define roles for the two ends of a TCP connection, so as to name 6. Define roles for the two ends of a TCP connection, so as to name
each end of a connection for encryption or authentication each end of a connection for encryption or authentication
purposes even following a symmetric simultaneous open. purposes even following a symmetric simultaneous open.
3. Terminology 3. Terminology
We define the following terms, which are used throughout this Throughout this document, we use the following terms, several of
document: which have more detailed normative descriptions in [RFC0793]:
SYN segment SYN segment
A TCP segment in which the SYN flag is set A TCP segment in which the SYN flag is set
ACK segment ACK segment
A TCP segment in which the ACK flag is set (which includes most A TCP segment in which the ACK flag is set (which includes most
segments other than an initial SYN segment) segments other than an initial SYN segment)
non-SYN segment non-SYN segment
A TCP segment in which the SYN flag is clear A TCP segment in which the SYN flag is clear
skipping to change at page 5, line 38 skipping to change at page 5, line 40
A unique 7-bit value in the range 0x20-0x7f that IANA has assigned A unique 7-bit value in the range 0x20-0x7f that IANA has assigned
to a TEP. to a TEP.
Negotiated TEP Negotiated TEP
The single TEP governing a TCP connection, determined by use of The single TEP governing a TCP connection, determined by use of
the TCP ENO option specified in this document. the TCP ENO option specified in this document.
4. TCP-ENO Specification 4. TCP-ENO Specification
TCP-ENO extends TCP connection establishment to enable encryption TCP-ENO extends TCP connection establishment to enable encryption
opportunistically. It uses a new TCP option kind to negotiate one opportunistically. It uses a new TCP option-kind [RFC0793] to
among multiple possible TCP encryption protocols or TEPs. The negotiate one among multiple possible TCP encryption protocols
negotiation involves hosts exchanging sets of supported TEPs, where (TEPs). The negotiation involves hosts exchanging sets of supported
each TEP is represented by a _suboption_ within a larger TCP ENO TEPs, where each TEP is represented by a _suboption_ within a larger
option in the offering host's SYN segment. TCP ENO option in the offering host's SYN segment.
If TCP-ENO succeeds, it yields the following information: If TCP-ENO succeeds, it yields the following information:
o A negotiated TEP, represented by a unique 7-bit TEP identifier, o A negotiated TEP, represented by a unique 7-bit TEP identifier,
o A few extra bytes of suboption data from each host, if needed by o A few extra bytes of suboption data from each host, if needed by
the TEP, the TEP,
o A negotiation transcript with which to mitigate attacks on the o A negotiation transcript with which to mitigate attacks on the
negotiation itself, negotiation itself,
skipping to change at page 7, line 16 skipping to change at page 7, line 16
+-----+-----+-----...----+ +-----+-----+-----...----+
|Kind=|Len= | ignored | |Kind=|Len= | ignored |
| TBD | N+2 | by TCP-ENO | | TBD | N+2 | by TCP-ENO |
+-----+-----+-----...----+ +-----+-----+-----...----+
Figure 3: Non-SYN form of ENO, where N MAY be 0 Figure 3: Non-SYN form of ENO, where N MAY be 0
Every suboption starts with a byte of the form illustrated in Every suboption starts with a byte of the form illustrated in
Figure 4. The high bit "v", when set, introduces suboptions with Figure 4. The high bit "v", when set, introduces suboptions with
variable-length data. When "v = 0", the byte itself constitutes the variable-length data. When "v = 0", the byte itself constitutes the
entirety of the suboption. The 7-bit value "glt" expresses one of: entirety of the suboption. The remaining 7-bit value, called "glt",
takes on various meanings, as defined below:
o Global configuration data (discussed in Section 4.2), o Global configuration data (discussed in Section 4.2),
o Suboption data length for the next suboption (discussed in o Suboption data length for the next suboption (discussed in
Section 4.4), or Section 4.4), or
o An offer to use a particular TEP defined in a separate TEP o An offer to use a particular TEP defined in a separate TEP
specification document. specification document.
bit 7 6 5 4 3 2 1 0 bit 7 6 5 4 3 2 1 0
skipping to change at page 7, line 44 skipping to change at page 7, line 45
Figure 4: Format of initial suboption byte Figure 4: Format of initial suboption byte
Table 1 summarizes the meaning of initial suboption bytes. Values of Table 1 summarizes the meaning of initial suboption bytes. Values of
"glt" below 0x20 are used for global suboptions and length "glt" below 0x20 are used for global suboptions and length
information (the "gl" in "glt"), while those greater than or equal to information (the "gl" in "glt"), while those greater than or equal to
0x20 are TEP identifiers (the "t"). When "v = 0", the initial 0x20 are TEP identifiers (the "t"). When "v = 0", the initial
suboption byte constitutes the entirety of the suboption and all suboption byte constitutes the entirety of the suboption and all
information is expressed by the 7-bit "glt" value, which can be information is expressed by the 7-bit "glt" value, which can be
either a global suboption or a TEP identifier. When "v = 1", it either a global suboption or a TEP identifier. When "v = 1", it
indicates a suboption with variable-length suboption data. Only TEP indicates a suboption with variable-length suboption data. Only TEP
identifiers may have suboption data, not global suboptions. Hence, identifiers have suboption data, not global suboptions. Hence, bytes
bytes with "v = 1" and "glt < 0x20" are not global suboptions but with "v = 1" and "glt < 0x20" are not global suboptions but rather
rather length bytes governing the length of the next suboption (which length bytes governing the length of the next suboption (which MUST
MUST be a TEP identifier). In the absence of a length byte, a TEP be a TEP identifier). In the absence of a length byte, a TEP
identifier suboption with "v = 1" has suboption data extending to the identifier suboption with "v = 1" has suboption data extending to the
end of the TCP option. end of the TCP option.
+-----------+---+-------------------------------------------+ +-----------+---+-------------------------------------------+
| glt | v | Meaning | | glt | v | Meaning |
+-----------+---+-------------------------------------------+ +-----------+---+-------------------------------------------+
| 0x00-0x1f | 0 | Global suboption (Section 4.2) | | 0x00-0x1f | 0 | Global suboption (Section 4.2) |
| 0x00-0x1f | 1 | Length byte (Section 4.4) | | 0x00-0x1f | 1 | Length byte (Section 4.4) |
| 0x20-0x7f | 0 | TEP identifier without suboption data | | 0x20-0x7f | 0 | TEP identifier without suboption data |
| 0x20-0x7f | 1 | TEP identifier followed by suboption data | | 0x20-0x7f | 1 | TEP identifier followed by suboption data |
skipping to change at page 8, line 52 skipping to change at page 8, line 52
Figure 5: Format of the global suboption byte Figure 5: Format of the global suboption byte
The fields of the bitmask are interpreted as follows: The fields of the bitmask are interpreted as follows:
b b
The passive role bit MUST be 1 for all passive openers. For The passive role bit MUST be 1 for all passive openers. For
active openers, it MUST default to 0, but implementations MUST active openers, it MUST default to 0, but implementations MUST
provide an API through which an application can explicitly set "b provide an API through which an application can explicitly set "b
= 1" before initiating an active open. (Manual configuration of = 1" before initiating an active open. (Manual configuration of
"b" is necessary to enable encryption with a simultaneous open.) "b" is only necessary to enable encryption with a simultaneous
open, and requires prior coordination to ensure exactly one
endpoint sets "b = 1" before connecting.)
a a
Legacy applications can benefit from ENO-specific updates that Legacy applications can benefit from ENO-specific updates that
improve endpoint authentication or avoid double encryption. The improve endpoint authentication or avoid double encryption. The
application-aware bit "a" is an out-of-band signal through which application-aware bit "a" is an out-of-band signal through which
higher-layer protocols can enable ENO-specific updates that would higher-layer protocols can enable ENO-specific updates that would
otherwise not be backwards-compatible. Implementations MUST set otherwise not be backwards-compatible. Implementations MUST set
this bit to 0 by default, and MUST provide an API through which this bit to 0 by default, and MUST provide an API through which
applications can change the value of the bit as well as examine applications can change the value of the bit as well as examine
the value of the bit sent by the remote host. Implementations the value of the bit sent by the remote host. Implementations
skipping to change at page 9, line 30 skipping to change at page 9, line 32
MUST be set to zero in sent segments and MUST be ignored in MUST be set to zero in sent segments and MUST be ignored in
received segments. received segments.
A SYN segment without an explicit global suboption has an implicit A SYN segment without an explicit global suboption has an implicit
global suboption of 0x00. Because passive openers MUST always set "b global suboption of 0x00. Because passive openers MUST always set "b
= 1", they cannot rely on this implicit 0x00 byte and MUST include an = 1", they cannot rely on this implicit 0x00 byte and MUST include an
explicit global suboption in their SYN-ACK segments. explicit global suboption in their SYN-ACK segments.
4.3. TCP-ENO Roles 4.3. TCP-ENO Roles
TCP-ENO uses abstract roles to distinguish the two ends of a TCP TCP-ENO uses abstract roles called "A" and "B" to distinguish the two
connection. These roles are determined by the "b" bit in the global ends of a TCP connection. These roles are determined by the "b" bit
suboption. The host that sent an implicit or explicit suboption with in the global suboption. The host that sent an implicit or explicit
"b = 0" plays the "A" role. The host that sent "b = 1" plays the "B" suboption with "b = 0" plays the A role. The host that sent "b = 1"
role. 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.
If both sides of a connection set "b = 1" (which can happen if the Applications performing a simultaneous open, if they desire TCP-level
active opener misconfigures "b" before calling "connect"), or both encryption, need to arrange for exactly one endpoint to set "b = 1"
sides set "b = 0" (which can happen with simultaneous open), then (despite being an active opener) while the other endpoint keeps the
TCP-ENO MUST be disabled and the connection MUST fall back to default "b = 0". Otherwise, if both sides use the default "b = 0" or
unencrypted TCP. 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 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 asymmetric behavior by the two hosts. For the remainder of this
document, we will use the terms "host A" and "host B" to designate document, we will use the terms "host A" and "host B" to designate
the hosts with roles A and B, respectively, in a connection. the hosts with roles A and B, respectively, in a connection.
4.4. Specifying Suboption Data Length 4.4. Specifying Suboption Data Length
A TEP MAY optionally make use of one or more bytes of suboption data. 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 The presence of such data is indicated by setting "v = 1" in the
initial suboption byte (see Figure 4). By default, suboption data initial suboption byte (see Figure 4). A suboption introduced by a
extends to the end of the TCP option. Hence, if only one suboption TEP identifier with "v = 1" (i.e., a suboption whose first octet has
requires data, the most compact way to encode it is to place it last value 0xa0 or higher) extends to the end of the TCP option. Hence,
in the ENO option, after all other suboptions. As an example, in if only one suboption requires data, the most compact way to encode
Figure 2, the last suboption, "Opt_i", has suboption data and thus it is to place it last in the ENO option, after all other suboptions.
requires "v = 1"; however, the suboption data length is inferred from As an example, in Figure 2, the last suboption, "Opt_i", has
the total length of the TCP option. 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 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 MUST explicitly specify the suboption data length for the receiver to
know where the next suboption starts. The sender does so by know where the next suboption starts. The sender does so by
preceding the suboption with a length byte, depicted in Figure 6. introducing the suboption with a length byte, depicted in Figure 6.
The length byte encodes a 5-bit value "nnnnn". Adding one to "nnnnn" The length byte encodes a 5-bit value "nnnnn". Adding one to "nnnnn"
yields the length of the suboption data (not including the length yields the length of the suboption data (not including the length
byte or the TEP identifier). Hence, a length byte can designate byte or the TEP identifier). Hence, a length byte can designate
anywhere from 1 to 32 bytes of suboption data (inclusive). anywhere from 1 to 32 bytes of suboption data (inclusive).
bit 7 6 5 4 3 2 1 0 bit 7 6 5 4 3 2 1 0
+---+---+---+-------------------+ +---+---+---+-------------------+
| 1 0 0 nnnnn | | 1 0 0 nnnnn |
+---+---+---+-------------------+ +---+---+---+-------------------+
skipping to change at page 11, line 16 skipping to change at page 11, line 37
its length inferred from the 8-bit TCP option length, it MAY contain its length inferred from the 8-bit TCP option length, it MAY contain
more than 32 bytes of suboption data. Other suboptions are limited more than 32 bytes of suboption data. Other suboptions are limited
to 32 bytes by the length byte format. The TCP header itself can to 32 bytes by the length byte format. The TCP header itself can
only accommodate a maximum of 40 bytes of options, however. Hence, only accommodate a maximum of 40 bytes of options, however. Hence,
regardless of the length byte format, a segment would not be able to 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, contain more than one suboption over 32 bytes in size. That said,
TEPs MAY define the use of multiple suboptions with the same TEP TEPs MAY define the use of multiple suboptions with the same TEP
identifier in the same SYN segment, providing another way to convey identifier in the same SYN segment, providing another way to convey
over 32 bytes of suboption data even with length bytes. over 32 bytes of suboption data even with length bytes.
4.5. The Negotiated Tep 4.5. The Negotiated TEP
A TEP identifier "glt" (with "glt >= 0x20") is _valid_ for a A TEP identifier "glt" (with "glt >= 0x20") is _valid_ for a
connection when: connection when:
1. Each side has sent a suboption for "glt" in its SYN-form ENO 1. Each side has sent a suboption for "glt" in its SYN-form ENO
option, option,
2. Any suboption data in these "glt" suboptions is valid according 2. Any suboption data in these "glt" suboptions is valid according
to the TEP specification and satisfies any runtime constraints, to the TEP specification and satisfies any runtime constraints,
and and
skipping to change at page 12, line 40 skipping to change at page 13, line 13
role negotiation failed). role negotiation failed).
Once a host has both sent and received an ACK segment containing an Once a host has both sent and received an ACK segment containing an
ENO option, encryption MUST be enabled. Once encryption is enabled, ENO option, encryption MUST be enabled. Once encryption is enabled,
hosts MUST follow the specification of the negotiated TEP and MUST hosts MUST follow the specification of the negotiated TEP and MUST
NOT present raw TCP payload data to the application. In particular, NOT present raw TCP payload data to the application. In particular,
data segments MUST NOT contain plaintext application data, but rather data segments MUST NOT contain plaintext application data, but rather
ciphertext, key negotiation parameters, or other messages as ciphertext, key negotiation parameters, or other messages as
determined by the negotiated TEP. determined by the negotiated TEP.
A host MAY send a _vacuous_ SYN-form ENO option containing zero TEP A host MAY send a SYN-form ENO option containing zero TEP identifier
identifier suboptions. If either host sends a vacuous ENO option, it suboptions, which we term a _vacuous_ ENO option. If either host's
follows that there are no valid TEP identifiers for the connection SYN segment contains a vacuous ENO option, it follows that there are
and hence the connection must fall back to unencrypted TCP. Hosts no valid TEP identifiers for the connection and hence the connection
MAY send vacuous ENO options to indicate that ENO is supported but MUST fall back to unencrypted TCP. Hosts MAY send vacuous ENO
unavailable by configuration, or to probe network paths for options to indicate that ENO is supported but unavailable by
robustness to ENO options. However, a passive opener MUST NOT send a configuration, or to probe network paths for robustness to ENO
vacuous ENO option in a SYN-ACK segment unless there was an ENO options. However, a passive opener MUST NOT send a vacuous ENO
option in the SYN segment it received. Moreover, a passive opener's option in a SYN-ACK segment unless there was an ENO option in the SYN
SYN-form ENO option MUST still include a global suboption with "b = segment it received. Moreover, a passive opener's SYN-form ENO
1", as discussed in Section 4.3. option MUST still include a global suboption with "b = 1", as
discussed in Section 4.3.
4.7. Data in SYN Segments 4.7. Data in SYN Segments
TEPs MAY specify the use of data in SYN segments so as to reduce the 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 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 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 determined by the last TEP identifier in the ENO option, which we
term the segment's _SYN TEP_. 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 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. unless the SYN TEP's specification defines the use of such data.
Furthermore, to avoid conflicting interpretations of SYN data, a Furthermore, to avoid conflicting interpretations of SYN data, a
SYN+ENO segment MUST NOT include a non-empty TCP Fast Open (TFO) SYN+ENO segment MUST NOT include a non-empty TCP Fast Open (TFO)
option [RFC7413]. option [RFC7413].
Because a host can send SYN data before knowing which if any TEP will Because a host can send SYN data before knowing which if any TEP the
govern a connection, hosts implementing ENO are REQUIRED to discard connection will negotiate, hosts implementing ENO are REQUIRED to
data from SYN+ENO segments when the SYN TEP does not govern the discard data from SYN+ENO segments when the SYN TEP does not become
connection or when there is any ambiguity over the meaning of the SYN the negotiated TEP. Hosts are furthermore REQUIRED to discard SYN
data. This requirement applies to hosts that implement ENO even when data in cases where another Internet standard specifies a conflicting
ENO has been disabled by configuration. However, note that 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 discarding SYN data is already common practice [RFC4987] and the new
requirement applies only to segments containing ENO options. requirement applies only to segments containing ENO options.
More specifically, a host that implements ENO MUST discard the data More specifically, a host that implements ENO MUST discard the data
in a received SYN+ENO segment if any of the following applies: in a received SYN+ENO segment if any of the following applies:
o ENO fails and TEP-indicated encryption is disabled for the o ENO fails and TEP-indicated encryption is disabled for the
connection, connection,
o The received segment's SYN TEP is not the negotiated TEP, o The received segment's SYN TEP is not the negotiated TEP,
skipping to change at page 13, line 50 skipping to change at page 14, line 27
A host discarding SYN data in compliance with the above requirement A host discarding SYN data in compliance with the above requirement
MUST NOT acknowledge the sequence number of the discarded data, but MUST NOT acknowledge the sequence number of the discarded data, but
rather MUST acknowledge the other host's initial sequence number as rather MUST acknowledge the other host's initial sequence number as
if the received SYN segment contained no data. Furthermore, after if the received SYN segment contained no data. Furthermore, after
discarding SYN data, such a host MUST NOT assume the SYN data will be discarding SYN data, such a host MUST NOT assume the SYN data will be
identically retransmitted, and MUST process data only from non-SYN identically retransmitted, and MUST process data only from non-SYN
segments. segments.
If a host sends a SYN+ENO segment with data and receives If a host sends a SYN+ENO segment with data and receives
acknowledgment for the data, but the SYN TEP governing the data is acknowledgment for the data, but the SYN TEP in its transmitted SYN
not the negotiated TEP (either because a different TEP was negotiated segment is not the negotiated TEP (either because a different TEP was
or because ENO failed to negotiate encryption), then the host MUST negotiated or because ENO failed to negotiate encryption), then the
abort the TCP connection. Proceeding in any other fashion risks host MUST abort the TCP connection. Proceeding in any other fashion
misinterpreted SYN data. risks misinterpreted SYN data.
If a host sends a SYN-only SYN+ENO segment bearing data and If a host sends a SYN-only SYN+ENO segment bearing data and
subsequently receives a SYN-ACK segment without an ENO option, that subsequently receives a SYN-ACK segment without an ENO option, that
host MUST abort the connection even if the SYN-ACK segment does not host MUST abort the connection even if the SYN-ACK segment does not
acknowledge the SYN data. The issue is that unacknowledged data may acknowledge the SYN data. The issue is that unacknowledged data
nonetheless have been cached by the receiver; later retransmissions could nonetheless have been cached by the receiver; later
intended to supersede this unacknowledged data could fail to do so if retransmissions intended to supersede this unacknowledged data could
the receiver gives precedence to the cached original data. fail to do so if the receiver gives precedence to the cached original
Implementations MAY provide an API call for a non-default mode in data. Implementations MAY provide an API call for a non-default mode
which unacknowledged SYN data does not cause a connection abort, but in which unacknowledged SYN data does not cause a connection abort,
applications MUST use this mode only when a higher-layer integrity but applications MUST use this mode only when a higher-layer
check would anyway terminate a garbled connection. integrity check would anyway terminate a garbled connection.
To avoid unexpected connection aborts, ENO implementations MUST To avoid unexpected connection aborts, ENO implementations MUST
disable the use of data in SYN-only segments by default. Such data disable the use of data in SYN-only segments by default. Such data
MAY be enabled by an API command. In particular, implementations MAY MAY be enabled by an API command. In particular, implementations MAY
provide a per-connection mandatory encryption mode that automatically provide a per-connection mandatory encryption mode that automatically
aborts a connection if ENO fails, and MAY enable SYN data in this aborts a connection if ENO fails, and MAY enable SYN data in this
mode. mode.
To satisfy the requirement of the previous paragraph, all TEPs SHOULD To satisfy the requirement of the previous paragraph, all TEPs SHOULD
support a normal mode of operation that avoids data in SYN-only support a normal mode of operation that avoids data in SYN-only
segments. An exception is TEPs intended to be disabled by default. segments. An exception is TEPs intended to be disabled by default.
4.8. Negotiation Transcript 4.8. Negotiation Transcript
To defend against attacks on encryption negotiation itself, a TEP To defend against attacks on encryption negotiation itself, a TEP
MUST with high probability fail to establish a working connection MUST with high probability fail to establish a working connection
between two ENO-compliant hosts when SYN-form ENO options have been between two ENO-compliant hosts when SYN-form ENO options have been
altered in transit. (Of course, in the absence of endpoint altered in transit. (Of course, in the absence of endpoint
authentication, two compliant hosts can each still be connected to a authentication, two compliant hosts can each still be connected to a
man-in-the-middle attacker.) To detect SYN-form ENO option man-in-the-middle attacker.) To detect SYN-form ENO option
tampering, TEPs must reference a transcript of TCP-ENO's negotiation. tampering, TEPs MUST reference a transcript of TCP-ENO's negotiation.
TCP-ENO defines its negotiation transcript as a packed data structure TCP-ENO defines its negotiation transcript as a packed data structure
consisting of two TCP-ENO options exactly as they appeared in the TCP 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 header (including the TCP option-kind and TCP option length byte as
illustrated in Figure 1). The transcript is constructed from the illustrated in Figure 1). The transcript is constructed from the
following, in order: following, in order:
1. The TCP-ENO option in host A's SYN segment, including the kind 1. The TCP-ENO option in host A's SYN segment, including the kind
and length bytes. and length bytes.
2. The TCP-ENO option in host B's SYN segment, including the kind 2. The TCP-ENO option in host B's SYN segment, including the kind
and length bytes. and length bytes.
Note that because the ENO options in the transcript contain length Note that because the ENO options in the transcript contain length
skipping to change at page 15, line 18 skipping to change at page 15, line 44
5. Requirements for TEPs 5. Requirements for TEPs
TCP-ENO affords TEP specifications a large amount of design TCP-ENO affords TEP specifications a large amount of design
flexibility. However, to abstract TEP differences away from flexibility. However, to abstract TEP differences away from
applications requires fitting them all into a coherent framework. As applications requires fitting them all into a coherent framework. As
such, any TEP claiming an ENO TEP identifier MUST satisfy the such, any TEP claiming an ENO TEP identifier MUST satisfy the
following normative list of properties. following normative list of properties.
o TEPs MUST protect TCP data streams with authenticated encryption. o TEPs MUST protect TCP data streams with authenticated encryption.
(Note "authenticated encryption" designates the REQUIRED form (Note "authenticated encryption" refers only to the form of
encryption algorithm [RFC5116]; it does not imply any actual encryption, such as an AEAD algorithm meeting the requirements of
endpoint authentication.) [RFC5116]; it does not imply endpoint authentication.)
o TEPs MUST define a session ID whose value identifies the TCP o TEPs MUST define a session ID whose value identifies the TCP
connection and, with overwhelming probability, is unique over all connection and, with overwhelming probability, is unique over all
time if either host correctly obeys the TEP. Section 5.1 time if either host correctly obeys the TEP. Section 5.1
describes the requirements of the session ID in more detail. describes the requirements of the session ID in more detail.
o TEPs MUST NOT permit the negotiation of any encryption algorithms o TEPs MUST NOT make data confidentiality dependent on encryption
with significantly less than 128-bit security. algorithms with a security strength [SP800-57part1] of less than
120 bits. The number 120 was chosen to accommodate ciphers with
128-bit keys that lose a few bits of security either to
particularities of the key schedule or to highly theoretical and
unrealistic attacks.
o TEPs MUST NOT allow the negotiation of null cipher suites, even o TEPs MUST NOT allow the negotiation of null cipher suites, even
for debugging purposes. (Implementations MAY support debugging for debugging purposes. (Implementations MAY support debugging
modes that allow applications to extract their own session keys.) modes that allow applications to extract their own session keys.)
o TEPs MUST NOT depend on long-lived secrets for data o TEPs MUST guarantee the confidentiality of TCP streams without
confidentiality, as implementations SHOULD provide forward secrecy assuming the security of any long-lived secrets. Implementations
some bounded, short time after the close of a TCP connection. SHOULD provide forward secrecy soon after the close of a TCP
connection, and SHOULD therefore bound the delay between closing a
connection and erasing any relevant cryptographic secrets.
(Exceptions to forward secrecy are permissible only at the (Exceptions to forward secrecy are permissible only at the
implementation level, and only in response to hardware or implementation level, and only in response to hardware or
architectural constraints--e.g., storage that cannot be securely architectural constraints--e.g., storage that cannot be securely
erased.) erased.)
o TEPs MUST protect and authenticate the end-of-file marker conveyed o TEPs MUST protect and authenticate the end-of-file marker conveyed
by TCP's FIN flag. In particular, a receiver MUST with high by TCP's FIN flag. In particular, a receiver MUST with
probability detect a FIN flag that was set or cleared in transit overwhelming probability detect a FIN flag that was set or cleared
and does not match the sender's intent. A TEP MAY discard a in transit and does not match the sender's intent. A TEP MAY
segment with such a corrupted FIN bit, or may abort the connection discard a segment with such a corrupted FIN bit, or MAY abort the
in response to such a segment. However, any such abort MUST raise connection in response to such a segment. However, any such abort
an error condition distinct from an authentic end-of-file MUST raise an error condition distinct from an authentic end-of-
condition. file condition.
o TEPs MUST prevent corrupted packets from causing urgent data to be o TEPs MUST prevent corrupted packets from causing urgent data to be
delivered when none has been sent. A TEP MAY do so by delivered when none has been sent. There are several ways to do
cryptographically protecting the URG flag and urgent pointer so. For instance, a TEP MAY cryptographically protect the URG
alongside ordinary payload data. Alternatively, a TEP MAY disable flag and urgent pointer alongside ordinary payload data.
urgent data functionality by clearing the URG flag on all received Alternatively, a TEP MAY disable urgent data functionality by
segments and returning errors in response to sender-side urgent- clearing the URG flag on all received segments and returning
data API calls. Implementations SHOULD avoid negotiating TEPs errors in response to sender-side urgent-data API calls.
that disable urgent data by default. The exception is when Implementations SHOULD avoid negotiating TEPs that disable urgent
applications and protocols are known never to send urgent data. data by default. The exception is when applications and protocols
are known never to send urgent data.
5.1. Session IDs 5.1. Session IDs
Each TEP MUST define a session ID that is computable by both Each TEP MUST define a session ID that is computable by both
endpoints and uniquely identifies each encrypted TCP connection. endpoints and uniquely identifies each encrypted TCP connection.
Implementations MUST expose the session ID to applications via an API Implementations MUST expose the session ID to applications via an API
extension. The API extension MUST return an error when no session ID extension. The API extension MUST return an error when no session ID
is available because ENO has failed to negotiate encryption or is available because ENO has failed to negotiate encryption or
because no connection is yet established. Applications that are because no connection is yet established. Applications that are
aware of TCP-ENO SHOULD, when practical, authenticate the TCP aware of TCP-ENO SHOULD, when practical, authenticate the TCP
skipping to change at page 18, line 7 skipping to change at page 18, line 33
(1) A -> B: SYN ENO<X,Y> (1) A -> B: SYN ENO<X,Y>
(2) B -> A: SYN-ACK ENO<b=1,Y> (2) B -> A: SYN-ACK ENO<b=1,Y>
(3) A -> B: ACK ENO<> (3) A -> B: ACK ENO<>
[rest of connection encrypted according to TEP Y] [rest of connection encrypted according to TEP Y]
Figure 9: Three-way handshake with successful TCP-ENO negotiation Figure 9: Three-way handshake with successful TCP-ENO negotiation
Figure 9 shows a three-way handshake with a successful TCP-ENO Figure 9 shows a three-way handshake with a successful TCP-ENO
negotiation. Host A includes two ENO suboptions with TEP identifiers negotiation. Host A includes two ENO suboptions with TEP identifiers
X and Y. The two sides agree to follow the TEP identified by 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. suboption Y.
(1) A -> B: SYN ENO<X,Y> (1) A -> B: SYN ENO<X,Y>
(2) B -> A: SYN-ACK (2) B -> A: SYN-ACK
(3) A -> B: ACK (3) A -> B: ACK
[rest of connection unencrypted legacy TCP] [rest of connection unencrypted legacy TCP]
Figure 10: Three-way handshake with failed TCP-ENO negotiation Figure 10: Three-way handshake with failed TCP-ENO negotiation
Figure 10 shows a failed TCP-ENO negotiation. The active opener (A) Figure 10 shows a failed TCP-ENO negotiation. The active opener (A)
skipping to change at page 18, line 22 skipping to change at page 19, line 4
(3) A -> B: ACK (3) A -> B: ACK
[rest of connection unencrypted legacy TCP] [rest of connection unencrypted legacy TCP]
Figure 10: Three-way handshake with failed TCP-ENO negotiation Figure 10: Three-way handshake with failed TCP-ENO negotiation
Figure 10 shows a failed TCP-ENO negotiation. The active opener (A) Figure 10 shows a failed TCP-ENO negotiation. The active opener (A)
indicates support for TEPs corresponding to suboptions X and Y. indicates support for TEPs corresponding to suboptions X and Y.
Unfortunately, at this point one of several things occurs: Unfortunately, at this point one of several things occurs:
1. The passive opener (B) does not support TCP-ENO, 1. The passive opener (B) does not support TCP-ENO,
2. B supports TCP-ENO, but supports neither of TEPs X and Y, and so 2. B supports TCP-ENO, but supports neither of TEPs X and Y, and so
does not reply with an ENO option, does not reply with an ENO option,
3. B supports TCP-ENO, but has the connection configured in 3. B supports TCP-ENO, but has the connection configured in
mandatory application-aware mode and thus disables ENO because mandatory application-aware mode and thus disables ENO because
A's SYN segment does not set the application-aware bit, or A's SYN segment contains an implicit global suboption with "a =
0", or
4. The network stripped the ENO option out of A's SYN segment, so B 4. The network stripped the ENO option out of A's SYN segment, so B
did not receive it. did not receive it.
Whichever of the above applies, the connection transparently falls Whichever of the above applies, the connection transparently falls
back to unencrypted TCP. back to unencrypted TCP.
(1) A -> B: SYN ENO<X,Y> (1) A -> B: SYN ENO<X,Y>
(2) B -> A: SYN-ACK ENO<b=1,X> [ENO stripped by middlebox] (2) B -> A: SYN-ACK ENO<b=1,X> [ENO stripped by middlebox]
(3) A -> B: ACK (3) A -> B: ACK
skipping to change at page 20, line 23 skipping to change at page 21, line 11
8. Design Rationale 8. Design Rationale
This section describes some of the design rationale behind TCP-ENO. This section describes some of the design rationale behind TCP-ENO.
8.1. Handshake Robustness 8.1. Handshake Robustness
Incremental deployment of TCP-ENO depends critically on failure cases Incremental deployment of TCP-ENO depends critically on failure cases
devolving to unencrypted TCP rather than causing the entire TCP devolving to unencrypted TCP rather than causing the entire TCP
connection to fail. connection to fail.
Because a network path may drop ENO options in one direction only, a Because a network path might drop ENO options in one direction only,
host must know not just that the peer supports encryption, but that a host needs to know not just that the peer supports encryption, but
the peer has received an ENO option. To this end, ENO disables that the peer has received an ENO option. To this end, ENO disables
encryption unless it receives an ACK segment bearing an ENO option. encryption unless it receives an ACK segment bearing an ENO option.
To stay robust in the face of dropped segments, hosts continue to 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 include non-SYN form ENO options in segments until such point as they
have received a non-SYN segment from the other side. have received a non-SYN segment from the other side.
One particularly pernicious middlebox behavior found in the wild is One particularly pernicious middlebox behavior found in the wild is
load balancers that echo unknown TCP options found in SYN segments load balancers that echo unknown TCP options found in SYN segments
back to an active opener. The passive role bit "b" in global back to an active opener. The passive role bit "b" in global
suboptions ensures encryption will always be disabled under such suboptions ensures encryption will always be disabled under such
circumstances, as sending back a verbatim copy of an active opener's circumstances, as sending back a verbatim copy of an active opener's
skipping to change at page 21, line 30 skipping to change at page 22, line 12
hosts are active openers, so TCP-ENO requires that one host hosts are active openers, so TCP-ENO requires that one host
explicitly configure "b = 1". An alternate design might explicitly configure "b = 1". An alternate design might
automatically break the symmetry to avoid this need for explicit automatically break the symmetry to avoid this need for explicit
configuration. However, all such designs we considered either lacked configuration. However, all such designs we considered either lacked
robustness or consumed precious bytes of SYN option space even in the robustness or consumed precious bytes of SYN option space even in the
absence of simultaneous open. (One complicating factor is that TCP absence of simultaneous open. (One complicating factor is that TCP
does not know it is participating in a simultaneous open until after does not know it is participating in a simultaneous open until after
it has sent a SYN segment. Moreover, with packet loss, one host it has sent a SYN segment. Moreover, with packet loss, one host
might never learn it has participated in a simultaneous open.) might never learn it has participated in a simultaneous open.)
8.4. Use of ENO Option Kind by TEPs 8.4. Application-aware Bit
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.
8.5. Use of ENO Option Kind by TEPs
This draft does not specify the use of ENO options beyond the first This draft does not specify the use of ENO options beyond the first
few segments of a connection. Moreover, it does not specify the few segments of a connection. Moreover, it does not specify the
content of ENO options in non-SYN segments, only their presence. As 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 a result, any use of option-kind TBD after the SYN exchange does not
conflict with this document. Because, in addition, ENO guarantees at conflict with this document. Because, in addition, ENO guarantees at
most one negotiated TEP per connection, TEPs will not conflict with 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 one another or ENO if they use ENO's option-kind for out-of-band
signaling in non-SYN segments. signaling in non-SYN segments.
8.5. Unpredictability of Session IDs 8.6. Unpredictability of Session IDs
Section 5.1 specifies that all but the first (TEP identifier) byte of Section 5.1 specifies that all but the first (TEP identifier) byte of
a session ID MUST be computationally indistinguishable from random a session ID MUST be computationally indistinguishable from random
bytes to a network eavesdropper. This property is easy to ensure bytes to a network eavesdropper. This property is easy to ensure
under standard assumptions about cryptographic hash functions. Such under standard assumptions about cryptographic hash functions. Such
unpredictability helps security in a broad range of cases. For unpredictability helps security in a broad range of cases. For
example, it makes it possible for applications to use a session ID example, it makes it possible for applications to use a session ID
from one connection to authenticate a session ID from another, from one connection to authenticate a session ID from another,
thereby tying the two connections together. If furthermore helps thereby tying the two connections together. It furthermore helps
ensure that TEPs do not trivially subvert the 33-byte minimum length ensure that TEPs do not trivially subvert the 33-byte minimum length
requirement for session IDs by padding shorter session IDs with requirement for session IDs by padding shorter session IDs with
zeros. zeros.
9. Experiments 9. Experiments
This document has experimental status because TCP-ENO's viability This document has experimental status because TCP-ENO's viability
depends on middlebox behavior that can only be determined _a depends on middlebox behavior that can only be determined _a
posteriori_. Specifically, we must determine to what extent posteriori_. Specifically, we need to determine to what extent
middleboxes will permit the use of TCP-ENO. Once TCP-ENO is 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 deployed, we will be in a better position to gather data on two types
of failure: of failure:
1. Middleboxes downgrading TCP-ENO connections to unencrypted TCP. 1. Middleboxes downgrading TCP-ENO connections to unencrypted TCP.
This can happen if middleboxes strip unknown TCP options or if This can happen if middleboxes strip unknown TCP options or if
they terminate TCP connections and relay data back and forth. they terminate TCP connections and relay data back and forth.
2. Middleboxes causing TCP-ENO connections to fail completely. This 2. Middleboxes causing TCP-ENO connections to fail completely. This
can happen if middleboxes perform deep packet inspection and can happen if middleboxes perform deep packet inspection and
start dropping segments that unexpectedly contain ciphertext, or start dropping segments that unexpectedly contain ciphertext, or
if middleboxes strip ENO options from non-SYN segments after if middleboxes strip ENO options from non-SYN segments after
allowing them in SYN segments. allowing them in SYN segments.
The first type of failure is tolerable since TCP-ENO is designed for Type-1 failures are tolerable, since TCP-ENO is designed for
incremental deployment anyway. The second type of failure is more incremental deployment anyway. Type-2 failures are more problematic,
problematic, and, if prevalent, will require the development of and, if prevalent, will require the development of techniques to
techniques to avoid and recover from such failures. 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.
10. Security Considerations 10. Security Considerations
An obvious use case for TCP-ENO is opportunistic encryption--that is, An obvious use case for TCP-ENO is opportunistic encryption--that is,
encrypting some connections, but only where supported and without any encrypting some connections, but only where supported and without any
kind of endpoint authentication. Opportunistic encryption protects 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 against undetectable large-scale eavesdropping. However, it does not
protect against detectable large-scale eavesdropping (for instance, protect against detectable large-scale eavesdropping (for instance,
if ISPs terminate TCP connections and proxy them, or simply downgrade if ISPs terminate TCP connections and proxy them, or simply downgrade
connections to unencrypted). Moreover, opportunistic encryption connections to unencrypted). Moreover, opportunistic encryption
emphatically does not protect against targeted attacks that employ emphatically does not protect against targeted attacks that employ
trivial spoofing to redirect a specific high-value connection to a trivial spoofing to redirect a specific high-value connection to a
man-in-the-middle attacker. 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 Achieving stronger security with TCP-ENO requires verifying session
IDs. Any application relying on ENO for communications security MUST IDs. Any application relying on ENO for communications security MUST
incorporate session IDs into its endpoint authentication. By way of incorporate session IDs into its endpoint authentication. By way of
example, an authentication mechanism based on keyed digests (such as example, an authentication mechanism based on keyed digests (such as
Digest Access Authentication [RFC7616]) can be extended to include Digest Access Authentication [RFC7616]) can be extended to include
the role and session ID in the input of the keyed digest. Higher- the role and session ID in the input of the keyed digest.
layer protocols MAY use the application-aware "a" bit to negotiate Authentication mechanisms with a notion of channel binding (such as
the inclusion of session IDs in authentication even when there is no SCRAM [RFC5802]) can be updated to derive a channel binding from the
in-band way to carry out such a negotiation. Because there is only session ID. Higher-layer protocols MAY use the application-aware "a"
one "a" bit, however, a protocol extension that specifies use of the bit to negotiate the inclusion of session IDs in authentication even
"a" bit will likely require a built-in versioning or negotiation when there is no in-band way to carry out such a negotiation.
mechanism to accommodate crypto agility and future updates. 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 Because TCP-ENO enables multiple different TEPs to coexist, security
could potentially be only as strong as the weakest available TEP. In could potentially be only as strong as the weakest available TEP. In
particular, if session IDs do not depend on the TCP-ENO transcript in particular, if TEPs use a weak hash function to incorporate the TCP-
a strong way, an attacker can undetectably tamper with ENO options to ENO transcript into session IDs, then an attacker can undetectably
force negotiation of a deprecated and vulnerable TEP. To avoid such tamper with ENO options to force negotiation of a deprecated and
problems, TEPs MUST compute session IDs using only well-studied and vulnerable TEP. To avoid such problems, security reviewers of new
conservative hash functions. That way, even if other parts of a TEP TEPs SHOULD pay particular attention to the collision resistance of
are vulnerable, it is still intractable for an attacker to induce hash functions used for session IDs (including the state of
identical session IDs at both ends after tampering with ENO contents cryptanalysis and research into possible attacks). Even if other
in SYN segments. 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 Implementations MUST NOT send ENO options unless they have access to
an adequate source of randomness [RFC4086]. Without secret an adequate source of randomness [RFC4086]. Without secret
unpredictable data at both ends of a connection, it is impossible for unpredictable data at both ends of a connection, it is impossible for
TEPs to achieve confidentiality and forward secrecy. Because systems TEPs to achieve confidentiality and forward secrecy. Because systems
typically have very little entropy on bootup, implementations might typically have very little entropy on bootup, implementations might
need to disable TCP-ENO until after system initialization. need to disable TCP-ENO until after system initialization.
With a regular three-way handshake (meaning no simultaneous open), With a regular three-way handshake (meaning no simultaneous open),
the non-SYN form ENO option in an active opener's first ACK segment 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. 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 Such data is not part of the TCP-ENO negotiation transcript, and
hence MUST be separately authenticated by the TEP. hence MUST be separately authenticated by the TEP.
11. IANA Considerations 11. IANA Considerations
[RFC-editor: please replace TBD in this section, in Section 4.1, and [RFC-editor: please replace TBD in this section, in Section 4.1, and
in Section 8.4 with the assigned option kind number. Please also in Section 8.5 with the assigned option-kind number. Please also
replace RFC-TBD with this document's final RFC number.] replace RFC-TBD with this document's final RFC number.]
This document defines a new TCP option kind for TCP-ENO, assigned a 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: value of TBD from the TCP option space. This value is defined as:
+------+--------+----------------------------------+-----------+ +------+--------+----------------------------------+-----------+
| Kind | Length | Meaning | Reference | | Kind | Length | Meaning | Reference |
+------+--------+----------------------------------+-----------+ +------+--------+----------------------------------+-----------+
| TBD | N | Encryption Negotiation (TCP-ENO) | [RFC-TBD] | | TBD | N | Encryption Negotiation (TCP-ENO) | [RFC-TBD] |
+------+--------+----------------------------------+-----------+ +------+--------+----------------------------------+-----------+
TCP Option Kind Numbers TCP Option Kind Numbers
Early implementations of TCP-ENO and a predecessor TCP encryption Early implementations of TCP-ENO and a predecessor TCP encryption
protocol made unauthorized use of TCP option kind 69. protocol made unauthorized use of TCP option-kind 69.
[RFC-editor: please glue the following text to the previous paragraph [RFC-editor: please glue the following text to the previous paragraph
iff TBD == 69, otherwise delete it.] These earlier uses of option 69 iff TBD == 69, otherwise delete it.] These earlier uses of option 69
are not compatible with TCP-ENO and could disable encryption or are not compatible with TCP-ENO and could disable encryption or
suffer complete connection failure when interoperating with TCP-ENO- suffer complete connection failure when interoperating with TCP-ENO-
compliant hosts. Hence, legacy use of option 69 MUST be disabled on compliant hosts. Hence, legacy use of option 69 MUST be disabled on
hosts that cannot be upgraded to TCP-ENO. hosts that cannot be upgraded to TCP-ENO.
[RFC-editor: please glue this to the previous paragraph regardless of [RFC-editor: please glue this to the previous paragraph regardless of
the value of TBD.] More recent implementations used experimental the value of TBD.] More recent implementations used experimental
option 253 per [RFC6994] with 16-bit ExID 0x454E, and MUST migrate to option 253 per [RFC6994] with 16-bit ExID 0x454E. Current and new
option TBD. Section 4.1 requires at most one SYN-form ENO option per implementations of TCP-ENO MUST use option TBD, while any legacy
segment, which means hosts MUST NOT not include both option TBD and implementations MUST migrate to option TBD. Note in particular that
option 253 with ExID 0x454E in the same TCP segment. 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, 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 for which IANA is to create and maintain a new registry entitled "TCP
encryption protocol identifiers" under the "Transmission Control encryption protocol identifiers" under the "Transmission Control
Protocol (TCP) Parameters" registry. The initial contents of the TCP Protocol (TCP) Parameters" registry. The initial contents of the TCP
encryption protocol identifier registry is shown in Table 2, encryption protocol identifier registry is shown in Table 2. This
reflecting that this document reserves one TEP identifier for document allocates one TEP identifier (0x20) for experimental use.
experimental use. Subsequent assignments are to be made under the In case the TEP identifier space proves too small, identifiers in the
"RFC Required" policy detailed in [RFC8126], relying on early range 0x70-0x7f are reserved to enable a future update to this
allocation [RFC7120] to facilitate testing before an RFC is 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. finalized.
+-------+------------------+-----------+ +-----------+------------------------------+-----------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+------------------+-----------+ +-----------+------------------------------+-----------+
| 0x20 | Experimental Use | [RFC-TBD] | | 0x20 | Experimental Use | [RFC-TBD] |
+-------+------------------+-----------+ | 0x70-0x7f | Reserved for extended values | [RFC-TBD] |
+-----------+------------------------------+-----------+
Table 2: TCP encryption protocol identifiers Table 2: TCP encryption protocol identifiers
12. Acknowledgments 12. Acknowledgments
We are grateful for contributions, help, discussions, and feedback We are grateful for contributions, help, discussions, and feedback
from the IETF and its TCPINC working group, including Marcelo from the IETF and its TCPINC working group, including Marcelo
Bagnulo, David Black, Bob Briscoe, Jake Holland, Jana Iyengar, Tero Bagnulo, David Black, Bob Briscoe, Benoit Claise, Spencer Dawkins,
Kivinen, Mirja Kuhlewind, Watson Ladd, Yoav Nir, Christoph Paasch, Jake Holland, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Watson
Eric Rescorla, Kyle Rose, Michael Scharf, and Joe Touch. This work Ladd, Kathleen Moriarty, Yoav Nir, Christoph Paasch, Eric Rescorla,
was partially funded by DARPA CRASH and the Stanford Secure Internet Adam Roach, Kyle Rose, Michael Scharf, Joe Touch, and Eric Vyncke.
of Things Project. This work was partially funded by DARPA CRASH and the Stanford Secure
Internet of Things Project.
13. Contributors 13. Contributors
Dan Boneh was a co-author of the draft that became this document. Dan Boneh was a co-author of the draft that became this document.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
skipping to change at page 25, line 36 skipping to change at page 28, line 5
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SP800-57part1]
Barker, E., "Recommendation for Key Management, Part 1:
General", NIST Special Publication 800-57 Part 1, Revision
4, January 2016,
<http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4>.
14.2. Informative References 14.2. Informative References
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003, RFC 3493, DOI 10.17487/RFC3493, February 2003,
<https://www.rfc-editor.org/info/rfc3493>. <https://www.rfc-editor.org/info/rfc3493>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>. <https://www.rfc-editor.org/info/rfc4987>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, DOI 10.17487/RFC5382, October 2008, RFC 5382, DOI 10.17487/RFC5382, October 2008,
<https://www.rfc-editor.org/info/rfc5382>. <https://www.rfc-editor.org/info/rfc5382>.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
DOI 10.17487/RFC5802, July 2010,
<https://www.rfc-editor.org/info/rfc5802>.
[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based
Authentication of Named Entities (DANE)", RFC 6394, Authentication of Named Entities (DANE)", RFC 6394,
DOI 10.17487/RFC6394, October 2011, DOI 10.17487/RFC6394, October 2011,
<https://www.rfc-editor.org/info/rfc6394>. <https://www.rfc-editor.org/info/rfc6394>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", [RFC6994] Touch, J., "Shared Use of Experimental TCP Options",
RFC 6994, DOI 10.17487/RFC6994, August 2013, RFC 6994, DOI 10.17487/RFC6994, August 2013,
<https://www.rfc-editor.org/info/rfc6994>. <https://www.rfc-editor.org/info/rfc6994>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616, Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015, DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/info/rfc7616>. <https://www.rfc-editor.org/info/rfc7616>.
Authors' Addresses Authors' Addresses
Andrea Bittau Andrea Bittau
Google Google
345 Spear Street 345 Spear Street
 End of changes. 63 change blocks. 
173 lines changed or deleted 303 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/