idnits 2.17.1 draft-ietf-tcpinc-api-03.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 (July 24, 2017) is 2465 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-06 == Outdated reference: A later version (-19) exists of draft-ietf-tcpinc-tcpeno-08 -- 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: January 25, 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 July 24, 2017 15 Interface Extensions for TCP-ENO and tcpcrypt 16 draft-ietf-tcpinc-api-03 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 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 January 25, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. TCP-ENO API extensions . . . . . . . . . . . . . . . . . . . 3 67 2.1. Per-connection options . . . . . . . . . . . . . . . . . 3 68 2.2. Global options . . . . . . . . . . . . . . . . . . . . . 7 69 3. tcpcrypt API extensions . . . . . . . . . . . . . . . . . . . 8 70 3.1. Per-connection options . . . . . . . . . . . . . . . . . 8 71 3.2. Global 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 . . . . . . . . . . . . . . . . . . . 11 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 8.2. Informative References . . . . . . . . . . . . . . . . . 12 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 encryption schemes (and 109 perhaps versions) 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_NEGSPEC | R | int (32-127, 160-255) | 154 | TCP_ENO_SPECS | 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 existing error codes 172 corresponding to the same conditions. "EINVAL" is the existing error 173 returned when attempting to set options or otherwise operate on a 174 closed socket. "EISCONN" corresponds to calling connect a second 175 time, while "ENOTCONN" corresponds to requesting the peer address of 176 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 Unless otherwise specified, all of the read-only options (R) return 190 an error if ENO is disabled ("EINVAL"), the connection is not yet 191 established ("ENOTCONN"), the connection is established and ENO 192 failed to negotiate encryption ("EINVAL"), or the connection is in 193 raw mode ("EINVAL"). 195 TCP_ENO_ENABLED 196 When set to 0, completely disables TCP-ENO regardless of any other 197 socket option settings except "TCP_ENO_RAW". When set to 1, 198 enables TCP-ENO. When set to -1, uses a system-wide default 199 determined at the time of an "accept" or "connect" system call, as 200 described in Section 2.2. This option must return an error 201 ("EISCONN") after a SYN segment has already been sent. 203 TCP_ENO_SESSID 204 Returns the session ID of the connection, as defined by the 205 encryption spec in use. 207 TCP_ENO_NEGSPEC 208 Returns a byte in which the lower 7 bits correspond to the spec 209 identifier of the negotiated encryption spec for the current 210 connection, and the high bit is 1 if there was suboption data 211 present. As defined by TCP-ENO, the negotiated spec is the last 212 valid TEP suboption in the SYN segment sent by host "B". 214 TCP_ENO_SPECS 215 Allows the application to specify an ordered list of encryption 216 specs different from the system default list. If the list is 217 empty, TCP-ENO is disabled for the connection. Each byte in the 218 list specifies one suboption type from 0x20-0x7f (32-127). For 219 future extensibility, the high bit ("v") in these bytes should be 220 set to 0 by applications and ignored by implementations. The 221 order of the list matters only for the host playing the "B" role. 222 Implementations must return an error ("EISCONN") if an application 223 attempts to set this option after the SYN segment has been sent. 224 Implementations should return an error ("EINVAL") if any of the 225 bytes are below 0x20, are between 0x80-0xa0, or are not 226 implemented by the TCP stack. 228 TCP_ENO_SELF_GOPT 229 Sets the 5-bit value of the hosts global suboption. The default 230 value should initially be 0. In accordance the ENO specification, 231 regardless of any value set by the application, the least 232 significant bit--termed the _passive role bit_--is forced to 1 233 when a connection is configured for passive open (i.e., following 234 a "listen" call). Implementations must return an error 235 ("EISCONN") if an application attempts to set this option after a 236 SYN segment has been sent. 238 TCP_ENO_AA_MANDATORY 239 If set to 1, enables mandatory application-aware mode in which the 240 local host will disable TCP-ENO unless the remote host has set the 241 application-aware bit (the second-least significant bit in its 242 global suboption). The default value is 0. Implementations must 243 return an error ("EISCONN") if an application attempts to set this 244 option after a SYN segment has been sent. 246 TCP_ENO_TEP_MANDATORY 247 If set to 1, enables mandatory encryption mode in which the local 248 host will abort the entire TCP connection if TCP-ENO fails to 249 negotiate encryption. The default value is 0. Setting this 250 option to 1 may permit optimizations (such as SYN data) that could 251 prevent falling back transparently to unencrypted TCP. Causes an 252 immediate connection abort if set to 1 on an established 253 unencrypted connection. 255 TCP_ENO_PEER_GOPT 256 Returns an integer from 0-31 reporting the value of the global 257 suboption in the peer's SYN segment. 259 TCP_ENO_ROLE 260 Returns 0 on host "A" and 1 on host "B", according to the roles 261 defined by TCP-ENO. When successful, the value is always equal to 262 the least significant bit of the value returned by 263 TCP_ENO_SELF_GOPT. 265 TCP_ENO_SELF_NAME 266 Returns one byte containing the value of TCP_ENO_ROLE (0 or 1) 267 prepended to the TCP_ENO_SESSID, thereby providing a unique name 268 for the local end of the connection. 270 TCP_ENO_PEER_NAME 271 Like TCP_ENO_SELF_NAME, but negates the first byte, thereby 272 providing a unique name for the remote end of the connection. 273 (When successful, TCP_ENO_SELF_NAME at one end of a connection 274 should always equal TCP_ENO_PEER_NAME at the other.) 276 TCP_ENO_RAW 277 This option is for use by library-level TEP implementations. It 278 allows applications to make use of the TCP-ENO option, potentially 279 including encryption specs not supported by the transport layer, 280 and then entirely bypass any TCP-level encryption so as to encrypt 281 above the transport layer. The default value of this option is a 282 0-byte vector, which disables RAW mode. If the option is set to 283 any other value, it disables all other socket options described in 284 this section except for TCP_ENO_TRANSCRIPT. 286 The value of the option is a raw ENO option contents (without the 287 kind and length) to be included in the host's SYN segment. In raw 288 mode, the TCP layer considers negotiation successful when the two 289 SYN segments both contain a suboption with the same encryption 290 spec value "cs" >= 0x20. For an active opener in raw mode, the 291 TCP layer automatically sends a two-byte minimal ENO option when 292 negotiation is successful. Note that raw mode performs no sanity 293 checking on the "v" bits or any suboption data, and hence provides 294 slightly less flexibility than a true TCP-level implementation. 296 TCP_ENO_TRANSCRIPT 297 Returns the negotiation transcript as specified by TCP-ENO. 298 Unlike any of the other read-only options, this option works in 299 conjunction with TCP_ENO_RAW to allow application-layer encryption 300 to determine what was negotiated. 302 2.2. Global options 304 In addition to these per-socket options, implementations should use a 305 global configuration mechanism to allow administrators to configure a 306 default value for "TCP_ENO_SPECS", as well as default behavior for 307 when "TCP_ENO_ENABLED" is -1. These defaults can be system-wide, or 308 per network namespace on systems that provide network namespaces. 310 Table 3 provides a table of suggested parameters. The type "words" 311 corresponds to a list of 16-bit unsigned words representing TCP port 312 numbers (similar to the "baddynamic" sysctls that, on some operating 313 systems, blacklist automatic assignment of particular port numbers). 315 +-----------------------+-------------+ 316 | Name | Type | 317 +-----------------------+-------------+ 318 | eno_specs | bytes | 319 | eno_enable_connect | int (0 - 1) | 320 | eno_enable_listen | int (0 - 1) | 321 | eno_bad_connect_ports | words | 322 | eno_bad_listen_ports | words | 323 +-----------------------+-------------+ 325 Table 3: Suggested global parameters 327 "eno_specs" is simply a string of bytes, and provides the default 328 value for the "TCP_ENO_SPECS" socket option. If "TCP_ENO_SPECS" is 329 non-empty, the remaining sysctls determine whether to attempt TCP-ENO 330 negotiation when the "TCP_ENO_ENABLED" option is -1 (the default), 331 using the following rules. 333 o On active openers: If "eno_enable_connect" is 0, then TCP-ENO is 334 disabled. If the remote port number is in 335 "eno_bad_connect_ports", then TCP-ENO is disabled. Otherwise, the 336 host attempts to use TCP-ENO. 338 o On passive openers: If "eno_enable_listen" is 0, then TCP-ENO is 339 disabled. Otherwise, if the local port is in 340 "eno_bad_listen_ports", then TCP-ENO is disabled. Otherwise, if 341 the host receives an SYN segment with an ENO option containing 342 compatible encryption specs, it attempts negotiation. 344 Because initial deployment may run into issues with middleboxes or 345 incur slowdown for unnecessary double-encryption, sites may wish to 346 blacklist particular ports. For example setting 347 "eno_bad_connect_ports" to 443,993 would disable ENO encryption on 348 outgoing connections to ports 443 and 993 (which use application- 349 layer encryption for HTTP and IMAP, respectively). If the per-socket 350 "TCP_ENO_ENABLED" is not -1, it overrides the sysctl values. 352 Similarly, on a server, setting "eno_bad_listen_ports" to 443 makes 353 it possible to disable TCP-ENO for incoming HTTPS connection without 354 modifying the web server to set "TCP_ENO_ENABLED" to 0. 356 3. tcpcrypt API extensions 358 This section recommends further extensions to the API set forth in 359 Section 2 that are specific to the tcpcrypt TEP. Future TEPs may 360 similarly provide TEP-specific options. 362 3.1. Per-connection options 364 +-----------------------+----+-------------+ 365 | Option name | RW | Type | 366 +-----------------------+----+-------------+ 367 | TCP_CRYPT_CONF | R | int (0-255) | 368 | TCP_CRYPT_CACHE_FLUSH | W | int (1) | 369 | TCP_CRYPT_ACONF | RW | bytes | 370 | TCP_CRYPT_BCONF | RW | bytes | 371 +-----------------------+----+-------------+ 373 Table 4: Suggested per-connection tcpcrypt-specific options 375 Table 4 summarizes the proposed tcpcrypt-specific per-connection 376 options. 378 TCP_CRYPT_CONF 379 Returns the one-byte specifier for the authenticated encryption 380 algorithm in use by the connection. 382 TCP_CRYPT_CACHE_FLUSH 383 Setting this option to the value 1 wipes cached session keys as 384 specified in section "Session caching" of 385 [I-D.ietf-tcpinc-tcpcrypt]. Useful if application-level 386 authentication discovers a man in the middle attack, to prevent 387 the next connection from using session caching. 389 TCP_CRYPT_ACONF 390 Set of allowed symmetric ciphers (AEAD algorithms) this host 391 advertises in "Init1" messages. These bytes are encoded exactly 392 as the bytes "sym-cipher0 ... sym-cipherK" in section "Key 393 exchange messages" of [I-D.ietf-tcpinc-tcpcrypt]; that is, each is 394 one of the "sym-cipher" bytes from the table of AEAD algorithms. 395 The order of these bytes is immaterial. 397 TCP_CRYPT_BCONF 398 Order of preference of symmetric ciphers. These bytes are encoded 399 in the same way as for "TCP_CRYPT_ACONF" above, except they 400 indicate the decreasing order of preference used to determine 401 which "sym-cipher" value to choose when sending an "Init2" 402 message. 404 3.2. Global options 406 +-------------+-------+ 407 | Name | Type | 408 +-------------+-------+ 409 | crypt_aconf | bytes | 410 | crypt_bconf | bytes | 411 +-------------+-------+ 413 Table 5: Suggested tcrypt-specific global parameters 415 System administrators should also be able to set defaults for the 416 per-socket connection parameters. Table 5 lists the system-wide 417 parameters for doing so, which can exist along side the general ENO 418 parameters described in Table 3. 420 4. Example API mappings 422 The previous sections presented abstract APIs for per-connection and 423 global options. One implementation strategy would be to map these 424 APIs to existing per-socket and global configuration mechanisms. By 425 way of example, this section describes a way to map the per- 426 connection settings to BSD sockets options and global configuration 427 to the Unix "sysctl" interface. 429 4.1. Socket options for per-connection settings 431 Systems with sockets can allow applications to configure TCP-ENO 432 through the same mechanism they use for other TCP connection 433 configuration such as "TCP_NODELAY" [RFC0896], namely the 434 "getsockopt" and "setsockopt" system calls shown in Figure 1. 436 int getsockopt(int socket, int level, int option_name, 437 void *option_value, socklen_t *option_len); 439 int setsockopt(int socket, int level, int option_name, 440 const void *option_value, socklen_t option_len); 442 Figure 1: Socket option API 444 Socket-based TCP-ENO implementations can define a set of new 445 "option_name" values accessible at "level" "IPPROTO_TCP" (generally 446 defined as 6, to match the IP protocol field), where each entry in 447 Table 1 corresponds to a unique "option_name" constant. 449 4.2. Setting System-wide options with sysctl 451 User-level implementations of TCP-ENO can use a configuration file to 452 set global options. However, such an approach may be awkward for 453 kernel-based implementations. Instead, kernel-level implementations 454 can use the "sysctl" configuration tool. With this approach, TCP-ENO 455 parameters should be placed alongside most TCP parameters. For 456 example, on BSD derived systems a suitable name would be 457 "net.inet.tcp.eno.specs", while on Linux a more appropriate name 458 would be "net.ipv4.tcp_eno_specs". 460 5. Examples 462 This section provides examples of how applications might authenticate 463 session IDs. Authentication requires exchanging messages over the 464 TCP connection, and hence is not backwards compatible with existing 465 application protocols. To fall back to opportunistic encryption in 466 the event that both applications have not been updated to 467 authenticate the session ID, TCP-ENO provides the application-aware 468 bit. To signal it has been upgraded to support application-level 469 authentication, an application should set the second-least 470 significant bit of "TCP_ENO_SELF_GOPT" before opening a connection. 471 An application should then check that "TCP_ENO_PEER_GOPT" has this 472 bit set before attempting to send authenticators that would otherwise 473 be misinterpreted as application data. 475 5.1. Cookie-based authentication 477 In cookie-based authentication, a client and server both share a 478 cryptographically strong random or pseudo-random secret known as a 479 "cookie". Such a cookie is preferably at least 128 bits long. To 480 authenticate a session ID using a cookie, each host computes and 481 sends the following value to the other side: 483 authenticator = PRF(cookie, local-name) 485 Here "PRF" is a pseudo-random function such as HMAC-SHA-256 486 [RFC6234]. "local-name" is the result of the "TCP_ENO_LOCAL_NAME" 487 socket option. Each side must verify that the other side's 488 authenticator is correct. To do so, software obtains the remote 489 host's name via the "TCP_ENO_PEER_NAME" socket option. Assuming the 490 authenticators are correct, applications can rely on the TCP-layer 491 encryption for resistance against active network attackers. 493 Note that if the same cookie is used in other contexts besides 494 session ID authentication, appropriate domain separation must be 495 employed, such as prefixing "local-name" with a unique prefix to 496 ensure "authenticator" cannot be used out of context. 498 5.2. Signature-based authentication 500 In signature-based authentication, one or both endpoints of a 501 connection possess a private signature key the public half of which 502 is known to or verifiable by the other endpoint. To authenticate 503 itself, the host with a private key computes the following signature: 505 authenticator = Sign(PrivKey, local-name) 507 The other end verifies this value using the corresponding public key. 508 Whichever side validates an authenticator in this way knows that the 509 other side belongs to a host that possesses the appropriate signature 510 key. 512 Once again, if the same signature key is used in other contexts 513 besides session ID authentication, appropriate domain separation 514 should be employed, such as prefixing "local-name" with a unique 515 prefix to ensure "authenticator" cannot be used out of context. 517 6. Security considerations 519 The TCP-ENO specification [I-D.ietf-tcpinc-tcpeno] discusses several 520 important security considerations that this document incorporates by 521 reference. The most important one, which bears reiterating, is that 522 until and unless a session ID has been authenticated, TCP-ENO is 523 vulnerable to an active network attacker, through either a downgrade 524 or active man-in-the-middle attack. 526 Because of this vulnerability to active network attackers, it is 527 critical that implementations return appropriate errors as suggested 528 in this document for socket options when TCP-ENO is not enabled. An 529 example of an API design with potentially catastrophic consequences 530 would be to attempt to communicate TCP-ENO failure by successfully 531 returning a zero-length or zero-valued session ID. Equally critical 532 is that applications must never use these socket options without 533 checking for errors. 535 Applications with high security requirements that rely on TCP-ENO for 536 security must either fail or fall back to application-layer 537 encryption if TCP-ENO fails or session ID authentication fails. 539 7. Acknowledgments 541 We are grateful for contributions, help, discussions, and feedback 542 from the TCPINC working group, including Marcelo Bagnulo, David 543 Black, Bob Briscoe, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Yoav 544 Nir, Christoph Paasch, Eric Rescorla, Kyle Rose, and Joe Touch. This 545 work was partially funded by DARPA CRASH and the Stanford Secure 546 Internet of Things Project. 548 8. References 550 8.1. Normative References 552 [I-D.ietf-tcpinc-tcpcrypt] 553 Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 554 Q., and E. Smith, "Cryptographic protection of TCP Streams 555 (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-06 (work in 556 progress), March 2017. 558 [I-D.ietf-tcpinc-tcpeno] 559 Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. 560 Smith, "TCP-ENO: Encryption Negotiation Option", draft- 561 ietf-tcpinc-tcpeno-08 (work in progress), March 2017. 563 8.2. Informative References 565 [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", 566 RFC 896, DOI 10.17487/RFC0896, January 1984, 567 . 569 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 570 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 571 DOI 10.17487/RFC6234, May 2011, 572 . 574 Authors' Addresses 576 Andrea Bittau 577 Google 578 345 Spear Street 579 San Francisco, CA 94105 580 US 582 Email: bittau@google.com 584 Dan Boneh 585 Stanford University 586 353 Serra Mall, Room 475 587 Stanford, CA 94305 588 US 590 Email: dabo@cs.stanford.edu 592 Daniel B. Giffin 593 Stanford University 594 353 Serra Mall, Room 288 595 Stanford, CA 94305 596 US 598 Email: dbg@scs.stanford.edu 600 Mark Handley 601 University College London 602 Gower St. 603 London WC1E 6BT 604 UK 606 Email: M.Handley@cs.ucl.ac.uk 607 David Mazieres 608 Stanford University 609 353 Serra Mall, Room 290 610 Stanford, CA 94305 611 US 613 Email: dm@uun.org 615 Eric W. Smith 616 Kestrel Institute 617 3260 Hillview Avenue 618 Palo Alto, CA 94304 619 US 621 Email: eric.smith@kestrel.edu