idnits 2.17.1 draft-ietf-tcpinc-tcpeno-08.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5246]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2017) is 2608 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC-TBD' is mentioned on line 1070, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-15) exists of draft-ietf-tcpinc-tcpcrypt-05 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 3 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: September 8, 2017 Stanford University 6 M. Handley 7 University College London 8 D. Mazieres 9 Stanford University 10 E. Smith 11 Kestrel Institute 12 March 7, 2017 14 TCP-ENO: Encryption Negotiation Option 15 draft-ietf-tcpinc-tcpeno-08 17 Abstract 19 Despite growing adoption of TLS [RFC5246], a significant fraction of 20 TCP 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 http://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 September 8, 2017. 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. TCP-ENO specification . . . . . . . . . . . . . . . . . . . . 5 70 4.1. ENO option . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. The global suboption . . . . . . . . . . . . . . . . . . 9 72 4.3. TCP-ENO roles . . . . . . . . . . . . . . . . . . . . . . 10 73 4.4. Specifying suboption data length . . . . . . . . . . . . 10 74 4.5. The negotiated TEP . . . . . . . . . . . . . . . . . . . 12 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. Design rationale . . . . . . . . . . . . . . . . . . . . . . 19 82 7.1. Future developments . . . . . . . . . . . . . . . . . . . 19 83 7.2. Handshake robustness . . . . . . . . . . . . . . . . . . 20 84 7.3. Suboption data . . . . . . . . . . . . . . . . . . . . . 21 85 7.4. Passive role bit . . . . . . . . . . . . . . . . . . . . 21 86 7.5. Use of ENO option kind by TEPs . . . . . . . . . . . . . 21 87 8. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 9. Security considerations . . . . . . . . . . . . . . . . . . . 22 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 90 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 91 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 94 13.2. Informative References . . . . . . . . . . . . . . . . . 26 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 97 1. Requirements language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Introduction 105 Many applications and protocols running on top of TCP today do not 106 encrypt traffic. This failure to encrypt lowers the bar for certain 107 attacks, harming both user privacy and system security. 108 Counteracting the problem demands a minimally intrusive, backward- 109 compatible mechanism for incrementally deploying encryption. The TCP 110 Encryption Negotiation Option (TCP-ENO) specified in this document 111 provides such a mechanism. 113 Introducing TCP options, extending operating system interfaces to 114 support TCP-level encryption, and extending applications to take 115 advantage of TCP-level encryption all require effort. To the 116 greatest extent possible, the effort invested in realizing TCP-level 117 encryption today needs to remain applicable in the future should the 118 need arise to change encryption strategies. To this end, it is 119 useful to consider two questions separately: 121 1. How to negotiate the use of encryption at the TCP layer, and 123 2. How to perform encryption at the TCP layer. 125 This document addresses question 1 with a new TCP option, ENO. TCP- 126 ENO provides a framework in which two endpoints can agree on one 127 among multiple possible TCP encryption protocols or _TEPs_. For 128 future compatibility, TEPs can vary widely in terms of wire format, 129 use of TCP option space, and integration with the TCP header and 130 segmentation. However, ENO abstracts these differences to ensure the 131 introduction of new TEPs can be transparent to applications taking 132 advantage of TCP-level encryption. 134 Question 2 is addressed by one or more companion TEP specification 135 documents. While current TEPs enable TCP-level traffic encryption 136 today, TCP-ENO ensures that the effort invested to deploy today's 137 TEPs will additionally benefit future ones. 139 2.1. Design goals 141 TCP-ENO was designed to achieve the following goals: 143 1. Enable endpoints to negotiate the use of a separately specified 144 TCP encryption protocol or _TEP_. 146 2. Transparently fall back to unencrypted TCP when not supported by 147 both endpoints. 149 3. Provide out-of-band signaling through which applications can 150 better take advantage of TCP-level encryption (for instance, by 151 improving authentication mechanisms in the presence of TCP-level 152 encryption). 154 4. Provide a standard negotiation transcript through which TEPs can 155 defend against tampering with TCP-ENO. 157 5. Make parsimonious use of TCP option space. 159 6. Define roles for the two ends of a TCP connection, so as to name 160 each end of a connection for encryption or authentication 161 purposes even following a symmetric simultaneous open. 163 3. Terminology 165 We define the following terms, which are used throughout this 166 document: 168 SYN segment 169 A TCP segment in which the SYN flag is set 171 ACK segment 172 A TCP segment in which the ACK flag is set (which includes most 173 segments other than an initial SYN segment) 175 non-SYN segment 176 A TCP segment in which the SYN flag is clear 178 SYN-only segment 179 A TCP segment in which the SYN flag is set but the ACK flag is 180 clear 182 SYN-ACK segment 183 A TCP segment in which the SYN and ACK flags are both set 185 Active opener 186 A host that initiates a connection by sending a SYN-only segment. 187 With the BSD socket API, an active opener calls "connect". In 188 client-server configurations, active openers are typically 189 clients. 191 Passive opener 192 A host that does not send a SYN-only segment, but responds to one 193 with a SYN-ACK segment. With the BSD socket API, passive openers 194 call "listen" and "accept", rather than "connect". In client- 195 server configurations, passive openers are typically servers. 197 Simultaneous open 198 The act of symmetrically establishing a TCP connection between two 199 active openers (both of which call "connect" with BSD sockets). 200 Each host of a simultaneous open sends both a SYN-only and a SYN- 201 ACK segment. Simultaneous open is less common than asymmetric 202 open with one active and one passive opener, but can be used for 203 NAT traversal by peer-to-peer applications [RFC5382]. 205 TEP 206 A TCP encryption protocol intended for use with TCP-ENO and 207 specified in a separate document. 209 TEP identifier 210 A unique 7-bit value in the range 0x20-0x7f that IANA has assigned 211 to a TEP. 213 Negotiated TEP 214 The single TEP governing a TCP connection, determined by use of 215 the TCP ENO option specified in this document. 217 4. TCP-ENO specification 219 TCP-ENO extends TCP connection establishment to enable encryption 220 opportunistically. It uses a new TCP option kind to negotiate one 221 among multiple possible TCP encryption protocols or TEPs. The 222 negotiation involves hosts exchanging sets of supported TEPs, where 223 each TEP is represented by a _suboption_ within a larger TCP ENO 224 option in the offering host's SYN segment. 226 If TCP-ENO succeeds, it yields the following information: 228 o A negotiated TEP, represented by a unique 7-bit TEP identifier, 230 o A few extra bytes of suboption data from each host, if needed by 231 the TEP, 233 o A negotiation transcript with which to mitigate attacks on the 234 negotiation itself, 236 o Role assignments designating one endpoint "host A" and the other 237 endpoint "host B", and 239 o A bit available to higher-layer protocols at each endpoint for 240 out-of-band negotiation of updated behavior in the presence of TCP 241 encryption. 243 If TCP-ENO fails, encryption is disabled and the connection falls 244 back to traditional unencrypted TCP. 246 The remainder of this section provides the normative description of 247 the TCP ENO option and handshake protocol. 249 4.1. ENO option 251 TCP-ENO employs an option in the TCP header [RFC0793]. There are two 252 equivalent kinds of ENO option, shown in Figure 1. Section 10 253 specifies which of the two kinds is permissible and/or preferred. 255 byte 0 1 2 N+1 (N+2 bytes total) 256 +-----+-----+-----+--....--+-----+ 257 |Kind=|Len= | | 258 | TBD | N+2 | contents (N bytes) | 259 +-----+-----+-----+--....--+-----+ 261 byte 0 1 2 3 4 N+3 (N+4 bytes total) 262 +-----+-----+-----+-----+-----+--....--+-----+ 263 |Kind=|Len= | ExID | | 264 | 253 | N+4 | 69 | 78 | contents (N bytes) | 265 +-----+-----+-----+-----+-----+--....--+-----+ 267 Figure 1: Two equivalent kinds of 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 byte 0 1 2 3 4 5 ... N+3 287 +-----+-----+-----+-----+-----+-----+--...--+-----+----...----+ 288 |Kind=|Len= | ExID |Opt_0|Opt_1| |Opt_i| Opt_i | 289 | 253 | N+4 | 69 | 78 | | | | | data | 290 +-----+-----+-----+-----+-----+-----+--...--+-----+----...----+ 292 Figure 2: SYN form of ENO 294 byte 0 1 2 N+1 295 +-----+-----+-----...----+ 296 |Kind=|Len= | ignored | 297 | TBD | N+2 | by TCP-ENO | 298 +-----+-----+-----...----+ 300 byte 0 1 2 3 4 N+3 301 +-----+-----+-----+-----+-----...----+ 302 |Kind=|Len= | ExID | ignored | 303 | 253 | N+4 | 69 | 78 | by TCP-ENO | 304 +-----+-----+-----+-----+-----...----+ 306 Figure 3: Non-SYN form of ENO, where N MAY be 0 308 Every suboption starts with a byte of the form illustrated in 309 Figure 4. The high bit "v", when set, introduces suboptions with 310 variable-length data. When "v = 0", the byte itself constitutes the 311 entirety of the suboption. The 7-bit value "glt" expresses one of: 313 o Global configuration data (discussed in Section 4.2), 315 o Suboption data length for the next suboption (discussed in 316 Section 4.4), or 318 o An offer to use a particular TEP defined in a separate TEP 319 specification document. 321 bit 7 6 5 4 3 2 1 0 322 +---+---+---+---+---+---+---+---+ 323 | v | glt | 324 +---+---+---+---+---+---+---+---+ 326 v - non-zero for use with variable-length suboption data 327 glt - Global suboption, Length, or TEP identifier 329 Figure 4: Format of initial suboption byte 331 Table 1 summarizes the meaning of initial suboption bytes. Values of 332 "glt" below 0x20 are used for global suboptions and length 333 information (the "gl" in "glt"), while those greater than or equal to 334 0x20 are TEP identifiers (the "t"). When "v = 0", the initial 335 suboption byte constitutes the entirety of the suboption and all 336 information is expressed by the 7-bit "glt" value, which can be 337 either a global suboption or a TEP identifier. When "v = 1", it 338 indicates a suboption with variable-length suboption data. Only TEP 339 identifiers may have suboption data, not global suboptions. Hence, 340 bytes with "v = 1" and "glt < 0x20" are not global suboptions but 341 rather length bytes governing the length of the next suboption (which 342 MUST be a TEP identifer). In the absence of a length byte, a TEP 343 identifier suboption with "v = 1" has suboption data extending to the 344 end of the TCP option. 346 +-----------+---+-------------------------------------------+ 347 | glt | v | Meaning | 348 +-----------+---+-------------------------------------------+ 349 | 0x00-0x1f | 0 | Global suboption (Section 4.2) | 350 | 0x00-0x1f | 1 | Length byte (Section 4.4) | 351 | 0x20-0x7f | 0 | TEP identifier without suboption data | 352 | 0x20-0x7f | 1 | TEP identifier followed by suboption data | 353 +-----------+---+-------------------------------------------+ 355 Table 1: Initial suboption byte values 357 A SYN segment MUST contain at most one TCP ENO option. If a SYN 358 segment contains more than one ENO option, the receiver MUST behave 359 as though the segment contained no ENO options and disable 360 encryption. A TEP MAY specify the use of multiple ENO options in a 361 non-SYN segment. For non-SYN segments, ENO itself only distinguishes 362 between the presence or absence of ENO options; multiple ENO options 363 are interpreted the same as one. 365 4.2. The global suboption 367 Suboptions 0x00-0x1f are used for global configuration that applies 368 regardless of the negotiated TEP. A TCP SYN segment MUST include at 369 most one ENO suboption in this range. A receiver MUST ignore all but 370 the first suboption in this range so as to anticipate updates to ENO 371 that assign new meaning to bits in subsequent global suboptions. The 372 value of a global suboption byte is interpreted as a bitmask, 373 illustrated in Figure 5. 375 bit 7 6 5 4 3 2 1 0 376 +---+---+---+---+---+---+---+---+ 377 | 0 | 0 | 0 |z1 |z2 |z3 | a | b | 378 +---+---+---+---+---+---+---+---+ 380 b - Passive role bit 381 a - Application-aware bit 382 z* - Zero bits (reserved for future use) 384 Figure 5: Format of the global suboption byte 386 The fields of the bitmask are interpreted as follows: 388 b 389 The passive role bit MUST be 1 for all passive openers. For 390 active openers, it MUST default to 0, but implementations MUST 391 provide an API through which an application can explicitly set "b 392 = 1" before initiating an active open. (Manual configuration of 393 "b" is necessary to enable encryption with a simultaneous open.) 395 a 396 Legacy applications can benefit from ENO-specific updates that 397 improve endpoint authentication or avoid double encryption. The 398 application-aware bit "a" is an out-of-band signal through which 399 higher-layer protocols can enable ENO-specific updates that would 400 otherwise not be backwards-compatible. Implementations MUST set 401 this bit to 0 by default, and MUST provide an API through which 402 applications can change the value of the bit as well as examine 403 the value of the bit sent by the remote host. Implementations 404 MUST furthermore support a _mandatory_ application-aware mode in 405 which TCP-ENO is automatically disabled if the remote host does 406 not set "a = 1". 408 z1, z2, z3 409 The "z" bits are reserved for future updates to TCP-ENO. They 410 MUST be set to zero in sent segments and MUST be ignored in 411 received segments. 413 A SYN segment without an explicit global suboption has an implicit 414 global suboption of 0x00. Because passive openers MUST always set "b 415 = 1", they cannot rely on this implicit 0x00 byte and MUST include an 416 explicit global suboption in their SYN-ACK segments. 418 4.3. TCP-ENO roles 420 TCP-ENO uses abstract roles to distinguish the two ends of a TCP 421 connection. These roles are determined by the "b" bit in the global 422 suboption. The host that sent an implicit or explicit suboption with 423 "b = 0" plays the "A" role. The host that sent "b = 1" plays the "B" 424 role. 426 If both sides of a connection set "b = 1" (which can happen if the 427 active opener misconfigures "b" before calling "connect"), or both 428 sides set "b = 0" (which can happen with simultaneous open), then 429 TCP-ENO MUST be disabled and the connection MUST fall back to 430 unencrypted TCP. 432 TEP specifications SHOULD refer to TCP-ENO's A and B roles to specify 433 asymmetric behavior by the two hosts. For the remainder of this 434 document, we will use the terms "host A" and "host B" to designate 435 the hosts with roles A and B, respectively, in a connection. 437 4.4. Specifying suboption data length 439 A TEP MAY optionally make use of one or more bytes of suboption data. 440 The presence of such data is indicated by setting "v = 1" in the 441 initial suboption byte (see Figure 4). By default, suboption data 442 extends to the end of the TCP option. Hence, if only one suboption 443 requires data, the most compact way to encode it is to place it last 444 in the ENO option, after all other suboptions. As an example, in 445 Figure 2, the last suboption, "Opt_i", has suboption data and thus 446 requires "v = 1"; however, the suboption data length is inferred from 447 the total length of the TCP option. 449 When a suboption with data is not last in an ENO option, the sender 450 MUST explicitly specify the suboption data length for the receiver to 451 know where the next suboption starts. The sender does so by 452 preceding the suboption with a length byte, depicted in Figure 6. 453 The length byte encodes a 5-bit value "nnnnn". Adding one to "nnnnn" 454 yields the length of the suboption data (not including the length 455 byte or the TEP identifier). Hence, a length byte can designate 456 anywhere from 1 to 32 bytes of suboption data (inclusive). 458 bit 7 6 5 4 3 2 1 0 459 +---+---+---+-------------------+ 460 | 1 0 0 nnnnn | 461 +---+---+---+-------------------+ 463 nnnnn - 5-bit value encoding (length - 1) 465 Figure 6: Format of a length byte 467 A suboption preceded by a length byte MUST be a TEP identifier ("glt 468 >= 0x20") and MUST have "v = 1". Figure 7 shows an example of such a 469 suboption. 471 byte 0 1 2 nnnnn+2 (nnnnn+3 bytes total) 472 +------+------+-------...-------+ 473 |length| TEP | suboption data | 474 | byte |ident.| (nnnnn+1 bytes) | 475 +------+------+-------...-------+ 477 length byte - specifies nnnnn 478 TEP identifier - MUST have v = 1 and glt >= 0x20 479 suboption data - length specified by nnnnn+1 481 Figure 7: Suboption with length byte 483 A host MUST ignore an ENO option in a SYN segment and MUST disable 484 encryption if either: 486 1. A length byte indicates that suboption data would extend beyond 487 the end of the TCP ENO option, or 489 2. A length byte is followed by an octet in the range 0x00-0x9f 490 (meaning the following byte has "v = 0" or "glt < 0x20"). 492 Because the last suboption in an ENO option is special-cased to have 493 its length inferred from the 8-bit TCP option length, it MAY contain 494 more than 32 bytes of suboption data. Other suboptions are limited 495 to 32 bytes by the length byte format. The TCP header itself can 496 only accommodate a maximum of 40 bytes of options, however. Hence, 497 regardless of the length byte format, a segment would not be able to 498 contain more than one suboption over 32 bytes in size. That said, 499 TEPs MAY define the use of multiple suboptions with the same TEP 500 identifier in the same SYN segment, providing another way to convey 501 over 32 bytes of suboption data even with length bytes. 503 4.5. The negotiated TEP 505 A TEP identifier "glt" (with "glt >= 0x20") is _valid_ for a 506 connection when: 508 1. Each side has sent a suboption for "glt" in its SYN-form ENO 509 option, 511 2. Any suboption data in these "glt" suboptions is valid according 512 to the TEP specification and satisfies any runtime constraints, 513 and 515 3. If an ENO option contains multiple suboptions with "glt", then 516 such repetition is well-defined by the TEP specification. 518 The _negotiated TEP_ is the last valid TEP identifier in host B's 519 SYN-form ENO option. This definition means host B specifies TEP 520 suboptions in order of increasing priority, while host A does not 521 influence TEP priority. 523 A passive opener (which is always host B) sees the remote host's SYN 524 segment before constructing its own SYN-ACK. Hence, a passive opener 525 SHOULD include only one TEP identifier in SYN-ACK segments and SHOULD 526 ensure this TEP identifier is valid. However, simultaneous open or 527 implementation considerations can prevent host B from offering only 528 one TEP. 530 4.6. TCP-ENO handshake 532 A host employing TCP-ENO for a connection MUST include an ENO option 533 in every TCP segment sent until either encryption is disabled or the 534 host receives a non-SYN segment. 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 _vacuous_ SYN-form ENO option containing zero TEP 572 identifier suboptions. If either host sends a vacuous ENO option, it 573 follows that there are no valid TEP identifiers for the connection 574 and hence the connection must fall back to unencrypted TCP. Hosts 575 MAY send vacuous ENO options to indicate that ENO is supported but 576 unavailable by configuration, or to probe network paths for 577 robustness to ENO options. However, a passive opener MUST NOT send a 578 vacuous ENO option in a SYN-ACK segment unless there was an ENO 579 option in the SYN segment it received. Moreover, a passive opener's 580 SYN-form ENO option MUST still include a global suboption with "b = 581 1", as discussed in Section 4.3. 583 4.7. Data in SYN segments 585 TEPs MAY specify the use of data in SYN segments so as to reduce the 586 number of round trips required for connection setup. The meaning of 587 data in a SYN segment with an ENO option (a SYN+ENO segment) is 588 determined by the last TEP identifier in the ENO option, which we 589 term the segment's _SYN TEP_. 591 A host sending a SYN+ENO segment MUST NOT include data in the segment 592 unless the SYN TEP's specification defines the use of such data. 593 Furthermore, to avoid conflicting interpretations of SYN data, a 594 SYN+ENO segment MUST NOT include a non-empty TCP Fast Open (TFO) 595 option [RFC7413]. 597 Because a host can send SYN data before knowing which if any TEP will 598 govern a connection, hosts implementing ENO are REQUIRED to discard 599 data from SYN+ENO segments when the SYN TEP does not govern the 600 connection or when there is any ambiguity over the meaning of the SYN 601 data. This requirement applies to hosts that implement ENO even when 602 ENO has been disabled by configuration. However, note that 603 discarding SYN data is already common practice [RFC4987] and the new 604 requirement applies only to segments containing ENO options. 606 More specifically, a host that implements ENO MUST discard the data 607 in a received SYN+ENO segment if any of the following applies: 609 o ENO fails and TEP-indicated encryption is disabled for the 610 connection, 612 o The received segment's SYN TEP is not the negotiated TEP, 614 o The negotiated TEP does not define the use of SYN data, or 616 o The SYN segment contains a non-empty TFO option or any other TCP 617 option implying a conflicting definition of SYN data. 619 A host discarding SYN data in compliance with the above requirement 620 MUST NOT acknowledge the sequence number of the discarded data, but 621 rather MUST acknowledge the other host's initial sequence number as 622 if the received SYN segment contained no data. Furthermore, after 623 discarding SYN data, such a host MUST NOT assume the SYN data will be 624 identically retransmitted, and MUST process data only from non-SYN 625 segments. 627 If a host sends a SYN+ENO segment with data and receives 628 acknowledgment for the data, but the SYN TEP governing the data is 629 not the negotiated TEP (either because a different TEP was negotiated 630 or because ENO failed to negotiate encryption), then the host MUST 631 abort the TCP connection. Proceeding in any other fashion risks 632 misinterpreted SYN data. 634 If a host sends a SYN-only SYN+ENO segment bearing data and 635 subsequently receives a SYN-ACK segment without an ENO option, that 636 host MUST abort the connection even if the SYN-ACK segment does not 637 acknowledge the SYN data. The issue is that unacknowledged data may 638 nonetheless have been cached by the receiver; later retransmissions 639 intended to supersede this unacknowledged data could fail to do so if 640 the receiver gives precedence to the cached original data. 641 Implementations MAY provide an API call for a non-default mode in 642 which unacknowledged SYN data does not cause a connection abort, but 643 applications MUST use this mode only when a higher-layer integrity 644 check would anyway terminate a garbled connection. 646 To avoid unexpected connection aborts, ENO implementations MUST 647 disable the use of data in SYN-only segments by default. Such data 648 MAY be enabled by an API command. In particular, implementations MAY 649 provide a per-connection mandatory encryption mode that automatically 650 aborts a connection if ENO fails, and MAY enable SYN data in this 651 mode. 653 To satisfy the requirement of the previous paragraph, all TEPs SHOULD 654 support a normal mode of operation that avoids data in SYN-only 655 segments. An exception is TEPs intended to be disabled by default. 657 4.8. Negotiation transcript 659 To defend against attacks on encryption negotiation itself, TEPs need 660 a way to reference a transcript of TCP-ENO's negotiation. In 661 particular, a TEP MUST with high probability fail to reach key 662 agreement between two honest endpoints if the TEP's selection 663 resulted from tampering with the contents of SYN-form ENO options. 664 (Of course, in the absence of endpoint authentication, two honest 665 endpoints can still each end up talking to a man-in-the-middle 666 attacker rather than to each other.) 668 TCP-ENO defines its negotiation transcript as a packed data structure 669 consisting of two TCP-ENO options exactly as they appeared in the TCP 670 header (including the TCP option kind, TCP option length byte, and, 671 for option kind 253, the bytes 69 and 78 as illustrated in Figure 1). 672 The transcript is constructed from the following, in order: 674 1. The TCP-ENO option in host A's SYN segment, including the kind 675 and length bytes. 677 2. The TCP-ENO option in host B's SYN segment, including the kind 678 and length bytes. 680 Note that because the ENO options in the transcript contain length 681 bytes as specified by TCP, the transcript unambiguously delimits A's 682 and B's ENO options. 684 5. Requirements for TEPs 686 TCP-ENO affords TEP specifications a large amount of design 687 flexibility. However, to abstract TEP differences away from 688 applications requires fitting them all into a coherent framework. As 689 such, any TEP claiming an ENO TEP identifier MUST satisfy the 690 following normative list of properties. 692 o TEPs MUST protect TCP data streams with authenticated encryption. 694 o TEPs MUST define a session ID whose value identifies the TCP 695 connection and, with overwhelming probability, is unique over all 696 time if either host correctly obeys the TEP. Section 5.1 697 describes the requirements of the session ID in more detail. 699 o TEPs MUST NOT permit the negotiation of any encryption algorithms 700 with significantly less than 128-bit security. 702 o TEPs MUST NOT allow the negotiation of null cipher suites, even 703 for debugging purposes. (Implementations MAY support debugging 704 modes that allow applications to extract their own session keys.) 706 o TEPs MUST NOT depend on long-lived secrets for data 707 confidentiality, as implementations SHOULD provide forward secrecy 708 some bounded, short time after the close of a TCP connection. 709 (Exceptions to forward secrecy are permissible only at the 710 implementation level, and only in response to hardware or 711 architectural constraints--e.g., storage that cannot be securely 712 erased.) 714 o TEPs MUST protect and authenticate the end-of-file marker conveyed 715 by TCP's FIN flag. In particular, a receiver MUST with high 716 probability detect a FIN flag that was set or cleared in transit 717 and does not match the sender's intent. A TEP MAY discard a 718 segment with such a corrupted FIN bit, or may abort the connection 719 in response to such a segment. However, any such abort MUST raise 720 an error condition distinct from an authentic end-of-file 721 condition. 723 o TEPs MUST prevent corrupted packets from causing urgent data to be 724 delivered when none has been sent. A TEP MAY do so by 725 cryptographically protecting the URG flag and urgent pointer 726 alongside ordinary payload data. Alternatively, a TEP MAY disable 727 urgent data functionality by clearing the URG flag on all received 728 segments and returning errors in response to sender-side urgent- 729 data API calls. Implementations SHOULD avoid negotiating TEPs 730 that disable urgent data by default. The exception is when 731 applications and protocols are known never to send urgent data. 733 5.1. Session IDs 735 Each TEP MUST define a session ID that is computable by both 736 endpoints and uniquely identifies each encrypted TCP connection. 737 Implementations MUST expose the session ID to applications via an API 738 extension. The API extension MUST return an error when no session ID 739 is available because ENO has failed to negotiate encryption or 740 because no connection is yet established. Applications that are 741 aware of TCP-ENO SHOULD, when practical, authenticate the TCP 742 endpoints by incorporating the values of the session ID and TCP-ENO 743 role (A or B) into higher-layer authentication mechanisms. 745 In order to avoid replay attacks and prevent authenticated session 746 IDs from being used out of context, session IDs MUST be unique over 747 all time with high probability. This uniqueness property MUST hold 748 even if one end of a connection maliciously manipulates the protocol 749 in an effort to create duplicate session IDs. In other words, it 750 MUST be infeasible for a host, even by violating the TEP 751 specification, to establish two TCP connections with the same session 752 ID to remote hosts properly implementing the TEP. 754 To prevent session IDs from being confused across TEPs, all session 755 IDs begin with the negotiated TEP identifier--that is, the last valid 756 TEP identifier in host B's SYN segment. Futhermore, this initial 757 byte has bit "v" set to the same value that accompanied the 758 negotiated TEP identifier in B's SYN segment. However, only this 759 single byte is included, not any suboption data. Figure 8 shows the 760 resulting format. This format is designed for TEPs to compute unique 761 identifiers; it is not intended for application authors to pick apart 762 session IDs. Applications SHOULD treat session IDs as monolithic 763 opaque values and SHOULD NOT discard the first byte to shorten 764 identifiers. (An exception is for non-security-relevant purposes, 765 such as gathering statistics about negotiated TEPs.) 767 byte 0 1 2 N-1 N 768 +-----+------------...------------+ 769 | sub-| collision-resistant hash | 770 | opt | of connection information | 771 +-----+------------...------------+ 773 Figure 8: Format of a session ID 775 Though TEP specifications retain considerable flexibility in their 776 definitions of the session ID, all session IDs MUST meet the 777 following normative list of requirements: 779 o The session ID MUST be at least 33 bytes (including the one-byte 780 suboption), though TEPs MAY choose longer session IDs. 782 o The session ID MUST depend in a collision-resistant way on all of 783 the following (meaning it is computationally infeasible to produce 784 collisions of the session ID derivation function unless all of the 785 following quantities are identical): 787 * Fresh data contributed by both sides of the connection, 789 * Any public keys, public Diffie-Hellman parameters, or other 790 public asymmetric cryptographic parameters that are employed by 791 the TEP and have corresponding private data that is known by 792 only one side of the connection, and 794 * The negotiation transcript specified in Section 4.8. 796 o Unless and until applications disclose information about the 797 session ID, all but the first byte MUST be computationally 798 indistinguishable from random bytes to a network eavesdropper. 800 o Applications MAY choose to make session IDs public. Therefore, 801 TEPs MUST NOT place any confidential data in the session ID (such 802 as data permitting the derivation of session keys). 804 6. Examples 806 This subsection illustrates the TCP-ENO handshake with a few non- 807 normative examples. 809 (1) A -> B: SYN ENO 810 (2) B -> A: SYN-ACK ENO 811 (3) A -> B: ACK ENO<> 812 [rest of connection encrypted according to TEP Y] 814 Figure 9: Three-way handshake with successful TCP-ENO negotiation 816 Figure 9 shows a three-way handshake with a successful TCP-ENO 817 negotiation. The two sides agree to follow the TEP identified by 818 suboption Y. 820 (1) A -> B: SYN ENO 821 (2) B -> A: SYN-ACK 822 (3) A -> B: ACK 823 [rest of connection unencrypted legacy TCP] 825 Figure 10: Three-way handshake with failed TCP-ENO negotiation 827 Figure 10 shows a failed TCP-ENO negotiation. The active opener (A) 828 indicates support for TEPs corresponding to suboptions X and Y. 829 Unfortunately, at this point one of several things occurs: 831 1. The passive opener (B) does not support TCP-ENO, 833 2. B supports TCP-ENO, but supports neither of TEPs X and Y, and so 834 does not reply with an ENO option, 836 3. B supports TCP-ENO, but has the connection configured in 837 mandatory application-aware mode and thus disables ENO because 838 A's SYN segment does not set the application-aware bit, or 840 4. The network stripped the ENO option out of A's SYN segment, so B 841 did not receive it. 843 Whichever of the above applies, the connection transparently falls 844 back to unencrypted TCP. 846 (1) A -> B: SYN ENO 847 (2) B -> A: SYN-ACK ENO [ENO stripped by middlebox] 848 (3) A -> B: ACK 849 [rest of connection unencrypted legacy TCP] 851 Figure 11: Failed TCP-ENO negotiation because of network filtering 853 Figure 11 Shows another handshake with a failed encryption 854 negotiation. In this case, the passive opener B receives an ENO 855 option from A and replies. However, the reverse network path from B 856 to A strips ENO options. Hence, A does not receive an ENO option 857 from B, disables ENO, and does not include a non-SYN-form ENO option 858 when ACKing B's SYN segment. The lack of ENO in A's ACK segment 859 signals to B that the connection will not be encrypted. At this 860 point, the two hosts proceed with an unencrypted TCP connection. 862 (1) A -> B: SYN ENO 863 (2) B -> A: SYN ENO 864 (3) A -> B: SYN-ACK ENO 865 (4) B -> A: SYN-ACK ENO 866 [rest of connection encrypted according to TEP Y] 868 Figure 12: Simultaneous open with successful TCP-ENO negotiation 870 Figure 12 shows a successful TCP-ENO negotiation with simultaneous 871 open. Here the first four segments MUST contain a SYN-form ENO 872 option, as each side sends both a SYN-only and a SYN-ACK segment. 873 The ENO option in each host's SYN-ACK is identical to the ENO option 874 in its SYN-only segment, as otherwise connection establishment could 875 not recover from the loss of a SYN segment. The last valid TEP in 876 host B's ENO option is Y, so Y is the negotiated TEP. 878 7. Design rationale 880 This section describes some of the design rationale behind TCP-ENO. 882 7.1. Future developments 884 TCP-ENO is designed to capitalize on future developments that could 885 alter trade-offs and change the best approach to TCP-level encryption 886 (beyond introducing new cipher suites). By way of example, we 887 discuss a few such possible developments. 889 Various proposals exist to increase the maximum space for options in 890 the TCP header. These proposals are highly experimental-- 891 particularly those that apply to SYN segments. Hence, future TEPs 892 are unlikely to to benefit from extended SYN option space. In the 893 unlikely event that SYN option space is one day extended, however, 894 future TEPs could benefit by embedding key agreement messages 895 directly in SYN segments. Under such usage, the 32-byte limit on 896 length bytes could prove insufficient. This draft intentionally 897 aborts TCP-ENO if a length byte is followed by an octet in the range 898 0x00-0x9f. If necessary, a future update to this document can define 899 a format for larger suboptions by assigning meaning to such currently 900 undefined byte sequences. 902 New revisions to socket interfaces [RFC3493] could involve library 903 calls that simultaneously have access to hostname information and an 904 underlying TCP connection. Such an API enables the possibility of 905 authenticating servers transparently to the application, particularly 906 in conjunction with technologies such as DANE [RFC6394]. An update 907 to TCP-ENO can adopt one of the "z" bits in the global suboption to 908 negotiate the use of an endpoint authentication protocol before any 909 application use of the TCP connection. Over time, the consequences 910 of failed or missing endpoint authentication can gradually be 911 increased from issuing log messages to aborting the connection if 912 some as yet unspecified DNS record indicates authentication is 913 mandatory. Through shared library updates, such endpoint 914 authentication can potentially be added transparently to legacy 915 applications without recompilation. 917 TLS can currently only be added to legacy applications whose 918 protocols accommodate a STARTTLS command or equivalent. TCP-ENO, 919 because it provides out-of-band signaling, opens the possibility of 920 future TLS revisions being generically applicable to any TCP 921 application. 923 7.2. Handshake robustness 925 Incremental deployment of TCP-ENO depends critically on failure cases 926 devolving to unencrypted TCP rather than causing the entire TCP 927 connection to fail. 929 Because a network path may drop ENO options in one direction only, a 930 host must know not just that the peer supports encryption, but that 931 the peer has received an ENO option. To this end, ENO disables 932 encryption unless it receives an ACK segment bearing an ENO option. 933 To stay robust in the face of dropped segments, hosts must continue 934 to include non-SYN form ENO options in segments until such point as 935 they have received a non-SYN segment from the other side. 937 One particularly pernicious middlebox behavior found in the wild is 938 load balancers that echo unknown TCP options found in SYN segments 939 back to an active opener. The passive role bit "b" in global 940 suboptions ensures encryption will always be disabled under such 941 circumstances, as sending back a verbatim copy of an active opener's 942 SYN-form ENO option always causes role negotiation to fail. 944 7.3. Suboption data 946 TEPs can employ suboption data for session caching, cipher suite 947 negotiation, or other purposes. However, TCP currently limits total 948 option space consumed by all options to only 40 bytes, making it 949 impractical to have many suboptions with data. For this reason, ENO 950 optimizes the case of a single suboption with data by inferring the 951 length of the last suboption from the TCP option length. Doing so 952 saves one byte. 954 7.4. Passive role bit 956 TCP-ENO, TEPs, and applications all have asymmetries that require an 957 unambiguous way to identify one of the two connection endpoints. As 958 an example, Section 4.8 specifies that host A's ENO option comes 959 before host B's in the negotiation transcript. As another example, 960 an application might need to authenticate one end of a TCP connection 961 with a digital signature. To ensure the signed message cannot not be 962 interpreted out of context to authenticate the other end, the signed 963 message would need to include both the session ID and the local role, 964 A or B. 966 A normal TCP three-way handshake involves one active and one passive 967 opener. This asymmetry is captured by the default configuration of 968 the "b" bit in the global suboption. With simultaneous open, both 969 hosts are active openers, so TCP-ENO requires that one host 970 explicitly configure "b = 1". An alternate design might 971 automatically break the symmetry to avoid this need for explicit 972 configuration. However, all such designs we considered either lacked 973 robustness or consumed precious bytes of SYN option space even in the 974 absence of simultaneous open. (One complicating factor is that TCP 975 does not know it is participating in a simultaneous open until after 976 it has sent a SYN segment. Moreover, with packet loss, one host 977 might never learn it has participated in a simultaneous open.) 979 7.5. Use of ENO option kind by TEPs 981 This draft does not specify the use of ENO options beyond the first 982 few segments of a connection. Moreover, it does not specify the 983 content of ENO options in non-SYN segments, only their presence. As 984 a result, any use of option kind TBD (or option kind 253 with ExID 985 0x454E) after the SYN exchange does not conflict with this document. 986 Because, in addition, ENO guarantees at most one negotiated TEP per 987 connection, TEPs will not conflict with one another or ENO if they 988 use ENO's option kind for out-of-band signaling in non-SYN segments. 990 8. Experiments 992 This document has experimental status because TCP-ENO's viability 993 depends on middlebox behavior that can only be determined _a 994 posteriori_. Specifically, we must determine to what extent 995 middleboxes will permit the use of TCP-ENO. Once TCP-ENO is 996 deployed, we will be in a better position to gather data on two types 997 of failure: 999 1. Middleboxes downgrading TCP-ENO connections to unencrypted TCP. 1000 This can happen if middleboxes strip unknown TCP options or if 1001 they terminate TCP connections and relay data back and forth. 1003 2. Middleboxes causing TCP-ENO connections to fail completely. This 1004 can happen if applications perform deep packet inspection and 1005 start dropping segments that unexpectedly contain ciphertext. 1007 The first type of failure is tolerable since TCP-ENO is designed for 1008 incremental deployment anyway. The second type of failure is more 1009 problematic, and, if prevalent, will require the development of 1010 techniques to avoid and recover from such failures. 1012 9. Security considerations 1014 An obvious use case for TCP-ENO is opportunistic encryption--that is, 1015 encrypting some connections, but only where supported and without any 1016 kind of endpoint authentication. Opportunistic encryption protects 1017 against undetectable large-scale eavesdropping. However, it does not 1018 protect against detectable large-scale eavesdropping (for instance, 1019 if ISPs terminate TCP connections and proxy them, or simply downgrade 1020 connections to unencrypted). Moreover, opportunistic encryption 1021 emphatically does not protect against targeted attacks that employ 1022 trivial spoofing to redirect a specific high-value connection to a 1023 man-in-the-middle attacker. 1025 Achieving stronger security with TCP-ENO requires verifying session 1026 IDs. Any application relying on ENO for communications security MUST 1027 incorporate session IDs into its endpoint authentication. By way of 1028 example, an authentication mechanism based on keyed digests (such as 1029 Digest Access Authentication [RFC7616]) can be extended to include 1030 the role and session ID in the input of the keyed digest. Higher- 1031 layer protocols MAY use the application-aware "a" bit to negotiate 1032 the inclusion of session IDs in authentication even when there is no 1033 in-band way to carry out such a negotiation. Because there is only 1034 one "a" bit, however, a protocol extension that specifies use of the 1035 "a" bit will likely require a built-in versioning or negotiation 1036 mechanism to accommodate crypto agility and future updates. 1038 Because TCP-ENO enables multiple different TEPs to coexist, security 1039 could potentially be only as strong as the weakest available TEP. In 1040 particular, if session IDs do not depend on the TCP-ENO transcript in 1041 a strong way, an attacker can undetectably tamper with ENO options to 1042 force negotiation of a deprecated and vulnerable TEP. To avoid such 1043 problems, TEPs MUST compute session IDs using only well-studied and 1044 conservative hash functions. That way, even if other parts of a TEP 1045 are vulnerable, it is still intractable for an attacker to induce 1046 identical session IDs at both ends after tampering with ENO contents 1047 in SYN segments. 1049 Implementations MUST NOT send ENO options unless they have access to 1050 an adequate source of randomness [RFC4086]. Without secret 1051 unpredictable data at both ends of a connection, it is impossible for 1052 TEPs to achieve confidentiality and forward secrecy. Because systems 1053 typically have very little entropy on bootup, implementations might 1054 need to disable TCP-ENO until after system initialization. 1056 With a regular three-way handshake (meaning no simultaneous open), 1057 the non-SYN form ENO option in an active opener's first ACK segment 1058 MAY contain N > 0 bytes of TEP-specific data, as shown in Figure 3. 1059 Such data is not part of the TCP-ENO negotiation transcript, and 1060 hence MUST be separately authenticated by the TEP. 1062 10. IANA Considerations 1064 This document defines a new TCP option kind for TCP-ENO, assigned a 1065 value of TBD from the TCP option space. This value is defined as: 1067 +------+--------+----------------------------------+-----------+ 1068 | Kind | Length | Meaning | Reference | 1069 +------+--------+----------------------------------+-----------+ 1070 | TBD | N | Encryption Negotiation (TCP-ENO) | [RFC-TBD] | 1071 +------+--------+----------------------------------+-----------+ 1073 TCP Option Kind Numbers 1075 Early implementations of TCP-ENO and a predecessor TCP encryption 1076 protocol made unauthorized use of TCP option kind 69. 1078 [RFC-editor: please glue the following text to the previous paragraph 1079 iff TBD == 69, otherwise delete it.] These earlier uses of option 69 1080 are not compatible with TCP-ENO and could disable encryption or 1081 suffer complete connection failure when interoperating with TCP-ENO- 1082 compliant hosts. Hence, legacy use of option 69 MUST be disabled on 1083 hosts that cannot be upgraded to TCP-ENO. 1085 [RFC-editor: please glue this to the previous paragraph regardless of 1086 the value of TBD.] More recent implementations used experimental 1087 option 253 per [RFC6994] with 16-bit ExID 0x454E, and SHOULD migrate 1088 to option TBD by default. 1090 This document defines a 7-bit "glt" field in the range of 0x20-0x7f 1091 for which IANA shall maintain a new sub-registry entitled "TCP 1092 encryption protocol identifiers" under the "Transmission Control 1093 Protocol (TCP) Parameters" registry. The description of this 1094 registry should be interpreted with respect to the terminology 1095 defined in [RFC5226]. 1097 The intention is for IANA to grant registration requests for TEP 1098 identifiers in anticipation of a published RFC. Hence, a 1099 Specification is Required. However, to allow for implementation 1100 experience, identifiers should be allocated prior to the RFC being 1101 approved for publication. A Designated Expert appointed by the IESG 1102 area director shall approve allocations once it seems more likely 1103 than not that an RFC will eventually be published. The Designated 1104 Expert shall post a request to the TCPINC WG mailing list (or a 1105 successor designated by the Area Director) for comment and review, 1106 including an Internet-Draft. Before a period of 30 days has passed, 1107 the Designated Expert will either approve or deny the registration 1108 request and publish a notice of the decision to the TCPINC WG mailing 1109 list or its successor, as well as informing IANA. A denial notice 1110 MUST be justified by an explanation, and in the cases where it is 1111 possible, concrete suggestions on how the request can be modified so 1112 as to become acceptable should be provided. 1114 The initial values of the TCP-ENO encryption protocol identifier 1115 registry are shown in Table 2. 1117 +-------+---------------------------+----------------------------+ 1118 | Value | Meaning | Reference | 1119 +-------+---------------------------+----------------------------+ 1120 | 0x20 | Experimental Use | | 1121 | 0x21 | TCPCRYPT_ECDHE_P256 | [I-D.ietf-tcpinc-tcpcrypt] | 1122 | 0x22 | TCPCRYPT_ECDHE_P521 | [I-D.ietf-tcpinc-tcpcrypt] | 1123 | 0x23 | TCPCRYPT_ECDHE_Curve25519 | [I-D.ietf-tcpinc-tcpcrypt] | 1124 | 0x24 | TCPCRYPT_ECDHE_Curve448 | [I-D.ietf-tcpinc-tcpcrypt] | 1125 | 0x30 | TCP-Use-TLS | [I-D.ietf-tcpinc-use-tls] | 1126 +-------+---------------------------+----------------------------+ 1128 Table 2: TCP encryption protocol identifiers 1130 11. Acknowledgments 1132 We are grateful for contributions, help, discussions, and feedback 1133 from the TCPINC working group, including Marcelo Bagnulo, David 1134 Black, Bob Briscoe, Jake Holland, Jana Iyengar, Tero Kivinen, Mirja 1135 Kuhlewind, Yoav Nir, Christoph Paasch, Eric Rescorla, Kyle Rose, 1136 Michael Scharf, and Joe Touch. This work was partially funded by 1137 DARPA CRASH and the Stanford Secure Internet of Things Project. 1139 12. Contributors 1141 Dan Boneh was a co-author of the draft that became this document. 1143 13. References 1145 13.1. Normative References 1147 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1148 RFC 793, DOI 10.17487/RFC0793, September 1981, 1149 . 1151 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1152 Requirement Levels", BCP 14, RFC 2119, 1153 DOI 10.17487/RFC2119, March 1997, 1154 . 1156 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1157 "Randomness Requirements for Security", BCP 106, RFC 4086, 1158 DOI 10.17487/RFC4086, June 2005, 1159 . 1161 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1162 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1163 DOI 10.17487/RFC5226, May 2008, 1164 . 1166 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 1167 RFC 6994, DOI 10.17487/RFC6994, August 2013, 1168 . 1170 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1171 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1172 . 1174 13.2. Informative References 1176 [I-D.ietf-tcpinc-tcpcrypt] 1177 Bittau, A., Boneh, D., Giffin, D., Hamburg, M., Handley, 1178 M., Mazieres, D., Slack, Q., and E. Smith, "Cryptographic 1179 protection of TCP Streams (tcpcrypt)", draft-ietf-tcpinc- 1180 tcpcrypt-05 (work in progress), February 2017. 1182 [I-D.ietf-tcpinc-use-tls] 1183 Rescorla, E., "Using TLS to Protect TCP Streams", draft- 1184 ietf-tcpinc-use-tls-01 (work in progress), May 2016. 1186 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1187 Stevens, "Basic Socket Interface Extensions for IPv6", 1188 RFC 3493, DOI 10.17487/RFC3493, February 2003, 1189 . 1191 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1192 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1193 . 1195 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1196 (TLS) Protocol Version 1.2", RFC 5246, 1197 DOI 10.17487/RFC5246, August 2008, 1198 . 1200 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 1201 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1202 RFC 5382, DOI 10.17487/RFC5382, October 2008, 1203 . 1205 [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based 1206 Authentication of Named Entities (DANE)", RFC 6394, 1207 DOI 10.17487/RFC6394, October 2011, 1208 . 1210 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 1211 Digest Access Authentication", RFC 7616, 1212 DOI 10.17487/RFC7616, September 2015, 1213 . 1215 Authors' Addresses 1216 Andrea Bittau 1217 Google 1218 345 Spear Street 1219 San Francisco, CA 94105 1220 US 1222 Email: bittau@google.com 1224 Daniel B. Giffin 1225 Stanford University 1226 353 Serra Mall, Room 288 1227 Stanford, CA 94305 1228 US 1230 Email: dbg@scs.stanford.edu 1232 Mark Handley 1233 University College London 1234 Gower St. 1235 London WC1E 6BT 1236 UK 1238 Email: M.Handley@cs.ucl.ac.uk 1240 David Mazieres 1241 Stanford University 1242 353 Serra Mall, Room 290 1243 Stanford, CA 94305 1244 US 1246 Email: dm@uun.org 1248 Eric W. Smith 1249 Kestrel Institute 1250 3260 Hillview Avenue 1251 Palo Alto, CA 94304 1252 US 1254 Email: eric.smith@kestrel.edu