< draft-ietf-tcpinc-tcpeno-16.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: May 20, 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
November 16, 2017 June 29, 2018
TCP-ENO: Encryption Negotiation Option TCP-ENO: Encryption Negotiation Option
draft-ietf-tcpinc-tcpeno-16 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
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 May 20, 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 49 skipping to change at page 2, line 49
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 20 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Handshake Robustness . . . . . . . . . . . . . . . . . . 21 8.1. Handshake Robustness . . . . . . . . . . . . . . . . . . 21
8.2. Suboption Data . . . . . . . . . . . . . . . . . . . . . 21 8.2. Suboption Data . . . . . . . . . . . . . . . . . . . . . 21
8.3. Passive Role Bit . . . . . . . . . . . . . . . . . . . . 21 8.3. Passive Role Bit . . . . . . . . . . . . . . . . . . . . 21
8.4. Application-aware Bit . . . . . . . . . . . . . . . . . . 22 8.4. Application-aware Bit . . . . . . . . . . . . . . . . . . 22
8.5. Use of ENO Option Kind by TEPs . . . . . . . . . . . . . 23 8.5. Use of ENO Option Kind by TEPs . . . . . . . . . . . . . 23
8.6. Unpredictability of Session IDs . . . . . . . . . . . . . 23 8.6. Unpredictability of Session IDs . . . . . . . . . . . . . 23
9. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . 27 14.1. Normative References . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . 28 14.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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
skipping to change at page 3, line 39 skipping to change at page 3, line 39
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 a TCP ENO provides a framework in which two endpoints can agree on a TCP
encryption protocol or _TEP_ out of multiple possible 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.
skipping to change at page 7, line 17 skipping to change at page 7, line 17
|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 remaining 7-bit value, called "glt", entirety of the suboption. The remaining 7-bit value, called "glt",
may take on various meanings, as defined below: 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 45 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 10, line 12 skipping to change at page 10, line 12
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). A suboption introduced by a initial suboption byte (see Figure 4). A suboption introduced by a
TEP identifier with "v = 1" (i.e., a sub option whose first octet has TEP identifier with "v = 1" (i.e., a suboption whose first octet has
value 0xa0 or higher) extends to the end of the TCP option. Hence, value 0xa0 or higher) extends to the end of the TCP option. Hence,
if only one suboption requires data, the most compact way to encode if only one suboption requires data, the most compact way to encode
it is to place it last in the ENO option, after all other suboptions. it is to place it last in the ENO option, after all other suboptions.
As an example, in Figure 2, the last suboption, "Opt_i", has As an example, in Figure 2, the last suboption, "Opt_i", has
suboption data and thus requires "v = 1"; however, the suboption data suboption data and thus requires "v = 1"; however, the suboption data
length is inferred from the total length of the TCP option. 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
skipping to change at page 13, line 14 skipping to change at page 13, line 14
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 SYN-form ENO option containing zero TEP identifier A host MAY send a SYN-form ENO option containing zero TEP identifier
suboptions, which we term a _vacuous_ SYN-form ENO option. If either suboptions, which we term a _vacuous_ ENO option. If either host's
host sends a vacuous ENO option, it follows that there are no valid SYN segment contains a vacuous ENO option, it follows that there are
TEP identifiers for the connection and hence the connection MUST fall no valid TEP identifiers for the connection and hence the connection
back to unencrypted TCP. Hosts MAY send vacuous ENO options to MUST fall back to unencrypted TCP. Hosts MAY send vacuous ENO
indicate that ENO is supported but unavailable by configuration, or options to indicate that ENO is supported but unavailable by
to probe network paths for robustness to ENO options. However, a configuration, or to probe network paths for robustness to ENO
passive opener MUST NOT send a vacuous ENO option in a SYN-ACK options. However, a passive opener MUST NOT send a vacuous ENO
segment unless there was an ENO option in the SYN segment it option in a SYN-ACK segment unless there was an ENO option in the SYN
received. Moreover, a passive opener's SYN-form ENO option MUST segment it received. Moreover, a passive opener's SYN-form ENO
still include a global suboption with "b = 1", as discussed in option MUST still include a global suboption with "b = 1", as
Section 4.3. 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_. A SYN+ENO segment may of course 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 include multiple TEP suboptions, but only the SYN TEP (i.e., the last
one) specifies how to interpret the SYN segment's data payload. 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 the Because a host can send SYN data before knowing which if any TEP the
skipping to change at page 14, line 36 skipping to change at page 14, line 36
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 in its transmitted SYN acknowledgment for the data, but the SYN TEP in its transmitted SYN
segment is not the negotiated TEP (either because a different TEP was segment is not the negotiated TEP (either because a different TEP was
negotiated or because ENO failed to negotiate encryption), then the negotiated or because ENO failed to negotiate encryption), then the
host MUST abort the TCP connection. Proceeding in any other fashion host MUST abort the TCP connection. Proceeding in any other fashion
risks 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
skipping to change at page 15, line 44 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 make data confidentiality dependent on encryption o TEPs MUST NOT make data confidentiality dependent on encryption
algorithms with a security strength [SP800-57part1] of less than algorithms with a security strength [SP800-57part1] of less than
120 bits. The number 120 was chosen to accommodate ciphers with 120 bits. The number 120 was chosen to accommodate ciphers with
128-bit keys that lose a few bits of security either to 128-bit keys that lose a few bits of security either to
skipping to change at page 16, line 30 skipping to change at page 16, line 30
connection and erasing any relevant cryptographic secrets. 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 by TCP's FIN flag. In particular, a receiver MUST with
overwhelming probability detect a FIN flag that was set or cleared overwhelming probability detect a FIN flag that was set or cleared
in transit and does not match the sender's intent. A TEP MAY in transit and does not match the sender's intent. A TEP MAY
discard a segment with such a corrupted FIN bit, or may abort the discard a segment with such a corrupted FIN bit, or MAY abort the
connection in response to such a segment. However, any such abort connection in response to such a segment. However, any such abort
MUST raise an error condition distinct from an authentic end-of- MUST raise an error condition distinct from an authentic end-of-
file 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. There are several ways to do delivered when none has been sent. There are several ways to do
so. For instance, a TEP MAY cryptographically protect the URG so. For instance, a TEP MAY cryptographically protect the URG
flag and urgent pointer alongside ordinary payload data. flag and urgent pointer alongside ordinary payload data.
Alternatively, a TEP MAY disable urgent data functionality by Alternatively, a TEP MAY disable urgent data functionality by
clearing the URG flag on all received segments and returning clearing the URG flag on all received segments and returning
skipping to change at page 18, line 33 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<a=0,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)
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:
skipping to change at page 18, line 48 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 21, line 11 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 needs to know not just that the peer supports encryption, but a host needs to know not just that the peer supports encryption, but
that the peer has received an ENO option. To this end, ENO disables 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
skipping to change at page 24, line 17 skipping to change at page 24, line 17
In addition to the question of basic viability, deploying TCP-ENO In addition to the question of basic viability, deploying TCP-ENO
will allow us to identify and address other potential corner cases or will allow us to identify and address other potential corner cases or
relaxations. For example, does the slight decrease in effective TCP relaxations. For example, does the slight decrease in effective TCP
segment payload pose a problem to any applications, requiring segment payload pose a problem to any applications, requiring
restrictions on how TEPs interpret socket buffer sizes? Conversely, restrictions on how TEPs interpret socket buffer sizes? Conversely,
can we relax the prohibition on default TEPs that disable urgent can we relax the prohibition on default TEPs that disable urgent
data? data?
A final important metric, related to the pace of deployment and A final important metric, related to the pace of deployment and
incidence of Type-1 failures, will be the extent to which incidence of type-1 failures, will be the extent to which
applications adopt TCP-ENO-specific enhancements for endpoint applications adopt TCP-ENO-specific enhancements for endpoint
authentication. 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 provides a kind of endpoint authentication. Opportunistic encryption provides a
property known as _opportunistic security_ [RFC7435], which protects 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
skipping to change at page 24, line 42 skipping to change at page 24, line 42
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. Hence, the mere presence of TEP- man-in-the-middle attacker. Hence, the mere presence of TEP-
indicated encryption does not suffice for an application to represent indicated encryption does not suffice for an application to represent
a connection as "secure" to the user. 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 TEPs use a weak hash function to incorporate the TCP- particular, if TEPs use a weak hash function to incorporate the TCP-
ENO transcript into session IDs, then an attacker can undetectably ENO transcript into session IDs, then an attacker can undetectably
tamper with ENO options to force negotiation of a deprecated and tamper with ENO options to force negotiation of a deprecated and
vulnerable TEP. To avoid such problems, security reviewers of new vulnerable TEP. To avoid such problems, security reviewers of new
TEPs SHOULD pay particular attention to the collision resistance of TEPs SHOULD pay particular attention to the collision resistance of
hash functions used for session IDs (including the state of hash functions used for session IDs (including the state of
cryptanalysis and research into possible attacks). Even if other cryptanalysis and research into possible attacks). Even if other
skipping to change at page 28, line 34 skipping to change at page 28, line 40
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <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
 End of changes. 23 change blocks. 
51 lines changed or deleted 62 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/