idnits 2.17.1 draft-ietf-tcpinc-api-06.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2018) is 2127 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-tcpinc-tcpcrypt-11 == Outdated reference: A later version (-19) exists of draft-ietf-tcpinc-tcpeno-18 -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Bittau 3 Internet-Draft Google 4 Intended status: Informational D. Boneh 5 Expires: December 31, 2018 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 June 29, 2018 15 Interface Extensions for TCP-ENO and tcpcrypt 16 draft-ietf-tcpinc-api-06 18 Abstract 20 TCP-ENO and tcpcrypt perform encryption at the transport layer. They 21 also define a few parameters that are intended to be used or 22 configured by applications. This document specifies operating system 23 interfaces for access to these parameters. We describe the 24 interfaces in terms of socket options, the de facto standard API for 25 adjusting per-connection behavior in TCP/IP, and sysctl, a popular 26 mechanism for setting global defaults. Operating systems that lack 27 socket or sysctl functionality can implement similar interfaces in 28 their native frameworks, but should ideally adapt their interfaces 29 from those presented in this document. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 31, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. TCP-ENO API extensions . . . . . . . . . . . . . . . . . . . 3 67 2.1. Per-connection options . . . . . . . . . . . . . . . . . 3 68 2.2. System-wide options . . . . . . . . . . . . . . . . . . . 7 69 3. tcpcrypt API extensions . . . . . . . . . . . . . . . . . . . 8 70 3.1. Per-connection options . . . . . . . . . . . . . . . . . 8 71 3.2. System-wide options . . . . . . . . . . . . . . . . . . . 9 72 4. Example API mappings . . . . . . . . . . . . . . . . . . . . 9 73 4.1. Socket options for per-connection settings . . . . . . . 10 74 4.2. Setting System-wide options with sysctl . . . . . . . . . 10 75 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 5.1. Cookie-based authentication . . . . . . . . . . . . . . . 11 77 5.2. Signature-based authentication . . . . . . . . . . . . . 11 78 6. Security considerations . . . . . . . . . . . . . . . . . . . 12 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 8.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 The TCP Encryption Negotiation Option (TCP-ENO) 88 [I-D.ietf-tcpinc-tcpeno] permits hosts to negotiate encryption of a 89 TCP connection. One of TCP-ENO's use cases is to encrypt traffic 90 transparently, unbeknownst to legacy applications. Transparent 91 encryption requires no changes to existing APIs. However, other use 92 cases require applications to interact with TCP-ENO. In particular: 94 o Transparent encryption protects only against passive 95 eavesdroppers. Stronger security requires applications to 96 authenticate a _Session ID_ value associated with each encrypted 97 connection. 99 o Applications that have been updated to authenticate Session IDs 100 must somehow advertise this fact to peers in a backward-compatible 101 way. TCP-ENO carries an "application-aware" bit for this purpose, 102 but the bit is not accessible through existing interfaces. 104 o Applications employing TCP's simultaneous open feature need a way 105 to configure a passive-role bit to break symmetry for TCP-ENO. 107 o System administrators and applications may wish to set and examine 108 negotiation preferences, such as which TCP encryption protocols 109 (TEPs) to enable and disable. 111 o Applications that perform their own encryption may wish to disable 112 TCP-ENO entirely. 114 The tcpcrypt protocol [I-D.ietf-tcpinc-tcpcrypt] may be negotiated 115 via TCP-ENO, and can operate without configuration. But users may 116 wish to control a few operational details of the protocol: 118 o Users or system administrators may wish to specify which symmetric 119 ciphers they accept or prefer, or to inspect which cipher has been 120 negotiated for a particular connection. (The key-exchange schemes 121 used by tcpcrypt may be configured via the TCP-ENO API.) 123 o If connection tampering has been detected via session 124 authentication failure, it may be prudent to purge cached session 125 keys. 127 The remainder of this document describes APIs through which systems 128 can meet the above needs. The API extensions relate back to 129 quantities defined by TCP-ENO and tcpcrypt. 131 2. TCP-ENO API extensions 133 This section describes an API for per-connection options, followed by 134 a discussion of system-wide configuration options. 136 2.1. Per-connection options 138 Table 1 summarizes a set of options that TCP-ENO implementations 139 should provide on a per-socket basis. For each option, the table 140 lists whether it is read-only (R) or read-write (RW), as well as the 141 type of the option's value. Read-write options, when read, always 142 return the previously successfully written value or the default if 143 they have not been written. Options of type "bytes" consist of a 144 variable-length array of bytes, while options of type "int" consist 145 of a small integer with the exact range indicated in parentheses. We 146 discuss each option in more detail below. 148 +-----------------------+----+-----------------------+ 149 | Option name | RW | Type | 150 +-----------------------+----+-----------------------+ 151 | TCP_ENO_ENABLED | RW | int (-1, 0, or 1) | 152 | TCP_ENO_SESSID | R | bytes | 153 | TCP_ENO_NEGTEP | R | int (32-127, 160-255) | 154 | TCP_ENO_TEPS | RW | bytes | 155 | TCP_ENO_SELF_GOPT | RW | int (0-31) | 156 | TCP_ENO_PEER_GOPT | R | int (0-31) | 157 | TCP_ENO_AA_MANDATORY | RW | int (0 or 1) | 158 | TCP_ENO_TEP_MANDATORY | RW | int (0 or 1) | 159 | TCP_ENO_ROLE | R | int (0 or 1) | 160 | TCP_ENO_SELF_NAME | R | bytes | 161 | TCP_ENO_PEER_NAME | R | bytes | 162 | TCP_ENO_RAW | RW | bytes | 163 | TCP_ENO_TRANSCRIPT | R | bytes | 164 +-----------------------+----+-----------------------+ 166 Table 1: Suggested per-connection options 168 The socket options must return errors under certain circumstances. 169 These errors are mapped to three suggested error codes shown in 170 Table 2. Systems based on sockets already have constants for these 171 errors. Non-socket systems should use error codes corresponding to 172 the same conditions. "EINVAL" is the existing error returned when 173 attempting to set options or otherwise operate on a socket that has 174 been shut down or is otherwise no longer valid. "EISCONN" 175 corresponds to calling connect a second time, while "ENOTCONN" 176 corresponds to requesting the peer address of an unconnected socket. 178 +----------+--------------------------------------------------------+ 179 | Symbol | Description | 180 +----------+--------------------------------------------------------+ 181 | EINVAL | General error signifying bad parameters | 182 | EISCONN | Option no longer valid because connection established | 183 | ENOTCONN | Option not (yet) valid because no connection | 184 | | established | 185 +----------+--------------------------------------------------------+ 187 Table 2: Suggested error codes 189 With ENO, a connection can be in one of three high-level states: 190 negotiating or ready to negotiate encryption, encrypting, or 191 disabled. Unless otherwise specified, all of the read-only options 192 (R) succeed only when a connection is in the encrypting state. 193 Specifically, attempts to read options should return "ENOTCONN" while 194 the connection is in the negotiating state and "EINVAL" if ENO is 195 disabled. 197 TCP_ENO_ENABLED 198 When set to 0, completely disables TCP-ENO regardless of any other 199 socket option settings except "TCP_ENO_RAW". When set to 1, 200 enables TCP-ENO. When set to -1, uses a system-wide default 201 determined at the time of an "accept" or "connect" system call, as 202 described in Section 2.2. Attempts to set this option must return 203 an error ("EISCONN") after a SYN segment has already been sent. 205 TCP_ENO_SESSID 206 Returns the session ID of the connection, as defined by the 207 encryption spec in use. 209 TCP_ENO_NEGTEP 210 Returns a byte in which the lower 7 bits correspond to the TEP 211 identifier of the negotiated TEP for the current connection, and 212 the high bit is 1 if the "v" bit was set (i.e., there was 213 suboption data present) in the suboption of the SYN segment sent 214 by host "B". 216 TCP_ENO_TEPS 217 Allows the application to specify an ordered list of TEPs to 218 negotiate different from the system default list. If the list is 219 empty, TCP-ENO is disabled for the connection. Each byte in the 220 list specifies one ENO suboption type from 0x20-0x7f (32-127). 221 For future extensibility, the high bit ("v") in these bytes should 222 be set to 0 by applications and ignored by implementations. The 223 order of the list matters only for the host playing the "B" role. 224 Implementations must return an error ("EISCONN") if an application 225 attempts to set this option after the SYN segment has been sent. 226 Implementations should return an error ("EINVAL") if any of the 227 bytes are below 0x20, are between 0x80-0xa0, or are not 228 implemented by the TCP stack. 230 TCP_ENO_SELF_GOPT 231 Gets or sets the 5-bit value of the local host's global suboption. 232 The default value should initially be 0. In accordance the ENO 233 specification, regardless of any value set by the application, the 234 least significant bit--termed the _passive role bit_--is forced to 235 1 when a connection is configured for passive open (i.e., 236 following a "listen" call). Implementations must return an error 237 ("EISCONN") if an application attempts to set this option after a 238 SYN segment has been sent. 240 TCP_ENO_PEER_GOPT 241 Returns an integer from 0-31 reporting the value of the global 242 suboption in the peer's SYN segment. 244 TCP_ENO_AA_MANDATORY 245 If set to 1, enables mandatory application-aware mode in which the 246 local host will disable TCP-ENO unless the remote host has set the 247 application-aware bit (the second-least significant bit in its 248 global suboption). The default value is 0. Implementations must 249 return an error ("EISCONN") if an application attempts to set this 250 option after a SYN segment has been sent. 252 TCP_ENO_TEP_MANDATORY 253 If set to 1, enables mandatory encryption mode in which the local 254 host will abort the entire TCP connection if TCP-ENO fails to 255 negotiate encryption. The default value is 0. Setting this 256 option to 1 may permit optimizations (such as SYN data) that could 257 prevent falling back transparently to unencrypted TCP. 258 Immediately aborts the connection if set to 1 on an established 259 unencrypted connection. 261 TCP_ENO_ROLE 262 Returns 0 on host "A" and 1 on host "B", according to the roles 263 defined by TCP-ENO. When successful, the value is always equal to 264 the least significant bit of the value returned by 265 TCP_ENO_SELF_GOPT. 267 TCP_ENO_SELF_NAME 268 Returns the concatenation of one byte containing the value of 269 TCP_ENO_ROLE (0 or 1) and the TCP_ENO_SESSID, thereby providing a 270 unique name for the local end of the connection. 272 TCP_ENO_PEER_NAME 273 Like TCP_ENO_SELF_NAME, but logically negates the first byte, 274 thereby providing a unique name for the remote end of the 275 connection. (When successful, TCP_ENO_SELF_NAME at one end of a 276 connection should always equal TCP_ENO_PEER_NAME at the other, and 277 vice versa.) 279 TCP_ENO_RAW 280 This option is for use by library-level TEP implementations. It 281 allows applications to make use of the TCP-ENO option for TEPs not 282 supported by the transport layer and then entirely bypass any TCP- 283 level encryption so as to encrypt above the transport layer. The 284 default value of this option is a 0-byte vector, which disables 285 RAW mode. If the option is set to any other value, it disables 286 all other socket options described in this section except for 287 TCP_ENO_TRANSCRIPT. 289 The value of the option is a raw ENO option contents (without the 290 kind and length) to be included in the host's SYN segment. In raw 291 mode, the TCP layer considers negotiation successful when the two 292 SYN segments both contain a suboption with the same TEP identifier 293 "cs" >= 0x20. For an active opener in raw mode, the TCP layer 294 automatically sends a two-byte minimal ENO option when negotiation 295 is successful. Note that raw mode performs no sanity checking on 296 the "v" bits or any suboption data, and hence provides slightly 297 less flexibility than a true TCP-level implementation. 299 TCP_ENO_TRANSCRIPT 300 Returns the negotiation transcript as specified by TCP-ENO. 301 Unlike any of the other read-only options, this option also works 302 in conjunction with "TCP_ENO_RAW" to allow application-layer 303 encryption to determine what was negotiated. 305 2.2. System-wide options 307 In addition to these per-socket options, implementations should use a 308 system-wide configuration mechanism to allow administrators to 309 configure a default value for "TCP_ENO_TEPS", as well as default 310 behavior for when "TCP_ENO_ENABLED" is -1. These defaults can be 311 truly system-wide, or else scoped to a network namespace on systems 312 that provide network namespaces. 314 Table 3 provides a table of suggested parameters. The type "words" 315 corresponds to a list of 16-bit unsigned words representing TCP port 316 numbers (similar to the "baddynamic" sysctls that, on some operating 317 systems, blacklist automatic assignment of particular port numbers). 319 +-----------------------+-------------+ 320 | Name | Type | 321 +-----------------------+-------------+ 322 | eno_teps | bytes | 323 | eno_enable_connect | int (0 - 1) | 324 | eno_enable_listen | int (0 - 1) | 325 | eno_bad_connect_ports | words | 326 | eno_bad_listen_ports | words | 327 +-----------------------+-------------+ 329 Table 3: Suggested system-wide parameters 331 "eno_teps" is simply a string of bytes; it provides the default value 332 for the "TCP_ENO_TEPS" socket option. If "TCP_ENO_TEPS" is non- 333 empty, the remaining sysctls determine whether to attempt TCP-ENO 334 negotiation when the "TCP_ENO_ENABLED" option is -1 (the default), 335 using the following rules. 337 o On active openers: If "eno_enable_connect" is 0, then TCP-ENO is 338 disabled. If the remote port number is in 339 "eno_bad_connect_ports", then TCP-ENO is disabled. Otherwise, the 340 host attempts to use TCP-ENO. 342 o On passive openers: If "eno_enable_listen" is 0, then TCP-ENO is 343 disabled. Otherwise, if the local port is in 344 "eno_bad_listen_ports", then TCP-ENO is disabled. Otherwise, if 345 the host receives an SYN segment with an ENO option containing 346 compatible TEP identifiers, it attempts negotiation. 348 Because initial deployment may run into issues with middleboxes or 349 incur slowdown for unnecessary double-encryption, sites may wish to 350 blacklist particular ports. For example setting 351 "eno_bad_connect_ports" to 443,993 would disable ENO encryption on 352 outgoing connections to ports 443 and 993 (which use application- 353 layer encryption for HTTP and IMAP, respectively). If the per-socket 354 "TCP_ENO_ENABLED" is not -1, it overrides the sysctl values. 356 Similarly, on a server, setting "eno_bad_listen_ports" to 443 makes 357 it possible to disable TCP-ENO for incoming HTTPS connection without 358 modifying the web server to set "TCP_ENO_ENABLED" to 0. 360 3. tcpcrypt API extensions 362 This section recommends further extensions to the API set forth in 363 Section 2 that are specific to the tcpcrypt TEP. Future TEPs may 364 similarly provide TEP-specific options. 366 3.1. Per-connection options 368 +-----------------------+----+-------------+ 369 | Option name | RW | Type | 370 +-----------------------+----+-------------+ 371 | TCP_CRYPT_CONF | R | int (0-255) | 372 | TCP_CRYPT_CACHE_FLUSH | W | int (1) | 373 | TCP_CRYPT_ACONF | RW | bytes | 374 | TCP_CRYPT_BCONF | RW | bytes | 375 +-----------------------+----+-------------+ 377 Table 4: Suggested per-connection tcpcrypt-specific options 379 Table 4 summarizes the proposed tcpcrypt-specific per-connection 380 options. 382 TCP_CRYPT_CONF 383 Returns the one-byte specifier for the authenticated encryption 384 algorithm in use by the connection. 386 TCP_CRYPT_CACHE_FLUSH 387 Setting this option to the value 1 on an unconnected socket 388 disables the use of cached session keys as specified in section 389 "Session caching" of [I-D.ietf-tcpinc-tcpcrypt]. Setting it to 1 390 on an established connection flushes any cache state that was used 391 in or resulted from establishing the connection. 393 TCP_CRYPT_ACONF 394 Set of allowed symmetric ciphers (AEAD algorithms) this host 395 advertises in "Init1" messages. These bytes are encoded exactly 396 as the bytes "sym-cipher0 ... sym-cipherK" in section "Key 397 exchange messages" of [I-D.ietf-tcpinc-tcpcrypt]; that is, each is 398 one of the "sym-cipher" bytes from the table of AEAD algorithms. 399 The order of these bytes is immaterial. 401 TCP_CRYPT_BCONF 402 Order of preference of symmetric ciphers. These bytes are encoded 403 in the same way as for "TCP_CRYPT_ACONF" above, except they 404 indicate the increasing order of preference used to determine 405 which "sym-cipher" value to choose when sending an "Init2" 406 message. 408 3.2. System-wide options 410 +-------------+-------+ 411 | Name | Type | 412 +-------------+-------+ 413 | crypt_aconf | bytes | 414 | crypt_bconf | bytes | 415 +-------------+-------+ 417 Table 5: Suggested tcrypt-specific global parameters 419 System administrators should also be able to set defaults for the 420 per-socket connection parameters. Table 5 lists the system-wide 421 parameters for doing so, which can exist alongside the system-wide 422 ENO parameters described in Table 3. 424 4. Example API mappings 426 The previous sections presented abstract APIs for per-connection and 427 global options. One implementation strategy would be to map these 428 APIs to existing per-socket and global configuration mechanisms. By 429 way of example, this section describes a way to map the per- 430 connection settings to BSD socket options and the global 431 configuration settings to the Unix "sysctl" interface. 433 4.1. Socket options for per-connection settings 435 Systems with sockets can allow applications to configure TCP-ENO 436 through the same mechanism they use for other TCP connection 437 configuration such as "TCP_NODELAY" [RFC0896], namely the 438 "getsockopt" and "setsockopt" system calls shown in Figure 1. 440 int getsockopt(int socket, int level, int option_name, 441 void *option_value, socklen_t *option_len); 443 int setsockopt(int socket, int level, int option_name, 444 const void *option_value, socklen_t option_len); 446 Figure 1: Socket option API 448 Socket-based TCP-ENO implementations can define a set of new 449 "option_name" values accessible at "level" "IPPROTO_TCP" (generally 450 defined as 6, to match the IP protocol field), where each entry in 451 Table 1 corresponds to a unique "option_name" constant. 453 4.2. Setting System-wide options with sysctl 455 User-level implementations of TCP-ENO can use a configuration file to 456 set global options. However, such an approach may be awkward for 457 kernel-based implementations. Instead, kernel-level implementations 458 can use the "sysctl" configuration tool. With this approach, TCP-ENO 459 parameters should be placed alongside most TCP parameters. For 460 example, on BSD derived systems a suitable name would be 461 "net.inet.tcp.eno.teps", while on Linux a more appropriate name would 462 be "net.ipv4.tcp_eno_teps". 464 5. Examples 466 This section provides examples of how applications might authenticate 467 session IDs. Authentication requires exchanging messages over the 468 TCP connection, and hence is not backwards compatible with existing 469 application protocols. To fall back to opportunistic encryption in 470 the event that both applications have not been updated to 471 authenticate the session ID, TCP-ENO provides the application-aware 472 bit. To signal it has been upgraded to support application-level 473 authentication, an application should set the second-least 474 significant bit of "TCP_ENO_SELF_GOPT" before opening a connection. 475 An application should then check that "TCP_ENO_PEER_GOPT" has this 476 bit set before attempting to send authenticators that would otherwise 477 be misinterpreted as application data. 479 5.1. Cookie-based authentication 481 In cookie-based authentication, a client and server both share a 482 cryptographically strong random or pseudo-random pre-shared secret 483 known as a "cookie". Such a cookie is preferably at least 128 bits 484 long. To authenticate a session ID using a cookie, each host 485 computes and sends the following value to the other side: 487 authenticator = PRF(cookie, local-name) 489 Here "PRF" is a pseudo-random function such as HMAC-SHA-256 490 [RFC6234]. "local-name" is the result of the "TCP_ENO_SELF_NAME" 491 socket option. Each side must verify that the other side's 492 authenticator is correct. To do so, software obtains the remote 493 host's name via the "TCP_ENO_PEER_NAME" socket option. Assuming the 494 authenticators are correct, applications can rely on the TCP-layer 495 encryption for resistance against active network attackers. 497 Note that if the same cookie is used in other contexts besides 498 session ID authentication, appropriate domain separation must be 499 employed, such as prefixing "local-name" with a unique prefix to 500 ensure "authenticator" cannot be used out of context. 502 Establishing pre-shared secrets can involve a computational or 503 administrative burden, while computing and verifying PRF-based 504 authenticators is inexpensive. Hence, applications with pre-shared 505 secrets should whenever possible leverage those secrets to achieve 506 mutual authentication by sending one authenticator in each direction. 508 5.2. Signature-based authentication 510 In signature-based authentication, one or both endpoints of a 511 connection possess a private signature key the public half of which 512 is known to or verifiable by the other endpoint. To authenticate 513 itself, a host uses its private key to compute the following 514 signature: 516 authenticator = Sign(PrivKey, local-name) 518 The other end verifies this value using the corresponding public key. 519 Whichever side validates an authenticator in this way knows that the 520 other side belongs to a host that possesses the appropriate signature 521 key. 523 Once again, if the same signature key is used in other contexts 524 besides session ID authentication, appropriate domain separation 525 should be employed, such as prefixing "local-name" with a unique 526 prefix to ensure "authenticator" cannot be used out of context. 528 Note that signature-based authentication can be either mutual, if 529 both sides have public keys, or unidirectional, when one endpoint is 530 anonymous. 532 6. Security considerations 534 The TCP-ENO specification [I-D.ietf-tcpinc-tcpeno] discusses several 535 important security considerations that this document incorporates by 536 reference. The most important one, which bears reiterating, is that 537 until and unless a session ID has been authenticated, TCP-ENO is 538 vulnerable to an active network attacker, through either a downgrade 539 or active man-in-the-middle attack. 541 Because of this vulnerability to active network attackers, it is 542 critical that implementations return appropriate errors as suggested 543 in this document for socket options when TCP-ENO is not enabled. An 544 example of an API design with potentially catastrophic consequences 545 would be to attempt to communicate TCP-ENO failure by successfully 546 returning a zero-length or zero-valued session ID. Equally critical 547 is that applications must never use these socket options without 548 checking for errors. 550 Applications with high security requirements that rely on TCP-ENO for 551 security must either fail or fall back to application-layer 552 encryption if TCP-ENO fails or session ID authentication fails. 554 7. Acknowledgments 556 We are grateful for contributions, help, discussions, and feedback 557 from the TCPINC working group, including Marcelo Bagnulo, David 558 Black, Bob Briscoe, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Yoav 559 Nir, Christoph Paasch, Eric Rescorla, Kyle Rose, and Joe Touch. This 560 work was partially funded by DARPA CRASH and the Stanford Secure 561 Internet of Things Project. 563 8. References 565 8.1. Normative References 567 [I-D.ietf-tcpinc-tcpcrypt] 568 Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 569 Q., and E. Smith, "Cryptographic protection of TCP Streams 570 (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-11 (work in 571 progress), November 2017. 573 [I-D.ietf-tcpinc-tcpeno] 574 Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. 575 Smith, "TCP-ENO: Encryption Negotiation Option", draft- 576 ietf-tcpinc-tcpeno-18 (work in progress), November 2017. 578 8.2. Informative References 580 [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", 581 RFC 896, DOI 10.17487/RFC0896, January 1984, 582 . 584 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 585 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 586 DOI 10.17487/RFC6234, May 2011, 587 . 589 Authors' Addresses 591 Andrea Bittau 592 Google 593 345 Spear Street 594 San Francisco, CA 94105 595 US 597 Email: bittau@google.com 599 Dan Boneh 600 Stanford University 601 353 Serra Mall, Room 475 602 Stanford, CA 94305 603 US 605 Email: dabo@cs.stanford.edu 607 Daniel B. Giffin 608 Stanford University 609 353 Serra Mall, Room 288 610 Stanford, CA 94305 611 US 613 Email: dbg@scs.stanford.edu 614 Mark Handley 615 University College London 616 Gower St. 617 London WC1E 6BT 618 UK 620 Email: M.Handley@cs.ucl.ac.uk 622 David Mazieres 623 Stanford University 624 353 Serra Mall, Room 290 625 Stanford, CA 94305 626 US 628 Email: dm@uun.org 630 Eric W. Smith 631 Kestrel Institute 632 3260 Hillview Avenue 633 Palo Alto, CA 94304 634 US 636 Email: eric.smith@kestrel.edu