idnits 2.17.1 draft-rescorla-tcpinc-tls-option-05.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([RFC5246], [I-D.bittau-tcpinc-tcpeno]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 19, 2015) is 3113 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ENO' is mentioned on line 99, but not defined == Missing Reference: 'TLS' is mentioned on line 108, but not defined == Unused Reference: 'I-D.ietf-tls-applayerprotoneg' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-chacha20-poly1305' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'I-D.bittau-tcp-crypt' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-falsestart' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'RFC5929' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'RFC6919' is defined on line 726, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental draft: draft-bittau-tcpinc-tcpeno (ref. 'I-D.bittau-tcpinc-tcpeno') == Outdated reference: A later version (-04) exists of draft-ietf-tls-chacha20-poly1305-00 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-10 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-curves (ref. 'I-D.irtf-cfrg-curves') ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5869 == Outdated reference: A later version (-02) exists of draft-ietf-tls-falsestart-00 Summary: 6 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPING E. Rescorla 3 Internet-Draft Mozilla 4 Intended status: Standards Track October 19, 2015 5 Expires: April 21, 2016 7 TCP Use TLS Option 8 draft-rescorla-tcpinc-tls-option-05 10 Abstract 12 This document defines the use of TLS [RFC5246] with the TCP-ENO 13 option [I-D.bittau-tcpinc-tcpeno]. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 21, 2016. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. TLS Profile . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. TLS 1.3 Profile . . . . . . . . . . . . . . . . . . . . . 4 53 3.1.1. Handshake Modes . . . . . . . . . . . . . . . . . . . 4 54 3.1.2. Basic 1-RTT Handshake . . . . . . . . . . . . . . . . 5 55 3.1.3. Hello Retry Request [6.3.1.3] . . . . . . . . . . . . 8 56 3.1.4. Zero-RTT Exchange . . . . . . . . . . . . . . . . . . 9 57 3.1.5. Key Schedule . . . . . . . . . . . . . . . . . . . . 10 58 3.1.6. Record Protection . . . . . . . . . . . . . . . . . . 11 59 3.2. TLS 1.2 Profile . . . . . . . . . . . . . . . . . . . . . 11 60 3.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 12 61 3.4. Session ID . . . . . . . . . . . . . . . . . . . . . . . 12 62 3.5. Cryptographic Algorithms . . . . . . . . . . . . . . . . 12 63 4. Suboption Definition . . . . . . . . . . . . . . . . . . . . 12 64 5. Transport Integrity . . . . . . . . . . . . . . . . . . . . . 12 65 6. Implementation Options . . . . . . . . . . . . . . . . . . . 13 66 7. NAT/Firewall considerations . . . . . . . . . . . . . . . . . 13 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 71 10.2. Informative References . . . . . . . . . . . . . . . . . 16 73 1. Introduction 75 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this 76 draft is maintained in GitHub. Suggested changes should be submitted 77 as pull requests at https://github.com/ekr/tcpinc-tls. Instructions 78 are on that page as well. 80 The TCPINC WG is chartered to define protocols to provide ubiquitous, 81 transparent security for TCP connections. The WG is specifying The 82 TCP Encryption Negotiation Option (TCP-ENO) 83 [I-D.bittau-tcpinc-tcpeno] which allows for negotiation of encryption 84 at the TCP layer. This document describes a binding of TLS [RFC5246] 85 to TCP-ENO as what ENO calls an "encryption spec", thus allowing TCP- 86 ENO to negotiate TLS. 88 2. Overview 90 The basic idea behind this draft is simple. The SYN and SYN/ACK 91 messages carry the TCP-ENO options indicating the willingness to do 92 TLS. If both sides want to do TLS, then a TLS handshake is started 93 and once that completes, the data is TLS protected prior to being 94 sent over TCP. Otherwise, the application data is sent as usual. 96 Client Server 98 SYN + TCP-ENO [TLS]-> 99 <- SYN/ACK + TCP-ENO [ENO] 100 ACK -> 101 <---------------- TLS Handshake ---------------> 102 <--------- Application Data over TLS ----------> 104 Figure 1: Negotiating TLS with TCP-TLS 106 Client Server 108 SYN + TCP-ENO [TLS] -> 109 <- SYN/ACK 110 ACK -> 111 <--------- Application Data over TLS ----------> 113 Figure 2: Fall back to TCP 115 If use of TLS is negotiated, the data sent over TCP simply is TLS 116 data in compliance with TLS 1.2 [RFC5246] or TLS 1.3 117 [I-D.ietf-tls-tls13]. 119 Once the TLS handshake has completed, all application data SHALL be 120 sent over that negotiated TLS channel. Application data MUST NOT be 121 sent prior to the TLS handshake. 123 If the TLS handshake fails for non-cryptographic reasons such as 124 failure to negotiate a compatible cipher or the like, endpoints 125 SHOULD behave as if the the TCP-TLS option was not present. This is 126 obviously not the conventional behavior for TLS failure, but as the 127 entire idea here is to be opportunistic and the attacker can simply 128 suppress the TCP-TLS option entirely, this provides the maximum 129 robustness against broken intermediaries. If the TLS handshake fails 130 for cryptographic reasons that indicate damage to the datastream 131 (e.g., a decryption failure or a Finished failure) then the endpoints 132 SHOULD signal a connection failure, as this suggests that there is a 133 middlebox modifying the data and there is a reasonable chance that 134 the state is now corrupted. 136 3. TLS Profile 138 The TLS Profile defined in this document is intended to be a 139 compromise between two separate use cases. For the straight TCPINC 140 use case of ubiquitous transport encryption, we desire that 141 implementations solely implement TLS 1.3 [I-D.ietf-tls-tls13] or 142 greater. However, we also want to allow the use of TCP-ENO as a 143 signal for applications to do out-of-band negotiation of TLS, and 144 those applications are likely to already have support for TLS 1.2 145 [RFC5246]. In order to accomodate both cases, we specify a wire 146 encoding that allows for negotiation of multiple TLS versions 147 (Section 4) but encourage implementations to implement only TLS 1.3. 148 Implementations which also implement TLS 1.2 MUST implement the 149 profile described in Section 3.2 151 3.1. TLS 1.3 Profile 153 TLS 1.3 is the preferred version of TLS for this specification. In 154 order to facilitate implementation, this section provides a non- 155 normative description of the parts of TLS 1.3 which are relevant to 156 TCPINC and defines a baseline of algorithms and modes which MUST be 157 supported. Other modes, cipher suites, key exchange algorithms, 158 certificate formats as defined in [I-D.ietf-tls-tls13] MAY also be 159 used and that document remains the normative reference for TLS 1.3. 160 Bracketed references (e.g., [S. 1.2.3.4] refer to the corresponding 161 section in that document.) In order to match TLS terminology, we use 162 the term "client" to indicate the TCP-ENO "A" role (See 163 [I-D.bittau-tcpinc-tcpeno]; Section 3.1) and "server" to indicate the 164 "B" role. 166 3.1.1. Handshake Modes 168 TLS 1.3 as used in TCPINC supports two handshake modes, both based on 169 ECDHE key exchange. 171 o A 1-RTT mode which is used when the client has no information 172 about the server's keying material (see Figure 1) 174 o A 0-RTT mode which is used when the client and server have 175 connected previous and which allows the client to send data on the 176 first flight (see Figure 2 178 In both case, the server is expected to have an ECDSA signing key 179 which may either be a freshly-generated key or a long-term key 180 (allowing TOFU-style applications). The key need not be associated 181 with any certificate and can simply be a bare key. 183 Full TLS 1.3 includes support for additional modes based on pre- 184 shared keys, but TCPINC implementations MAY opt to omit them. 185 Implementations MUST implement the 1-RTT mode and SHOULD implement 186 the 0-RTT mode. 188 Client Server 190 ClientHello 191 + ClientKeyShare --------> 192 ServerHello 193 ServerKeyShare 194 {EncryptedExtensions} 195 {ServerConfiguration*} 196 {Certificate} 197 {CertificateVerify} 198 <-------- {Finished} 199 {Finished} --------> 200 [Application Data] <-------> [Application Data] 202 * Indicates optional or situation-dependent 203 messages that are not always sent. 205 {} Indicates messages protected using keys 206 derived from the ephemeral secret. 208 [] Indicates messages protected using keys 209 derived from the master secret. 211 Figure 1: Message flow for full TLS Handshake 213 Note: Although these diagrams indicate a message called 214 "Certificate", this message MAY either contain a bare public key or 215 an X.509 certificate (this is intended to support the out-of-band use 216 case indicated above). Implementations MUST support bare public keys 217 and MAY support X.509 certificates. 219 3.1.2. Basic 1-RTT Handshake 221 3.1.2.1. Client's First Flight 223 3.1.2.1.1. Sending 225 In order to initiate the TLS handshake, the client sends a 226 "ClientHello" message [S. 6.3.1.1]. 228 struct { 229 ProtocolVersion client_version = { 3, 4 }; /* TLS v1.3 */ 230 Random random; 231 uint8 session_id_len_RESERVED; /* Must be zero */ 232 CipherSuite cipher_suites<2..2^16-2>; 233 uint8 compression_methods_len_RESERVED; /* Must be zero */ 234 Extension extensions<0..2^16-1>; 235 } ClientHello; 237 The fields listed here have the following meanings: 239 client_version 240 The version of the TLS protocol by which the client wishes to 241 communicate during this session. 243 random 244 A 32-byte random nonce. 246 cipher_suites 247 This is a list of the cryptographic options supported by the 248 client, with the client's first preference first. 250 extensions contains a set of extension fields. The client MUST 251 include the following extensions: 253 SignatureAlgorithms [S. 6.3.2.1] 254 A list of signature/hash algorithm pairs the client supports. 256 NamedGroup [S. 6.3.2.2] 257 A list of ECDHE groups that the client supports 259 ClientKeyShare [S. 6.3.2.3] 260 Zero or more ECDHE shares drawn from the groups in NamedGroup. 261 This SHOULD contain either a P-256 key or an X25519 key. 263 The client MUST also include a ServerCertTypeExtension containing 264 type "Raw Public Key" [RFC7250], indicating its willingness to accept 265 a raw public key rather than an X.509 certificate in the server's 266 Certificate message. 268 3.1.2.1.2. Receiving 270 Upon receiving the client's ClientHello, the server selects a 271 ciphersuite and ECDHE group out of the lists provided by the client 272 in the cipher_suites list and the NamedGroup extension. If the 273 client supplied an appropriate ClientKeyShare for that group, then 274 the server responds with a ServerHello (see {{server-first-flight). 275 Otherwise, it replies with a HelloRetryRequest (Section 3.1.3), 276 indicating that the client needs to re-send the ClientHello with an 277 appropriate key share; because all TCPINC implementations are 278 required to support P-256, this should not happen unless P-256 is 279 deprecated by a subsequent specification. 281 3.1.2.2. Server's First Flight 283 3.1.2.2.1. Sending 285 The server respond's to the client's first flight with a sequence of 286 messages: 288 ServerHello [6.3.1.2] 289 Contains a nonce and the cipher suite that the server has selected 290 out of the client's list. The server MUST support the extensions 291 listed in Section 3.1.2.1.1 and MUST also ignore any extensions it 292 does not recognize; this implies that the server can implement 293 solely the extensions listed in Section 3.1.2.1.1. 295 ServerKeyShare [6.3.3] 296 Contains the server's ECDHE share for one of the groups offered in 297 the client's ClientKeyShare message. All messages after 298 ServerKeyShare are encrypted using keys derived from the 299 ClientKeyShare and ServerKeyShare. 301 EncryptedExtensions [6.3.4] 302 Responses to the extensions offered by the client. In this case, 303 the only relevant extension is the ServerCertTypeExtension. 305 Certificate [6.3.5] 306 The server's certificate. If the client offered a "Raw Public 307 Key" type in ServerCertTypeExtension this message SHALL contain a 308 SubjectPublicKeyInfo value for the server's key as specified in 309 [RFC7250]. Otherwise, it SHALL contain one or more X.509 310 Certificates, as specified in [I-D.ietf-tls-tls13], Section 6.3.5. 311 In either case, this message MUST contain a key which is 312 consistent with the client's SignatureAlgorithms and NamedGroup 313 extensions. 315 ServerConfiguration [6.3.7] 316 A server configuration value for use in 0-RTT (see Section 3.1.4). 318 CertificateVerify [6.3.8] 319 A signature over the handshake transcript using the key provided 320 in the certificate message. 322 Finished [6.3.9] 323 A MAC over the entire handshake transcript up to this point. 325 Once the server has sent the Finished message, it can immediately 326 generate the application traffic keys and start sending application 327 traffic to the client. 329 3.1.2.3. Receiving 331 Upon receiving the server's first flight, the client proceeds as 332 follows: 334 o Read the ServerHello message to determine the cryptographic 335 parameters. 337 o Read the ServerKeyShare message and use that in combination with 338 the ClientKeyShare to compute the keys which are used to encrypt 339 the rest of the handshake. 341 o Read the EncryptedExtensions message. As noted above, the main 342 extension which needs to be processed is ServerCertTypeExtension, 343 which indicates the format of the server's certificate message. 345 o Read the server's certificate message and store the server's 346 public key. Unless the implementation is specifically configured 347 otherwise, it SHOULD NOT attempt to validate the certificate, even 348 if it is of type X.509 but merely extract the key. 350 o Read the server's CertificateVerify message and verify the 351 server's signature over the handshake transcript. If the 352 signature does not verify, the client terminates the handshake 353 with an alert (Section 6.1.2). 355 o Read the server's Finished message and verify the finished MAC 356 based on the DH shared secret. If the MAC does not verify, the 357 client terminates the handshake with an alert. 359 3.1.2.4. Client's Second Flight 361 Finally, the client sends a Finished message which contains a MAC 362 over the handshake transcript (except for the server's Finished). 363 [[TODO: In the upcoming draft of TLS 1.3, the client's Finished will 364 likely include the server's Finished.]] Once the client has 365 transmitted the Finished, it can begin sending encrypted traffic to 366 the server. 368 The server reads the client's Finished message and verifies the MAC. 369 If the MAC does not verify, the client terminates the handshake with 370 an alert. 372 3.1.3. Hello Retry Request [6.3.1.3] 374 Because there are a small number of recommended groups, the 375 ClientKeyShare will generally contain a key share for a group that 376 the server supports. However, it is possible that the client will 377 not send such a key share, but there may be another group that the 378 client and server jointly support. In that case, the server MUST 379 send a HelloRetryRequest indicating the desired group: 381 struct { 382 ProtocolVersion server_version; 383 CipherSuite cipher_suite; 384 NamedGroup selected_group; 385 Extension extensions<0..2^16-1>; 386 } HelloRetryRequest; 388 In response to the HelloRetryRequest the client re-sends its 389 ClientHello but with the addition of the group indicated in 390 "selected_group". 392 3.1.4. Zero-RTT Exchange 394 TLS 1.3 allows the server to send its first application data message 395 to the client immediately upon receiving the client's first handshake 396 message (which the client can send upon receiving the server's SYN/ 397 ACK). However, in the basic handshake, the client is required to 398 wait for the server's first flight before it can send to the server. 399 TLS 1.3 also includes a "Zero-RTT" feature which allows the client to 400 send data on its first flight to the server. 402 In order to enable this feature, in an initial handshake the server 403 sends a ServerConfiguration message which contains the server's semi- 404 static (EC)DH key which can be used for a future handshake: 406 struct { 407 opaque configuration_id<1..2^16-1>; 408 uint32 expiration_date; 409 NamedGroup group; 410 opaque server_key<1..2^16-1>; 411 EarlyDataType early_data_type; 412 ConfigurationExtension extensions<0..2^16-1>; 413 } ServerConfiguration; 415 The group and server_key fields contain the server's (EC)DH key and 416 the early_data_type field is used to indicate what data can be sent 417 in zero-RTT. Because client authentication is forbidden in TCPINC- 418 uses of TLS 1.3 (see Section 3.3), the only valid value here is 419 "early_data", indicating that the client can send data in 0-RTT. 421 When a ServerConfiguration is available, the client can send an 422 EarlyDataIndication extension in its ClientHello and then start 423 sending data immediately, as shown below. 425 Client Server 427 ClientHello 428 + ClientKeyShare 429 + EarlyDataIndication 430 (EncryptedExtensions) 431 (Application Data) --------> 432 ServerHello 433 + EarlyDataIndication 434 ServerKeyShare 435 {EncryptedExtensions} 436 {ServerConfiguration*} 437 {Certificate} 438 {CertificateVerify} 439 <-------- {Finished} 440 {Finished} --------> 442 [Application Data] <-------> [Application Data] 444 () Indicates messages protected using keys 445 derived from the static secret. 447 Figure 2: Message flow for a zero round trip handshake 449 IMPORTANT NOTE: TLS 1.3 Zero-RTT data is inherently replayable (see 450 the note in [I-D.ietf-tls-tls13] Section 6.2.2). If only passive 451 threat models are relevant, this issue becomes less important. 452 However, if applications are performing an external channel binding 453 using the session id to prevent active attack, then care must be 454 taken to prevent this form of attack. See Section 6.2.2 of 455 [I-D.ietf-tls-tls13] for more information on this topic. [[OPEN 456 ISSUE: can we use data from the TCP SYN as anti-replay stuff.]] 458 3.1.5. Key Schedule 460 TLS 1.3 derives its traffic keys from two input keying material 461 values: 463 Ephemeral Secret (ES): A secret which is derived from ClientKeyShare 464 and ServerKeyShare. 466 Static Secret (SS): A secret which which is derived from 467 ClientKeyShare and either ServerKeyShare (in the 1-RTT case) or the 468 public key in the ServerConfiguration (in the 0-RTT case). 470 The handshake is encrypted under keys derived from ES. The ordinary 471 traffic keys are derived from the combination of ES and SS. The 472 0-RTT traffic keys are derived solely from ES and therefore have 473 limited forward security. All key derivation is done using HKDF 474 [RFC5869]. 476 3.1.6. Record Protection 478 Once the TLS handshake has completed, all data is protected as a 479 series of TLS Records. 481 struct { 482 ContentType opaque_type = application_data(23); /* see fragment.type */ 483 ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ 484 uint16 length; 485 aead-ciphered struct { 486 opaque content[TLSPlaintext.length]; 487 ContentType type; 488 uint8 zeros[length_of_padding]; 489 } fragment; 490 } TLSCiphertext; 492 Each record is encrypted with an AEAD cipher with the following 493 parameters: 495 o The AEAD nonce is constructed by generating a per-connection nonce 496 mask of length max(8 bytes, N_MIN) for the AEAD algorithm (see 497 [RFC5116] Section 4) and XORing it with the record sequence number 498 (left-padded with zeroed). 500 o The additional data is the sequence number + the TLS version 501 number. 503 The record data MAY BE padded with zeros to the right. Because the 504 content type value is always non-zero, the padding is removed by 505 removing bytes from the right until a non-zero byte is encountered. 507 3.2. TLS 1.2 Profile 509 Implementations MUST implement and require the TLS Extended Master 510 Secret Extension [I-D.ietf-tls-session-hash] and MUST NOT negotiate 511 versions of TLS prior to TLS 1.2. Implementations MUST NOT negotiate 512 non-AEAD cipher suites and MUST use only PFS cipher suites with a key 513 of at least 2048 bits (finite field) or 256 bites (elliptic curve). 514 TLS 1.2 implementations MUST NOT initiate renegotiation and MUST 515 respond to renegotiation with a fatal "no_renegotiation" alert. 517 3.3. Deprecated Features 519 When TLS is used with TCPINC, a number of TLS features MUST NOT be 520 used, including: 522 o TLS certificate-based client authentication 524 o Session resumption [????] 526 3.4. Session ID 528 TCP-ENO Section 4.1 defines a session ID feature (not to be confused 529 with TLS Session IDs). When the protocol in use is TLS, the session 530 ID is computed via a TLS Exporter [RFC5705] using the Exporter Label 531 [[TBD]] and with the "context" input being the TCP-ENO negotiation 532 transcript defined in [I-D.bittau-tcpinc-tcpeno] Section 3.4. 534 3.5. Cryptographic Algorithms 536 Implementations of this specification MUST implement the following 537 cipher suite: 539 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 541 These cipher suites MUST support both digital signatures and key 542 exchange with secp256r1 (NIST P-256) and SHOULD support key agrement 543 with X25519 [I-D.irtf-cfrg-curves]. 545 Implementations of this specification SHOULD implement the following 546 cipher suites: 548 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 549 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 551 4. Suboption Definition 553 This document uses a one byte TCP-ENO suboption. See Section 8. 555 5. Transport Integrity 557 The basic operational mode defined by TCP-TLS protects only the 558 application layer content, but not the TCP segment metadata. Upon 559 receiving a packet, implementations MUST first check the TCP checksum 560 and discard corrupt packets without presenting them to TLS. If the 561 TCP checksum passes but TLS integrity fails, the connection MUST be 562 torn down. 564 Thus, TCP-TLS provides automatic security for the content, but not 565 protection against DoS-style attacks. For instance, attackers will 566 be able to inject RST packets, bogus application segments, etc., 567 regardless of whether TLS authentication is used. Because the 568 application data is TLS protected, this will not result in the 569 application receiving bogus data, but it will constitute a DoS on the 570 connection. 572 This attack could be countered by using TCP-TLS in combination with 573 TCP-AO [RFC5925], using ALPN to negotiate the use of AO. [[OPEN 574 ISSUE: Is this something we want? Maybe in a separate 575 specification.]] 577 6. Implementation Options 579 There are two primary implementation options for TCP-TLS: 581 o Implement all of TCP-TLS in the operating system kernel. 583 o Implement just the TCP-TLS negotiation option in the operating 584 system kernel with an interface to tell the application that TCP- 585 TLS has been negotiated and therefore that the application must 586 negotiate TLS. 588 The former option obviously achieves easier deployment for 589 applications, which don't have to do anything, but is more effort for 590 kernel developers and requires a wider interface to the kernel to 591 configure the TLS stack. The latter option is inherently more 592 flexible but does not provide as immediate transparent deployment. 593 It is also possible for systems to offer both options. 595 7. NAT/Firewall considerations 597 If use of TLS is negotiated, the data sent over TCP simply is TLS 598 data in compliance with {{RFC5246}. Thus it is extremely likely to 599 pass through NATs, firewalls, etc. The only kind of middlebox that 600 is likely to cause a problem is one which does protocol enforcement 601 that blocks TLS on arbitrary (non-443) ports but _also_ passes 602 unknown TCP options. Although no doubt such devices do exist, 603 because this is a common scenario, a client machine should be able to 604 probe to determine if it is behind such a device relatively readily. 606 8. IANA Considerations 608 IANA [shall register/has registered] the TCP-ENO suboption XX for 609 TCP-TLS. 611 IANA [shall register/has registered] the ALPN code point "tcpao" to 612 indicate the use of TCP-TLS with TCP-AO. 614 9. Security Considerations 616 The mechanisms in this document are inherently vulnerable to active 617 attack because an attacker can remove the TCP-TLS option, thus 618 downgrading you to ordinary TCP. Even when TCP-AO is used, all that 619 is being provided is continuity of authentication from the initial 620 handshake. If some sort of external authentication mechanism was 621 provided or certificates are used, then you might get some protection 622 against active attack. 624 Once the TCP-TLS option has been negotiated, then the connection is 625 resistant to active data injection attacks. If TCP-AO is not used, 626 then injected packets appear as bogus data at the TLS layer and will 627 result in MAC errors followed by a fatal alert. The result is that 628 while data integrity is provided, the connection is not resistant to 629 DoS attacks intended to terminate it. 631 If TCP-AO is used, then any bogus packets injected by an attacker 632 will be rejected by the TCP-AO integrity check and therefore will 633 never reach the TLS layer. Thus, in this case, the connection is 634 also resistant to DoS attacks, provided that endpoints require 635 integrity protection for RST packets. If endpoints accept 636 unauthenticated RST, then no DoS protection is provided. 638 10. References 640 10.1. Normative References 642 [I-D.bittau-tcpinc-tcpeno] 643 Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres, 644 D., and E. Smith, "TCP-ENO: Encryption Negotiation 645 Option", draft-bittau-tcpinc-tcpeno-02 (work in progress), 646 September 2015. 648 [I-D.ietf-tls-applayerprotoneg] 649 Friedl, S., Popov, A., Langley, A., and S. Emile, 650 "Transport Layer Security (TLS) Application Layer Protocol 651 Negotiation Extension", draft-ietf-tls-applayerprotoneg-05 652 (work in progress), March 2014. 654 [I-D.ietf-tls-chacha20-poly1305] 655 Langley, A., Chang, W., Mavrogiannopoulos, N., 656 Strombergson, J., and S. Josefsson, "The ChaCha20-Poly1305 657 AEAD Cipher for Transport Layer Security", draft-ietf-tls- 658 chacha20-poly1305-00 (work in progress), June 2015. 660 [I-D.ietf-tls-session-hash] 661 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 662 A., and M. Ray, "Transport Layer Security (TLS) Session 663 Hash and Extended Master Secret Extension", draft-ietf- 664 tls-session-hash-06 (work in progress), July 2015. 666 [I-D.ietf-tls-tls13] 667 Rescorla, E., "The Transport Layer Security (TLS) Protocol 668 Version 1.3", draft-ietf-tls-tls13-10 (work in progress), 669 October 2015. 671 [I-D.irtf-cfrg-curves] 672 Langley, A. and M. Hamburg, "Elliptic Curves for 673 Security", draft-irtf-cfrg-curves-11 (work in progress), 674 October 2015. 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 678 RFC2119, March 1997, 679 . 681 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 682 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 683 . 685 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 686 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 687 RFC5246, August 2008, 688 . 690 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 691 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 692 March 2010, . 694 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 695 Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/ 696 RFC5869, May 2010, 697 . 699 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 700 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 701 June 2010, . 703 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 704 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 705 Transport Layer Security (TLS) and Datagram Transport 706 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 707 June 2014, . 709 10.2. Informative References 711 [I-D.bittau-tcp-crypt] 712 Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres, 713 D., and Q. Slack, "Cryptographic protection of TCP Streams 714 (tcpcrypt)", draft-bittau-tcp-crypt-04 (work in progress), 715 February 2014. 717 [I-D.ietf-tls-falsestart] 718 Langley, A., Modadugu, N., and B. Moeller, "Transport 719 Layer Security (TLS) False Start", draft-ietf-tls- 720 falsestart-00 (work in progress), May 2015. 722 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 723 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 724 . 726 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 727 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 728 DOI 10.17487/RFC6919, April 2013, 729 . 731 Author's Address 733 Eric Rescorla 734 Mozilla 736 EMail: ekr@rtfm.com