idnits 2.17.1 draft-ietf-tcpinc-tcpeno-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 16, 2017) is 2350 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC-TBD' is mentioned on line 1217, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Bittau 3 Internet-Draft Google 4 Intended status: Experimental D. Giffin 5 Expires: May 20, 2018 Stanford University 6 M. Handley 7 University College London 8 D. Mazieres 9 Stanford University 10 E. Smith 11 Kestrel Institute 12 November 16, 2017 14 TCP-ENO: Encryption Negotiation Option 15 draft-ietf-tcpinc-tcpeno-15 17 Abstract 19 Despite growing adoption of TLS, a significant fraction of TCP 20 traffic on the Internet remains unencrypted. The persistence of 21 unencrypted traffic can be attributed to at least two factors. 22 First, some legacy protocols lack a signaling mechanism (such as a 23 "STARTTLS" command) by which to convey support for encryption, making 24 incremental deployment impossible. Second, legacy applications 25 themselves cannot always be upgraded, requiring a way to implement 26 encryption transparently entirely within the transport layer. The 27 TCP Encryption Negotiation Option (TCP-ENO) addresses both of these 28 problems through a new TCP option-kind providing out-of-band, fully 29 backward-compatible negotiation of encryption. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 20, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Requirements language . . . . . . . . . . . . . . . . . . . . 3 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Design goals . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. TCP-ENO Specification . . . . . . . . . . . . . . . . . . . . 5 70 4.1. ENO Option . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. The Global Suboption . . . . . . . . . . . . . . . . . . 8 72 4.3. TCP-ENO Roles . . . . . . . . . . . . . . . . . . . . . . 9 73 4.4. Specifying Suboption Data Length . . . . . . . . . . . . 10 74 4.5. The Negotiated TEP . . . . . . . . . . . . . . . . . . . 11 75 4.6. TCP-ENO Handshake . . . . . . . . . . . . . . . . . . . . 12 76 4.7. Data in SYN Segments . . . . . . . . . . . . . . . . . . 13 77 4.8. Negotiation Transcript . . . . . . . . . . . . . . . . . 15 78 5. Requirements for TEPs . . . . . . . . . . . . . . . . . . . . 15 79 5.1. Session IDs . . . . . . . . . . . . . . . . . . . . . . . 16 80 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 7. Future Developments . . . . . . . . . . . . . . . . . . . . . 20 82 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 20 83 8.1. Handshake Robustness . . . . . . . . . . . . . . . . . . 21 84 8.2. Suboption Data . . . . . . . . . . . . . . . . . . . . . 21 85 8.3. Passive Role Bit . . . . . . . . . . . . . . . . . . . . 21 86 8.4. Application-aware Bit . . . . . . . . . . . . . . . . . . 22 87 8.5. Use of ENO Option Kind by TEPs . . . . . . . . . . . . . 23 88 8.6. Unpredictability of Session IDs . . . . . . . . . . . . . 23 89 9. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 92 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 93 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 94 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 14.1. Normative References . . . . . . . . . . . . . . . . . . 27 96 14.2. Informative References . . . . . . . . . . . . . . . . . 28 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 99 1. Requirements language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 2. Introduction 109 Many applications and protocols running on top of TCP today do not 110 encrypt traffic. This failure to encrypt lowers the bar for certain 111 attacks, harming both user privacy and system security. 112 Counteracting the problem demands a minimally intrusive, backward- 113 compatible mechanism for incrementally deploying encryption. The TCP 114 Encryption Negotiation Option (TCP-ENO) specified in this document 115 provides such a mechanism. 117 Introducing TCP options, extending operating system interfaces to 118 support TCP-level encryption, and extending applications to take 119 advantage of TCP-level encryption all require effort. To the 120 greatest extent possible, the effort invested in realizing TCP-level 121 encryption today needs to remain applicable in the future should the 122 need arise to change encryption strategies. To this end, it is 123 useful to consider two questions separately: 125 1. How to negotiate the use of encryption at the TCP layer, and 127 2. How to perform encryption at the TCP layer. 129 This document addresses question 1 with a new TCP option, ENO. TCP- 130 ENO provides a framework in which two endpoints can agree on a TCP 131 encryption protocol or _TEP_ out of multiple possible TEPs. For 132 future compatibility, TEPs can vary widely in terms of wire format, 133 use of TCP option space, and integration with the TCP header and 134 segmentation. However, ENO abstracts these differences to ensure the 135 introduction of new TEPs can be transparent to applications taking 136 advantage of TCP-level encryption. 138 Question 2 is addressed by one or more companion TEP specification 139 documents. While current TEPs enable TCP-level traffic encryption 140 today, TCP-ENO ensures that the effort invested to deploy today's 141 TEPs will additionally benefit future ones. 143 2.1. Design goals 145 TCP-ENO was designed to achieve the following goals: 147 1. Enable endpoints to negotiate the use of a separately specified 148 TCP encryption protocol (_TEP_) suitable for either opportunistic 149 security [RFC7435] of arbitrary TCP communications or stronger 150 security of applications willing to perform endpoint 151 authentication. 153 2. Transparently fall back to unencrypted TCP when not supported by 154 both endpoints. 156 3. Provide out-of-band signaling through which applications can 157 better take advantage of TCP-level encryption (for instance, by 158 improving authentication mechanisms in the presence of TCP-level 159 encryption). 161 4. Define a standard negotiation transcript that TEPs can use to 162 defend against tampering with TCP-ENO. 164 5. Make parsimonious use of TCP option space. 166 6. Define roles for the two ends of a TCP connection, so as to name 167 each end of a connection for encryption or authentication 168 purposes even following a symmetric simultaneous open. 170 3. Terminology 172 Throughout this document, we use the following terms, several of 173 which have more detailed normative descriptions in [RFC0793]: 175 SYN segment 176 A TCP segment in which the SYN flag is set 178 ACK segment 179 A TCP segment in which the ACK flag is set (which includes most 180 segments other than an initial SYN segment) 182 non-SYN segment 183 A TCP segment in which the SYN flag is clear 185 SYN-only segment 186 A TCP segment in which the SYN flag is set but the ACK flag is 187 clear 189 SYN-ACK segment 190 A TCP segment in which the SYN and ACK flags are both set 192 Active opener 193 A host that initiates a connection by sending a SYN-only segment. 194 With the BSD socket API, an active opener calls "connect". In 195 client-server configurations, active openers are typically 196 clients. 198 Passive opener 199 A host that does not send a SYN-only segment, but responds to one 200 with a SYN-ACK segment. With the BSD socket API, passive openers 201 call "listen" and "accept", rather than "connect". In client- 202 server configurations, passive openers are typically servers. 204 Simultaneous open 205 The act of symmetrically establishing a TCP connection between two 206 active openers (both of which call "connect" with BSD sockets). 207 Each host of a simultaneous open sends both a SYN-only and a SYN- 208 ACK segment. Simultaneous open is less common than asymmetric 209 open with one active and one passive opener, but can be used for 210 NAT traversal by peer-to-peer applications [RFC5382]. 212 TEP 213 A TCP encryption protocol intended for use with TCP-ENO and 214 specified in a separate document. 216 TEP identifier 217 A unique 7-bit value in the range 0x20-0x7f that IANA has assigned 218 to a TEP. 220 Negotiated TEP 221 The single TEP governing a TCP connection, determined by use of 222 the TCP ENO option specified in this document. 224 4. TCP-ENO Specification 226 TCP-ENO extends TCP connection establishment to enable encryption 227 opportunistically. It uses a new TCP option-kind [RFC0793] to 228 negotiate one among multiple possible TCP encryption protocols 229 (TEPs). The negotiation involves hosts exchanging sets of supported 230 TEPs, where each TEP is represented by a _suboption_ within a larger 231 TCP ENO option in the offering host's SYN segment. 233 If TCP-ENO succeeds, it yields the following information: 235 o A negotiated TEP, represented by a unique 7-bit TEP identifier, 237 o A few extra bytes of suboption data from each host, if needed by 238 the TEP, 240 o A negotiation transcript with which to mitigate attacks on the 241 negotiation itself, 243 o Role assignments designating one endpoint "host A" and the other 244 endpoint "host B", and 246 o A bit available to higher-layer protocols at each endpoint for 247 out-of-band negotiation of updated behavior in the presence of TCP 248 encryption. 250 If TCP-ENO fails, encryption is disabled and the connection falls 251 back to traditional unencrypted TCP. 253 The remainder of this section provides the normative description of 254 the TCP ENO option and handshake protocol. 256 4.1. ENO Option 258 TCP-ENO employs an option in the TCP header [RFC0793]. Figure 1 259 illustrates the high-level format of this option. 261 byte 0 1 2 N+1 (N+2 bytes total) 262 +-----+-----+-----+--....--+-----+ 263 |Kind=|Len= | | 264 | TBD | N+2 | contents (N bytes) | 265 +-----+-----+-----+--....--+-----+ 267 Figure 1: The TCP-ENO option 269 The contents of an ENO option can take one of two forms. A SYN form, 270 illustrated in Figure 2, appears only in SYN segments. A non-SYN 271 form, illustrated in Figure 3, appears only in non-SYN segments. The 272 SYN form of ENO acts as a container for zero or more suboptions, 273 labeled "Opt_0", "Opt_1", ... in Figure 2. The non-SYN form, by its 274 presence, acts as a one-bit acknowledgment, with the actual contents 275 ignored by ENO. Particular TEPs MAY assign additional meaning to the 276 contents of non-SYN ENO options. When a negotiated TEP does not 277 assign such meaning, the contents of a non-SYN ENO option MUST be 278 zero bytes in sent segments and MUST be ignored in received segments. 280 byte 0 1 2 3 ... N+1 281 +-----+-----+-----+-----+--...--+-----+----...----+ 282 |Kind=|Len= |Opt_0|Opt_1| |Opt_i| Opt_i | 283 | TBD | N+2 | | | | | data | 284 +-----+-----+-----+-----+--...--+-----+----...----+ 286 Figure 2: SYN form of ENO 288 byte 0 1 2 N+1 289 +-----+-----+-----...----+ 290 |Kind=|Len= | ignored | 291 | TBD | N+2 | by TCP-ENO | 292 +-----+-----+-----...----+ 294 Figure 3: Non-SYN form of ENO, where N MAY be 0 296 Every suboption starts with a byte of the form illustrated in 297 Figure 4. The high bit "v", when set, introduces suboptions with 298 variable-length data. When "v = 0", the byte itself constitutes the 299 entirety of the suboption. The remaining 7-bit value, called "glt", 300 may take on various meanings, as defined below: 302 o Global configuration data (discussed in Section 4.2), 304 o Suboption data length for the next suboption (discussed in 305 Section 4.4), or 307 o An offer to use a particular TEP defined in a separate TEP 308 specification document. 310 bit 7 6 5 4 3 2 1 0 311 +---+---+---+---+---+---+---+---+ 312 | v | glt | 313 +---+---+---+---+---+---+---+---+ 315 v - non-zero for use with variable-length suboption data 316 glt - Global suboption, Length, or TEP identifier 318 Figure 4: Format of initial suboption byte 320 Table 1 summarizes the meaning of initial suboption bytes. Values of 321 "glt" below 0x20 are used for global suboptions and length 322 information (the "gl" in "glt"), while those greater than or equal to 323 0x20 are TEP identifiers (the "t"). When "v = 0", the initial 324 suboption byte constitutes the entirety of the suboption and all 325 information is expressed by the 7-bit "glt" value, which can be 326 either a global suboption or a TEP identifier. When "v = 1", it 327 indicates a suboption with variable-length suboption data. Only TEP 328 identifiers may have suboption data, not global suboptions. Hence, 329 bytes with "v = 1" and "glt < 0x20" are not global suboptions but 330 rather length bytes governing the length of the next suboption (which 331 MUST be a TEP identifier). In the absence of a length byte, a TEP 332 identifier suboption with "v = 1" has suboption data extending to the 333 end of the TCP option. 335 +-----------+---+-------------------------------------------+ 336 | glt | v | Meaning | 337 +-----------+---+-------------------------------------------+ 338 | 0x00-0x1f | 0 | Global suboption (Section 4.2) | 339 | 0x00-0x1f | 1 | Length byte (Section 4.4) | 340 | 0x20-0x7f | 0 | TEP identifier without suboption data | 341 | 0x20-0x7f | 1 | TEP identifier followed by suboption data | 342 +-----------+---+-------------------------------------------+ 344 Table 1: Initial suboption byte values 346 A SYN segment MUST contain at most one TCP ENO option. If a SYN 347 segment contains more than one ENO option, the receiver MUST behave 348 as though the segment contained no ENO options and disable 349 encryption. A TEP MAY specify the use of multiple ENO options in a 350 non-SYN segment. For non-SYN segments, ENO itself only distinguishes 351 between the presence or absence of ENO options; multiple ENO options 352 are interpreted the same as one. 354 4.2. The Global Suboption 356 Suboptions 0x00-0x1f are used for global configuration that applies 357 regardless of the negotiated TEP. A TCP SYN segment MUST include at 358 most one ENO suboption in this range. A receiver MUST ignore all but 359 the first suboption in this range in any given TCP segment so as to 360 anticipate updates to ENO that assign new meaning to bits in 361 subsequent global suboptions. The value of a global suboption byte 362 is interpreted as a bitmask, illustrated in Figure 5. 364 bit 7 6 5 4 3 2 1 0 365 +---+---+---+---+---+---+---+---+ 366 | 0 | 0 | 0 |z1 |z2 |z3 | a | b | 367 +---+---+---+---+---+---+---+---+ 369 b - Passive role bit 370 a - Application-aware bit 371 z* - Zero bits (reserved for future use) 373 Figure 5: Format of the global suboption byte 375 The fields of the bitmask are interpreted as follows: 377 b 378 The passive role bit MUST be 1 for all passive openers. For 379 active openers, it MUST default to 0, but implementations MUST 380 provide an API through which an application can explicitly set "b 381 = 1" before initiating an active open. (Manual configuration of 382 "b" is only necessary to enable encryption with a simultaneous 383 open, and requires prior coordination to ensure exactly one 384 endpoint sets "b = 1" before connecting.) 386 a 387 Legacy applications can benefit from ENO-specific updates that 388 improve endpoint authentication or avoid double encryption. The 389 application-aware bit "a" is an out-of-band signal through which 390 higher-layer protocols can enable ENO-specific updates that would 391 otherwise not be backwards-compatible. Implementations MUST set 392 this bit to 0 by default, and MUST provide an API through which 393 applications can change the value of the bit as well as examine 394 the value of the bit sent by the remote host. Implementations 395 MUST furthermore support a _mandatory_ application-aware mode in 396 which TCP-ENO is automatically disabled if the remote host does 397 not set "a = 1". 399 z1, z2, z3 400 The "z" bits are reserved for future updates to TCP-ENO. They 401 MUST be set to zero in sent segments and MUST be ignored in 402 received segments. 404 A SYN segment without an explicit global suboption has an implicit 405 global suboption of 0x00. Because passive openers MUST always set "b 406 = 1", they cannot rely on this implicit 0x00 byte and MUST include an 407 explicit global suboption in their SYN-ACK segments. 409 4.3. TCP-ENO Roles 411 TCP-ENO uses abstract roles called "A" and "B" to distinguish the two 412 ends of a TCP connection. These roles are determined by the "b" bit 413 in the global suboption. The host that sent an implicit or explicit 414 suboption with "b = 0" plays the A role. The host that sent "b = 1" 415 plays the B role. Because a passive opener MUST set "b = 1" and an 416 active opener by default has "b = 0", the normal case is for the 417 active opener to play role A and the passive opener role B. 419 Applications performing a simultaneous open, if they desire TCP-level 420 encryption, need to arrange for exactly one endpoint to set "b = 1" 421 (despite being an active opener) while the other endpoint keeps the 422 default "b = 0". Otherwise, if both sides use the default "b = 0" or 423 if both sides set "b = 1", then TCP-ENO will fail and fall back to 424 unencrypted TCP. Likewise, if an active opener explicitly configures 425 "b = 1" and connects to a passive opener (which MUST always have "b = 426 1"), then TCP-ENO will fail and fall back to unencrypted TCP. 428 TEP specifications SHOULD refer to TCP-ENO's A and B roles to specify 429 asymmetric behavior by the two hosts. For the remainder of this 430 document, we will use the terms "host A" and "host B" to designate 431 the hosts with roles A and B, respectively, in a connection. 433 4.4. Specifying Suboption Data Length 435 A TEP MAY optionally make use of one or more bytes of suboption data. 436 The presence of such data is indicated by setting "v = 1" in the 437 initial suboption byte (see Figure 4). A suboption introduced by a 438 TEP identifier with "v = 1" (i.e., a sub option whose first octet has 439 value 0xa0 or higher) extends to the end of the TCP option. Hence, 440 if only one suboption requires data, the most compact way to encode 441 it is to place it last in the ENO option, after all other suboptions. 442 As an example, in Figure 2, the last suboption, "Opt_i", has 443 suboption data and thus requires "v = 1"; however, the suboption data 444 length is inferred from the total length of the TCP option. 446 When a suboption with data is not last in an ENO option, the sender 447 MUST explicitly specify the suboption data length for the receiver to 448 know where the next suboption starts. The sender does so by 449 introducing the suboption with a length byte, depicted in Figure 6. 450 The length byte encodes a 5-bit value "nnnnn". Adding one to "nnnnn" 451 yields the length of the suboption data (not including the length 452 byte or the TEP identifier). Hence, a length byte can designate 453 anywhere from 1 to 32 bytes of suboption data (inclusive). 455 bit 7 6 5 4 3 2 1 0 456 +---+---+---+-------------------+ 457 | 1 0 0 nnnnn | 458 +---+---+---+-------------------+ 460 nnnnn - 5-bit value encoding (length - 1) 462 Figure 6: Format of a length byte 464 A suboption preceded by a length byte MUST be a TEP identifier ("glt 465 >= 0x20") and MUST have "v = 1". Figure 7 shows an example of such a 466 suboption. 468 byte 0 1 2 nnnnn+2 (nnnnn+3 bytes total) 469 +------+------+-------...-------+ 470 |length| TEP | suboption data | 471 | byte |ident.| (nnnnn+1 bytes) | 472 +------+------+-------...-------+ 474 length byte - specifies nnnnn 475 TEP identifier - MUST have v = 1 and glt >= 0x20 476 suboption data - length specified by nnnnn+1 478 Figure 7: Suboption with length byte 480 A host MUST ignore an ENO option in a SYN segment and MUST disable 481 encryption if either: 483 1. A length byte indicates that suboption data would extend beyond 484 the end of the TCP ENO option, or 486 2. A length byte is followed by an octet in the range 0x00-0x9f 487 (meaning the following byte has "v = 0" or "glt < 0x20"). 489 Because the last suboption in an ENO option is special-cased to have 490 its length inferred from the 8-bit TCP option length, it MAY contain 491 more than 32 bytes of suboption data. Other suboptions are limited 492 to 32 bytes by the length byte format. The TCP header itself can 493 only accommodate a maximum of 40 bytes of options, however. Hence, 494 regardless of the length byte format, a segment would not be able to 495 contain more than one suboption over 32 bytes in size. That said, 496 TEPs MAY define the use of multiple suboptions with the same TEP 497 identifier in the same SYN segment, providing another way to convey 498 over 32 bytes of suboption data even with length bytes. 500 4.5. The Negotiated TEP 502 A TEP identifier "glt" (with "glt >= 0x20") is _valid_ for a 503 connection when: 505 1. Each side has sent a suboption for "glt" in its SYN-form ENO 506 option, 508 2. Any suboption data in these "glt" suboptions is valid according 509 to the TEP specification and satisfies any runtime constraints, 510 and 512 3. If an ENO option contains multiple suboptions with "glt", then 513 such repetition is well-defined by the TEP specification. 515 A passive opener (which is always host B) sees the remote host's SYN 516 segment before constructing its own SYN-ACK segment. Hence, a 517 passive opener SHOULD include only one TEP identifier in SYN-ACK 518 segments and SHOULD ensure this TEP identifier is valid. However, 519 simultaneous open or implementation considerations can prevent host B 520 from offering only one TEP. 522 To accommodate scenarios in which host B sends multiple TEP 523 identifiers in the SYN-ACK segment, the _negotiated TEP_ is defined 524 as the last valid TEP identifier in host B's SYN-form ENO option. 525 This definition means host B specifies TEP suboptions in order of 526 increasing priority, while host A does not influence TEP priority. 528 4.6. TCP-ENO Handshake 530 A host employing TCP-ENO for a connection MUST include an ENO option 531 in every TCP segment sent until either encryption is disabled or the 532 host receives a non-SYN segment. In particular, this means an active 533 opener MUST include a non-SYN-form ENO option in the third segment of 534 a three-way handshake. 536 A host MUST disable encryption, refrain from sending any further ENO 537 options, and fall back to unencrypted TCP if any of the following 538 occurs: 540 1. Any segment it receives up to and including the first received 541 ACK segment does not contain a ENO option (or contains an ill- 542 formed SYN-form ENO option), 544 2. The SYN segment it receives does not contain a valid TEP 545 identifier, or 547 3. It receives a SYN segment with an incompatible global suboption. 548 (Specifically, incompatible means the two hosts set the same "b" 549 value or the connection is in mandatory application-aware mode 550 and the remote host set "a = 0".) 552 Hosts MUST NOT alter SYN-form ENO options in retransmitted segments, 553 or between the SYN and SYN-ACK segments of a simultaneous open, with 554 two exceptions for an active opener. First, an active opener MAY 555 unilaterally disable ENO (and thus remove the ENO option) between 556 retransmissions of a SYN-only segment. (Such removal could enable 557 recovery from middleboxes dropping segments with ENO options.) 558 Second, an active opener performing simultaneous open MAY include no 559 TCP-ENO option in its SYN-ACK if the received SYN caused it to 560 disable encryption according to the above rules (for instance because 561 role negotiation failed). 563 Once a host has both sent and received an ACK segment containing an 564 ENO option, encryption MUST be enabled. Once encryption is enabled, 565 hosts MUST follow the specification of the negotiated TEP and MUST 566 NOT present raw TCP payload data to the application. In particular, 567 data segments MUST NOT contain plaintext application data, but rather 568 ciphertext, key negotiation parameters, or other messages as 569 determined by the negotiated TEP. 571 A host MAY send a SYN-form ENO option containing zero TEP identifier 572 suboptions, which we term a _vacuous_ SYN-form ENO option. If either 573 host sends a vacuous ENO option, it follows that there are no valid 574 TEP identifiers for the connection and hence the connection MUST fall 575 back to unencrypted TCP. Hosts MAY send vacuous ENO options to 576 indicate that ENO is supported but unavailable by configuration, or 577 to probe network paths for robustness to ENO options. However, a 578 passive opener MUST NOT send a vacuous ENO option in a SYN-ACK 579 segment unless there was an ENO option in the SYN segment it 580 received. Moreover, a passive opener's SYN-form ENO option MUST 581 still include a global suboption with "b = 1", as discussed in 582 Section 4.3. 584 4.7. Data in SYN Segments 586 TEPs MAY specify the use of data in SYN segments so as to reduce the 587 number of round trips required for connection setup. The meaning of 588 data in a SYN segment with an ENO option (a SYN+ENO segment) is 589 determined by the last TEP identifier in the ENO option, which we 590 term the segment's _SYN TEP_. A SYN+ENO segment may of course 591 include multiple TEP suboptions, but only the SYN TEP (i.e., the last 592 one) specifies how to interpret the SYN segment's data payload. 594 A host sending a SYN+ENO segment MUST NOT include data in the segment 595 unless the SYN TEP's specification defines the use of such data. 596 Furthermore, to avoid conflicting interpretations of SYN data, a 597 SYN+ENO segment MUST NOT include a non-empty TCP Fast Open (TFO) 598 option [RFC7413]. 600 Because a host can send SYN data before knowing which if any TEP the 601 connection will negotiate, hosts implementing ENO are REQUIRED to 602 discard data from SYN+ENO segments when the SYN TEP does not become 603 the negotiated TEP. Hosts are furthermore REQUIRED to discard SYN 604 data in cases where another Internet standard specifies a conflicting 605 interpretation of SYN data (as would occur when receiving a non-empty 606 TFO option). This requirement applies to hosts that implement ENO 607 even when ENO has been disabled by configuration. However, note that 608 discarding SYN data is already common practice [RFC4987] and the new 609 requirement applies only to segments containing ENO options. 611 More specifically, a host that implements ENO MUST discard the data 612 in a received SYN+ENO segment if any of the following applies: 614 o ENO fails and TEP-indicated encryption is disabled for the 615 connection, 617 o The received segment's SYN TEP is not the negotiated TEP, 619 o The negotiated TEP does not define the use of SYN data, or 621 o The SYN segment contains a non-empty TFO option or any other TCP 622 option implying a conflicting definition of SYN data. 624 A host discarding SYN data in compliance with the above requirement 625 MUST NOT acknowledge the sequence number of the discarded data, but 626 rather MUST acknowledge the other host's initial sequence number as 627 if the received SYN segment contained no data. Furthermore, after 628 discarding SYN data, such a host MUST NOT assume the SYN data will be 629 identically retransmitted, and MUST process data only from non-SYN 630 segments. 632 If a host sends a SYN+ENO segment with data and receives 633 acknowledgment for the data, but the SYN TEP in its transmitted SYN 634 segment is not the negotiated TEP (either because a different TEP was 635 negotiated or because ENO failed to negotiate encryption), then the 636 host MUST abort the TCP connection. Proceeding in any other fashion 637 risks misinterpreted SYN data. 639 If a host sends a SYN-only SYN+ENO segment bearing data and 640 subsequently receives a SYN-ACK segment without an ENO option, that 641 host MUST abort the connection even if the SYN-ACK segment does not 642 acknowledge the SYN data. The issue is that unacknowledged data may 643 nonetheless have been cached by the receiver; later retransmissions 644 intended to supersede this unacknowledged data could fail to do so if 645 the receiver gives precedence to the cached original data. 646 Implementations MAY provide an API call for a non-default mode in 647 which unacknowledged SYN data does not cause a connection abort, but 648 applications MUST use this mode only when a higher-layer integrity 649 check would anyway terminate a garbled connection. 651 To avoid unexpected connection aborts, ENO implementations MUST 652 disable the use of data in SYN-only segments by default. Such data 653 MAY be enabled by an API command. In particular, implementations MAY 654 provide a per-connection mandatory encryption mode that automatically 655 aborts a connection if ENO fails, and MAY enable SYN data in this 656 mode. 658 To satisfy the requirement of the previous paragraph, all TEPs SHOULD 659 support a normal mode of operation that avoids data in SYN-only 660 segments. An exception is TEPs intended to be disabled by default. 662 4.8. Negotiation Transcript 664 To defend against attacks on encryption negotiation itself, a TEP 665 MUST with high probability fail to establish a working connection 666 between two ENO-compliant hosts when SYN-form ENO options have been 667 altered in transit. (Of course, in the absence of endpoint 668 authentication, two compliant hosts can each still be connected to a 669 man-in-the-middle attacker.) To detect SYN-form ENO option 670 tampering, TEPs MUST reference a transcript of TCP-ENO's negotiation. 672 TCP-ENO defines its negotiation transcript as a packed data structure 673 consisting of two TCP-ENO options exactly as they appeared in the TCP 674 header (including the TCP option-kind and TCP option length byte as 675 illustrated in Figure 1). The transcript is constructed from the 676 following, in order: 678 1. The TCP-ENO option in host A's SYN segment, including the kind 679 and length bytes. 681 2. The TCP-ENO option in host B's SYN segment, including the kind 682 and length bytes. 684 Note that because the ENO options in the transcript contain length 685 bytes as specified by TCP, the transcript unambiguously delimits A's 686 and B's ENO options. 688 5. Requirements for TEPs 690 TCP-ENO affords TEP specifications a large amount of design 691 flexibility. However, to abstract TEP differences away from 692 applications requires fitting them all into a coherent framework. As 693 such, any TEP claiming an ENO TEP identifier MUST satisfy the 694 following normative list of properties. 696 o TEPs MUST protect TCP data streams with authenticated encryption. 697 (Note "authenticated encryption" designates the REQUIRED form 698 encryption algorithm [RFC5116]; it does not imply any actual 699 endpoint authentication.) 701 o TEPs MUST define a session ID whose value identifies the TCP 702 connection and, with overwhelming probability, is unique over all 703 time if either host correctly obeys the TEP. Section 5.1 704 describes the requirements of the session ID in more detail. 706 o TEPs MUST NOT make data confidentiality dependent on encryption 707 algorithms with a security strength [SP800-57part1] of less than 708 120 bits. The number 120 was chosen to accommodate ciphers with 709 128-bit keys that lose a few bits of security either to 710 particularities of the key schedule or to highly theoretical and 711 unrealistic attacks. 713 o TEPs MUST NOT allow the negotiation of null cipher suites, even 714 for debugging purposes. (Implementations MAY support debugging 715 modes that allow applications to extract their own session keys.) 717 o TEPs MUST guarantee the confidentiality of TCP streams without 718 assuming the security of any long-lived secrets. Implementations 719 SHOULD provide forward secrecy soon after the close of a TCP 720 connection, and SHOULD therefore bound the delay between closing a 721 connection and erasing any relevant cryptographic secrets. 722 (Exceptions to forward secrecy are permissible only at the 723 implementation level, and only in response to hardware or 724 architectural constraints--e.g., storage that cannot be securely 725 erased.) 727 o TEPs MUST protect and authenticate the end-of-file marker conveyed 728 by TCP's FIN flag. In particular, a receiver MUST with 729 overwhelming probability detect a FIN flag that was set or cleared 730 in transit and does not match the sender's intent. A TEP MAY 731 discard a segment with such a corrupted FIN bit, or may abort the 732 connection in response to such a segment. However, any such abort 733 MUST raise an error condition distinct from an authentic end-of- 734 file condition. 736 o TEPs MUST prevent corrupted packets from causing urgent data to be 737 delivered when none has been sent. There are several ways to do 738 so. For instance, a TEP MAY cryptographically protect the URG 739 flag and urgent pointer alongside ordinary payload data. 740 Alternatively, a TEP MAY disable urgent data functionality by 741 clearing the URG flag on all received segments and returning 742 errors in response to sender-side urgent-data API calls. 743 Implementations SHOULD avoid negotiating TEPs that disable urgent 744 data by default. The exception is when applications and protocols 745 are known never to send urgent data. 747 5.1. Session IDs 749 Each TEP MUST define a session ID that is computable by both 750 endpoints and uniquely identifies each encrypted TCP connection. 751 Implementations MUST expose the session ID to applications via an API 752 extension. The API extension MUST return an error when no session ID 753 is available because ENO has failed to negotiate encryption or 754 because no connection is yet established. Applications that are 755 aware of TCP-ENO SHOULD, when practical, authenticate the TCP 756 endpoints by incorporating the values of the session ID and TCP-ENO 757 role (A or B) into higher-layer authentication mechanisms. 759 In order to avoid replay attacks and prevent authenticated session 760 IDs from being used out of context, session IDs MUST be unique over 761 all time with high probability. This uniqueness property MUST hold 762 even if one end of a connection maliciously manipulates the protocol 763 in an effort to create duplicate session IDs. In other words, it 764 MUST be infeasible for a host, even by violating the TEP 765 specification, to establish two TCP connections with the same session 766 ID to remote hosts properly implementing the TEP. 768 To prevent session IDs from being confused across TEPs, all session 769 IDs begin with the negotiated TEP identifier--that is, the last valid 770 TEP identifier in host B's SYN segment. Furthermore, this initial 771 byte has bit "v" set to the same value that accompanied the 772 negotiated TEP identifier in B's SYN segment. However, only this 773 single byte is included, not any suboption data. Figure 8 shows the 774 resulting format. This format is designed for TEPs to compute unique 775 identifiers; it is not intended for application authors to pick apart 776 session IDs. Applications SHOULD treat session IDs as monolithic 777 opaque values and SHOULD NOT discard the first byte to shorten 778 identifiers. (An exception is for non-security-relevant purposes, 779 such as gathering statistics about negotiated TEPs.) 781 byte 0 1 2 N-1 N 782 +-----+------------...------------+ 783 | sub-| collision-resistant hash | 784 | opt | of connection information | 785 +-----+------------...------------+ 787 Figure 8: Format of a session ID 789 Though TEP specifications retain considerable flexibility in their 790 definitions of the session ID, all session IDs MUST meet the 791 following normative list of requirements: 793 o The session ID MUST be at least 33 bytes (including the one-byte 794 suboption), though TEPs MAY choose longer session IDs. 796 o The session ID MUST depend in a collision-resistant way on all of 797 the following (meaning it is computationally infeasible to produce 798 collisions of the session ID derivation function unless all of the 799 following quantities are identical): 801 * Fresh data contributed by both sides of the connection, 802 * Any public keys, public Diffie-Hellman parameters, or other 803 public asymmetric cryptographic parameters that are employed by 804 the TEP and have corresponding private data that is known by 805 only one side of the connection, and 807 * The negotiation transcript specified in Section 4.8. 809 o Unless and until applications disclose information about the 810 session ID, all but the first byte MUST be computationally 811 indistinguishable from random bytes to a network eavesdropper. 813 o Applications MAY choose to make session IDs public. Therefore, 814 TEPs MUST NOT place any confidential data in the session ID (such 815 as data permitting the derivation of session keys). 817 6. Examples 819 This subsection illustrates the TCP-ENO handshake with a few non- 820 normative examples. 822 (1) A -> B: SYN ENO 823 (2) B -> A: SYN-ACK ENO 824 (3) A -> B: ACK ENO<> 825 [rest of connection encrypted according to TEP Y] 827 Figure 9: Three-way handshake with successful TCP-ENO negotiation 829 Figure 9 shows a three-way handshake with a successful TCP-ENO 830 negotiation. Host A includes two ENO suboptions with TEP identifiers 831 X and Y. The two sides agree to follow the TEP identified by 832 suboption Y. 834 (1) A -> B: SYN ENO 835 (2) B -> A: SYN-ACK 836 (3) A -> B: ACK 837 [rest of connection unencrypted legacy TCP] 839 Figure 10: Three-way handshake with failed TCP-ENO negotiation 841 Figure 10 shows a failed TCP-ENO negotiation. The active opener (A) 842 indicates support for TEPs corresponding to suboptions X and Y. 843 Unfortunately, at this point one of several things occurs: 845 1. The passive opener (B) does not support TCP-ENO, 847 2. B supports TCP-ENO, but supports neither of TEPs X and Y, and so 848 does not reply with an ENO option, 850 3. B supports TCP-ENO, but has the connection configured in 851 mandatory application-aware mode and thus disables ENO because 852 A's SYN segment does not set the application-aware bit, or 854 4. The network stripped the ENO option out of A's SYN segment, so B 855 did not receive it. 857 Whichever of the above applies, the connection transparently falls 858 back to unencrypted TCP. 860 (1) A -> B: SYN ENO 861 (2) B -> A: SYN-ACK ENO [ENO stripped by middlebox] 862 (3) A -> B: ACK 863 [rest of connection unencrypted legacy TCP] 865 Figure 11: Failed TCP-ENO negotiation because of option stripping 867 Figure 11 Shows another handshake with a failed encryption 868 negotiation. In this case, the passive opener B receives an ENO 869 option from A and replies. However, the reverse network path from B 870 to A strips ENO options. Hence, A does not receive an ENO option 871 from B, disables ENO, and does not include a non-SYN-form ENO option 872 in segment 3 when ACKing B's SYN. Had A not disabled encryption, 873 Section 4.6 would have required it to include a non-SYN ENO option in 874 segment 3. The omission of this option informs B that encryption 875 negotiation has failed, after which the two hosts proceed with 876 unencrypted TCP. 878 (1) A -> B: SYN ENO 879 (2) B -> A: SYN ENO 880 (3) A -> B: SYN-ACK ENO 881 (4) B -> A: SYN-ACK ENO 882 [rest of connection encrypted according to TEP Y] 884 Figure 12: Simultaneous open with successful TCP-ENO negotiation 886 Figure 12 shows a successful TCP-ENO negotiation with simultaneous 887 open. Here the first four segments contain a SYN-form ENO option, as 888 each side sends both a SYN-only and a SYN-ACK segment. The ENO 889 option in each host's SYN-ACK is identical to the ENO option in its 890 SYN-only segment, as otherwise connection establishment could not 891 recover from the loss of a SYN segment. The last valid TEP in host 892 B's ENO option is Y, so Y is the negotiated TEP. 894 7. Future Developments 896 TCP-ENO is designed to capitalize on future developments that could 897 alter trade-offs and change the best approach to TCP-level encryption 898 (beyond introducing new cipher suites). By way of example, we 899 discuss a few such possible developments. 901 Various proposals exist to increase the maximum space for options in 902 the TCP header. These proposals are highly experimental-- 903 particularly those that apply to SYN segments. Hence, future TEPs 904 are unlikely to benefit from extended SYN option space. In the 905 unlikely event that SYN option space is one day extended, however, 906 future TEPs could benefit by embedding key agreement messages 907 directly in SYN segments. Under such usage, the 32-byte limit on 908 length bytes could prove insufficient. This draft intentionally 909 aborts TCP-ENO if a length byte is followed by an octet in the range 910 0x00-0x9f. If necessary, a future update to this document can define 911 a format for larger suboptions by assigning meaning to such currently 912 undefined byte sequences. 914 New revisions to socket interfaces [RFC3493] could involve library 915 calls that simultaneously have access to hostname information and an 916 underlying TCP connection. Such an API enables the possibility of 917 authenticating servers transparently to the application, particularly 918 in conjunction with technologies such as DANE [RFC6394]. An update 919 to TCP-ENO can adopt one of the "z" bits in the global suboption to 920 negotiate the use of an endpoint authentication protocol before any 921 application use of the TCP connection. Over time, the consequences 922 of failed or missing endpoint authentication can gradually be 923 increased from issuing log messages to aborting the connection if 924 some as yet unspecified DNS record indicates authentication is 925 mandatory. Through shared library updates, such endpoint 926 authentication can potentially be added transparently to legacy 927 applications without recompilation. 929 TLS can currently only be added to legacy applications whose 930 protocols accommodate a STARTTLS command or equivalent. TCP-ENO, 931 because it provides out-of-band signaling, opens the possibility of 932 future TLS revisions being generically applicable to any TCP 933 application. 935 8. Design Rationale 937 This section describes some of the design rationale behind TCP-ENO. 939 8.1. Handshake Robustness 941 Incremental deployment of TCP-ENO depends critically on failure cases 942 devolving to unencrypted TCP rather than causing the entire TCP 943 connection to fail. 945 Because a network path may drop ENO options in one direction only, a 946 host needs to know not just that the peer supports encryption, but 947 that the peer has received an ENO option. To this end, ENO disables 948 encryption unless it receives an ACK segment bearing an ENO option. 949 To stay robust in the face of dropped segments, hosts continue to 950 include non-SYN form ENO options in segments until such point as they 951 have received a non-SYN segment from the other side. 953 One particularly pernicious middlebox behavior found in the wild is 954 load balancers that echo unknown TCP options found in SYN segments 955 back to an active opener. The passive role bit "b" in global 956 suboptions ensures encryption will always be disabled under such 957 circumstances, as sending back a verbatim copy of an active opener's 958 SYN-form ENO option always causes role negotiation to fail. 960 8.2. Suboption Data 962 TEPs can employ suboption data for session caching, cipher suite 963 negotiation, or other purposes. However, TCP currently limits total 964 option space consumed by all options to only 40 bytes, making it 965 impractical to have many suboptions with data. For this reason, ENO 966 optimizes the case of a single suboption with data by inferring the 967 length of the last suboption from the TCP option length. Doing so 968 saves one byte. 970 8.3. Passive Role Bit 972 TCP-ENO, TEPs, and applications all have asymmetries that require an 973 unambiguous way to identify one of the two connection endpoints. As 974 an example, Section 4.8 specifies that host A's ENO option comes 975 before host B's in the negotiation transcript. As another example, 976 an application might need to authenticate one end of a TCP connection 977 with a digital signature. To ensure the signed message cannot not be 978 interpreted out of context to authenticate the other end, the signed 979 message would need to include both the session ID and the local role, 980 A or B. 982 A normal TCP three-way handshake involves one active and one passive 983 opener. This asymmetry is captured by the default configuration of 984 the "b" bit in the global suboption. With simultaneous open, both 985 hosts are active openers, so TCP-ENO requires that one host 986 explicitly configure "b = 1". An alternate design might 987 automatically break the symmetry to avoid this need for explicit 988 configuration. However, all such designs we considered either lacked 989 robustness or consumed precious bytes of SYN option space even in the 990 absence of simultaneous open. (One complicating factor is that TCP 991 does not know it is participating in a simultaneous open until after 992 it has sent a SYN segment. Moreover, with packet loss, one host 993 might never learn it has participated in a simultaneous open.) 995 8.4. Application-aware Bit 997 Applications developed before TCP-ENO can potentially evolve to take 998 advantage of TCP-level encryption. For instance, an application 999 designed to run only on trusted networks might leverage TCP-ENO to 1000 run on untrusted networks, but, importantly, needs to authenticate 1001 endpoints and session IDs to do so. In addition to user-visible 1002 changes such as requesting credentials, this kind of authentication 1003 functionality requires application-layer protocol changes. Some 1004 protocols can accommodate the requisite changes--for instance by 1005 introducing a new verb analogous to "STARTTLS"--while others cannot 1006 do so in a backwards-compatible manner. 1008 The application-aware bit "a" in the the global suboption provides a 1009 means of incrementally deploying TCP-ENO-specific enhancements to 1010 application-layer protocols that would otherwise lack the necessary 1011 extensibility. Software implementing the enhancement always sets "a 1012 = 1" in its own global suboption, but only activates the new behavior 1013 when the other end of the connection also sets "a = 1". 1015 A related issue is that an application might leverage TCP-ENO as a 1016 replacement for legacy application-layer encryption. In this 1017 scenario, if both endpoints support TCP-ENO, then application-layer 1018 encryption can be disabled in favor of simply authenticating the TCP- 1019 ENO session ID. On the other hand, if one endpoint is not aware of 1020 the new TCP-ENO-specific mode of operation, there is little benefit 1021 to performing redundant encryption at the TCP layer; data is already 1022 encrypted once at the application layer, and authentication is only 1023 with respect to this application-layer encryption. The mandatory 1024 application-aware mode lets applications avoid double encryption in 1025 this case: the mode sets "a = 1" in the local host's global 1026 suboption, but also disables TCP-ENO entirely in the event that the 1027 other side has not also set "a = 1". 1029 Note that the application-aware bit is not needed by applications 1030 that already support adequate higher-layer encryption, such as 1031 provided by TLS [RFC5246] or SSH [RFC4253]. To avoid double- 1032 encryption in such cases, it suffices to disable TCP-ENO by 1033 configuration on any ports with known secure protocols. 1035 8.5. Use of ENO Option Kind by TEPs 1037 This draft does not specify the use of ENO options beyond the first 1038 few segments of a connection. Moreover, it does not specify the 1039 content of ENO options in non-SYN segments, only their presence. As 1040 a result, any use of option-kind TBD after the SYN exchange does not 1041 conflict with this document. Because, in addition, ENO guarantees at 1042 most one negotiated TEP per connection, TEPs will not conflict with 1043 one another or ENO if they use ENO's option-kind for out-of-band 1044 signaling in non-SYN segments. 1046 8.6. Unpredictability of Session IDs 1048 Section 5.1 specifies that all but the first (TEP identifier) byte of 1049 a session ID MUST be computationally indistinguishable from random 1050 bytes to a network eavesdropper. This property is easy to ensure 1051 under standard assumptions about cryptographic hash functions. Such 1052 unpredictability helps security in a broad range of cases. For 1053 example, it makes it possible for applications to use a session ID 1054 from one connection to authenticate a session ID from another, 1055 thereby tying the two connections together. It furthermore helps 1056 ensure that TEPs do not trivially subvert the 33-byte minimum length 1057 requirement for session IDs by padding shorter session IDs with 1058 zeros. 1060 9. Experiments 1062 This document has experimental status because TCP-ENO's viability 1063 depends on middlebox behavior that can only be determined _a 1064 posteriori_. Specifically, we need to determine to what extent 1065 middleboxes will permit the use of TCP-ENO. Once TCP-ENO is 1066 deployed, we will be in a better position to gather data on two types 1067 of failure: 1069 1. Middleboxes downgrading TCP-ENO connections to unencrypted TCP. 1070 This can happen if middleboxes strip unknown TCP options or if 1071 they terminate TCP connections and relay data back and forth. 1073 2. Middleboxes causing TCP-ENO connections to fail completely. This 1074 can happen if middleboxes perform deep packet inspection and 1075 start dropping segments that unexpectedly contain ciphertext, or 1076 if middleboxes strip ENO options from non-SYN segments after 1077 allowing them in SYN segments. 1079 Type-1 failures are tolerable, since TCP-ENO is designed for 1080 incremental deployment anyway. Type-2 failures are more problematic, 1081 and, if prevalent, will require the development of techniques to 1082 avoid and recover from such failures. The experiment will succeed so 1083 long as we can avoid type-2 failures and find sufficient use cases 1084 that avoid type-1 failures (possibly along with a gradual path for 1085 further reducing type-1 failures). 1087 In addition to the question of basic viability, deploying TCP-ENO 1088 will allow us to identify and address other potential corner cases or 1089 relaxations. For example, does the slight decrease in effective TCP 1090 segment payload pose a problem to any applications, requiring 1091 restrictions on how TEPs interpret socket buffer sizes? Conversely, 1092 can we relax the prohibition on default TEPs that disable urgent 1093 data? 1095 A final important metric, related to the pace of deployment and 1096 incidence of Type-1 failures, will be the extent to which 1097 applications adopt TCP-ENO-specific enhancements for endpoint 1098 authentication. 1100 10. Security Considerations 1102 An obvious use case for TCP-ENO is opportunistic encryption--that is, 1103 encrypting some connections, but only where supported and without any 1104 kind of endpoint authentication. Opportunistic encryption provides a 1105 property known as _opportunistic security_ [RFC7435], which protects 1106 against undetectable large-scale eavesdropping. However, it does not 1107 protect against detectable large-scale eavesdropping (for instance, 1108 if ISPs terminate TCP connections and proxy them, or simply downgrade 1109 connections to unencrypted). Moreover, opportunistic encryption 1110 emphatically does not protect against targeted attacks that employ 1111 trivial spoofing to redirect a specific high-value connection to a 1112 man-in-the-middle attacker. Hence, the mere presence of TEP- 1113 indicated encryption does not suffice for an application to represent 1114 a connection as "secure" to the user. 1116 Achieving stronger security with TCP-ENO requires verifying session 1117 IDs. Any application relying on ENO for communications security MUST 1118 incorporate session IDs into its endpoint authentication. By way of 1119 example, an authentication mechanism based on keyed digests (such as 1120 Digest Access Authentication [RFC7616]) can be extended to include 1121 the role and session ID in the input of the keyed digest. Higher- 1122 layer protocols MAY use the application-aware "a" bit to negotiate 1123 the inclusion of session IDs in authentication even when there is no 1124 in-band way to carry out such a negotiation. Because there is only 1125 one "a" bit, however, a protocol extension that specifies use of the 1126 "a" bit will likely require a built-in versioning or negotiation 1127 mechanism to accommodate crypto agility and future updates. 1129 Because TCP-ENO enables multiple different TEPs to coexist, security 1130 could potentially be only as strong as the weakest available TEP. In 1131 particular, if TEPs use a weak hash function to incorporate the TCP- 1132 ENO transcript into session IDs, then an attacker can undetectably 1133 tamper with ENO options to force negotiation of a deprecated and 1134 vulnerable TEP. To avoid such problems, security reviewers of new 1135 TEPs SHOULD pay particular attention to the collision resistance of 1136 hash functions used for session IDs (including the state of 1137 cryptanalysis and research into possible attacks). Even if other 1138 parts of a TEP rely on more esoteric cryptography that turns out to 1139 be vulnerable, it ought nonetheless to intractable for an attacker to 1140 induce identical session IDs at both ends after tampering with ENO 1141 contents in SYN segments. 1143 Implementations MUST NOT send ENO options unless they have access to 1144 an adequate source of randomness [RFC4086]. Without secret 1145 unpredictable data at both ends of a connection, it is impossible for 1146 TEPs to achieve confidentiality and forward secrecy. Because systems 1147 typically have very little entropy on bootup, implementations might 1148 need to disable TCP-ENO until after system initialization. 1150 With a regular three-way handshake (meaning no simultaneous open), 1151 the non-SYN form ENO option in an active opener's first ACK segment 1152 MAY contain N > 0 bytes of TEP-specific data, as shown in Figure 3. 1153 Such data is not part of the TCP-ENO negotiation transcript, and 1154 hence MUST be separately authenticated by the TEP. 1156 11. IANA Considerations 1158 [RFC-editor: please replace TBD in this section, in Section 4.1, and 1159 in Section 8.5 with the assigned option-kind number. Please also 1160 replace RFC-TBD with this document's final RFC number.] 1162 This document defines a new TCP option-kind for TCP-ENO, assigned a 1163 value of TBD from the TCP option space. This value is defined as: 1165 +------+--------+----------------------------------+-----------+ 1166 | Kind | Length | Meaning | Reference | 1167 +------+--------+----------------------------------+-----------+ 1168 | TBD | N | Encryption Negotiation (TCP-ENO) | [RFC-TBD] | 1169 +------+--------+----------------------------------+-----------+ 1171 TCP Option Kind Numbers 1173 Early implementations of TCP-ENO and a predecessor TCP encryption 1174 protocol made unauthorized use of TCP option-kind 69. 1176 [RFC-editor: please glue the following text to the previous paragraph 1177 iff TBD == 69, otherwise delete it.] These earlier uses of option 69 1178 are not compatible with TCP-ENO and could disable encryption or 1179 suffer complete connection failure when interoperating with TCP-ENO- 1180 compliant hosts. Hence, legacy use of option 69 MUST be disabled on 1181 hosts that cannot be upgraded to TCP-ENO. 1183 [RFC-editor: please glue this to the previous paragraph regardless of 1184 the value of TBD.] More recent implementations used experimental 1185 option 253 per [RFC6994] with 16-bit ExID 0x454E. Current and new 1186 implementations of TCP-ENO MUST use option TBD, while any legacy 1187 implementations MUST migrate to option TBD. Note in particular that 1188 Section 4.1 requires at most one SYN-form ENO option per segment, 1189 which means hosts MUST NOT not include both option TBD and option 253 1190 with ExID 0x454E in the same TCP segment. 1192 [IANA is also requested to update the entry for TCP-ENO in the TCP 1193 Experimental Option Experiment Identifiers (TCP ExIDs) sub-registry 1194 to reflect the guidance of the previous paragraph by adding a note 1195 saying "current and new implementations MUST use option TDB." RFC- 1196 editor: please remove this comment.] 1198 This document defines a 7-bit "glt" field in the range of 0x20-0x7f, 1199 for which IANA is to create and maintain a new registry entitled "TCP 1200 encryption protocol identifiers" under the "Transmission Control 1201 Protocol (TCP) Parameters" registry. The initial contents of the TCP 1202 encryption protocol identifier registry is shown in Table 2. This 1203 document allocates one TEP identifier (0x20) for experimental use. 1204 In case the TEP identifier space proves too small, identifiers in the 1205 range 0x70-0x7f are reserved to enable a future update to this 1206 document to define extended identifier values. Future assignments 1207 are to be made upon satisfying either of two policies defined in 1208 [RFC8126]: "IETF Review" or (for non-IETF stream specifications) 1209 "Expert Review with RFC Required." IANA will furthermore provide 1210 early allocation [RFC7120] to facilitate testing before RFCs are 1211 finalized. 1213 +-----------+------------------------------+-----------+ 1214 | Value | Meaning | Reference | 1215 +-----------+------------------------------+-----------+ 1216 | 0x20 | Experimental Use | [RFC-TBD] | 1217 | 0x70-0x7f | Reserved for extended values | [RFC-TBD] | 1218 +-----------+------------------------------+-----------+ 1220 Table 2: TCP encryption protocol identifiers 1222 12. Acknowledgments 1224 We are grateful for contributions, help, discussions, and feedback 1225 from the IETF and its TCPINC working group, including Marcelo 1226 Bagnulo, David Black, Bob Briscoe, Benoit Claise, Spencer Dawkins, 1227 Jake Holland, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Watson 1228 Ladd, Kathleen Moriarty, Yoav Nir, Christoph Paasch, Eric Rescorla, 1229 Adam Roach, Kyle Rose, Michael Scharf, Joe Touch, and Eric Vyncke. 1230 This work was partially funded by DARPA CRASH and the Stanford Secure 1231 Internet of Things Project. 1233 13. Contributors 1235 Dan Boneh was a co-author of the draft that became this document. 1237 14. References 1239 14.1. Normative References 1241 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1242 RFC 793, DOI 10.17487/RFC0793, September 1981, 1243 . 1245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1246 Requirement Levels", BCP 14, RFC 2119, 1247 DOI 10.17487/RFC2119, March 1997, 1248 . 1250 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1251 "Randomness Requirements for Security", BCP 106, RFC 4086, 1252 DOI 10.17487/RFC4086, June 2005, 1253 . 1255 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 1256 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 1257 2014, . 1259 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1260 Writing an IANA Considerations Section in RFCs", BCP 26, 1261 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1262 . 1264 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1265 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1266 May 2017, . 1268 [SP800-57part1] 1269 Barker, E., "Recommendation for Key Management, Part 1: 1270 General", NIST Special Publication 800-57 Part 1, Revision 1271 4, January 2016, 1272 . 1274 14.2. Informative References 1276 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1277 Stevens, "Basic Socket Interface Extensions for IPv6", 1278 RFC 3493, DOI 10.17487/RFC3493, February 2003, 1279 . 1281 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1282 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 1283 January 2006, . 1285 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1286 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1287 . 1289 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1290 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1291 . 1293 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1294 (TLS) Protocol Version 1.2", RFC 5246, 1295 DOI 10.17487/RFC5246, August 2008, 1296 . 1298 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 1299 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1300 RFC 5382, DOI 10.17487/RFC5382, October 2008, 1301 . 1303 [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based 1304 Authentication of Named Entities (DANE)", RFC 6394, 1305 DOI 10.17487/RFC6394, October 2011, 1306 . 1308 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 1309 RFC 6994, DOI 10.17487/RFC6994, August 2013, 1310 . 1312 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1313 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1314 . 1316 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1317 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1318 December 2014, . 1320 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 1321 Digest Access Authentication", RFC 7616, 1322 DOI 10.17487/RFC7616, September 2015, 1323 . 1325 Authors' Addresses 1327 Andrea Bittau 1328 Google 1329 345 Spear Street 1330 San Francisco, CA 94105 1331 US 1333 Email: bittau@google.com 1335 Daniel B. Giffin 1336 Stanford University 1337 353 Serra Mall, Room 288 1338 Stanford, CA 94305 1339 US 1341 Email: dbg@scs.stanford.edu 1343 Mark Handley 1344 University College London 1345 Gower St. 1346 London WC1E 6BT 1347 UK 1349 Email: M.Handley@cs.ucl.ac.uk 1351 David Mazieres 1352 Stanford University 1353 353 Serra Mall, Room 290 1354 Stanford, CA 94305 1355 US 1357 Email: dm@uun.org 1358 Eric W. Smith 1359 Kestrel Institute 1360 3260 Hillview Avenue 1361 Palo Alto, CA 94304 1362 US 1364 Email: eric.smith@kestrel.edu