idnits 2.17.1 draft-ietf-tcpinc-use-tls-01.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 (May 03, 2016) is 2914 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: 'TLS' is mentioned on line 112, but not defined == Missing Reference: 'TBD' is mentioned on line 134, but not defined == Unused Reference: 'I-D.ietf-tls-applayerprotoneg' is defined on line 729, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-chacha20-poly1305' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'I-D.bittau-tcp-crypt' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-falsestart' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'RFC5929' is defined on line 804, but no explicit reference was found in the text == Unused Reference: 'RFC6919' is defined on line 808, 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 (-28) exists of draft-ietf-tls-tls13-12 ** 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-01 Summary: 6 errors (**), 0 flaws (~~), 14 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 May 03, 2016 5 Expires: November 4, 2016 7 Using TLS to Protect TCP Streams 8 draft-ietf-tcpinc-use-tls-01 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 November 4, 2016. 32 Copyright Notice 34 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. TCP-ENO Binding . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. Suboption Definition . . . . . . . . . . . . . . . . . . 3 53 3.2. Session ID . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.3. Channel Close . . . . . . . . . . . . . . . . . . . . . . 4 55 4. TLS Profile . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. TLS 1.3 Profile . . . . . . . . . . . . . . . . . . . . . 5 57 4.1.1. Handshake Modes . . . . . . . . . . . . . . . . . . . 5 58 4.1.2. Basic 1-RTT Handshake . . . . . . . . . . . . . . . . 6 59 4.1.3. Hello Retry Request [6.3.1.3] . . . . . . . . . . . . 10 60 4.1.4. Zero-RTT Exchange . . . . . . . . . . . . . . . . . . 10 61 4.1.5. Key Schedule . . . . . . . . . . . . . . . . . . . . 12 62 4.1.6. Record Protection . . . . . . . . . . . . . . . . . . 13 63 4.2. TLS 1.2 Profile . . . . . . . . . . . . . . . . . . . . . 13 64 4.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 14 65 4.4. Cryptographic Algorithms . . . . . . . . . . . . . . . . 14 66 5. Transport Integrity . . . . . . . . . . . . . . . . . . . . . 14 67 6. API Considerations . . . . . . . . . . . . . . . . . . . . . 15 68 7. Implementation Considerations . . . . . . . . . . . . . . . . 15 69 8. NAT/Firewall considerations . . . . . . . . . . . . . . . . . 15 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 74 11.2. Informative References . . . . . . . . . . . . . . . . . 18 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 77 1. Introduction 79 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this 80 draft is maintained in GitHub. Suggested changes should be submitted 81 as pull requests at https://github.com/ekr/tcpinc-tls. Instructions 82 are on that page as well. 84 The TCPINC WG is chartered to define protocols to provide ubiquitous, 85 transparent security for TCP connections. The WG is specifying The 86 TCP Encryption Negotiation Option (TCP-ENO) 87 [I-D.bittau-tcpinc-tcpeno] which allows for negotiation of encryption 88 at the TCP layer. This document describes a binding of TLS [RFC5246] 89 to TCP-ENO as what ENO calls an "encryption spec", thus allowing TCP- 90 ENO to negotiate TLS. 92 2. Overview 94 The basic idea behind this draft is simple. The SYN and SYN/ACK 95 messages carry the TCP-ENO options indicating the willingness to do 96 TLS. If both sides want to do TLS, then a TLS handshake is started 97 and once that completes, the data is TLS protected prior to being 98 sent over TCP. Otherwise, the application data is sent as usual. 100 Client Server 102 SYN + TCP-ENO [TLS]-> 103 <- SYN/ACK + TCP-ENO [TLS] 104 ACK + TCP-ENO -> 105 <---------------- TLS Handshake ---------------> 106 <--------- Application Data over TLS ----------> 108 Figure 1 110 Client Server 112 SYN + TCP-ENO [TLS] -> 113 <- SYN/ACK 114 ACK -> 115 <--------- Application Data over TCP ----------> 117 Figure 2: Fall back to TCP 119 If use of TLS is negotiated, the data sent over TCP simply is TLS 120 data in compliance with TLS 1.2 [RFC5246] or TLS 1.3 121 [I-D.ietf-tls-tls13]. 123 Once the TLS handshake has completed, all application data SHALL be 124 sent over that negotiated TLS channel. Application data MUST NOT be 125 sent prior to the TLS handshake. 127 If the TLS handshake fails, the endpoint MUST tear down the TCP 128 connection and MUST NOT send plaintext data over the connection. 130 3. TCP-ENO Binding 132 3.1. Suboption Definition 134 TCP-ENO suboption with cs value set to [TBD]. Specifically, this 135 means that the SYN contains a 1-byte suboption indicating support for 136 this specification. 138 bit 7 6 5 4 3 2 1 0 139 +---+---+---+---+---+---+---+---+ 140 | 0 | TBD | 141 +---+---+---+---+---+---+---+---+ 143 [[OPEN ISSUE: It would be nice to indicate the desire to have 0-RTT, 144 but that would require a variable length suboption, which seems 145 perhaps excessive. Maybe that's the right answer anyway.]] 147 The SYN/ACK can be in one of two forms: 149 o A 1-byte suboption as in the SYN. 151 o A variable-length suboption. In this case, the remainder of the 152 option contains a nonce to be used for 0-RTT (see Section 4.1.4. 153 This nonce MUST be globally unique. Servers MUST NOT use this 154 form of the suboption unless explicitly configured (see 155 Section 6). [[OPEN ISSUE: I just thought this up recently, so 156 it's possible it's totally half-baked and won't work. In 157 particular, am I chewing up too much option space?]] 159 The ACK simply contains the bare TCP-ENO suboption. 161 3.2. Session ID 163 TCP-ENO Section 4.1 defines a session ID feature (not to be confused 164 with TLS Session IDs). When the protocol in use is TLS, the session 165 ID is computed via a TLS Exporter [RFC5705] using the Exporter Label 166 [[TBD]] and without a context value (the TCP-ENO transcript is 167 incorporated via the TCPENOTranscript extension). 169 3.3. Channel Close 171 Because TLS security is provided in the TCP transport stream rather 172 than at the segment level, the FIN is not an authenticated indicator 173 of end of data. Instead implementations following this specification 174 MUST send a TLS close_notify alert prior to sending a FIN and MUST 175 raise an error if a FIN or RST is receive prior to receiving a 176 close_notify. 178 4. TLS Profile 180 The TLS Profile defined in this document is intended to be a 181 compromise between two separate use cases. For the straight TCPINC 182 use case of ubiquitous transport encryption, we desire that 183 implementations solely implement TLS 1.3 [I-D.ietf-tls-tls13] or 184 greater. However, we also want to allow the use of TCP-ENO as a 185 signal for applications to do out-of-band negotiation of TLS, and 186 those applications are likely to already have support for TLS 1.2 187 [RFC5246]. In order to accomodate both cases, we specify a wire 188 encoding that allows for negotiation of multiple TLS versions 189 (Section 3.1) but encourage implementations to implement only TLS 190 1.3. Implementations which also implement TLS 1.2 MUST implement the 191 profile described in Section 4.2 193 4.1. TLS 1.3 Profile 195 TLS 1.3 is the preferred version of TLS for this specification. In 196 order to facilitate implementation, this section provides a non- 197 normative description of the parts of TLS 1.3 which are relevant to 198 TCPINC and defines a normative baseline of algorithms and modes which 199 MUST be supported. Other modes, cipher suites, key exchange 200 algorithms, certificate formats as defined in [I-D.ietf-tls-tls13] 201 MAY also be used and that document remains the normative reference 202 for TLS 1.3. Bracketed references (e.g., [S. 1.2.3.4] refer to the 203 corresponding section in that document.) In order to match TLS 204 terminology, we use the term "client" to indicate the TCP-ENO "A" 205 role (See [I-D.bittau-tcpinc-tcpeno]; Section 3.1) and "server" to 206 indicate the "B" role. 208 4.1.1. Handshake Modes 210 TLS 1.3 as used in TCPINC supports two handshake modes, both based on 211 Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange. 213 o A 1-RTT mode which is used when the client has no information 214 about the server's keying material (see Figure 3) 216 o A 0-RTT mode which is used when the client and server have 217 connected previous and which allows the client to send data on the 218 first flight (see Figure 4) 220 In both case, the server is expected to have an Elliptic-Curve 221 Digital Signature Algorithm (ECDSA) signing key which may either be a 222 freshly-generated key or a long-term key (allowing Trust-On-First-Use 223 (TOFU) style applications). The key need not be associated with any 224 certificate and can simply be a bare key. 226 Full TLS 1.3 includes support for additional modes based on pre- 227 shared keys, but TCPINC implementations MAY opt to omit them. 228 Implementations MUST implement the 1-RTT mode and SHOULD implement 229 the 0-RTT mode. 231 Client Server 233 ClientHello 234 + ClientKeyShare 235 + TCPENOTranscript -------> 236 ServerHello 237 ServerKeyShare 238 {EncryptedExtensions} 239 {ServerConfiguration*} 240 {Certificate} 241 {CertificateVerify} 242 <-------- {Finished} 243 <-------- [Application Data] 244 {Finished} --------> 245 [Application Data] <-------> [Application Data] 247 * Indicates optional or situation-dependent 248 messages that are not always sent. 250 {} Indicates messages protected using keys 251 derived from the ephemeral secret. 253 [] Indicates messages protected using keys 254 derived from the master secret. 256 Figure 3: Message flow for full TLS Handshake 258 Note: Although these diagrams indicate a message called 259 "Certificate", this message MAY either contain a bare public key or 260 an X.509 certificate (this is intended to support the out-of-band use 261 case indicated above). Implementations MUST support bare public keys 262 and MAY support X.509 certificates. 264 4.1.2. Basic 1-RTT Handshake 266 4.1.2.1. Client's First Flight 268 4.1.2.1.1. Sending 270 In order to initiate the TLS handshake, the client sends a 271 "ClientHello" message [S. 6.3.1.1]. 273 struct { 274 ProtocolVersion client_version = { 3, 4 }; /* TLS v1.3 */ 275 Random random; 276 uint8 session_id_len_RESERVED; /* Must be zero */ 277 CipherSuite cipher_suites<2..2^16-2>; 278 uint8 compression_methods_len_RESERVED; /* Must be zero */ 279 Extension extensions<0..2^16-1>; 280 } ClientHello; 282 The fields listed here have the following meanings: 284 client_version 285 The version of the TLS protocol by which the client wishes to 286 communicate during this session. 288 random 289 A 32-byte random nonce. 291 cipher_suites 292 This is a list of the cryptographic options supported by the 293 client, with the client's first preference first. 295 extensions contains a set of extension fields. The client MUST 296 include the following extensions: 298 SignatureAlgorithms [S. 6.3.2.1] 299 A list of signature/hash algorithm pairs the client supports. 301 NamedGroup [S. 6.3.2.2] 302 A list of ECDHE groups that the client supports 304 ClientKeyShare [S. 6.3.2.3] 305 Zero or more ECDHE shares drawn from the groups in NamedGroup. 306 This SHOULD contain either a P-256 key or an X25519 key. 308 The client MUST also include a ServerCertTypeExtension containing 309 type "Raw Public Key" [RFC7250], indicating its willingness to accept 310 a raw public key rather than an X.509 certificate in the server's 311 Certificate message. 313 The client MUST include a TCPENOTranscript extension containing the 314 TCP-ENO options that were used to negotiate ENO. 316 4.1.2.2. The TCPENOTranscript 318 TCPENOTranscript TLS Extension is used to carry the TCP ENO 319 negotiation transcript. The body of the extension simply includes 320 the TCP-ENO negotiation transcript as defined in TCP-ENO Section 3.4. 322 This serves two purposes: 324 o It binds the TCP-ENO negotiation into the TLS handshake. 326 o In 0-RTT mode (see Section 4.1.4) it allows the server to provide 327 an anti-replay nonce which is then mixed into the TLS handshake. 329 The server MUST validate that the TCPENOTranscript extension matches 330 the transcript. If not, it MUST fail the handshake with a fatal 331 "handshake_failure" exception. 333 4.1.2.2.1. Receiving 335 Upon receiving the client's ClientHello, the server selects a 336 ciphersuite and ECDHE group out of the lists provided by the client 337 in the cipher_suites list and the NamedGroup extension. If the 338 client supplied an appropriate ClientKeyShare for that group, then 339 the server responds with a ServerHello (see Section 4.1.2.3). 340 Otherwise, it replies with a HelloRetryRequest (Section 4.1.3), 341 indicating that the client needs to re-send the ClientHello with an 342 appropriate key share; because all TCPINC implementations are 343 required to support P-256, this should not happen unless P-256 is 344 deprecated by a subsequent specification. 346 4.1.2.3. Server's First Flight 348 4.1.2.3.1. Sending 350 The server responds to the client's first flight with a sequence of 351 messages: 353 ServerHello [6.3.1.2] 354 Contains a nonce and the cipher suite that the server has selected 355 out of the client's list. The server MUST support the extensions 356 listed in Section 4.1.2.1.1 and MUST also ignore any extensions it 357 does not recognize; this implies that the server can implement 358 solely the extensions listed in Section 4.1.2.1.1. 360 ServerKeyShare [6.3.3] 361 Contains the server's ECDHE share for one of the groups offered in 362 the client's ClientKeyShare message. All messages after 363 ServerKeyShare are encrypted using keys derived from the 364 ClientKeyShare and ServerKeyShare. 366 EncryptedExtensions [6.3.4] 367 Responses to the extensions offered by the client. In this case, 368 the only relevant extension is the ServerCertTypeExtension. 370 Certificate [6.3.5] 371 The server's certificate. If the client offered a "Raw Public 372 Key" type in ServerCertTypeExtension this message SHALL contain a 373 SubjectPublicKeyInfo value for the server's key as specified in 374 [RFC7250]. Otherwise, it SHALL contain one or more X.509 375 Certificates, as specified in [I-D.ietf-tls-tls13], Section 6.3.5. 376 In either case, this message MUST contain a key which is 377 consistent with the client's SignatureAlgorithms and NamedGroup 378 extensions. 380 ServerConfiguration [6.3.7] 381 A server configuration value for use in 0-RTT (see Section 4.1.4). 383 CertificateVerify [6.3.8] 384 A signature over the handshake transcript using the key provided 385 in the certificate message. 387 Finished [6.3.9] 388 A MAC over the entire handshake transcript up to this point. 390 Once the server has sent the Finished message, it can immediately 391 generate the application traffic keys and start sending application 392 traffic to the client. 394 4.1.2.4. Receiving 396 Upon receiving the server's first flight, the client proceeds as 397 follows: 399 o Read the ServerHello message to determine the cryptographic 400 parameters. 402 o Read the ServerKeyShare message and use that in combination with 403 the ClientKeyShare to compute the keys which are used to encrypt 404 the rest of the handshake. 406 o Read the EncryptedExtensions message. As noted above, the main 407 extension which needs to be processed is ServerCertTypeExtension, 408 which indicates the format of the server's certificate message. 410 o Read the server's certificate message and store the server's 411 public key. Unless the implementation is specifically configured 412 otherwise, it SHOULD NOT attempt to validate the certificate, even 413 if it is of type X.509 but merely extract the key. 415 o Read the server's CertificateVerify message and verify the 416 server's signature over the handshake transcript. If the 417 signature does not verify, the client terminates the handshake 418 with an alert (Section 6.1.2). 420 o Read the server's Finished message and verify the finished MAC 421 based on the DH shared secret. If the MAC does not verify, the 422 client terminates the handshake with an alert. 424 4.1.2.5. Client's Second Flight 426 Finally, the client sends a Finished message which contains a MAC 427 over the handshake transcript (except for the server's Finished). 428 [[TODO: In the upcoming draft of TLS 1.3, the client's Finished will 429 likely include the server's Finished.]] Once the client has 430 transmitted the Finished, it can begin sending encrypted traffic to 431 the server. 433 The server reads the client's Finished message and verifies the MAC. 434 If the MAC does not verify, the client terminates the handshake with 435 an alert. 437 4.1.3. Hello Retry Request [6.3.1.3] 439 Because there are a small number of recommended groups, the 440 ClientKeyShare will generally contain a key share for a group that 441 the server supports. However, it is possible that the client will 442 not send such a key share, but there may be another group that the 443 client and server jointly support. In that case, the server MUST 444 send a HelloRetryRequest indicating the desired group: 446 struct { 447 ProtocolVersion server_version; 448 CipherSuite cipher_suite; 449 NamedGroup selected_group; 450 Extension extensions<0..2^16-1>; 451 } HelloRetryRequest; 453 In response to the HelloRetryRequest the client re-sends its 454 ClientHello but with the addition of the group indicated in 455 "selected_group". 457 4.1.4. Zero-RTT Exchange 459 TLS 1.3 allows the server to send its first application data message 460 to the client immediately upon receiving the client's first handshake 461 message (which the client can send upon receiving the server's SYN/ 462 ACK). However, in the basic handshake, the client is required to 463 wait for the server's first flight before it can send to the server. 465 TLS 1.3 also includes a "Zero-RTT" feature which allows the client to 466 send data on its first flight to the server. 468 In order to enable this feature, in an initial handshake the server 469 sends a ServerConfiguration message which contains the server's semi- 470 static (EC)DH key which can be used for a future handshake: 472 struct { 473 opaque configuration_id<1..2^16-1>; 474 uint32 expiration_date; 475 NamedGroup group; 476 opaque server_key<1..2^16-1>; 477 EarlyDataType early_data_type; 478 ConfigurationExtension extensions<0..2^16-1>; 479 } ServerConfiguration; 481 The group and server_key fields contain the server's (EC)DH key and 482 the early_data_type field is used to indicate what data can be sent 483 in zero-RTT. Because client authentication is forbidden in TCPINC- 484 uses of TLS 1.3 (see Section 4.3), the only valid value here is 485 "early_data", indicating that the client can send data in 0-RTT. 487 In a future connection, a client MAY send 0-RTT data only if the 488 following three conditions obtain: 490 o It has been specifically configured to do so (see Section 6). 492 o A ServerConfiguration is available. 494 o The server supplied a nonce in its SYN/ACK suboption [[TODO: Work 495 out how to make this work with TFO if at all.]] 497 In this case, the client sends an EarlyDataIndication extension in 498 its ClientHello and can start sending data immediately, as shown 499 below. 501 Client Server 503 ClientHello 504 + ClientKeyShare 505 + EarlyDataIndication 506 + TCPENOTranscript 507 (EncryptedExtensions) 508 (Application Data) --------> 509 ServerHello 510 + EarlyDataIndication 511 ServerKeyShare 512 {EncryptedExtensions} 513 {ServerConfiguration*} 514 {Certificate} 515 {CertificateVerify} 516 <-------- {Finished} 517 <-------- [Application Data] 518 {Finished} --------> 520 [Application Data] <-------> [Application Data] 522 () Indicates messages protected using keys 523 derived from the static secret. 525 Figure 4: Message flow for a zero round trip handshake 527 IMPORTANT NOTE: TLS 1.3 Zero-RTT does not provide PFS and therefore 528 MUST only be used when explicitly configured. 530 Note: TLS 1.3 Zero-RTT data is inherently replayable (see the note in 531 [I-D.ietf-tls-tls13] Section 6.2.2). However, because the client and 532 server have already exchanged data in the _TCP_ handshake, this data 533 can be used to provide anti-replay for a 0-RTT mode TLS handshake via 534 the TCPENOTranscript extension. 536 4.1.5. Key Schedule 538 TLS 1.3 derives its traffic keys from two input keying material 539 values: 541 Ephemeral Secret (ES): A secret which is derived from ClientKeyShare 542 and ServerKeyShare. 544 Static Secret (SS): A secret which which is derived from 545 ClientKeyShare and either ServerKeyShare (in the 1-RTT case) or the 546 public key in the ServerConfiguration (in the 0-RTT case). 548 The handshake is encrypted under keys derived from ES. The ordinary 549 traffic keys are derived from the combination of ES and SS. The 550 0-RTT traffic keys are derived solely from ES and therefore have 551 limited forward security. All key derivation is done using the HKDF 552 key-derivation algorithm [RFC5869]. 554 4.1.6. Record Protection 556 Once the TLS handshake has completed, all data is protected as a 557 series of TLS Records. 559 struct { 560 ContentType opaque_type = application_data(23); /* see fragment.type */ 561 ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ 562 uint16 length; 563 aead-ciphered struct { 564 opaque content[TLSPlaintext.length]; 565 ContentType type; 566 uint8 zeros[length_of_padding]; 567 } fragment; 568 } TLSCiphertext; 570 Each record is encrypted with an Authenticated Encryption with 571 Additional Data (AEAD) cipher with the following parameters: 573 o The AEAD nonce is constructed by generating a per-connection nonce 574 mask of length max(8 bytes, N_MIN) for the AEAD algorithm (N_MIN 575 is the minimum nonce size defined in [RFC5116] Section 4) and 576 XORing it with the sequence number of the TLS record (left-padded 577 with zeroes). 579 o The additional data is the sequence number + the TLS version 580 number. 582 The record data MAY BE padded with zeros to the right. Because the 583 content type byte value is always non-zero, the padding is removed by 584 removing bytes from the right until a non-zero byte is encountered. 586 4.2. TLS 1.2 Profile 588 Implementations MUST implement and require the TLS Extended Master 589 Secret Extension [I-D.ietf-tls-session-hash] and MUST NOT negotiate 590 versions of TLS prior to TLS 1.2. Implementations MUST NOT negotiate 591 non-AEAD cipher suites and MUST use only PFS cipher suites with a key 592 of at least 2048 bits (finite field) or 256 bites (elliptic curve). 593 TLS 1.2 implementations MUST NOT initiate renegotiation and MUST 594 respond to renegotiation with a fatal "no_renegotiation" alert. 596 4.3. Deprecated Features 598 When TLS is used with TCPINC, a number of TLS features MUST NOT be 599 used, including: 601 o TLS certificate-based client authentication 603 o Session resumption 605 These features have only minimal advantage in this context and 606 interfere with offering a reduced profile. 608 4.4. Cryptographic Algorithms 610 Implementations of this specification MUST implement the following 611 cipher suite: 613 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 615 These cipher suites MUST support both digital signatures and key 616 exchange with secp256r1 (NIST P-256) and SHOULD support key agrement 617 with X25519 [I-D.irtf-cfrg-curves]. 619 Implementations of this specification SHOULD implement the following 620 cipher suites: 622 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 623 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 625 5. Transport Integrity 627 The basic operational mode defined by TCP-TLS protects only the 628 application layer content, but not the TCP segment metadata. Upon 629 receiving a packet, implementations MUST first check the TCP checksum 630 and discard corrupt packets without presenting them to TLS. If the 631 TCP checksum passes but TLS integrity fails, the connection MUST be 632 torn down. 634 Thus, TCP-TLS provides automatic security for the content, but not 635 protection against DoS-style attacks. For instance, attackers will 636 be able to inject RST packets, bogus application segments, etc., 637 regardless of whether TLS authentication is used. Because the 638 application data is TLS protected, this will not result in the 639 application receiving bogus data, but it will constitute a DoS on the 640 connection. 642 This attack could be countered by using TCP-TLS in combination with 643 TCP-AO [RFC5925], using Application-Layer Protocol Negotiation (ALPN) 645 [RFC7301] to negotiate the use of AO. [[OPEN ISSUE: Is this 646 something we want? Maybe in a separate specification.]] 648 6. API Considerations 650 Needed here: 652 o How to configure 0-RTT and send 0-RTT data (some sort of sockopt). 654 o When is the session-id available (post-connect() completion). 656 o How to indicate that the certificate should be validated. 658 7. Implementation Considerations 660 There are two primary implementation options for TCP-TLS: 662 o Implement all of TCP-TLS in the operating system kernel. 664 o Implement just the TCP-TLS negotiation option in the operating 665 system kernel with an interface to tell the application that TCP- 666 TLS has been negotiated and therefore that the application must 667 negotiate TLS. 669 The former option obviously achieves easier deployment for 670 applications, which don't have to do anything, but is more effort for 671 kernel developers and requires a wider interface to the kernel to 672 configure the TLS stack. The latter option is inherently more 673 flexible but does not provide as immediate transparent deployment. 674 It is also possible for systems to offer both options. 676 8. NAT/Firewall considerations 678 If use of TLS is negotiated, the data sent over TCP simply is TLS 679 data in compliance with [RFC5246]. Thus it is extremely likely to 680 pass through NATs, firewalls, etc. The only kind of middlebox that 681 is likely to cause a problem is one which does protocol enforcement 682 that blocks TLS on arbitrary (non-443) ports but _also_ passes 683 unknown TCP options. Although no doubt such devices do exist, 684 because this is a common scenario, a client machine should be able to 685 probe to determine if it is behind such a device relatively readily. 687 9. IANA Considerations 689 IANA [shall register/has registered] the TCP-ENO suboption XX for 690 TCP-TLS. 692 IANA [shall register/has registered] the ALPN code point "tcpao" to 693 indicate the use of TCP-TLS with TCP-AO. 695 10. Security Considerations 697 The mechanisms in this document are inherently vulnerable to active 698 attack because an attacker can remove the TCP-TLS option, thus 699 downgrading you to ordinary TCP. Even when TCP-AO is used, all that 700 is being provided is continuity of authentication from the initial 701 handshake. If some sort of external authentication mechanism was 702 provided or certificates are used, then you might get some protection 703 against active attack. 705 Once the TCP-TLS option has been negotiated, then the connection is 706 resistant to active data injection attacks. If TCP-AO is not used, 707 then injected packets appear as bogus data at the TLS layer and will 708 result in MAC errors followed by a fatal alert. The result is that 709 while data integrity is provided, the connection is not resistant to 710 DoS attacks intended to terminate it. 712 If TCP-AO is used, then any bogus packets injected by an attacker 713 will be rejected by the TCP-AO integrity check and therefore will 714 never reach the TLS layer. Thus, in this case, the connection is 715 also resistant to DoS attacks, provided that endpoints require 716 integrity protection for RST packets. If endpoints accept 717 unauthenticated RST, then no DoS protection is provided. 719 11. References 721 11.1. Normative References 723 [I-D.bittau-tcpinc-tcpeno] 724 Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres, 725 D., and E. Smith, "TCP-ENO: Encryption Negotiation 726 Option", draft-bittau-tcpinc-tcpeno-02 (work in progress), 727 September 2015. 729 [I-D.ietf-tls-applayerprotoneg] 730 Friedl, S., Popov, A., Langley, A., and S. Emile, 731 "Transport Layer Security (TLS) Application Layer Protocol 732 Negotiation Extension", draft-ietf-tls-applayerprotoneg-05 733 (work in progress), March 2014. 735 [I-D.ietf-tls-chacha20-poly1305] 736 Langley, A., Chang, W., Mavrogiannopoulos, N., 737 Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305 738 Cipher Suites for Transport Layer Security (TLS)", draft- 739 ietf-tls-chacha20-poly1305-04 (work in progress), December 740 2015. 742 [I-D.ietf-tls-session-hash] 743 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 744 A., and M. Ray, "Transport Layer Security (TLS) Session 745 Hash and Extended Master Secret Extension", draft-ietf- 746 tls-session-hash-06 (work in progress), July 2015. 748 [I-D.ietf-tls-tls13] 749 Rescorla, E., "The Transport Layer Security (TLS) Protocol 750 Version 1.3", draft-ietf-tls-tls13-12 (work in progress), 751 March 2016. 753 [I-D.irtf-cfrg-curves] 754 Langley, A. and M. Hamburg, "Elliptic Curves for 755 Security", draft-irtf-cfrg-curves-11 (work in progress), 756 October 2015. 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, 760 DOI 10.17487/RFC2119, March 1997, 761 . 763 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 764 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 765 . 767 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 768 (TLS) Protocol Version 1.2", RFC 5246, 769 DOI 10.17487/RFC5246, August 2008, 770 . 772 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 773 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 774 March 2010, . 776 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 777 Key Derivation Function (HKDF)", RFC 5869, 778 DOI 10.17487/RFC5869, May 2010, 779 . 781 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 782 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 783 June 2010, . 785 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 786 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 787 Transport Layer Security (TLS) and Datagram Transport 788 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 789 June 2014, . 791 11.2. Informative References 793 [I-D.bittau-tcp-crypt] 794 Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres, 795 D., and Q. Slack, "Cryptographic protection of TCP Streams 796 (tcpcrypt)", draft-bittau-tcp-crypt-04 (work in progress), 797 February 2014. 799 [I-D.ietf-tls-falsestart] 800 Langley, A., Modadugu, N., and B. Moeller, "Transport 801 Layer Security (TLS) False Start", draft-ietf-tls- 802 falsestart-01 (work in progress), November 2015. 804 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 805 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 806 . 808 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 809 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 810 DOI 10.17487/RFC6919, April 2013, 811 . 813 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 814 "Transport Layer Security (TLS) Application-Layer Protocol 815 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 816 July 2014, . 818 Author's Address 820 Eric Rescorla 821 Mozilla 823 EMail: ekr@rtfm.com