idnits 2.17.1 draft-ietf-tcpinc-tcpeno-13.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 2, 2017) is 2360 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC-TBD' is mentioned on line 1130, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 6, 2018 Stanford University 6 M. Handley 7 University College London 8 D. Mazieres 9 Stanford University 10 E. Smith 11 Kestrel Institute 12 November 2, 2017 14 TCP-ENO: Encryption Negotiation Option 15 draft-ietf-tcpinc-tcpeno-13 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 6, 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 . . . . . . . . . . . . . . . . . 14 78 5. Requirements for TEPs . . . . . . . . . . . . . . . . . . . . 15 79 5.1. Session IDs . . . . . . . . . . . . . . . . . . . . . . . 16 80 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 7. Future Developments . . . . . . . . . . . . . . . . . . . . . 19 82 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 20 83 8.1. Handshake Robustness . . . . . . . . . . . . . . . . . . 20 84 8.2. Suboption Data . . . . . . . . . . . . . . . . . . . . . 20 85 8.3. Passive Role Bit . . . . . . . . . . . . . . . . . . . . 21 86 8.4. Use of ENO Option Kind by TEPs . . . . . . . . . . . . . 21 87 8.5. Unpredictability of Session IDs . . . . . . . . . . . . . 21 88 9. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 91 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 92 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 93 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 94 14.1. Normative References . . . . . . . . . . . . . . . . . . 25 95 14.2. Informative References . . . . . . . . . . . . . . . . . 26 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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 one 131 among multiple possible TCP encryption protocols or _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 or _TEP_. 150 2. Transparently fall back to unencrypted TCP when not supported by 151 both endpoints. 153 3. Provide out-of-band signaling through which applications can 154 better take advantage of TCP-level encryption (for instance, by 155 improving authentication mechanisms in the presence of TCP-level 156 encryption). 158 4. Provide a standard negotiation transcript through which TEPs can 159 defend against tampering with TCP-ENO. 161 5. Make parsimonious use of TCP option space. 163 6. Define roles for the two ends of a TCP connection, so as to name 164 each end of a connection for encryption or authentication 165 purposes even following a symmetric simultaneous open. 167 3. Terminology 169 Throughout this document, we use the following terms, several of 170 which have more detailed normative descriptions in [RFC0793]: 172 SYN segment 173 A TCP segment in which the SYN flag is set 175 ACK segment 176 A TCP segment in which the ACK flag is set (which includes most 177 segments other than an initial SYN segment) 179 non-SYN segment 180 A TCP segment in which the SYN flag is clear 182 SYN-only segment 183 A TCP segment in which the SYN flag is set but the ACK flag is 184 clear 186 SYN-ACK segment 187 A TCP segment in which the SYN and ACK flags are both set 189 Active opener 190 A host that initiates a connection by sending a SYN-only segment. 191 With the BSD socket API, an active opener calls "connect". In 192 client-server configurations, active openers are typically 193 clients. 195 Passive opener 196 A host that does not send a SYN-only segment, but responds to one 197 with a SYN-ACK segment. With the BSD socket API, passive openers 198 call "listen" and "accept", rather than "connect". In client- 199 server configurations, passive openers are typically servers. 201 Simultaneous open 202 The act of symmetrically establishing a TCP connection between two 203 active openers (both of which call "connect" with BSD sockets). 204 Each host of a simultaneous open sends both a SYN-only and a SYN- 205 ACK segment. Simultaneous open is less common than asymmetric 206 open with one active and one passive opener, but can be used for 207 NAT traversal by peer-to-peer applications [RFC5382]. 209 TEP 210 A TCP encryption protocol intended for use with TCP-ENO and 211 specified in a separate document. 213 TEP identifier 214 A unique 7-bit value in the range 0x20-0x7f that IANA has assigned 215 to a TEP. 217 Negotiated TEP 218 The single TEP governing a TCP connection, determined by use of 219 the TCP ENO option specified in this document. 221 4. TCP-ENO Specification 223 TCP-ENO extends TCP connection establishment to enable encryption 224 opportunistically. It uses a new TCP option-kind [RFC0793] to 225 negotiate one among multiple possible TCP encryption protocols or 226 TEPs. The negotiation involves hosts exchanging sets of supported 227 TEPs, where each TEP is represented by a _suboption_ within a larger 228 TCP ENO option in the offering host's SYN segment. 230 If TCP-ENO succeeds, it yields the following information: 232 o A negotiated TEP, represented by a unique 7-bit TEP identifier, 234 o A few extra bytes of suboption data from each host, if needed by 235 the TEP, 237 o A negotiation transcript with which to mitigate attacks on the 238 negotiation itself, 240 o Role assignments designating one endpoint "host A" and the other 241 endpoint "host B", and 243 o A bit available to higher-layer protocols at each endpoint for 244 out-of-band negotiation of updated behavior in the presence of TCP 245 encryption. 247 If TCP-ENO fails, encryption is disabled and the connection falls 248 back to traditional unencrypted TCP. 250 The remainder of this section provides the normative description of 251 the TCP ENO option and handshake protocol. 253 4.1. ENO Option 255 TCP-ENO employs an option in the TCP header [RFC0793]. Figure 1 256 illustrates the high-level format of this option. 258 byte 0 1 2 N+1 (N+2 bytes total) 259 +-----+-----+-----+--....--+-----+ 260 |Kind=|Len= | | 261 | TBD | N+2 | contents (N bytes) | 262 +-----+-----+-----+--....--+-----+ 264 Figure 1: The TCP-ENO option 266 The contents of an ENO option can take one of two forms. A SYN form, 267 illustrated in Figure 2, appears only in SYN segments. A non-SYN 268 form, illustrated in Figure 3, appears only in non-SYN segments. The 269 SYN form of ENO acts as a container for zero or more suboptions, 270 labeled "Opt_0", "Opt_1", ... in Figure 2. The non-SYN form, by its 271 presence, acts as a one-bit acknowledgment, with the actual contents 272 ignored by ENO. Particular TEPs MAY assign additional meaning to the 273 contents of non-SYN ENO options. When a negotiated TEP does not 274 assign such meaning, the contents of a non-SYN ENO option MUST be 275 zero bytes in sent segments and MUST be ignored in received segments. 277 byte 0 1 2 3 ... N+1 278 +-----+-----+-----+-----+--...--+-----+----...----+ 279 |Kind=|Len= |Opt_0|Opt_1| |Opt_i| Opt_i | 280 | TBD | N+2 | | | | | data | 281 +-----+-----+-----+-----+--...--+-----+----...----+ 283 Figure 2: SYN form of ENO 285 byte 0 1 2 N+1 286 +-----+-----+-----...----+ 287 |Kind=|Len= | ignored | 288 | TBD | N+2 | by TCP-ENO | 289 +-----+-----+-----...----+ 291 Figure 3: Non-SYN form of ENO, where N MAY be 0 293 Every suboption starts with a byte of the form illustrated in 294 Figure 4. The high bit "v", when set, introduces suboptions with 295 variable-length data. When "v = 0", the byte itself constitutes the 296 entirety of the suboption. The 7-bit value "glt" expresses one of: 298 o Global configuration data (discussed in Section 4.2), 300 o Suboption data length for the next suboption (discussed in 301 Section 4.4), or 303 o An offer to use a particular TEP defined in a separate TEP 304 specification document. 306 bit 7 6 5 4 3 2 1 0 307 +---+---+---+---+---+---+---+---+ 308 | v | glt | 309 +---+---+---+---+---+---+---+---+ 311 v - non-zero for use with variable-length suboption data 312 glt - Global suboption, Length, or TEP identifier 314 Figure 4: Format of initial suboption byte 316 Table 1 summarizes the meaning of initial suboption bytes. Values of 317 "glt" below 0x20 are used for global suboptions and length 318 information (the "gl" in "glt"), while those greater than or equal to 319 0x20 are TEP identifiers (the "t"). When "v = 0", the initial 320 suboption byte constitutes the entirety of the suboption and all 321 information is expressed by the 7-bit "glt" value, which can be 322 either a global suboption or a TEP identifier. When "v = 1", it 323 indicates a suboption with variable-length suboption data. Only TEP 324 identifiers may have suboption data, not global suboptions. Hence, 325 bytes with "v = 1" and "glt < 0x20" are not global suboptions but 326 rather length bytes governing the length of the next suboption (which 327 MUST be a TEP identifier). In the absence of a length byte, a TEP 328 identifier suboption with "v = 1" has suboption data extending to the 329 end of the TCP option. 331 +-----------+---+-------------------------------------------+ 332 | glt | v | Meaning | 333 +-----------+---+-------------------------------------------+ 334 | 0x00-0x1f | 0 | Global suboption (Section 4.2) | 335 | 0x00-0x1f | 1 | Length byte (Section 4.4) | 336 | 0x20-0x7f | 0 | TEP identifier without suboption data | 337 | 0x20-0x7f | 1 | TEP identifier followed by suboption data | 338 +-----------+---+-------------------------------------------+ 340 Table 1: Initial suboption byte values 342 A SYN segment MUST contain at most one TCP ENO option. If a SYN 343 segment contains more than one ENO option, the receiver MUST behave 344 as though the segment contained no ENO options and disable 345 encryption. A TEP MAY specify the use of multiple ENO options in a 346 non-SYN segment. For non-SYN segments, ENO itself only distinguishes 347 between the presence or absence of ENO options; multiple ENO options 348 are interpreted the same as one. 350 4.2. The Global Suboption 352 Suboptions 0x00-0x1f are used for global configuration that applies 353 regardless of the negotiated TEP. A TCP SYN segment MUST include at 354 most one ENO suboption in this range. A receiver MUST ignore all but 355 the first suboption in this range in any given TCP segment so as to 356 anticipate updates to ENO that assign new meaning to bits in 357 subsequent global suboptions. The value of a global suboption byte 358 is interpreted as a bitmask, illustrated in Figure 5. 360 bit 7 6 5 4 3 2 1 0 361 +---+---+---+---+---+---+---+---+ 362 | 0 | 0 | 0 |z1 |z2 |z3 | a | b | 363 +---+---+---+---+---+---+---+---+ 365 b - Passive role bit 366 a - Application-aware bit 367 z* - Zero bits (reserved for future use) 369 Figure 5: Format of the global suboption byte 371 The fields of the bitmask are interpreted as follows: 373 b 374 The passive role bit MUST be 1 for all passive openers. For 375 active openers, it MUST default to 0, but implementations MUST 376 provide an API through which an application can explicitly set "b 377 = 1" before initiating an active open. (Manual configuration of 378 "b" is only necessary to enable encryption with a simultaneous 379 open.) 381 a 382 Legacy applications can benefit from ENO-specific updates that 383 improve endpoint authentication or avoid double encryption. The 384 application-aware bit "a" is an out-of-band signal through which 385 higher-layer protocols can enable ENO-specific updates that would 386 otherwise not be backwards-compatible. Implementations MUST set 387 this bit to 0 by default, and MUST provide an API through which 388 applications can change the value of the bit as well as examine 389 the value of the bit sent by the remote host. Implementations 390 MUST furthermore support a _mandatory_ application-aware mode in 391 which TCP-ENO is automatically disabled if the remote host does 392 not set "a = 1". 394 z1, z2, z3 395 The "z" bits are reserved for future updates to TCP-ENO. They 396 MUST be set to zero in sent segments and MUST be ignored in 397 received segments. 399 A SYN segment without an explicit global suboption has an implicit 400 global suboption of 0x00. Because passive openers MUST always set "b 401 = 1", they cannot rely on this implicit 0x00 byte and MUST include an 402 explicit global suboption in their SYN-ACK segments. 404 4.3. TCP-ENO Roles 406 TCP-ENO uses abstract roles to distinguish the two ends of a TCP 407 connection. These roles are determined by the "b" bit in the global 408 suboption. The host that sent an implicit or explicit suboption with 409 "b = 0" plays the "A" role. The host that sent "b = 1" plays the "B" 410 role. 412 If both sides of a connection set "b = 1" (which can happen if the 413 active opener misconfigures "b" before calling "connect"), or both 414 sides set "b = 0" (which can happen with simultaneous open), then 415 TCP-ENO MUST be disabled and the connection MUST fall back to 416 unencrypted TCP. 418 TEP specifications SHOULD refer to TCP-ENO's A and B roles to specify 419 asymmetric behavior by the two hosts. For the remainder of this 420 document, we will use the terms "host A" and "host B" to designate 421 the hosts with roles A and B, respectively, in a connection. 423 4.4. Specifying Suboption Data Length 425 A TEP MAY optionally make use of one or more bytes of suboption data. 426 The presence of such data is indicated by setting "v = 1" in the 427 initial suboption byte (see Figure 4). By default, suboption data 428 extends to the end of the TCP option. Hence, if only one suboption 429 requires data, the most compact way to encode it is to place it last 430 in the ENO option, after all other suboptions. As an example, in 431 Figure 2, the last suboption, "Opt_i", has suboption data and thus 432 requires "v = 1"; however, the suboption data length is inferred from 433 the total length of the TCP option. 435 When a suboption with data is not last in an ENO option, the sender 436 MUST explicitly specify the suboption data length for the receiver to 437 know where the next suboption starts. The sender does so by 438 preceding the suboption with a length byte, depicted in Figure 6. 439 The length byte encodes a 5-bit value "nnnnn". Adding one to "nnnnn" 440 yields the length of the suboption data (not including the length 441 byte or the TEP identifier). Hence, a length byte can designate 442 anywhere from 1 to 32 bytes of suboption data (inclusive). 444 bit 7 6 5 4 3 2 1 0 445 +---+---+---+-------------------+ 446 | 1 0 0 nnnnn | 447 +---+---+---+-------------------+ 449 nnnnn - 5-bit value encoding (length - 1) 451 Figure 6: Format of a length byte 453 A suboption preceded by a length byte MUST be a TEP identifier ("glt 454 >= 0x20") and MUST have "v = 1". Figure 7 shows an example of such a 455 suboption. 457 byte 0 1 2 nnnnn+2 (nnnnn+3 bytes total) 458 +------+------+-------...-------+ 459 |length| TEP | suboption data | 460 | byte |ident.| (nnnnn+1 bytes) | 461 +------+------+-------...-------+ 463 length byte - specifies nnnnn 464 TEP identifier - MUST have v = 1 and glt >= 0x20 465 suboption data - length specified by nnnnn+1 467 Figure 7: Suboption with length byte 469 A host MUST ignore an ENO option in a SYN segment and MUST disable 470 encryption if either: 472 1. A length byte indicates that suboption data would extend beyond 473 the end of the TCP ENO option, or 475 2. A length byte is followed by an octet in the range 0x00-0x9f 476 (meaning the following byte has "v = 0" or "glt < 0x20"). 478 Because the last suboption in an ENO option is special-cased to have 479 its length inferred from the 8-bit TCP option length, it MAY contain 480 more than 32 bytes of suboption data. Other suboptions are limited 481 to 32 bytes by the length byte format. The TCP header itself can 482 only accommodate a maximum of 40 bytes of options, however. Hence, 483 regardless of the length byte format, a segment would not be able to 484 contain more than one suboption over 32 bytes in size. That said, 485 TEPs MAY define the use of multiple suboptions with the same TEP 486 identifier in the same SYN segment, providing another way to convey 487 over 32 bytes of suboption data even with length bytes. 489 4.5. The Negotiated TEP 491 A TEP identifier "glt" (with "glt >= 0x20") is _valid_ for a 492 connection when: 494 1. Each side has sent a suboption for "glt" in its SYN-form ENO 495 option, 497 2. Any suboption data in these "glt" suboptions is valid according 498 to the TEP specification and satisfies any runtime constraints, 499 and 501 3. If an ENO option contains multiple suboptions with "glt", then 502 such repetition is well-defined by the TEP specification. 504 A passive opener (which is always host B) sees the remote host's SYN 505 segment before constructing its own SYN-ACK segment. Hence, a 506 passive opener SHOULD include only one TEP identifier in SYN-ACK 507 segments and SHOULD ensure this TEP identifier is valid. However, 508 simultaneous open or implementation considerations can prevent host B 509 from offering only one TEP. 511 To accommodate scenarios in which host B sends multiple TEP 512 identifiers in the SYN-ACK segment, the _negotiated TEP_ is defined 513 as the last valid TEP identifier in host B's SYN-form ENO option. 514 This definition means host B specifies TEP suboptions in order of 515 increasing priority, while host A does not influence TEP priority. 517 4.6. TCP-ENO Handshake 519 A host employing TCP-ENO for a connection MUST include an ENO option 520 in every TCP segment sent until either encryption is disabled or the 521 host receives a non-SYN segment. In particular, this means an active 522 opener MUST include a non-SYN-form ENO option in the third segment of 523 a three-way handshake. 525 A host MUST disable encryption, refrain from sending any further ENO 526 options, and fall back to unencrypted TCP if any of the following 527 occurs: 529 1. Any segment it receives up to and including the first received 530 ACK segment does not contain a ENO option (or contains an ill- 531 formed SYN-form ENO option), 533 2. The SYN segment it receives does not contain a valid TEP 534 identifier, or 536 3. It receives a SYN segment with an incompatible global suboption. 537 (Specifically, incompatible means the two hosts set the same "b" 538 value or the connection is in mandatory application-aware mode 539 and the remote host set "a = 0".) 541 Hosts MUST NOT alter SYN-form ENO options in retransmitted segments, 542 or between the SYN and SYN-ACK segments of a simultaneous open, with 543 two exceptions for an active opener. First, an active opener MAY 544 unilaterally disable ENO (and thus remove the ENO option) between 545 retransmissions of a SYN-only segment. (Such removal could enable 546 recovery from middleboxes dropping segments with ENO options.) 547 Second, an active opener performing simultaneous open MAY include no 548 TCP-ENO option in its SYN-ACK if the received SYN caused it to 549 disable encryption according to the above rules (for instance because 550 role negotiation failed). 552 Once a host has both sent and received an ACK segment containing an 553 ENO option, encryption MUST be enabled. Once encryption is enabled, 554 hosts MUST follow the specification of the negotiated TEP and MUST 555 NOT present raw TCP payload data to the application. In particular, 556 data segments MUST NOT contain plaintext application data, but rather 557 ciphertext, key negotiation parameters, or other messages as 558 determined by the negotiated TEP. 560 A host MAY send a SYN-form ENO option containing zero TEP identifier 561 suboptions, which we term a _vacuous_ SYN-form ENO option. If either 562 host sends a vacuous ENO option, it follows that there are no valid 563 TEP identifiers for the connection and hence the connection MUST fall 564 back to unencrypted TCP. Hosts MAY send vacuous ENO options to 565 indicate that ENO is supported but unavailable by configuration, or 566 to probe network paths for robustness to ENO options. However, a 567 passive opener MUST NOT send a vacuous ENO option in a SYN-ACK 568 segment unless there was an ENO option in the SYN segment it 569 received. Moreover, a passive opener's SYN-form ENO option MUST 570 still include a global suboption with "b = 1", as discussed in 571 Section 4.3. 573 4.7. Data in SYN Segments 575 TEPs MAY specify the use of data in SYN segments so as to reduce the 576 number of round trips required for connection setup. The meaning of 577 data in a SYN segment with an ENO option (a SYN+ENO segment) is 578 determined by the last TEP identifier in the ENO option, which we 579 term the segment's _SYN TEP_. 581 A host sending a SYN+ENO segment MUST NOT include data in the segment 582 unless the SYN TEP's specification defines the use of such data. 583 Furthermore, to avoid conflicting interpretations of SYN data, a 584 SYN+ENO segment MUST NOT include a non-empty TCP Fast Open (TFO) 585 option [RFC7413]. 587 Because a host can send SYN data before knowing which if any TEP will 588 govern a connection, hosts implementing ENO are REQUIRED to discard 589 data from SYN+ENO segments when the SYN TEP does not govern the 590 connection or when there is any ambiguity over the meaning of the SYN 591 data. This requirement applies to hosts that implement ENO even when 592 ENO has been disabled by configuration. However, note that 593 discarding SYN data is already common practice [RFC4987] and the new 594 requirement applies only to segments containing ENO options. 596 More specifically, a host that implements ENO MUST discard the data 597 in a received SYN+ENO segment if any of the following applies: 599 o ENO fails and TEP-indicated encryption is disabled for the 600 connection, 602 o The received segment's SYN TEP is not the negotiated TEP, 604 o The negotiated TEP does not define the use of SYN data, or 606 o The SYN segment contains a non-empty TFO option or any other TCP 607 option implying a conflicting definition of SYN data. 609 A host discarding SYN data in compliance with the above requirement 610 MUST NOT acknowledge the sequence number of the discarded data, but 611 rather MUST acknowledge the other host's initial sequence number as 612 if the received SYN segment contained no data. Furthermore, after 613 discarding SYN data, such a host MUST NOT assume the SYN data will be 614 identically retransmitted, and MUST process data only from non-SYN 615 segments. 617 If a host sends a SYN+ENO segment with data and receives 618 acknowledgment for the data, but the SYN TEP governing the data is 619 not the negotiated TEP (either because a different TEP was negotiated 620 or because ENO failed to negotiate encryption), then the host MUST 621 abort the TCP connection. Proceeding in any other fashion risks 622 misinterpreted SYN data. 624 If a host sends a SYN-only SYN+ENO segment bearing data and 625 subsequently receives a SYN-ACK segment without an ENO option, that 626 host MUST abort the connection even if the SYN-ACK segment does not 627 acknowledge the SYN data. The issue is that unacknowledged data may 628 nonetheless have been cached by the receiver; later retransmissions 629 intended to supersede this unacknowledged data could fail to do so if 630 the receiver gives precedence to the cached original data. 631 Implementations MAY provide an API call for a non-default mode in 632 which unacknowledged SYN data does not cause a connection abort, but 633 applications MUST use this mode only when a higher-layer integrity 634 check would anyway terminate a garbled connection. 636 To avoid unexpected connection aborts, ENO implementations MUST 637 disable the use of data in SYN-only segments by default. Such data 638 MAY be enabled by an API command. In particular, implementations MAY 639 provide a per-connection mandatory encryption mode that automatically 640 aborts a connection if ENO fails, and MAY enable SYN data in this 641 mode. 643 To satisfy the requirement of the previous paragraph, all TEPs SHOULD 644 support a normal mode of operation that avoids data in SYN-only 645 segments. An exception is TEPs intended to be disabled by default. 647 4.8. Negotiation Transcript 649 To defend against attacks on encryption negotiation itself, a TEP 650 MUST with high probability fail to establish a working connection 651 between two ENO-compliant hosts when SYN-form ENO options have been 652 altered in transit. (Of course, in the absence of endpoint 653 authentication, two compliant hosts can each still be connected to a 654 man-in-the-middle attacker.) To detect SYN-form ENO option 655 tampering, TEPs MUST reference a transcript of TCP-ENO's negotiation. 657 TCP-ENO defines its negotiation transcript as a packed data structure 658 consisting of two TCP-ENO options exactly as they appeared in the TCP 659 header (including the TCP option-kind and TCP option length byte as 660 illustrated in Figure 1). The transcript is constructed from the 661 following, in order: 663 1. The TCP-ENO option in host A's SYN segment, including the kind 664 and length bytes. 666 2. The TCP-ENO option in host B's SYN segment, including the kind 667 and length bytes. 669 Note that because the ENO options in the transcript contain length 670 bytes as specified by TCP, the transcript unambiguously delimits A's 671 and B's ENO options. 673 5. Requirements for TEPs 675 TCP-ENO affords TEP specifications a large amount of design 676 flexibility. However, to abstract TEP differences away from 677 applications requires fitting them all into a coherent framework. As 678 such, any TEP claiming an ENO TEP identifier MUST satisfy the 679 following normative list of properties. 681 o TEPs MUST protect TCP data streams with authenticated encryption. 682 (Note "authenticated encryption" designates the REQUIRED form 683 encryption algorithm [RFC5116]; it does not imply any actual 684 endpoint authentication.) 686 o TEPs MUST define a session ID whose value identifies the TCP 687 connection and, with overwhelming probability, is unique over all 688 time if either host correctly obeys the TEP. Section 5.1 689 describes the requirements of the session ID in more detail. 691 o TEPs MUST NOT permit the negotiation of any encryption algorithms 692 with significantly less than 128-bit security. 694 o TEPs MUST NOT allow the negotiation of null cipher suites, even 695 for debugging purposes. (Implementations MAY support debugging 696 modes that allow applications to extract their own session keys.) 698 o TEPs MUST NOT depend on long-lived secrets for data 699 confidentiality. Implementations SHOULD provide forward secrecy 700 soon after the close of a TCP connection, and SHOULD therefore 701 bound the delay between closing a connection and erasing any 702 relevant cryptographic secrets. (Exceptions to forward secrecy 703 are permissible only at the implementation level, and only in 704 response to hardware or architectural constraints--e.g., storage 705 that cannot be securely erased.) 707 o TEPs MUST protect and authenticate the end-of-file marker conveyed 708 by TCP's FIN flag. In particular, a receiver MUST with high 709 probability detect a FIN flag that was set or cleared in transit 710 and does not match the sender's intent. A TEP MAY discard a 711 segment with such a corrupted FIN bit, or may abort the connection 712 in response to such a segment. However, any such abort MUST raise 713 an error condition distinct from an authentic end-of-file 714 condition. 716 o TEPs MUST prevent corrupted packets from causing urgent data to be 717 delivered when none has been sent. A TEP MAY do so by 718 cryptographically protecting the URG flag and urgent pointer 719 alongside ordinary payload data. Alternatively, a TEP MAY disable 720 urgent data functionality by clearing the URG flag on all received 721 segments and returning errors in response to sender-side urgent- 722 data API calls. Implementations SHOULD avoid negotiating TEPs 723 that disable urgent data by default. The exception is when 724 applications and protocols are known never to send urgent data. 726 5.1. Session IDs 728 Each TEP MUST define a session ID that is computable by both 729 endpoints and uniquely identifies each encrypted TCP connection. 730 Implementations MUST expose the session ID to applications via an API 731 extension. The API extension MUST return an error when no session ID 732 is available because ENO has failed to negotiate encryption or 733 because no connection is yet established. Applications that are 734 aware of TCP-ENO SHOULD, when practical, authenticate the TCP 735 endpoints by incorporating the values of the session ID and TCP-ENO 736 role (A or B) into higher-layer authentication mechanisms. 738 In order to avoid replay attacks and prevent authenticated session 739 IDs from being used out of context, session IDs MUST be unique over 740 all time with high probability. This uniqueness property MUST hold 741 even if one end of a connection maliciously manipulates the protocol 742 in an effort to create duplicate session IDs. In other words, it 743 MUST be infeasible for a host, even by violating the TEP 744 specification, to establish two TCP connections with the same session 745 ID to remote hosts properly implementing the TEP. 747 To prevent session IDs from being confused across TEPs, all session 748 IDs begin with the negotiated TEP identifier--that is, the last valid 749 TEP identifier in host B's SYN segment. Furthermore, this initial 750 byte has bit "v" set to the same value that accompanied the 751 negotiated TEP identifier in B's SYN segment. However, only this 752 single byte is included, not any suboption data. Figure 8 shows the 753 resulting format. This format is designed for TEPs to compute unique 754 identifiers; it is not intended for application authors to pick apart 755 session IDs. Applications SHOULD treat session IDs as monolithic 756 opaque values and SHOULD NOT discard the first byte to shorten 757 identifiers. (An exception is for non-security-relevant purposes, 758 such as gathering statistics about negotiated TEPs.) 760 byte 0 1 2 N-1 N 761 +-----+------------...------------+ 762 | sub-| collision-resistant hash | 763 | opt | of connection information | 764 +-----+------------...------------+ 766 Figure 8: Format of a session ID 768 Though TEP specifications retain considerable flexibility in their 769 definitions of the session ID, all session IDs MUST meet the 770 following normative list of requirements: 772 o The session ID MUST be at least 33 bytes (including the one-byte 773 suboption), though TEPs MAY choose longer session IDs. 775 o The session ID MUST depend in a collision-resistant way on all of 776 the following (meaning it is computationally infeasible to produce 777 collisions of the session ID derivation function unless all of the 778 following quantities are identical): 780 * Fresh data contributed by both sides of the connection, 782 * Any public keys, public Diffie-Hellman parameters, or other 783 public asymmetric cryptographic parameters that are employed by 784 the TEP and have corresponding private data that is known by 785 only one side of the connection, and 787 * The negotiation transcript specified in Section 4.8. 789 o Unless and until applications disclose information about the 790 session ID, all but the first byte MUST be computationally 791 indistinguishable from random bytes to a network eavesdropper. 793 o Applications MAY choose to make session IDs public. Therefore, 794 TEPs MUST NOT place any confidential data in the session ID (such 795 as data permitting the derivation of session keys). 797 6. Examples 799 This subsection illustrates the TCP-ENO handshake with a few non- 800 normative examples. 802 (1) A -> B: SYN ENO 803 (2) B -> A: SYN-ACK ENO 804 (3) A -> B: ACK ENO<> 805 [rest of connection encrypted according to TEP Y] 807 Figure 9: Three-way handshake with successful TCP-ENO negotiation 809 Figure 9 shows a three-way handshake with a successful TCP-ENO 810 negotiation. Host A includes two ENO suboptions with TEP identifiers 811 X and Y. The two sides agree to follow the TEP identified by 812 suboption Y. 814 (1) A -> B: SYN ENO 815 (2) B -> A: SYN-ACK 816 (3) A -> B: ACK 817 [rest of connection unencrypted legacy TCP] 819 Figure 10: Three-way handshake with failed TCP-ENO negotiation 821 Figure 10 shows a failed TCP-ENO negotiation. The active opener (A) 822 indicates support for TEPs corresponding to suboptions X and Y. 823 Unfortunately, at this point one of several things occurs: 825 1. The passive opener (B) does not support TCP-ENO, 827 2. B supports TCP-ENO, but supports neither of TEPs X and Y, and so 828 does not reply with an ENO option, 830 3. B supports TCP-ENO, but has the connection configured in 831 mandatory application-aware mode and thus disables ENO because 832 A's SYN segment does not set the application-aware bit, or 834 4. The network stripped the ENO option out of A's SYN segment, so B 835 did not receive it. 837 Whichever of the above applies, the connection transparently falls 838 back to unencrypted TCP. 840 (1) A -> B: SYN ENO 841 (2) B -> A: SYN-ACK ENO [ENO stripped by middlebox] 842 (3) A -> B: ACK 843 [rest of connection unencrypted legacy TCP] 845 Figure 11: Failed TCP-ENO negotiation because of option stripping 847 Figure 11 Shows another handshake with a failed encryption 848 negotiation. In this case, the passive opener B receives an ENO 849 option from A and replies. However, the reverse network path from B 850 to A strips ENO options. Hence, A does not receive an ENO option 851 from B, disables ENO, and does not include a non-SYN-form ENO option 852 in segment 3 when ACKing B's SYN. Had A not disabled encryption, 853 Section 4.6 would have required it to include a non-SYN ENO option in 854 segment 3. The omission of this option informs B that encryption 855 negotiation has failed, after which the two hosts proceed with 856 unencrypted TCP. 858 (1) A -> B: SYN ENO 859 (2) B -> A: SYN ENO 860 (3) A -> B: SYN-ACK ENO 861 (4) B -> A: SYN-ACK ENO 862 [rest of connection encrypted according to TEP Y] 864 Figure 12: Simultaneous open with successful TCP-ENO negotiation 866 Figure 12 shows a successful TCP-ENO negotiation with simultaneous 867 open. Here the first four segments contain a SYN-form ENO option, as 868 each side sends both a SYN-only and a SYN-ACK segment. The ENO 869 option in each host's SYN-ACK is identical to the ENO option in its 870 SYN-only segment, as otherwise connection establishment could not 871 recover from the loss of a SYN segment. The last valid TEP in host 872 B's ENO option is Y, so Y is the negotiated TEP. 874 7. Future Developments 876 TCP-ENO is designed to capitalize on future developments that could 877 alter trade-offs and change the best approach to TCP-level encryption 878 (beyond introducing new cipher suites). By way of example, we 879 discuss a few such possible developments. 881 Various proposals exist to increase the maximum space for options in 882 the TCP header. These proposals are highly experimental-- 883 particularly those that apply to SYN segments. Hence, future TEPs 884 are unlikely to benefit from extended SYN option space. In the 885 unlikely event that SYN option space is one day extended, however, 886 future TEPs could benefit by embedding key agreement messages 887 directly in SYN segments. Under such usage, the 32-byte limit on 888 length bytes could prove insufficient. This draft intentionally 889 aborts TCP-ENO if a length byte is followed by an octet in the range 890 0x00-0x9f. If necessary, a future update to this document can define 891 a format for larger suboptions by assigning meaning to such currently 892 undefined byte sequences. 894 New revisions to socket interfaces [RFC3493] could involve library 895 calls that simultaneously have access to hostname information and an 896 underlying TCP connection. Such an API enables the possibility of 897 authenticating servers transparently to the application, particularly 898 in conjunction with technologies such as DANE [RFC6394]. An update 899 to TCP-ENO can adopt one of the "z" bits in the global suboption to 900 negotiate the use of an endpoint authentication protocol before any 901 application use of the TCP connection. Over time, the consequences 902 of failed or missing endpoint authentication can gradually be 903 increased from issuing log messages to aborting the connection if 904 some as yet unspecified DNS record indicates authentication is 905 mandatory. Through shared library updates, such endpoint 906 authentication can potentially be added transparently to legacy 907 applications without recompilation. 909 TLS can currently only be added to legacy applications whose 910 protocols accommodate a STARTTLS command or equivalent. TCP-ENO, 911 because it provides out-of-band signaling, opens the possibility of 912 future TLS revisions being generically applicable to any TCP 913 application. 915 8. Design Rationale 917 This section describes some of the design rationale behind TCP-ENO. 919 8.1. Handshake Robustness 921 Incremental deployment of TCP-ENO depends critically on failure cases 922 devolving to unencrypted TCP rather than causing the entire TCP 923 connection to fail. 925 Because a network path may drop ENO options in one direction only, a 926 host needs to know not just that the peer supports encryption, but 927 that the peer has received an ENO option. To this end, ENO disables 928 encryption unless it receives an ACK segment bearing an ENO option. 929 To stay robust in the face of dropped segments, hosts continue to 930 include non-SYN form ENO options in segments until such point as they 931 have received a non-SYN segment from the other side. 933 One particularly pernicious middlebox behavior found in the wild is 934 load balancers that echo unknown TCP options found in SYN segments 935 back to an active opener. The passive role bit "b" in global 936 suboptions ensures encryption will always be disabled under such 937 circumstances, as sending back a verbatim copy of an active opener's 938 SYN-form ENO option always causes role negotiation to fail. 940 8.2. Suboption Data 942 TEPs can employ suboption data for session caching, cipher suite 943 negotiation, or other purposes. However, TCP currently limits total 944 option space consumed by all options to only 40 bytes, making it 945 impractical to have many suboptions with data. For this reason, ENO 946 optimizes the case of a single suboption with data by inferring the 947 length of the last suboption from the TCP option length. Doing so 948 saves one byte. 950 8.3. Passive Role Bit 952 TCP-ENO, TEPs, and applications all have asymmetries that require an 953 unambiguous way to identify one of the two connection endpoints. As 954 an example, Section 4.8 specifies that host A's ENO option comes 955 before host B's in the negotiation transcript. As another example, 956 an application might need to authenticate one end of a TCP connection 957 with a digital signature. To ensure the signed message cannot not be 958 interpreted out of context to authenticate the other end, the signed 959 message would need to include both the session ID and the local role, 960 A or B. 962 A normal TCP three-way handshake involves one active and one passive 963 opener. This asymmetry is captured by the default configuration of 964 the "b" bit in the global suboption. With simultaneous open, both 965 hosts are active openers, so TCP-ENO requires that one host 966 explicitly configure "b = 1". An alternate design might 967 automatically break the symmetry to avoid this need for explicit 968 configuration. However, all such designs we considered either lacked 969 robustness or consumed precious bytes of SYN option space even in the 970 absence of simultaneous open. (One complicating factor is that TCP 971 does not know it is participating in a simultaneous open until after 972 it has sent a SYN segment. Moreover, with packet loss, one host 973 might never learn it has participated in a simultaneous open.) 975 8.4. Use of ENO Option Kind by TEPs 977 This draft does not specify the use of ENO options beyond the first 978 few segments of a connection. Moreover, it does not specify the 979 content of ENO options in non-SYN segments, only their presence. As 980 a result, any use of option-kind TBD after the SYN exchange does not 981 conflict with this document. Because, in addition, ENO guarantees at 982 most one negotiated TEP per connection, TEPs will not conflict with 983 one another or ENO if they use ENO's option-kind for out-of-band 984 signaling in non-SYN segments. 986 8.5. Unpredictability of Session IDs 988 Section 5.1 specifies that all but the first (TEP identifier) byte of 989 a session ID MUST be computationally indistinguishable from random 990 bytes to a network eavesdropper. This property is easy to ensure 991 under standard assumptions about cryptographic hash functions. Such 992 unpredictability helps security in a broad range of cases. For 993 example, it makes it possible for applications to use a session ID 994 from one connection to authenticate a session ID from another, 995 thereby tying the two connections together. If furthermore helps 996 ensure that TEPs do not trivially subvert the 33-byte minimum length 997 requirement for session IDs by padding shorter session IDs with 998 zeros. 1000 9. Experiments 1002 This document has experimental status because TCP-ENO's viability 1003 depends on middlebox behavior that can only be determined _a 1004 posteriori_. Specifically, we need to determine to what extent 1005 middleboxes will permit the use of TCP-ENO. Once TCP-ENO is 1006 deployed, we will be in a better position to gather data on two types 1007 of failure: 1009 1. Middleboxes downgrading TCP-ENO connections to unencrypted TCP. 1010 This can happen if middleboxes strip unknown TCP options or if 1011 they terminate TCP connections and relay data back and forth. 1013 2. Middleboxes causing TCP-ENO connections to fail completely. This 1014 can happen if middleboxes perform deep packet inspection and 1015 start dropping segments that unexpectedly contain ciphertext, or 1016 if middleboxes strip ENO options from non-SYN segments after 1017 allowing them in SYN segments. 1019 The first type of failure is tolerable since TCP-ENO is designed for 1020 incremental deployment anyway. The second type of failure is more 1021 problematic, and, if prevalent, will require the development of 1022 techniques to avoid and recover from such failures. 1024 10. Security Considerations 1026 An obvious use case for TCP-ENO is opportunistic encryption--that is, 1027 encrypting some connections, but only where supported and without any 1028 kind of endpoint authentication. Opportunistic encryption protects 1029 against undetectable large-scale eavesdropping. However, it does not 1030 protect against detectable large-scale eavesdropping (for instance, 1031 if ISPs terminate TCP connections and proxy them, or simply downgrade 1032 connections to unencrypted). Moreover, opportunistic encryption 1033 emphatically does not protect against targeted attacks that employ 1034 trivial spoofing to redirect a specific high-value connection to a 1035 man-in-the-middle attacker. 1037 Achieving stronger security with TCP-ENO requires verifying session 1038 IDs. Any application relying on ENO for communications security MUST 1039 incorporate session IDs into its endpoint authentication. By way of 1040 example, an authentication mechanism based on keyed digests (such as 1041 Digest Access Authentication [RFC7616]) can be extended to include 1042 the role and session ID in the input of the keyed digest. Higher- 1043 layer protocols MAY use the application-aware "a" bit to negotiate 1044 the inclusion of session IDs in authentication even when there is no 1045 in-band way to carry out such a negotiation. Because there is only 1046 one "a" bit, however, a protocol extension that specifies use of the 1047 "a" bit will likely require a built-in versioning or negotiation 1048 mechanism to accommodate crypto agility and future updates. 1050 Because TCP-ENO enables multiple different TEPs to coexist, security 1051 could potentially be only as strong as the weakest available TEP. In 1052 particular, if session IDs do not depend on the TCP-ENO transcript in 1053 a strong way, an attacker can undetectably tamper with ENO options to 1054 force negotiation of a deprecated and vulnerable TEP. To avoid such 1055 problems, TEPs MUST compute session IDs using only well-studied and 1056 conservative hash functions. That way, even if other parts of a TEP 1057 are vulnerable, it is still intractable for an attacker to induce 1058 identical session IDs at both ends after tampering with ENO contents 1059 in SYN segments. 1061 Implementations MUST NOT send ENO options unless they have access to 1062 an adequate source of randomness [RFC4086]. Without secret 1063 unpredictable data at both ends of a connection, it is impossible for 1064 TEPs to achieve confidentiality and forward secrecy. Because systems 1065 typically have very little entropy on bootup, implementations might 1066 need to disable TCP-ENO until after system initialization. 1068 With a regular three-way handshake (meaning no simultaneous open), 1069 the non-SYN form ENO option in an active opener's first ACK segment 1070 MAY contain N > 0 bytes of TEP-specific data, as shown in Figure 3. 1071 Such data is not part of the TCP-ENO negotiation transcript, and 1072 hence MUST be separately authenticated by the TEP. 1074 11. IANA Considerations 1076 [RFC-editor: please replace TBD in this section, in Section 4.1, and 1077 in Section 8.4 with the assigned option-kind number. Please also 1078 replace RFC-TBD with this document's final RFC number.] 1080 This document defines a new TCP option-kind for TCP-ENO, assigned a 1081 value of TBD from the TCP option space. This value is defined as: 1083 +------+--------+----------------------------------+-----------+ 1084 | Kind | Length | Meaning | Reference | 1085 +------+--------+----------------------------------+-----------+ 1086 | TBD | N | Encryption Negotiation (TCP-ENO) | [RFC-TBD] | 1087 +------+--------+----------------------------------+-----------+ 1089 TCP Option Kind Numbers 1091 Early implementations of TCP-ENO and a predecessor TCP encryption 1092 protocol made unauthorized use of TCP option-kind 69. 1094 [RFC-editor: please glue the following text to the previous paragraph 1095 iff TBD == 69, otherwise delete it.] These earlier uses of option 69 1096 are not compatible with TCP-ENO and could disable encryption or 1097 suffer complete connection failure when interoperating with TCP-ENO- 1098 compliant hosts. Hence, legacy use of option 69 MUST be disabled on 1099 hosts that cannot be upgraded to TCP-ENO. 1101 [RFC-editor: please glue this to the previous paragraph regardless of 1102 the value of TBD.] More recent implementations used experimental 1103 option 253 per [RFC6994] with 16-bit ExID 0x454E. Current and new 1104 implementations of TCP-ENO MUST use option TBD, while any legacy 1105 implementations MUST migrate to option TBD. Note in particular that 1106 Section 4.1 requires at most one SYN-form ENO option per segment, 1107 which means hosts MUST NOT not include both option TBD and option 253 1108 with ExID 0x454E in the same TCP segment. 1110 [IANA is also requested to update the entry for TCP-ENO in the TCP 1111 Experimental Option Experiment Identifiers (TCP ExIDs) sub-registry 1112 to reflect the guidance of the previous paragraph by adding a note 1113 saying "current and new implementations MUST use option TDB." RFC- 1114 editor: please remove this comment.] 1116 This document defines a 7-bit "glt" field in the range of 0x20-0x7f, 1117 for which IANA is to create and maintain a new registry entitled "TCP 1118 encryption protocol identifiers" under the "Transmission Control 1119 Protocol (TCP) Parameters" registry. The initial contents of the TCP 1120 encryption protocol identifier registry is shown in Table 2, 1121 reflecting that this document reserves one TEP identifier for 1122 experimental use. Subsequent assignments are to be made under the 1123 "RFC Required" policy detailed in [RFC8126], relying on early 1124 allocation [RFC7120] to facilitate testing before an RFC is 1125 finalized. 1127 +-------+------------------+-----------+ 1128 | Value | Meaning | Reference | 1129 +-------+------------------+-----------+ 1130 | 0x20 | Experimental Use | [RFC-TBD] | 1131 +-------+------------------+-----------+ 1133 Table 2: TCP encryption protocol identifiers 1135 12. Acknowledgments 1137 We are grateful for contributions, help, discussions, and feedback 1138 from the IETF and its TCPINC working group, including Marcelo 1139 Bagnulo, David Black, Bob Briscoe, Spencer Dawkins, Jake Holland, 1140 Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Watson Ladd, Yoav Nir, 1141 Christoph Paasch, Eric Rescorla, Kyle Rose, Michael Scharf, and Joe 1142 Touch. This work was partially funded by DARPA CRASH and the 1143 Stanford Secure Internet of Things Project. 1145 13. Contributors 1147 Dan Boneh was a co-author of the draft that became this document. 1149 14. References 1151 14.1. Normative References 1153 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1154 RFC 793, DOI 10.17487/RFC0793, September 1981, 1155 . 1157 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1158 Requirement Levels", BCP 14, RFC 2119, 1159 DOI 10.17487/RFC2119, March 1997, 1160 . 1162 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1163 "Randomness Requirements for Security", BCP 106, RFC 4086, 1164 DOI 10.17487/RFC4086, June 2005, 1165 . 1167 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 1168 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 1169 2014, . 1171 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1172 Writing an IANA Considerations Section in RFCs", BCP 26, 1173 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1174 . 1176 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1177 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1178 May 2017, . 1180 14.2. Informative References 1182 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1183 Stevens, "Basic Socket Interface Extensions for IPv6", 1184 RFC 3493, DOI 10.17487/RFC3493, February 2003, 1185 . 1187 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1188 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1189 . 1191 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1192 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1193 . 1195 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 1196 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1197 RFC 5382, DOI 10.17487/RFC5382, October 2008, 1198 . 1200 [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based 1201 Authentication of Named Entities (DANE)", RFC 6394, 1202 DOI 10.17487/RFC6394, October 2011, 1203 . 1205 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 1206 RFC 6994, DOI 10.17487/RFC6994, August 2013, 1207 . 1209 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1210 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1211 . 1213 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 1214 Digest Access Authentication", RFC 7616, 1215 DOI 10.17487/RFC7616, September 2015, 1216 . 1218 Authors' Addresses 1220 Andrea Bittau 1221 Google 1222 345 Spear Street 1223 San Francisco, CA 94105 1224 US 1226 Email: bittau@google.com 1227 Daniel B. Giffin 1228 Stanford University 1229 353 Serra Mall, Room 288 1230 Stanford, CA 94305 1231 US 1233 Email: dbg@scs.stanford.edu 1235 Mark Handley 1236 University College London 1237 Gower St. 1238 London WC1E 6BT 1239 UK 1241 Email: M.Handley@cs.ucl.ac.uk 1243 David Mazieres 1244 Stanford University 1245 353 Serra Mall, Room 290 1246 Stanford, CA 94305 1247 US 1249 Email: dm@uun.org 1251 Eric W. Smith 1252 Kestrel Institute 1253 3260 Hillview Avenue 1254 Palo Alto, CA 94304 1255 US 1257 Email: eric.smith@kestrel.edu