idnits 2.17.1 draft-ietf-tcpinc-tcpeno-00.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Implementations MUST not send ENO options unless encryption specs have access to a strong source of randomness or pseudo-randomness. Without secret unpredictable data at both ends of a connection, it is impossible for encryption specs to satisfy the confidentiality and forward secrecy properties required by this document. -- The document date (September 30, 2015) is 3121 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.briscoe-tcpm-inspace-mode-tcpbis' is defined on line 867, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcp-edo-03 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-07 == Outdated reference: A later version (-12) exists of draft-touch-tcpm-tcp-syn-ext-opt-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 6 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 D. Boneh 4 Intended status: Experimental D. Giffin 5 Expires: April 2, 2016 Stanford University 6 M. Handley 7 University College London 8 D. Mazieres 9 Stanford University 10 E. Smith 11 Kestrel Institute 12 September 30, 2015 14 TCP-ENO: Encryption Negotiation Option 15 draft-ietf-tcpinc-tcpeno-00 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 April 2, 2016. 48 Copyright Notice 50 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . 2 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. The TCP-ENO option . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. TCP-ENO roles . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. TCP-ENO handshake . . . . . . . . . . . . . . . . . . . . 7 70 3.2.1. Handshake examples . . . . . . . . . . . . . . . . . 9 71 3.3. General suboptions . . . . . . . . . . . . . . . . . . . 10 72 3.4. Negotiation transcript . . . . . . . . . . . . . . . . . 11 73 4. Requirements for encryption specs . . . . . . . . . . . . . . 12 74 4.1. Session IDs . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.2. Option kind sharing . . . . . . . . . . . . . . . . . . . 14 76 5. API extensions . . . . . . . . . . . . . . . . . . . . . . . 15 77 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 6.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 15 79 6.2. Simultaneous open . . . . . . . . . . . . . . . . . . . . 15 80 6.3. Multiple Session IDs . . . . . . . . . . . . . . . . . . 16 81 6.4. Suboption data . . . . . . . . . . . . . . . . . . . . . 17 82 7. Security considerations . . . . . . . . . . . . . . . . . . . 18 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 87 10.2. Informative References . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Requirements language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Introduction 98 Many applications and protocols running on top of TCP today do not 99 encrypt traffic. This failure to encrypt lowers the bar for certain 100 attacks, harming both user privacy and system security. 101 Counteracting the problem demands a minimally intrusive, backward- 102 compatible mechanism for incrementally deploying encryption. The TCP 103 Encryption Negotiation Option (TCP-ENO) specified in this document 104 provides such a mechanism. 106 While the need for encryption is immediate, future developments could 107 alter trade-offs and change the best approach to TCP-level encryption 108 (beyond introducing new cipher suites). For example: 110 o Increased option space in TCP [I-D.ietf-tcpm-tcp-edo][I-D.briscoe- 111 tcpm-inspace-mode-tcpbis][I-D.touch-tcpm-tcp-syn-ext-opt] could 112 reduce round trip times and simplify protocols. 114 o API revisions to socket interfaces [RFC3493] could benefit from 115 integration with TCP-level encryption, particularly if combined 116 with technologies such as DANE [RFC6394]. 118 o The forthcoming TLS 1.3 [I-D.ietf-tls-tls13] standard could reach 119 more applications given an out-of-band, backward-compatible 120 mechanism for enabling encryption. 122 o TCP fast open [RFC7413], as it gains more widespread adoption and 123 middlebox acceptance, could potentially benefit from tailored 124 encryption support. 126 o Cryptographic developments that either shorten or lengthen the 127 minimal key exchange messages required could affect how such 128 messages are best encoded in TCP segments. 130 Introducing TCP options, extending operating system interfaces to 131 support TCP-level encryption, and extending applications to take 132 advantage of TCP-level encryption will all require effort. To the 133 greatest extent possible, this effort ought to remain applicable if 134 the need arises to change encryption strategies. To this end, it is 135 useful to consider two questions separately: 137 1. How to negotiate the use of encryption at the TCP layer, and 139 2. How to perform encryption at the TCP layer. 141 This document addresses question 1 with a new option called TCP-ENO. 142 TCP-ENO provides a framework in which two endpoints can agree on one 143 among multiple possible TCP encryption _specs_. For future 144 compatibility, encryption specs can vary widely in terms of wire 145 format, use of TCP option space, and integration with the TCP header 146 and segmentation. A companion document, the TCPINC encryption spec, 147 addresses question 2. TCPINC enables TCP-level traffic encryption 148 today. TCP-ENO ensures that the effort invested to deploy TCPINC can 149 benefit future encryption specs should a different approach at some 150 point be preferable. 152 At a lower level, TCP-ENO was designed to achieve the following 153 goals: 155 1. Enable endpoints to negotiate the use of a separately specified 156 encryption _spec_. 158 2. Transparently fall back to unencrypted TCP when not supported by 159 both endpoints. 161 3. Provide signaling through which applications can better take 162 advantage of TCP-level encryption (for instance by improving 163 authentication mechanisms in the presence of TCP-level 164 encryption). 166 4. Provide a standard negotiation transcript through which specs can 167 defend against tampering with TCP-ENO. 169 5. Make parsimonious use of TCP option space. 171 6. Define roles for the two ends of a TCP connection, so as to name 172 each end of a connection for encryption or authentication 173 purposes even following a symmetric simultaneous open. 175 3. The TCP-ENO option 177 TCP-ENO is a TCP option used during connection establishment to 178 negotiate how to encrypt traffic. As an option, TCP-ENO can be 179 deployed incrementally. Legacy hosts unaware of the option simply 180 ignore it and never send it, causing traffic to fall back to 181 unencrypted TCP. Similarly, middleboxes that strip out unknown 182 options including TCP-ENO will downgrade connections to plaintext 183 without breaking them. Of course, downgrading makes TCP-ENO 184 vulnerable to active attackers, but appropriately modified 185 applications can protect themselves by considering the state of TCP- 186 level encryption during authentication, as discussed in Section 7. 188 The ENO option takes two forms. In TCP segments with the SYN flag 189 set, it acts as a container for a series of one or more suboptions, 190 labeled "Opt_0", "Opt_1", ... in Figure 1. In non-SYN segments, ENO 191 conveys only a single bit of information, namely an acknowledgment 192 that the sender received an ENO option in the other host's SYN 193 segment. (Such acknowledgments enable graceful fallback to 194 unencrypted TCP in the event that a middlebox strips ENO options in 195 one direction.) Figure 2 illustrates the non-SYN form of the ENO 196 option. Encryption specs MAY include extra bytes in a non-SYN ENO 197 option, but TCP-ENO itself MUST ignore them. In accordance with TCP 198 [RFC0793], the first two bytes of the ENO option always consist of 199 the kind (ENO) and the total length of the option. 201 byte 0 1 2 3 2+i 3+i ... N-1 202 +-----+-----+-----+-----+--...--+-----+----...----+ 203 |Kind=|Len= |Opt_0|Opt_1| |Opt_i| Opt_i | 204 | ENO | N | | | | | data | 205 +-----+-----+-----+-----+--...--+-----+----...----+ 207 Figure 1: TCP-ENO option in SYN segment (MUST contain at least one 208 suboption) 210 byte 0 1 0 1 2 N-1 211 +-----+-----+ +-----+-----+-----...----+ 212 |Kind=|Len= | |Kind=|Len= | ignored | 213 | ENO | 2 | or | ENO | N | by TCP-ENO | 214 +-----+-----+ +-----+-----+-----...----+ 216 Figure 2: non-SYN TCP-ENO option in segment without SYN flag 218 Every suboption starts with a byte of the form illustrated in 219 Figure 3. The seven-bit value "cs" specifies the meaning of the 220 suboption. Each value of "cs" either specifies general parameters 221 (discussed in Section 3.3) or indicates the willingness to use a 222 specific encryption spec detailed in a separate document. 224 bit 7 6 5 4 3 2 1 0 225 +---+---+---+---+---+---+---+---+ 226 | v | cs | 227 +---+---+---+---+---+---+---+---+ 229 v - 1 when suboption followed by variable-length data 230 cs - global configuration option or encryption spec identifier 232 Figure 3: Format of suboption byte 234 The high bit "v" in a suboption's first byte specifies whether or not 235 the suboption is followed by variable-length data. If "v" is 0, the 236 suboption consists of only the one byte shown in Figure 3. If "v" is 237 1, then the suboption is followed by variable-length data. Suboption 238 data MAY be used for session caching, cipher suite negotiation, key 239 exchange, or other purposes, as determined by the value of "cs". 241 Every suboption but the last in an ENO option MUST be a one-byte 242 suboption (with "v" = 0). The last suboption MAY be a variable- 243 length suboption. Its length is determined by the total length of 244 the TCP option. In Figure 1, "Opt_i" is the variable-length option; 245 its total size is N-(2+i) bytes--one byte for "Opt_i" itself and 246 N-(3+i) bytes for additional data. Multiple suboptions with data may 247 be included in a single TCP SYN segment by repeating the ENO option. 249 Table 1 summarizes the allocation of values of "cs". Values under 250 0x10 are assigned to _general suboptions_ whose meaning applies 251 across encryption specs, as discussed in Section 3.3. Values greater 252 than or equal to 0x20 will be assigned to _spec identifiers_. Values 253 in the range 0x10-0x1f are reserved for possible future general 254 options. Implementations MUST ignore all unknown suboptions. 256 +-----------+-----------------------------------------------------+ 257 | cs | Meaning | 258 +-----------+-----------------------------------------------------+ 259 | 0x00-0x0f | General options (see Section 3.3) | 260 | 0x10-0x1f | Reserved for possible use by future general options | 261 | 0x20-0x7f | Used to designate encryption specs | 262 +-----------+-----------------------------------------------------+ 264 Table 1: Allocation of cs bits in TCP-ENO suboptions 266 3.1. TCP-ENO roles 268 TCP-ENO uses abstract roles to distinguish the two ends of a TCP 269 connection: One host plays the "A" role, while the other host plays 270 the "B" role. Following a normal three-way handshake, the active 271 opener plays the A role and the passive opener plays the B role. An 272 active opener is a host that sends a SYN segment without the ACK flag 273 set (after a "connect" system call on socket-based systems). A 274 passive opener's SYN segment always contains the ACK flag (and 275 follows a "listen" call on socket-based systems). 277 Roles are abstracted from the active/passive opener distinction to 278 deal with simultaneous open, in which both hosts are active openers. 279 For simultaneous open, the general suboptions discussed in 280 Section 3.3 define a tie-breaker bit "b", where the host with "b = 1" 281 plays the B role, and the host with "b = 0" plays the A role. If two 282 active openers have the same "b" bit, TCP-ENO fails and reverts to 283 unencrypted TCP. 285 More precisely, the above role assignment can be reduced to comparing 286 a two-bit role _priority_ for each host, shown in Figure 4. The most 287 significant bit, "p", is 1 for a passive opener and 0 for an active 288 opener. The least-significant bit "b" is the tie-breaker bit. The 289 host with the lower priority assumes the A role; the host with the 290 higher priority assumes the B role. In the event of a tie, TCP-ENO 291 fails and MUST continue with unencrypted TCP as if the ENO options 292 had not been present in SYN segments. 294 bit 1 0 295 +---+---+ 296 | p b | 297 +---+---+ 299 p - 0 for active opener, 1 for passive opener 300 b - b bit from general suboptions sent by host 302 Figure 4: Role priority of an endpoint 304 Encryption specs SHOULD refer to TCP-ENO's A and B roles to specify 305 asymmetric behavior by the two hosts. For the remainder of this 306 document, we will use the terms "host A" and "host B" to designate 307 the hosts with role A and B respectively in a connection. 309 3.2. TCP-ENO handshake 311 The TCP-ENO option is intended for use during TCP connection 312 establishment. To enable incremental deployment, a host needs to 313 ensure both that the other host supports TCP-ENO and that no 314 middlebox has stripped the ENO option from its own TCP segments. In 315 the event that either of these conditions does not hold, 316 implementations MUST immediately cease sending TCP-ENO options and 317 MUST continue with unencrypted TCP as if the ENO option had not been 318 present. 320 More precisely, for negotiation to succeed, the TCP-ENO option MUST 321 be present in the SYN segment sent by each host, so as to indicate 322 support for TCP-ENO. Additionally, the ENO option MUST be present in 323 the first ACK segment sent by each host, so as to indicate that no 324 middlebox stripped the ENO option from the ACKed SYN. Depending on 325 whether a host is an active or a passive opener, the first ACK 326 segment may or may not be the same as the SYN segment. Specifically: 328 o An active opener begins with a SYN-only segment, and hence must 329 send two segments containing ENO options. The initial SYN-only 330 segment MUST contain an ENO option with at least one suboption, as 331 pictured in Figure 1. If ENO succeeds, the active opener's first 332 ACK segment MUST subsequently contain a non-SYN ENO option, as 333 pictured in Figure 2. 335 o A passive opener's first transmitted segment has both the SYN and 336 ACK flags set. Therefore, a passive opener sends an ENO option of 337 the type shown in Figure 1 in its single SYN-ACK segment and does 338 not send a non-SYN ENO option. 340 A spec identifier in one host's SYN segment is _valid_ if it is 341 compatible with a suboption in the other host's SYN segment. Two 342 suboptions are _compatible_ when they have the same "cs" value (>= 343 0x20) and when the particular combination of "v" bits and suboption 344 data in suboptions of the two SYN segments is well-defined by the 345 corresponding encryption spec. Specs MAY allow or disallow any 346 combination of values of "v" in the two SYN segments. 348 Once the two sides have exchanged SYN segments, the _negotiated spec_ 349 is the last valid spec identifier in the SYN segment of host B (that 350 is, the passive opener in the absence of simultaneous open). In 351 other words, the order of suboptions in host B's SYN segment 352 determines spec priority, while the order of suboptions in host A's 353 SYN segment has no effect. Hosts must disable TCP-ENO if there is no 354 valid spec in host B's SYN segment. Note that negotiation 355 prioritizes the last rather than the first valid suboption so as to 356 favor the spec with suboption data, if there is one. 358 When possible, host B SHOULD send only one spec identifier (suboption 359 in the range 0x20-0xff), and SHOULD ensure this option is valid. 360 However, sending a single valid spec identifier is not required, as 361 doing so could be impractical in some cases, such as simultaneous 362 open or library-level implementations that can only provide a static 363 TCP-ENO option to the kernel. 365 A host MUST disable ENO if any of the following conditions holds: 367 1. The host receives a SYN segment without an ENO option, 369 2. The host receives a SYN segment that contains no valid encryption 370 specs when paired with the SYN segment that the host has already 371 sent or would otherwise have sent, 373 3. The host receives a SYN segment containing general suboptions 374 that are incompatible with the SYN segment that it has already 375 sent or would otherwise have sent, or 377 4. The first ACK segment received by a host does not contain an ENO 378 option. 380 After disabling ENO, a host MUST NOT transmit any further ENO options 381 and MUST fall back to unencrypted TCP. 383 Conversely, if a host receives an ACK segment containing an ENO 384 option, then encryption MUST be enabled. From this point the host 385 MUST follow the encryption protocol of the negotiated spec and MUST 386 NOT present raw TCP payload data to the application. In particular, 387 data segments MUST contain ciphertext or key agreement messages as 388 determined by the negotiated spec, and MUST NOT contain plaintext 389 application data. 391 3.2.1. Handshake examples 393 (1) A -> B: SYN ENO 394 (2) B -> A: SYN-ACK ENO 395 (3) A -> B: ACK ENO<> 396 [rest of connection encrypted according to spec for Y] 398 Figure 5: Three-way handshake with successful TCP-ENO negotiation 400 Figure 5 shows a three-way handshake with a successful TCP-ENO 401 negotiation. The two sides agree to follow the encryption spec 402 identified by suboption Y. 404 (1) A -> B: SYN ENO 405 (2) B -> A: SYN-ACK 406 (3) A -> B: ACK 407 [rest of connection unencrypted legacy TCP] 409 Figure 6: Three-way handshake with failed TCP-ENO negotiation 411 Figure 6 shows a failed TCP-ENO negotiation. The active opener (A) 412 indicates support for specs corresponding to suboptions X and Y. 413 Unfortunately, at this point one of thee things occurs: 415 1. The passive opener (B) does not support TCP-ENO, 417 2. B supports TCP-ENO, but supports neither of specs X and Y, and so 418 does not reply with an ENO option, or 420 3. The network stripped the ENO option out of A's SYN segment, so B 421 did not receive it. 423 Whichever of the above applies, the connection transparently falls 424 back to unencrypted TCP. 426 (1) A -> B: SYN ENO 427 (2) B -> A: SYN-ACK ENO [ENO stripped by middlebox] 428 (3) A -> B: ACK 429 [rest of connection unencrypted legacy TCP] 431 Figure 7: Failed TCP-ENO negotiation because of network filtering 433 Figure 7 Shows another handshake with a failed encryption 434 negotiation. In this case, the passive opener B receives an ENO 435 option from A and replies. However, the reverse network path from B 436 to A strips ENO options. Hence, A does not receive an ENO option 437 from B, disables ENO, and does not include the required non-SYN ENO 438 option when ACKing the other host's SYN segment. The lack of ENO in 439 A's ACK segment signals to B that the connection will not be 440 encrypted. At this point, the two hosts proceed with an unencrypted 441 TCP connection. 443 (1) A -> B: SYN ENO 444 (2) B -> A: SYN ENO<0x01,X,Y,Z> 445 (3) A -> B: SYN-ACK ENO 446 (4) B -> A: SYN-ACK ENO<0x01,X,Y,Z> 447 [rest of connection encrypted according to spec for Y] 449 Figure 8: Simultaneous open with successful TCP-ENO negotiation 451 Figure 8 shows a successful TCP-ENO negotiation with simultaneous 452 open. Here the first four segments MUST contain an ENO option, as 453 each side sends both a SYN-only and a SYN-ACK segment. The ENO 454 option in each hosts's SYN-ACK is identical to the ENO option in its 455 SYN-only segment, as otherwise connection establishment could not 456 recover from the loss of a SYN segment. Note the use of the tie- 457 breaker bit in general suboption 0x01 assigns B its role, as 458 discussed in Section 3.3. The last valid spec in B's ENO option is 459 Y, so Y is the negotiated spec. 461 3.3. General suboptions 463 Suboptions 0x00-0x0f are used for general conditions that apply 464 regardless of the negotiated encryption spec. A TCP segment MUST 465 include at most one ENO suboption whose high nibble is 0. The value 466 of the low nibble is interpreted as a bitmask, illustrated in 467 Figure 9. 469 bit 7 6 5 4 3 2 1 0 470 +---+---+---+---+---+-------+---+ 471 | 0 0 0 0 z aa b | 472 +---+---+---+---+---+-------+---+ 474 z - Zero bit (reserved for future use) 475 aa - Application-aware bits 476 b - Tie-breaker bit for simultaneous open 478 Figure 9: Format of the general option byte 480 The fields of the bitmask are interpreted as follows: 482 z The "z" bit is reserved for future revisions of TCP-ENO. Its 483 value MUST be set to zero in sent segments and ignored in received 484 segments. 486 aa The two application-aware bits indicate that the application on 487 the sending host is aware of TCP-ENO and has been extended to 488 alter its behavior in the presence of encrypted TCP. There are 489 four possible values, as shown in Table 2. The default, when 490 applications have not been modified to take advantage of TCP-ENO, 491 MUST be 00. However, implementations SHOULD provide an API 492 through which applications can set the bits to other values and 493 query for the other host's application-aware bits. The value 01 494 indicates that the application is aware of TCP-ENO. The value 10 495 (binary) is reserved for future use. It MUST be interpreted as 496 the application being aware of TCP-ENO, but MUST never be sent. 498 Value 11 (binary) indicates that an application is aware of TCP- 499 ENO and requires application awareness from the other side. If 500 one host sends value 00 and the other host sends 11, then TCP-ENO 501 MUST be disabled and fall back to unencrypted TCP. Any other 502 combination of values (including the reserved 10) is compatible 503 with enabling encryption. A possible use of value 11 is for 504 applications that perform legacy encryption and wish to disable 505 TCP-ENO unless higher-layer encryption can be disabled. 507 +-------+-------------------------------------------------------+ 508 | Value | Meaning | 509 +-------+-------------------------------------------------------+ 510 | 00 | Application is not aware of TCP-ENO | 511 | 01 | Application is aware of TCP-ENO | 512 | 10 | Reserved but interpreted as ENO-aware | 513 | 11 | Application awareness is mandatory for use of TCP-ENO | 514 +-------+-------------------------------------------------------+ 516 Table 2: Meaning of the two application-aware bits 518 b This is the tie-breaker bit in role priority, discussed in 519 Section 3.1. 521 A SYN segment without an explicit general suboption has an implicit 522 general suboption of 0x00. 524 3.4. Negotiation transcript 526 To defend against attacks on encryption negotiation itself, 527 encryption specs need a way to reference a transcript of TCP-ENO's 528 negotiation. In particular, an encryption spec MUST fail with high 529 probability if its selection resulted from tampering with or forging 530 initial SYN segments. 532 TCP-ENO defines its negotiation transcript as a packed data structure 533 consisting of a series of TCP-ENO options (each including the ENO and 534 length bytes, as they appeared in the TCP header). Specifically, the 535 transcript is constructed from the following, in order: 537 1. Every TCP-ENO option in host A's SYN segment, including the kind 538 and length bytes, in the order the options appeared in that SYN 539 segment. 541 2. A minimal two-byte ENO option, as shown on the left in Figure 2. 543 3. Every TCP-ENO option in host B's SYN segment, including the kind 544 and length bytes, in the order the options appeared in that SYN 545 segment. 547 4. A minimal two-byte ENO option, as shown on the left in Figure 2. 549 Note that 2 and 4 merely serve as delimiters to separate the two 550 hosts' options from each other and from any data that follows the 551 transcript. Note further that any ignored data in non-SYN ENO 552 options does not appear in the transcript. Because parts 2 and 4 are 553 always exactly two bytes and SYN segments MUST NOT contain two-byte 554 ENO options, this encoding is unambiguous. 556 For the transcript to be well defined, hosts MUST NOT alter ENO 557 options in retransmitted segments, or between the SYN and SYN-ACK 558 segments of a simultaneous open, except that an active opener MAY 559 remove the ENO option altogether from a retransmitted SYN-only 560 segment and disable TCP-ENO. Such removal could be useful if 561 middleboxes are dropping segments with the ENO option. 563 4. Requirements for encryption specs 565 TCP-ENO was designed to afford encryption spec authors a large amount 566 of design flexibility. Nonetheless, to fit all encryption specs into 567 a coherent framework and abstract most of the differences away for 568 application writers, all encryption specs claiming ENO "cs" numbers 569 MUST satisfy the following properties. 571 o Specs MUST protect TCP data streams with authenticated encryption. 573 o Specs MUST define a session ID whose value identifies the TCP 574 connection and, with overwhelming probability, is unique over all 575 time if either host correctly obeys the spec. Section 4.1 576 describes the requirements of the session ID in more detail. 578 o Specs MUST NOT permit the negotiation of any encryption algorithms 579 with significantly less than 128-bit security. 581 o Specs MUST NOT allow the negotiation of null cipher suites, even 582 for debugging purposes. (Implementations MAY support debugging 583 modes that allow applications to extract their own session keys.) 585 o Specs MUST NOT allow the negotiation of encryption modes that do 586 not provide forward secrecy some bounded, short time after the 587 close of a TCP connection. 589 o Specs MUST protect and authenticate the end-of-file marker 590 traditionally conveyed by TCP's FIN flag when the remote 591 application calls "close" or "shutdown". However, end-of-file MAY 592 be conveyed though a mechanism other than TCP FIN. Moreover, 593 specs MAY permit attacks that cause TCP connections to abort, but 594 such an abort MUST raise an error that is distinct from an end-of- 595 file condition. 597 o Specs MAY disallow the use of TCP urgent data by applications, but 598 MUST NOT allow attackers to manipulate the URG flag and urgent 599 pointer in ways that are visible to applications. 601 4.1. Session IDs 603 Each spec MUST define a session ID that uniquely identifies each 604 encrypted TCP connection. Implementations SHOULD expose the session 605 ID to applications via an API extension. Applications that are aware 606 of TCP-ENO SHOULD incorporate the session ID value and TCP-ENO role 607 (A or B) into any authentication mechanisms layered over TCP 608 encryption so as to authenticate actual TCP endpoints. 610 In order to avoid replay attacks and prevent authenticated session 611 IDs from being used out of context, session IDs MUST be unique over 612 all time with high probability. This uniqueness property MUST hold 613 even if one end of a connection maliciously manipulates the protocol 614 in an effort to create duplicate session IDs. In other words, it 615 MUST be infeasible for a host, even by deviating from the encryption 616 spec, to establish two TCP connections with the same session ID to 617 remote hosts obeying the spec. 619 To prevent session IDs from being confused across specs, all session 620 IDs begin with the negotiated spec identifier--that is, the last 621 valid spec identifier in host B's SYN segment. If the "v" bit was 1 622 in host B's SYN segment, then it is also 1 in the session ID. 623 However, only the first byte is included, not the suboption data. 624 Figure 10 shows the resulting format. This format is designed for 625 spec authors to compute unique identifiers; it is not intended for 626 applications authors to pick apart session IDs. Applications SHOULD 627 treat session IDs as monolithic opaque values and SHOULD NOT discard 628 the first byte to shorten identifiers. 630 byte 0 1 2 N-1 N 631 +-----+------------...------------+ 632 | sub-| collision-resistant hash | 633 | opt | of connection information | 634 +-----+------------...------------+ 636 Figure 10: Format of a session ID 638 Though specs retain considerable flexibility in their definitions of 639 the session ID, all session IDs MUST meet certain minimum 640 requirements. In particular: 642 o The session ID MUST be at least 33 bytes (including the one-byte 643 suboption), though specs may choose longer session IDs. 645 o The session ID MUST depend in a collision-resistant way on fresh 646 data contributed by both sides of the connection. 648 o The session ID MUST depend in a collision-resistant way on any 649 public keys, public Diffie-Hellman parameters, or other public 650 asymmetric cryptographic parameters that are employed by the 651 encryption spec and have corresponding private data that is known 652 by only one side of the connection. 654 o Unless and until applications disclose information about the 655 session ID, all but the first byte MUST be computationally 656 indistinguishable from random bytes to a network eavesdropper. 658 o Applications MAY chose to make session IDs public. Therefore, 659 specs MUST NOT place any confidential data in the session ID (such 660 as data permitting the derivation of session keys). 662 o The session ID MUST depend on the negotiation transcript specified 663 in Section 3.4 in a collision-resistant way. 665 4.2. Option kind sharing 667 This draft does not specify the use of ENO options in any segments 668 other than the initial SYN and ACK segments of a connection. 669 Moreover, it does not specify the content of ENO options in an 670 initial ACK segment that has the SYN flag clear. As a result, any 671 use of the ENO option kind after the SYN exchange will not conflict 672 with TCP-ENO. Therefore, encryption specs that require TCP option 673 space MAY re-purpose the ENO option kind for use in segments after 674 the initial SYN. 676 5. API extensions 678 Implementations SHOULD provide API extensions through which 679 applications can query and configure the behavior of TCP-ENO, 680 including retrieving session IDs, setting and reading application- 681 aware bits, and specifying which specs to negotiate. The specifics 682 of such an API are outside the scope of this document. 684 6. Open issues 686 This document has experimental status because of several open issues. 687 Some questions about TCP-ENO's viability depend on middlebox behavior 688 that can only be determined a posteriori. Hence, initial deployment 689 of ENO will be an experiment. In addition, a few design questions 690 exists on which consensus is not clear, and hence for which greater 691 discussion and justification of TCP-ENO's design may be helpful. 693 6.1. Experiments 695 One of the primary open questions is to what extent middleboxes will 696 permit the use of TCP-ENO. Once TCP-ENO is deployed, we will be in a 697 better position to gather data on two types of failure: 699 1. Middleboxes downgrading TCP-ENO connections to unencrypted TCP. 700 This can happen if middleboxes strip unknown TCP options or if 701 they terminate TCP connections and relay data back and forth. 703 2. Middleboxes causing TCP-ENO connections to fail completely. This 704 can happen if applications perform deep packet inspection and 705 start dropping segments that unexpectedly contain ciphertext. 707 The first type of failure is tolerable since TCP-ENO is designed for 708 incremental deployment anyway. The second type of failure is more 709 problematic, and, if prevalent, will require the development of 710 techniques to avoid and recover from such failures. 712 6.2. Simultaneous open 714 Simultaneous open is the only way to establish a TCP connection 715 between TCP hosts in certain NAT configurations [RFC5382]. The 716 principle challenge in simultaneous open is breaking TCP's symmetry 717 for both sides to agree on the assignment of the A and B roles. 718 Relying on TCP/IP header fields such as the IP address, port number, 719 and initial sequence number is problematic as these values may be 720 modified by middleboxes, meaning a sender does not know what values 721 the recipient will see for these fields. 723 The authors lack data on how prevalent simultaneous open is in the 724 wild. The use of simultaneous open has been specified for ICE 725 [RFC6544], but the highest profile implementation (the firefox 726 browser) currently prefers UDP over TCP when permitted by firewalls. 727 Moreover, applications of ICE typically already encrypt data and 728 would disable TCP-ENO to avoid double encryption. It is therefore 729 unclear what level of support TCP-ENO should provide for simultaneous 730 open, or at what cost such support is justified. The working group 731 has discussed four levels of support with no clear consensus: 733 1. Require applications to break the tie out of band and assign 734 themselves A and B roles. If applications do not assign the 735 roles properly, the TCP connection fails entirely. 737 2. As above, require applications to specify roles, but if they do 738 so incorrectly fall back to unencrypted TCP. 740 3. Require applications to declare that they are using simultaneous 741 open, but do not require them to negotiate roles. Leave it to 742 TCP-ENO break the tie and negotiate roles. 744 4. Design TCP-ENO so that it works completely transparently in 745 conjunction with simultaneous open, with no application 746 involvement required. 748 This simplest and cheapest solution is obviously #1. This document 749 currently embraces design point #2, at the cost of an extra bit (the 750 "b" bit in the general suboption) for hosts to check whether roles 751 were properly assigned. Solution #3 would likely consume 4-8 752 additional bytes of option space in the case of a simultaneous open, 753 so as to include a random tie-breaker value. Solution #4 would 754 consume 4-8 additional bytes of option space in every SYN segment, as 755 current APIs make it impossible to distinguish a "connect" call 756 intended for a simultaneous open from one intended for a three-way 757 handshake. 759 6.3. Multiple Session IDs 761 Though currently specs must output a single session ID, it might 762 alternatively be useful to define multiple identifiers per 763 connection. As an example, a public session ID might be used to 764 authenticate a connection, while a private session ID could be used 765 as an authentication key to link out-of-band data (such as another 766 TCP connection) to the original connection. 768 6.4. Suboption data 770 TCP-ENO currently optimizes for the case that a single suboption per 771 SYN segment contains suboption data. This design was chosen in 772 expectation that the following two use cases will be the most common: 774 o An active opener advertises support for multiple specs using one- 775 byte suboptions. The passive opener picks one of the advertised 776 specs and replies with a single suboption, possibly using 777 suboption data for options within the negotiated spec. Such spec- 778 specific options might convey supported elliptic curves or public 779 key ciphers. 781 o An active opener advertises support for multiple specs as above, 782 but also includes a single longer suboption containing a session 783 caching cookie with which the hosts may be able to avoid the cost 784 of public key cryptography. In this case, the server either 785 accepts the cookie or reverts to picking one of the other specs as 786 in the previous case. 788 Both of these use cases require at most one multi-byte suboption per 789 SYN segment. To optimize for this case, TCP-ENO relies on the TCP 790 option length byte to specify the length of the multi-byte suboption 791 implicitly. Segments with more than one multi-byte suboption must 792 repeat the ENO kind byte, losing one byte of precious TCP SYN option 793 space. 795 An alternative would be for each multi-byte suboption to be followed 796 by its own length field. This would cost an extra byte of SYN option 797 space in the two cases above, but save one byte for each additional 798 multi-byte suboption. 800 As an example, in the current ENO design, a SYN segment with ENO 801 suboption containing 2 bytes of data consumes 5 bytes (the ENO kind, 802 the TCP option length, the spec identifier, and 2 bytes of suboption 803 data). An ENO option with two 2-byte suboptions requires double 804 this, or 10 bytes. By contrast, in a design with a suboption length 805 byte, one 2-byte suboption would cost 6 bytes (ENO kind, TCP option 806 length, suboption, suboption length, and 2 bytes of option data), but 807 two 2-byte suboptions could be packed together, without repeating the 808 ENO kind byte, in only 9 bytes of option space. 810 In the event that the above two use cases are not the most prevalent, 811 it may be worth revisiting ENO's choice of optimized case. 813 7. Security considerations 815 An obvious use case for TCP-ENO is opportunistic encryption. 816 However, if applications do not check and verify the session ID, they 817 will be open to man-in-the-middle attacks as well as simple downgrade 818 attacks in which an attacker strips off the TCP-ENO option. Hence, 819 where possible, applications SHOULD be modified to fold the session 820 ID into authentication mechanisms, and SHOULD employ the application- 821 aware bits as needed to enable such negotiation in a backward- 822 compatible way. 824 Because TCP-ENO enables multiple different encryption specs to 825 coexist, security could potentially be only as strong as the weakest 826 available encryption spec. For this reason, it is crucial for 827 session IDs to depend on the TCP-ENO transcript in a strong way. 828 Hence, encryption specs SHOULD compute session IDs using only well- 829 studied and conservative hash functions. Thus, even if an encryption 830 spec is broken, and even if people deprecate it instead of disabling 831 it, and even if an attacker tampers with ENO options to force 832 negotiation of the broken spec, it should still be intractable for 833 the attacker to induce identical session IDs at both hosts. 835 Implementations MUST not send ENO options unless encryption specs 836 have access to a strong source of randomness or pseudo-randomness. 837 Without secret unpredictable data at both ends of a connection, it is 838 impossible for encryption specs to satisfy the confidentiality and 839 forward secrecy properties required by this document. 841 8. IANA Considerations 843 A new TCP option kind number needs to be assigned to ENO by IANA. 845 In addition, IANA will need to maintain an ENO suboption registry 846 mapping suboption "cs" values to encryption specs. 848 9. Acknowledgments 850 This work was funded by DARPA CRASH under contract #N66001-10-2-4088. 852 10. References 854 10.1. Normative References 856 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 857 793, DOI 10.17487/RFC0793, September 1981, 858 . 860 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 861 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 862 RFC2119, March 1997, 863 . 865 10.2. Informative References 867 [I-D.briscoe-tcpm-inspace-mode-tcpbis] 868 Briscoe, B., "Inner Space for all TCP Options (Kitchen 869 Sink Draft - to be Split Up)", draft-briscoe-tcpm-inspace- 870 mode-tcpbis-00 (work in progress), March 2015. 872 [I-D.ietf-tcpm-tcp-edo] 873 Touch, J. and W. Eddy, "TCP Extended Data Offset Option", 874 draft-ietf-tcpm-tcp-edo-03 (work in progress), April 2015. 876 [I-D.ietf-tls-tls13] 877 Rescorla, E., "The Transport Layer Security (TLS) Protocol 878 Version 1.3", draft-ietf-tls-tls13-07 (work in progress), 879 July 2015. 881 [I-D.touch-tcpm-tcp-syn-ext-opt] 882 Touch, J. and T. Faber, "TCP SYN Extended Option Space 883 Using an Out-of-Band Segment", draft-touch-tcpm-tcp-syn- 884 ext-opt-02 (work in progress), April 2015. 886 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 887 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 888 3493, DOI 10.17487/RFC3493, February 2003, 889 . 891 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 892 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 893 RFC5246, August 2008, 894 . 896 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 897 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 898 RFC 5382, DOI 10.17487/RFC5382, October 2008, 899 . 901 [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based 902 Authentication of Named Entities (DANE)", RFC 6394, DOI 903 10.17487/RFC6394, October 2011, 904 . 906 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 907 "TCP Candidates with Interactive Connectivity 908 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 909 March 2012, . 911 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 912 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 913 . 915 Authors' Addresses 917 Andrea Bittau 918 Stanford University 919 353 Serra Mall, Room 288 920 Stanford, CA 94305 921 US 923 Email: bittau@cs.stanford.edu 925 Dan Boneh 926 Stanford University 927 353 Serra Mall, Room 475 928 Stanford, CA 94305 929 US 931 Email: dabo@cs.stanford.edu 933 Daniel B. Giffin 934 Stanford University 935 353 Serra Mall, Room 288 936 Stanford, CA 94305 937 US 939 Email: dbg@scs.stanford.edu 941 Mark Handley 942 University College London 943 Gower St. 944 London WC1E 6BT 945 UK 947 Email: M.Handley@cs.ucl.ac.uk 948 David Mazieres 949 Stanford University 950 353 Serra Mall, Room 290 951 Stanford, CA 94305 952 US 954 Email: dm@uun.org 956 Eric W. Smith 957 Kestrel Institute 958 3260 Hillview Avenue 959 Palo Alto, CA 94304 960 US 962 Email: eric.smith@kestrel.edu