idnits 2.17.1 draft-ietf-tcpinc-tcpeno-07.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 (January 19, 2017) is 2654 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC-TBD' is mentioned on line 1064, but not defined == Unused Reference: 'I-D.ietf-tcpm-tcp-edo' is defined on line 1181, but no explicit reference was found in the text == Unused Reference: 'I-D.touch-tcpm-tcp-syn-ext-opt' is defined on line 1186, but no explicit reference was found in the text ** 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-04 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcp-edo-07 == Outdated reference: A later version (-12) exists of draft-touch-tcpm-tcp-syn-ext-opt-06 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 7 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. Boneh 5 Expires: July 23, 2017 D. Giffin 6 Stanford University 7 M. Handley 8 University College London 9 D. Mazieres 10 Stanford University 11 E. Smith 12 Kestrel Institute 13 January 19, 2017 15 TCP-ENO: Encryption Negotiation Option 16 draft-ietf-tcpinc-tcpeno-07 18 Abstract 20 Despite growing adoption of TLS [RFC5246], a significant fraction of 21 TCP traffic on the Internet remains unencrypted. The persistence of 22 unencrypted traffic can be attributed to at least two factors. 23 First, some legacy protocols lack a signaling mechanism (such as a 24 "STARTTLS" command) by which to convey support for encryption, making 25 incremental deployment impossible. Second, legacy applications 26 themselves cannot always be upgraded, requiring a way to implement 27 encryption transparently entirely within the transport layer. The 28 TCP Encryption Negotiation Option (TCP-ENO) addresses both of these 29 problems through a new TCP option kind providing out-of-band, fully 30 backward-compatible negotiation of encryption. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 23, 2017. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Requirements language . . . . . . . . . . . . . . . . . . . . 3 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Design goals . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. TCP-ENO specification . . . . . . . . . . . . . . . . . . . . 5 71 4.1. ENO option . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.2. The global suboption . . . . . . . . . . . . . . . . . . 9 73 4.3. TCP-ENO roles . . . . . . . . . . . . . . . . . . . . . . 10 74 4.4. Specifying suboption data length . . . . . . . . . . . . 10 75 4.5. The negotiated TEP . . . . . . . . . . . . . . . . . . . 12 76 4.6. TCP-ENO handshake . . . . . . . . . . . . . . . . . . . . 12 77 4.7. Data in SYN segments . . . . . . . . . . . . . . . . . . 13 78 4.8. Negotiation transcript . . . . . . . . . . . . . . . . . 15 79 5. Requirements for TEPs . . . . . . . . . . . . . . . . . . . . 15 80 5.1. Session IDs . . . . . . . . . . . . . . . . . . . . . . . 16 81 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 7. Design rationale . . . . . . . . . . . . . . . . . . . . . . 19 83 7.1. Future developments . . . . . . . . . . . . . . . . . . . 19 84 7.2. Handshake robustness . . . . . . . . . . . . . . . . . . 20 85 7.3. Suboption data . . . . . . . . . . . . . . . . . . . . . 21 86 7.4. Passive role bit . . . . . . . . . . . . . . . . . . . . 21 87 7.5. Use of ENO option kind by TEPs . . . . . . . . . . . . . 21 88 8. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 9. Security considerations . . . . . . . . . . . . . . . . . . . 22 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 91 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 94 12.2. Informative References . . . . . . . . . . . . . . . . . 25 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 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 indicating whether or not the application at each end knows 240 it is using TCP-ENO. 242 If TCP-ENO fails, encryption is disabled and the connection falls 243 back to traditional unencrypted TCP. 245 The remainder of this section provides the normative description of 246 the TCP ENO option and handshake protocol. 248 4.1. ENO option 250 TCP-ENO employs an option in the TCP header [RFC0793]. There are two 251 equivalent kinds of ENO option, shown in Figure 1. Section 10 252 specifies which of the two kinds is permissible and/or preferred. 254 byte 0 1 2 N+1 (N+2 bytes total) 255 +-----+-----+-----+--....--+-----+ 256 |Kind=|Len= | | 257 | TBD | N+2 | contents (N bytes) | 258 +-----+-----+-----+--....--+-----+ 260 byte 0 1 2 3 4 N+3 (N+4 bytes total) 261 +-----+-----+-----+-----+-----+--....--+-----+ 262 |Kind=|Len= | ExID | | 263 | 253 | N+4 | 69 | 78 | contents (N bytes) | 264 +-----+-----+-----+-----+-----+--....--+-----+ 266 Figure 1: Two equivalent kinds of TCP-ENO option 268 The contents of an ENO option can take one of two forms. A SYN form, 269 illustrated in Figure 2, appears only in SYN segments. A non-SYN 270 form, illustrated in Figure 3, appears only in non-SYN segments. The 271 SYN form of ENO acts as a container for zero or more suboptions, 272 labeled "Opt_0", "Opt_1", ... in Figure 2. The non-SYN form, by its 273 presence, acts as a one-bit acknowledgment, with the actual contents 274 ignored by ENO. Particular TEPs MAY assign additional meaning to the 275 contents of non-SYN ENO options. When a negotiated TEP does not 276 assign such meaning, the contents of a non-SYN ENO option MUST be 277 zero bytes in sent segments and MUST be ignored in received segments. 279 byte 0 1 2 3 ... N+1 280 +-----+-----+-----+-----+--...--+-----+----...----+ 281 |Kind=|Len= |Opt_0|Opt_1| |Opt_i| Opt_i | 282 | TBD | N+2 | | | | | data | 283 +-----+-----+-----+-----+--...--+-----+----...----+ 285 byte 0 1 2 3 4 5 ... N+3 286 +-----+-----+-----+-----+-----+-----+--...--+-----+----...----+ 287 |Kind=|Len= | ExID |Opt_0|Opt_1| |Opt_i| Opt_i | 288 | 253 | N+4 | 69 | 78 | | | | | data | 289 +-----+-----+-----+-----+-----+-----+--...--+-----+----...----+ 291 Figure 2: SYN form of ENO 293 byte 0 1 2 N+1 294 +-----+-----+-----...----+ 295 |Kind=|Len= | ignored | 296 | TBD | N+2 | by TCP-ENO | 297 +-----+-----+-----...----+ 299 byte 0 1 2 3 4 N+3 300 +-----+-----+-----+-----+-----...----+ 301 |Kind=|Len= | ExID | ignored | 302 | 253 | N+4 | 69 | 78 | by TCP-ENO | 303 +-----+-----+-----+-----+-----...----+ 305 Figure 3: Non-SYN form of ENO, where N MAY be 0 307 Every suboption starts with a byte of the form illustrated in 308 Figure 4. The high bit "v", when set, introduces suboptions with 309 variable-length data. When "v = 0", the byte itself constitutes the 310 entirety of the suboption. The 7-bit value "glt" expresses one of: 312 o Global configuration data (discussed in Section 4.2), 314 o Suboption data length for the next suboption (discussed in 315 Section 4.4), or 317 o An offer to use a particular TEP defined in a separate TEP 318 specification document. 320 bit 7 6 5 4 3 2 1 0 321 +---+---+---+---+---+---+---+---+ 322 | v | glt | 323 +---+---+---+---+---+---+---+---+ 325 v - non-zero for use with variable-length suboption data 326 glt - Global suboption, Length, or TEP identifier 328 Figure 4: Format of initial suboption byte 330 Table 1 summarizes the meaning of initial suboption bytes. Values of 331 "glt" below 0x20 are used for global suboptions and length 332 information (the "gl" in "glt"), while those greater than or equal to 333 0x20 are TEP identifiers (the "t"). When "v = 0", the initial 334 suboption byte constitutes the entirety of the suboption and all 335 information is expressed by the 7-bit "glt" value, which can be 336 either a global suboption or a TEP identifier. When "v = 1", it 337 indicates a suboption with variable-length suboption data. Only TEP 338 identifiers may have suboption data, not global suboptions. Hence, 339 bytes with "v = 1" and "glt < 0x20" are not global suboptions but 340 rather length bytes governing the length of the next suboption (which 341 MUST be a TEP identifer). In the absence of a length byte, a TEP 342 identifier suboption with "v = 1" has suboption data extending to the 343 end of the TCP option. 345 +-----------+---+-------------------------------------------+ 346 | glt | v | Meaning | 347 +-----------+---+-------------------------------------------+ 348 | 0x00-0x1f | 0 | Global suboption (Section 4.2) | 349 | 0x00-0x1f | 1 | Length byte (Section 4.4) | 350 | 0x20-0x7f | 0 | TEP identifier without suboption data | 351 | 0x20-0x7f | 1 | TEP identifier followed by suboption data | 352 +-----------+---+-------------------------------------------+ 354 Table 1: Initial suboption byte values 356 A SYN segment MUST contain at most one TCP ENO option. If a SYN 357 segment contains more than one ENO option, the receiver MUST behave 358 as though the segment contained no ENO options and disable 359 encryption. A TEP MAY specify the use of multiple ENO options in a 360 non-SYN segment. For non-SYN segments, ENO itself only distinguishes 361 between the presence or absence of ENO options; multiple ENO options 362 are interpreted the same as one. 364 4.2. The global suboption 366 Suboptions 0x00-0x1f are used for global configuration that applies 367 regardless of the negotiated TEP. A TCP SYN segment MUST include at 368 most one ENO suboption in this range. A receiver MUST ignore all but 369 the first suboption in this range so as to anticipate updates to ENO 370 that assign new meaning to bits in subsequent global suboptions. The 371 value of a global suboption byte is interpreted as a bitmask, 372 illustrated in Figure 5. 374 bit 7 6 5 4 3 2 1 0 375 +---+---+---+---+---+---+---+---+ 376 | 0 | 0 | 0 |z1 |z2 |z3 | a | b | 377 +---+---+---+---+---+---+---+---+ 379 b - Passive role bit 380 a - Application-aware bit 381 z* - Zero bits (reserved for future use) 383 Figure 5: Format of the global suboption byte 385 The fields of the bitmask are interpreted as follows: 387 b 388 The passive role bit MUST be 1 for all passive openers. For 389 active openers, it MUST default to 0, but implementations MUST 390 provide an API through which an application can explicitly set "b 391 = 1" before initiating an active open. (Manual configuration of 392 "b" is necessary to enable encryption with a simultaneous open.) 394 a 395 The application-aware bit "a" is an out-of-band signal indicating 396 that the application on the sending host is aware of TCP-ENO and 397 has been extended to alter its behavior in the presence of 398 encrypted TCP. Implementations MUST set this bit to 0 by default, 399 and SHOULD provide an API through which applications can change 400 the value of the bit as well as examine the value of the bit sent 401 by the remote host. Implementations SHOULD furthermore support a 402 _mandatory_ application-aware mode in which TCP-ENO is 403 automatically disabled if the remote host does not set "a = 1". 405 z1, z2, z3 406 The "z" bits are reserved for future updates to TCP-ENO. They 407 MUST be set to zero in sent segments and MUST be ignored in 408 received segments. 410 A SYN segment without an explicit global suboption has an implicit 411 global suboption of 0x00. Because passive openers MUST always set "b 412 = 1", they cannot rely on this implicit 0x00 byte and MUST include an 413 explicit global suboption in their SYN-ACK segments. 415 4.3. TCP-ENO roles 417 TCP-ENO uses abstract roles to distinguish the two ends of a TCP 418 connection. These roles are determined by the "b" bit in the global 419 suboption. The host that sent an implicit or explicit suboption with 420 "b = 0" plays the "A" role. The host that sent "b = 1" plays the "B" 421 role. 423 If both sides of a connection set "b = 1" (which can happen if the 424 active opener misconfigures "b" before calling "connect"), or both 425 sides set "b = 0" (which can happen with simultaneous open), then 426 TCP-ENO MUST be disabled and the connection MUST fall back to 427 unencrypted TCP. 429 TEP specifications SHOULD refer to TCP-ENO's A and B roles to specify 430 asymmetric behavior by the two hosts. For the remainder of this 431 document, we will use the terms "host A" and "host B" to designate 432 the hosts with roles A and B, respectively, in a connection. 434 4.4. Specifying suboption data length 436 A TEP MAY optionally make use of one or more bytes of suboption data. 437 The presence of such data is indicated by setting "v = 1" in the 438 initial suboption byte (see Figure 4). By default, suboption data 439 extends to the end of the TCP option. Hence, if only one suboption 440 requires data, the most compact way to encode it is to place it last 441 in the ENO option, after all other suboptions. As an example, in 442 Figure 2, the last suboption, "Opt_i", has suboption data and thus 443 requires "v = 1"; however, the suboption data length can be inferred 444 from the total length of the TCP option. 446 When a suboption with data is not last in an ENO option, the sender 447 MUST explicitly specify the suboption data length for the receiver to 448 know where the next suboption starts. The sender does so by 449 preceding the suboption with a length byte, depicted in Figure 6. 450 The length byte encodes a 5-bit value "nnnnn". Adding one to "nnnnn" 451 yields the length of the suboption data (not including the length 452 byte or the TEP identifier). Hence, a length byte can designate 453 anywhere from 1 to 32 bytes of suboption data (inclusive). 455 bit 7 6 5 4 3 2 1 0 456 +---+---+---+-------------------+ 457 | 1 0 0 nnnnn | 458 +---+---+---+-------------------+ 460 nnnnn - 5-bit value encoding (length - 1) 462 Figure 6: Format of a length byte 464 A suboption preceded by a length byte MUST be a TEP identifier ("glt 465 >= 0x20") and MUST have "v = 1". Figure 7 shows an example of such a 466 suboption. 468 byte 0 1 2 nnnnn+2 (nnnnn+3 bytes total) 469 +------+------+-------...-------+ 470 |length| TEP | suboption data | 471 | byte |ident.| (nnnnn+1 bytes) | 472 +------+------+-------...-------+ 474 length byte - specifies nnnnn 475 TEP identifier - MUST have v = 1 and glt >= 0x20 476 suboption data - length specified by nnnnn+1 478 Figure 7: Suboption with length byte 480 A host MUST ignore an ENO option in a SYN segment and MUST disable 481 encryption if either: 483 1. A length byte indicates that suboption data would extend beyond 484 the end of the TCP ENO option, or 486 2. A length byte is followed by an octet in the range 0x00-0x9f 487 (meaning the following byte has "v = 0" or "glt < 0x20"). 489 Because the last suboption in an ENO option is special-cased to have 490 its length inferred from the 8-bit TCP option length, it MAY contain 491 more than 32 bytes of suboption data. Other suboptions are limited 492 to 32 bytes by the length byte format. The TCP header itself can 493 only accommodate a maximum of 40 bytes of options, however. Hence, 494 regardless of the length byte format, a segment would not be able to 495 contain more than one suboption over 32 bytes in size. That said, 496 TEPs MAY define the use of multiple suboptions with the same TEP 497 identifier in the same SYN segment, providing another way to convey 498 over 32 bytes of suboption data even with length bytes. 500 4.5. The negotiated TEP 502 A TEP identifier "glt" (with "glt >= 0x20") is _valid_ for a 503 connection when: 505 1. Each side has sent a suboption for "glt" in its SYN-form ENO 506 option, 508 2. Any suboption data in these "glt" suboptions is valid according 509 to the TEP specification and satisfies any runtime constraints, 510 and 512 3. If an ENO option contains multiple suboptions with "glt", then 513 such repetition is well-defined by the TEP specification. 515 The _negotiated TEP_ is the last valid TEP identifier in host B's 516 SYN-form ENO option. This definition means host B specifies TEP 517 suboptions in order of increasing priority, while host A does not 518 influence TEP priority. 520 A passive opener (which is always host B) sees the remote host's SYN 521 segment before constructing its own SYN-ACK. Hence, a passive opener 522 SHOULD include only one TEP identifier in SYN-ACK segments and SHOULD 523 ensure this TEP identifier is valid. However, simultaneous open or 524 implementation considerations can prevent host B from offering only 525 one TEP. 527 4.6. TCP-ENO handshake 529 A host employing TCP-ENO for a connection MUST include an ENO option 530 in every TCP segment sent until either encryption is disabled or the 531 host receives a non-SYN segment. 533 A host MUST disable encryption, refrain from sending any further ENO 534 options, and fall back to unencrypted TCP if any of the following 535 occurs: 537 1. Any segment it receives up to and including the first received 538 ACK segment does not contain a ENO option (or contains an ill- 539 formed SYN-form ENO option), 541 2. The SYN segment it receives does not contain a valid TEP 542 identifier, or 544 3. It receives a SYN segment with an incompatible global suboption. 545 (Specifically, incompatible means the two hosts set the same "b" 546 value or the connection is in mandatory application-aware mode 547 and the remote host set "a = 0".) 549 Hosts MUST NOT alter SYN-form ENO options in retransmitted segments, 550 or between the SYN and SYN-ACK segments of a simultaneous open, with 551 two exceptions for an active opener. First, an active opener MAY 552 unilaterally disable ENO (and thus remove the ENO option) between 553 retransmissions of a SYN-only segment. (Such removal could enable 554 recovery from middleboxes dropping segments with ENO options.) 555 Second, an active opener performing simultaneous open MAY include no 556 TCP-ENO option in its SYN-ACK if the received SYN caused it to 557 disable encryption according to the above rules (for instance because 558 role negotiation failed). 560 Once a host has both sent and received an ACK segment containing an 561 ENO option, encryption MUST be enabled. Once encryption is enabled, 562 hosts MUST follow the specification of the negotiated TEP and MUST 563 NOT present raw TCP payload data to the application. In particular, 564 data segments MUST NOT contain plaintext application data, but rather 565 ciphertext, key negotiation parameters, or other messages as 566 determined by the negotiated TEP. 568 A host MAY send a _vacuous_ SYN-form ENO option containing zero TEP 569 identifier suboptions. If either host sends a vacuous ENO option, it 570 follows that there are no valid TEP identifiers for the connection 571 and hence the connection must fall back to unencrypted TCP. Hosts 572 MAY send vacuous ENO options to indicate that ENO is supported but 573 unavailable by configuration, or to probe network paths for 574 robustness to ENO options. However, a passive opener MUST NOT send a 575 vacuous ENO option in a SYN-ACK segment unless there was an ENO 576 option in the SYN segment it received. Moreover, a passive opener's 577 SYN-form ENO option MUST still include a global suboption with "b = 578 1", as discussed in Section 4.3. 580 4.7. Data in SYN segments 582 TEPs MAY specify the use of data in SYN segments so as to reduce the 583 number of round trips required for connection setup. The meaning of 584 data in a SYN segment with an ENO option (a SYN+ENO segment) is 585 determined by the last TEP identifier in the ENO option, which we 586 term the segment's _SYN TEP_. 588 A host sending a SYN+ENO segment MUST NOT include data in the segment 589 unless the SYN TEP's specification defines the use of such data. 590 Furthermore, to avoid conflicting interpretations of SYN data, a 591 SYN+ENO segment MUST NOT include a non-empty TCP Fast Open (TFO) 592 option [RFC7413]. 594 Because a host can send SYN data before knowing which if any TEP will 595 govern a connection, hosts implementing ENO are REQUIRED to discard 596 data from SYN+ENO segments when the SYN TEP does not govern the 597 connection or when there is any ambiguity over the meaning of the SYN 598 data. This requirement applies to hosts that implement ENO even when 599 ENO has been disabled by configuration. However, note that 600 discarding SYN data is already common practice [RFC4987] and the new 601 requirement applies only to segments containing ENO options. 603 More specifically, a host that implements ENO MUST discard the data 604 in a received SYN+ENO segment if any of the following applies: 606 o ENO fails and TEP-indicated encryption is disabled for the 607 connection, 609 o The received segment's SYN TEP is not the negotiated TEP, 611 o The negotiated TEP does not define the use of SYN data, or 613 o The SYN segment contains a non-empty TFO option or any other TCP 614 option implying a conflicting definition of SYN data. 616 A host discarding SYN data in compliance with the above requirement 617 MUST NOT acknowledge the sequence number of the discarded data, but 618 rather MUST acknowledge the other host's initial sequence number as 619 if the received SYN segment contained no data. Furthermore, after 620 discarding SYN data, such a host MUST NOT assume the SYN data will be 621 identically retransmitted, and MUST process data only from non-SYN 622 segments. 624 If a host sends a SYN+ENO segment with data and receives 625 acknowledgment for the data, but the SYN TEP governing the data is 626 not the negotiated TEP (either because a different TEP was negotiated 627 or because ENO failed to negotiate encryption), then the host MUST 628 reset the TCP connection. Proceeding in any other fashion risks 629 misinterpreted SYN data. 631 If a host sends a SYN-only SYN+ENO segment bearing data and 632 subsequently receives a SYN-ACK segment without an ENO option, that 633 host MUST reset the connection even if the SYN-ACK segment does not 634 acknowledge the SYN data. The issue is that unacknowledged data may 635 nonetheless have been cached by the receiver; later retransmissions 636 intended to supersede this unacknowledged data could fail to do so if 637 the receiver gives precedence to the cached original data. 638 Implementations MAY provide an API call for a non-default mode in 639 which unacknowledged SYN data does not cause a connection reset, but 640 applications MUST only use this mode when a higher-layer integrity 641 check would anyway terminate a garbled connection. 643 To avoid unexpected connection resets, ENO implementations MUST 644 disable the use of data in SYN-only segments by default. Such data 645 MAY be enabled by an API command. In particular, implementations MAY 646 provide a per-connection mandatory encryption mode that automatically 647 resets a connection if ENO fails, and MAY enable SYN data in this 648 mode. 650 To satisfy the requirement of the previous paragraph, all TEPs SHOULD 651 support a normal mode of operation that avoids data in SYN-only 652 segments. An exception is TEPs intended to be disabled by default. 654 4.8. Negotiation transcript 656 To defend against attacks on encryption negotiation itself, TEPs need 657 a way to reference a transcript of TCP-ENO's negotiation. In 658 particular, a TEP MUST with high probability fail to reach key 659 agreement between two honest endpoints if the TEP's selection 660 resulted from tampering with the contents of SYN-form ENO options. 661 (Of course, in the absence of endpoint authentication, two honest 662 endpoints can still each end up talking to a man-in-the-middle 663 attacker rather than to each other.) 665 TCP-ENO defines its negotiation transcript as a packed data structure 666 consisting of two TCP-ENO options exactly as they appeared in the TCP 667 header (including the TCP option kind, TCP option length byte, and, 668 for option kind 253, the bytes 69 and 78 as illustrated in Figure 1). 669 The transcript is constructed from the following, in order: 671 1. The TCP-ENO option in host A's SYN segment, including the kind 672 and length bytes. 674 2. The TCP-ENO option in host B's SYN segment, including the kind 675 and length bytes. 677 Note that because the ENO options in the transcript contain length 678 bytes as specified by TCP, the transcript unambiguously delimits A's 679 and B's ENO options. 681 5. Requirements for TEPs 683 TCP-ENO affords TEP specifications a large amount of design 684 flexibility. However, to abstract TEP differences away from 685 applications requires fitting them all into a coherent framework. As 686 such, any TEP claiming an ENO TEP identifier MUST satisfy the 687 following normative list of properties. 689 o TEPs MUST protect TCP data streams with authenticated encryption. 691 o TEPs MUST define a session ID whose value identifies the TCP 692 connection and, with overwhelming probability, is unique over all 693 time if either host correctly obeys the TEP. Section 5.1 694 describes the requirements of the session ID in more detail. 696 o TEPs MUST NOT permit the negotiation of any encryption algorithms 697 with significantly less than 128-bit security. 699 o TEPs MUST NOT allow the negotiation of null cipher suites, even 700 for debugging purposes. (Implementations MAY support debugging 701 modes that allow applications to extract their own session keys.) 703 o TEPs MUST NOT depend on long-lived secrets for data 704 confidentiality, as implementations SHOULD provide forward secrecy 705 at some bounded, short time after the close of a TCP connection. 706 (Exceptions to forward secrecy are permissible only at the 707 implementation level, and only in response to hardware or 708 architectural constraints--e.g., storage that cannot be securely 709 erased.) 711 o TEPs MUST protect and authenticate the end-of-file marker conveyed 712 by TCP's FIN flag. In particular, a receiver MUST with high 713 probability detect a FIN flag that was set or cleared in transit 714 and does not match the sender's intent. A TEP MAY discard a 715 segment with such a corrupted FIN bit, or may abort the connection 716 in response to such a segment. However, any such abort MUST raise 717 an error condition distinct from an authentic end-of-file 718 condition. 720 o TEPs MUST prevent corrupted packets from causing urgent data to be 721 delivered when none has been sent. A TEP MAY do so by 722 cryptographically protecting the URG flag and urgent pointer 723 alongside ordinary payload data. Alternatively, a TEP MAY disable 724 urgent data functionality by clearing the URG flag on all received 725 segments and returning errors in response to sender-side urgent- 726 data API calls. Implementations SHOULD avoid negotiating TEPs 727 that disable urgent data by default. The exception is when 728 applications and protocols are known never to send urgent data. 730 5.1. Session IDs 732 Each TEP MUST define a session ID that is computable by both 733 endpoints and uniquely identifies each encrypted TCP connection. 734 Implementations MUST expose the session ID to applications via an API 735 extension. Applications that are aware of TCP-ENO SHOULD, when 736 practical, authenticate the TCP endpoints by incorporating the values 737 of the session ID and TCP-ENO role (A or B) into higher-layer 738 authentication mechanisms. 740 In order to avoid replay attacks and prevent authenticated session 741 IDs from being used out of context, session IDs MUST be unique over 742 all time with high probability. This uniqueness property MUST hold 743 even if one end of a connection maliciously manipulates the protocol 744 in an effort to create duplicate session IDs. In other words, it 745 MUST be infeasible for a host, even by violating the TEP 746 specification, to establish two TCP connections with the same session 747 ID to remote hosts properly implementing the TEP. 749 To prevent session IDs from being confused across TEPs, all session 750 IDs begin with the negotiated TEP identifier--that is, the last valid 751 TEP identifier in host B's SYN segment. Futhermore, this initial 752 byte has bit "v" set to the same value that accompanied the 753 negotiated TEP identifier in B's SYN segment. However, only this 754 single byte is included, not any suboption data. Figure 8 shows the 755 resulting format. This format is designed for TEPs to compute unique 756 identifiers; it is not intended for application authors to pick apart 757 session IDs. Applications SHOULD treat session IDs as monolithic 758 opaque values and SHOULD NOT discard the first byte to shorten 759 identifiers. (An exception is for non-security-relevant purposes, 760 such as gathering statistics about negotiated TEPs.) 762 byte 0 1 2 N-1 N 763 +-----+------------...------------+ 764 | sub-| collision-resistant hash | 765 | opt | of connection information | 766 +-----+------------...------------+ 768 Figure 8: Format of a session ID 770 Though TEP specifications retain considerable flexibility in their 771 definitions of the session ID, all session IDs MUST meet the 772 following normative list of requirements: 774 o The session ID MUST be at least 33 bytes (including the one-byte 775 suboption), though TEPs MAY choose longer session IDs. 777 o The session ID MUST depend in a collision-resistant way on all of 778 the following (meaning it is computationally infeasible to produce 779 collisions of the session ID derivation function unless all of the 780 following quantities are identical): 782 * Fresh data contributed by both sides of the connection, 784 * Any public keys, public Diffie-Hellman parameters, or other 785 public asymmetric cryptographic parameters that are employed by 786 the TEP and have corresponding private data that is known by 787 only one side of the connection, and 789 * The negotiation transcript specified in Section 4.8. 791 o Unless and until applications disclose information about the 792 session ID, all but the first byte MUST be computationally 793 indistinguishable from random bytes to a network eavesdropper. 795 o Applications MAY choose to make session IDs public. Therefore, 796 TEPs MUST NOT place any confidential data in the session ID (such 797 as data permitting the derivation of session keys). 799 6. Examples 801 This subsection illustrates the TCP-ENO handshake with a few non- 802 normative examples. 804 (1) A -> B: SYN ENO 805 (2) B -> A: SYN-ACK ENO 806 (3) A -> B: ACK ENO<> 807 [rest of connection encrypted according to TEP Y] 809 Figure 9: Three-way handshake with successful TCP-ENO negotiation 811 Figure 9 shows a three-way handshake with a successful TCP-ENO 812 negotiation. The two sides agree to follow the TEP identified by 813 suboption Y. 815 (1) A -> B: SYN ENO 816 (2) B -> A: SYN-ACK 817 (3) A -> B: ACK 818 [rest of connection unencrypted legacy TCP] 820 Figure 10: Three-way handshake with failed TCP-ENO negotiation 822 Figure 10 shows a failed TCP-ENO negotiation. The active opener (A) 823 indicates support for TEPs corresponding to suboptions X and Y. 824 Unfortunately, at this point one of several things occurs: 826 1. The passive opener (B) does not support TCP-ENO, 828 2. B supports TCP-ENO, but supports neither of TEPs X and Y, and so 829 does not reply with an ENO option, 831 3. B supports TCP-ENO, but has the connection configured in 832 mandatory application-aware mode and thus disables ENO because 833 A's SYN segment does not set the application-aware bit, or 835 4. The network stripped the ENO option out of A's SYN segment, so B 836 did not receive it. 838 Whichever of the above applies, the connection transparently falls 839 back to unencrypted TCP. 841 (1) A -> B: SYN ENO 842 (2) B -> A: SYN-ACK ENO [ENO stripped by middlebox] 843 (3) A -> B: ACK 844 [rest of connection unencrypted legacy TCP] 846 Figure 11: Failed TCP-ENO negotiation because of network filtering 848 Figure 11 Shows another handshake with a failed encryption 849 negotiation. In this case, the passive opener B receives an ENO 850 option from A and replies. However, the reverse network path from B 851 to A strips ENO options. Hence, A does not receive an ENO option 852 from B, disables ENO, and does not include a non-SYN-form ENO option 853 when ACKing B's SYN segment. The lack of ENO in A's ACK segment 854 signals to B that the connection will not be encrypted. At this 855 point, the two hosts proceed with an unencrypted TCP connection. 857 (1) A -> B: SYN ENO 858 (2) B -> A: SYN ENO 859 (3) A -> B: SYN-ACK ENO 860 (4) B -> A: SYN-ACK ENO 861 [rest of connection encrypted according to TEP Y] 863 Figure 12: Simultaneous open with successful TCP-ENO negotiation 865 Figure 12 shows a successful TCP-ENO negotiation with simultaneous 866 open. Here the first four segments MUST contain a SYN-form ENO 867 option, as each side sends both a SYN-only and a SYN-ACK segment. 868 The ENO option in each host's SYN-ACK is identical to the ENO option 869 in its SYN-only segment, as otherwise connection establishment could 870 not recover from the loss of a SYN segment. The last valid TEP in 871 host B's ENO option is Y, so Y is the negotiated TEP. 873 7. Design rationale 875 This section describes some of the design rationale behind TCP-ENO. 877 7.1. Future developments 879 TCP-ENO is designed to capitalize on future developments that could 880 alter trade-offs and change the best approach to TCP-level encryption 881 (beyond introducing new cipher suites). By way of example, we 882 discuss a few such possible developments. 884 Various proposals exist to increase option space in TCP [I-D.ietf-tcp 885 m-tcp-edo][I-D.briscoe-tcpm-inspace-mode-tcpbis][I-D.touch-tcpm-tcp-s 886 yn-ext-opt]. If SYN segments gain large options, it becomes possible 887 to fit public keys or Diffie-Hellman parameters into SYN segments. 888 Future TEPs can take advantage of this by performing key agreement 889 directly within suboption data, both simplifying protocols and 890 reducing the number of round trips required for connection setup. 892 If TCP gains large SYN option support, the 32-byte limit on length 893 bytes may prove problematic. This draft intentionally aborts TCP-ENO 894 if a length byte is followed by an octet in the range 0x00-0x9f. Any 895 document updating TCP's option size limit can also enable larger 896 suboptions by updating this draft to assign meaning to such currently 897 undefined byte sequences. 899 New revisions to socket interfaces [RFC3493] could involve library 900 calls that simultaneously have access to hostname information and an 901 underlying TCP connection. Such an API enables the possibility of 902 authenticating servers transparently to the application, particularly 903 in conjunction with technologies such as DANE [RFC6394]. An update 904 to TCP-ENO can adopt one of the "z" bits in the global suboption to 905 negotiate the use of an endpoint authentication protocol before any 906 application use of the TCP connection. Over time, the consequences 907 of failed or missing endpoint authentication can gradually be 908 increased from issuing log messages to aborting the connection if 909 some as yet unspecified DNS record indicates authentication is 910 mandatory. Through shared library updates, such endpoint 911 authentication can potentially be added transparently to legacy 912 applications without recompilation. 914 TLS can currently only be added to legacy applications whose 915 protocols accommodate a STARTTLS command or equivalent. TCP-ENO, 916 because it provides out-of-band signaling, opens the possibility of 917 future TLS revisions being generically applicable to any TCP 918 application. 920 7.2. Handshake robustness 922 Incremental deployment of TCP-ENO depends critically on failure cases 923 devolving to unencrypted TCP rather than causing the entire TCP 924 connection to fail. 926 Because a network path may drop ENO options in one direction only, a 927 host must know not just that the peer supports encryption, but that 928 the peer has received an ENO option. To this end, ENO disables 929 encryption unless it receives an ACK segment bearing an ENO option. 930 To stay robust in the face of dropped segments, hosts must continue 931 to include non-SYN form ENO options in segments until such point as 932 they have received a non-SYN segment from the other side. 934 One particularly pernicious middlebox behavior found in the wild is 935 load balancers that echo unknown TCP options found in SYN segments 936 back to an active opener. The passive role bit "b" in global 937 suboptions ensures encryption will always be disabled under such 938 circumstances, as sending back a verbatim copy of an active opener's 939 SYN-form ENO option always causes role negotiation to fail. 941 7.3. Suboption data 943 TEPs can employ suboption data for session caching, cipher suite 944 negotiation, or other purposes. However, TCP currently limits total 945 option space consumed by all options to only 40 bytes, making it 946 impractical to have many suboptions with data. For this reason, ENO 947 optimizes the case of a single suboption with data by inferring the 948 length of the last suboption from the TCP option length. Doing so 949 saves one byte. 951 7.4. Passive role bit 953 TCP-ENO, TEPs, and applications all have asymmetries that require an 954 unambiguous way to identify one of the two connection endpoints. As 955 an example, Section 4.8 specifies that host A's ENO option comes 956 before host B's in the negotiation transcript. As another example, 957 an application might need to authenticate one end of a TCP connection 958 with a digital signature. To ensure the signed message cannot not be 959 interpreted out of context to authenticate the other end, the signed 960 message would need to include both the session ID and the local role, 961 A or B. 963 A normal TCP three-way handshake involves one active and one passive 964 opener. This asymmetry is captured by the default configuration of 965 the "b" bit in the global suboption. With simultaneous open, both 966 hosts are active openers, so TCP-ENO requires that one host manually 967 configure "b = 1". An alternate design might automatically break the 968 symmetry to avoid this need for manual configuration. However, all 969 such designs we considered either lacked robustness or consumed 970 precious bytes of SYN option space even in the absence of 971 simultaneous open. (One complicating factor is that TCP does not 972 know it is participating in a simultaneous open until after it has 973 sent a SYN segment. Moreover, with packet loss, one host might never 974 learn it has participated in a simultaneous open.) 976 7.5. Use of ENO option kind by TEPs 978 This draft does not specify the use of ENO options beyond the first 979 few segments of a connection. Moreover, it does not specify the 980 content of ENO options in non-SYN segments, only their presence. As 981 a result, any use of option kind TBD (or option kind 253 with ExID 982 0x454E) after the SYN exchange does not conflict with this document. 983 Because, in addition, ENO guarantees at most one negotiated TEP per 984 connection, TEPs will not conflict with one another or ENO if they 985 use ENO's option kind for out-of-band signaling in non-SYN segments. 987 8. Experiments 989 This document has experimental status because TCP-ENO's viability 990 depends on middlebox behavior that can only be determined _a 991 posteriori_. Specifically, we must determine to what extent 992 middleboxes will permit the use of TCP-ENO. Once TCP-ENO is 993 deployed, we will be in a better position to gather data on two types 994 of failure: 996 1. Middleboxes downgrading TCP-ENO connections to unencrypted TCP. 997 This can happen if middleboxes strip unknown TCP options or if 998 they terminate TCP connections and relay data back and forth. 1000 2. Middleboxes causing TCP-ENO connections to fail completely. This 1001 can happen if applications perform deep packet inspection and 1002 start dropping segments that unexpectedly contain ciphertext. 1004 The first type of failure is tolerable since TCP-ENO is designed for 1005 incremental deployment anyway. The second type of failure is more 1006 problematic, and, if prevalent, will require the development of 1007 techniques to avoid and recover from such failures. 1009 9. Security considerations 1011 An obvious use case for TCP-ENO is opportunistic encryption--that is, 1012 encrypting some connections, but only where supported and without any 1013 kind of endpoint authentication. Opportunistic encryption protects 1014 against undetectable large-scale eavesdropping. However, it does not 1015 protect against detectable large-scale eavesdropping (for instance, 1016 if ISPs terminate TCP connections and proxy them, or simply downgrade 1017 connections to unencrypted). Moreover, opportunistic encryption 1018 emphatically does not protect against targeted attacks that employ 1019 trivial spoofing to redirect a specific high-value connection to a 1020 man-in-the-middle attacker. 1022 Achieving stronger security with TCP-ENO requires verifying session 1023 IDs. Any application relying on ENO for communications security MUST 1024 incorporate session IDs into its endpoint authentication. By way of 1025 example, an authentication mechanism based on keyed digests (such 1026 Digest Access Authentication [RFC7616]) can be extended to include 1027 the role and session ID in the input of the keyed digest. To 1028 preserve backwards compatibility, applications MAY use the 1029 application-aware bit to negotiate the inclusion of session IDs in 1030 authentication. 1032 Because TCP-ENO enables multiple different TEPs to coexist, security 1033 could potentially be only as strong as the weakest available TEP. In 1034 particular, if session IDs do not depend on the TCP-ENO transcript in 1035 a strong way, an attacker can undetectably tamper with ENO options to 1036 force negotiation of a deprecated and vulnerable TEP. To avoid such 1037 problems, TEPs MUST compute session IDs using only well-studied and 1038 conservative hash functions. That way, even if other parts of a TEP 1039 are vulnerable, it is still intractable for an attacker to induce 1040 identical session IDs at both ends after tampering with ENO contents 1041 in SYN segments. 1043 Implementations MUST NOT send ENO options unless they have access to 1044 an adequate source of randomness [RFC4086]. Without secret 1045 unpredictable data at both ends of a connection, it is impossible for 1046 TEPs to achieve confidentiality and forward secrecy. Because systems 1047 typically have very little entropy on bootup, implementations might 1048 need to disable TCP-ENO until after system initialization. 1050 With a regular three-way handshake (meaning no simultaneous open), 1051 the non-SYN form ENO option in an active opener's first ACK segment 1052 MAY contain N > 0 bytes of TEP-specific data, as shown in Figure 3. 1053 Such data is not part of the TCP-ENO negotiation transcript, and 1054 hence MUST be separately authenticated by the TEP. 1056 10. IANA Considerations 1058 This document defines a new TCP option kind for TCP-ENO, assigned a 1059 value of TBD from the TCP option space. This value is defined as: 1061 +------+--------+----------------------------------+-----------+ 1062 | Kind | Length | Meaning | Reference | 1063 +------+--------+----------------------------------+-----------+ 1064 | TBD | N | Encryption Negotiation (TCP-ENO) | [RFC-TBD] | 1065 +------+--------+----------------------------------+-----------+ 1067 TCP Option Kind Numbers 1069 Early implementations of TCP-ENO and a predecessor TCP encryption 1070 protocol made unauthorized use of TCP option kind 69. 1072 [RFC-editor: please glue the following text to the previous paragraph 1073 iff TBD == 69, otherwise delete it.] These earlier uses of option 69 1074 are not compatible with TCP-ENO and could disable encryption or 1075 suffer complete connection failure when interoperating with TCP-ENO- 1076 compliant hosts. Hence, legacy use of option 69 MUST be disabled on 1077 hosts that cannot be upgraded to TCP-ENO. 1079 [RFC-editor: please glue this to the previous paragraph regardless of 1080 the value of TBD.] More recent implementations used experimental 1081 option 253 per [RFC6994] with 16-bit ExID 0x454E, and SHOULD migrate 1082 to option TBD by default. 1084 This document defines a 7-bit "glt" field in the range of 0x20-0x7f 1085 for which IANA shall maintain a new sub-registry entitled "TCP 1086 encryption protocol identifiers" under the "Transmission Control 1087 Protocol (TCP) Parameters" registry. The description of this 1088 registry should be interpreted with respect to the terminology 1089 defined in [RFC5226]. 1091 The intention is for IANA to grant registration requests for TEP 1092 identifiers in anticipation of a published RFC. Hence, a 1093 Specification is Required. However, to allow for implementation 1094 experience, identifiers should be allocated prior to the RFC being 1095 approved for publication. A Designated Expert appointed by the IESG 1096 area director shall approve allocations once it seems more likely 1097 than not that an RFC will eventually be published. The Designated 1098 Expert shall post a request to the TCPINC WG mailing list (or a 1099 successor designated by the Area Director) for comment and review, 1100 including an Internet-Draft. Before a period of 30 days has passed, 1101 the Designated Expert will either approve or deny the registration 1102 request and publish a notice of the decision to the TCPINC WG mailing 1103 list or its successor, as well as informing IANA. A denial notice 1104 must be justified by an explanation, and in the cases where it is 1105 possible, concrete suggestions on how the request can be modified so 1106 as to become acceptable should be provided. 1108 The initial values of the TCP-ENO encryption protocol identifier 1109 registry are shown in Table 2. 1111 +-------+---------------------------+----------------------------+ 1112 | Value | Meaning | Reference | 1113 +-------+---------------------------+----------------------------+ 1114 | 0x20 | Experimental Use | | 1115 | 0x21 | TCPCRYPT_ECDHE_P256 | [I-D.ietf-tcpinc-tcpcrypt] | 1116 | 0x22 | TCPCRYPT_ECDHE_P521 | [I-D.ietf-tcpinc-tcpcrypt] | 1117 | 0x23 | TCPCRYPT_ECDHE_Curve25519 | [I-D.ietf-tcpinc-tcpcrypt] | 1118 | 0x24 | TCPCRYPT_ECDHE_Curve448 | [I-D.ietf-tcpinc-tcpcrypt] | 1119 | 0x30 | TCP-Use-TLS | [I-D.ietf-tcpinc-use-tls] | 1120 +-------+---------------------------+----------------------------+ 1122 Table 2: TCP encryption protocol identifiers 1124 11. Acknowledgments 1126 We are grateful for contributions, help, discussions, and feedback 1127 from the TCPINC working group, including Marcelo Bagnulo, David 1128 Black, Bob Briscoe, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Yoav 1129 Nir, Christoph Paasch, Eric Rescorla, Kyle Rose, and Joe Touch. This 1130 work was partially funded by DARPA CRASH and the Stanford Secure 1131 Internet of Things Project. 1133 12. References 1135 12.1. Normative References 1137 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1138 RFC 793, DOI 10.17487/RFC0793, September 1981, 1139 . 1141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1142 Requirement Levels", BCP 14, RFC 2119, 1143 DOI 10.17487/RFC2119, March 1997, 1144 . 1146 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1147 "Randomness Requirements for Security", BCP 106, RFC 4086, 1148 DOI 10.17487/RFC4086, June 2005, 1149 . 1151 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1152 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1153 DOI 10.17487/RFC5226, May 2008, 1154 . 1156 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 1157 RFC 6994, DOI 10.17487/RFC6994, August 2013, 1158 . 1160 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1161 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1162 . 1164 12.2. Informative References 1166 [I-D.briscoe-tcpm-inspace-mode-tcpbis] 1167 Briscoe, B., "Inner Space for all TCP Options (Kitchen 1168 Sink Draft - to be Split Up)", draft-briscoe-tcpm-inspace- 1169 mode-tcpbis-00 (work in progress), March 2015. 1171 [I-D.ietf-tcpinc-tcpcrypt] 1172 Bittau, A., Boneh, D., Giffin, D., Hamburg, M., Handley, 1173 M., Mazieres, D., Slack, Q., and E. Smith, "Cryptographic 1174 protection of TCP Streams (tcpcrypt)", draft-ietf-tcpinc- 1175 tcpcrypt-04 (work in progress), January 2017. 1177 [I-D.ietf-tcpinc-use-tls] 1178 Rescorla, E., "Using TLS to Protect TCP Streams", draft- 1179 ietf-tcpinc-use-tls-01 (work in progress), May 2016. 1181 [I-D.ietf-tcpm-tcp-edo] 1182 Touch, J. and W. Eddy, "TCP Extended Data Offset Option", 1183 draft-ietf-tcpm-tcp-edo-07 (work in progress), January 1184 2017. 1186 [I-D.touch-tcpm-tcp-syn-ext-opt] 1187 Touch, J. and T. Faber, "TCP SYN Extended Option Space 1188 Using an Out-of-Band Segment", draft-touch-tcpm-tcp-syn- 1189 ext-opt-06 (work in progress), January 2017. 1191 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1192 Stevens, "Basic Socket Interface Extensions for IPv6", 1193 RFC 3493, DOI 10.17487/RFC3493, February 2003, 1194 . 1196 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1197 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1198 . 1200 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1201 (TLS) Protocol Version 1.2", RFC 5246, 1202 DOI 10.17487/RFC5246, August 2008, 1203 . 1205 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 1206 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1207 RFC 5382, DOI 10.17487/RFC5382, October 2008, 1208 . 1210 [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based 1211 Authentication of Named Entities (DANE)", RFC 6394, 1212 DOI 10.17487/RFC6394, October 2011, 1213 . 1215 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 1216 Digest Access Authentication", RFC 7616, 1217 DOI 10.17487/RFC7616, September 2015, 1218 . 1220 Authors' Addresses 1222 Andrea Bittau 1223 Google 1224 345 Spear Street 1225 San Francisco, CA 94105 1226 US 1228 Email: bittau@google.com 1230 Dan Boneh 1231 Stanford University 1232 353 Serra Mall, Room 475 1233 Stanford, CA 94305 1234 US 1236 Email: dabo@cs.stanford.edu 1238 Daniel B. Giffin 1239 Stanford University 1240 353 Serra Mall, Room 288 1241 Stanford, CA 94305 1242 US 1244 Email: dbg@scs.stanford.edu 1246 Mark Handley 1247 University College London 1248 Gower St. 1249 London WC1E 6BT 1250 UK 1252 Email: M.Handley@cs.ucl.ac.uk 1254 David Mazieres 1255 Stanford University 1256 353 Serra Mall, Room 290 1257 Stanford, CA 94305 1258 US 1260 Email: dm@uun.org 1261 Eric W. Smith 1262 Kestrel Institute 1263 3260 Hillview Avenue 1264 Palo Alto, CA 94304 1265 US 1267 Email: eric.smith@kestrel.edu