idnits 2.17.1 draft-ietf-tls-falsestart-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2015) is 3091 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 97, but not defined ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 7507 (Obsoleted by RFC 8996) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group A. Langley 3 Internet-Draft N. Modadugu 4 Intended status: Experimental B. Moeller 5 Expires: May 5, 2016 Google 6 November 2, 2015 8 Transport Layer Security (TLS) False Start 9 draft-ietf-tls-falsestart-01 11 Abstract 13 This document specifies an optional behavior of TLS client 14 implementations, dubbed False Start. It affects only protocol 15 timing, not on-the-wire protocol data, and can be implemented 16 unilaterally. A TLS False Start reduces handshake latency to one 17 round trip. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 5, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. False Start Compatibility . . . . . . . . . . . . . . . . . . 4 56 4. Client-side False Start . . . . . . . . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 5.1. Symmetric Cipher . . . . . . . . . . . . . . . . . . . . 6 59 5.2. Protocol Version . . . . . . . . . . . . . . . . . . . . 7 60 5.3. Key Exchange and Client Certificate Type . . . . . . . . 7 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 8.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Requirements Notation 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [RFC2119]. 75 2. Introduction 77 A full handshake in TLS protocol versions up to TLS 1.2 [RFC5246] 78 requires two full protocol rounds (four flights) before the handshake 79 is complete and the protocol parties may begin to send application 80 data. Thus, using TLS can add a latency penalty of two network 81 round-trip times for application protocols in which the client sends 82 data first, such as HTTP [RFC2616]. 84 Client Server 86 ClientHello --------> 87 ServerHello 88 Certificate* 89 ServerKeyExchange* 90 CertificateRequest* 91 <-------- ServerHelloDone 92 Certificate* 93 ClientKeyExchange 94 CertificateVerify* 95 [ChangeCipherSpec] 96 Finished --------> 97 [ChangeCipherSpec] 98 <-------- Finished 99 Application Data <-------> Application Data 101 Figure 1 [RFC5246]. Message flow for a full handshake 103 This document describes a technique that alleviates the latency 104 burden imposed by TLS: the client-side TLS False Start. If certain 105 conditions are met, the client can start to send application data 106 when the full handshake is only partially complete, namely, when the 107 client has sent its own "ChangeCipherSpec" and "Finished" messages 108 (thus having updated its TLS Record Protocol write state as 109 negotiated in the handshake), but has yet to receive the server's 110 "ChangeCipherSpec" and "Finished" messages. (By section 7.4.9 of 111 [RFC5246], after a full handshake, the client would have to delay 112 sending application data until it has received and validated the 113 server's "Finished" message.) Accordingly, the latency penalty for 114 using TLS with HTTP can be kept at one round-trip time. 116 When an earlier TLS session is resumed, TLS uses an abbreviated 117 handshake with only three protocol flights. For application 118 protocols in which the client sends data first, this abbreviated 119 handshake adds just one round-trip time to begin with, so there is no 120 need for a client-side False Start. However, if the server sends 121 application data first, the abbreviated handshake adds two round-trip 122 times, and this could be reduced to just one added round-trip time by 123 doing a server-side False Start. There is little need for this in 124 practice, so this document does not consider server-side False Starts 125 further. 127 Note also that TLS versions 1.3 [tls13] and beyond are out of scope 128 for this document. False Start will not be needed with these newer 129 versions since protocol flows minimizing the number of round trips 130 have become a first-order design goal. 132 In a False Start, when the client sends application data before it 133 has received and verified the server's "Finished" message, there are 134 two possible outcomes: 136 o The handshake completes successfully: Once both "Finished" 137 messages have been received and verified, this retroactively 138 validates the handshake. In this case, the transcript of protocol 139 data carried over the transport underlying TLS will look as usual, 140 apart from the different timing. 142 o The handshake fails: If a party does not receive the other side's 143 "Finished" message, or if the "Finished" message's contents are 144 not correct, the handshake never gets validated. This means that 145 an attacker may have removed, changed, or injected handshake 146 messages. In this case, data has been sent over the underlying 147 transport that would not have been sent without the False Start. 149 The latter scenario makes it necessary to restrict when a False Start 150 is allowed, as described in this document. Section 3 considers basic 151 requirements for using False Start. Section 4 specifies the behavior 152 for clients, referring to important security considerations in 153 Section 5. 155 3. False Start Compatibility 157 TLS False Start as described in detail in the subsequent sections, if 158 implemented, is an optional feature. 160 A TLS server implementation is defined to be "False Start compatible" 161 if it tolerates receiving TLS records on the transport connection 162 early, before the protocol has reached the state to process these. 163 For successful use of client-side False Start in a TLS connection, 164 the server has to be False Start compatible. Out-of-band knowledge 165 that the server is False Start compatible may be available, e.g. if 166 this is mandated by specific application profile standards. As 167 discussed in Appendix A, the requirement for False Start 168 compatibility does generally not pose a hindrance in practice. 170 4. Client-side False Start 172 This section specifies a change to the behavior of TLS client 173 implementations in full TLS handshakes. 175 When the client has sent its "ChangeCipherSpec" and "Finished" 176 messages, its default behavior following [RFC5246] is to not send 177 application data until it has received the server's 178 "ChangeCipherSpec" and "Finished" messages, which completes the 179 handshake. With the False Start protocol modification, the client 180 MAY send application data earlier (under the new Cipher Spec) if each 181 of the following conditions is satisfied: 183 o The application layer has requested the TLS False Start option. 185 o The symmetric cipher defined by the cipher suite negotiated in 186 this handshake has been whitelisted for use with False Start 187 according to the Security Considerations in Section 5.1. 189 o The protocol version chosen by ServerHello.server_version has been 190 whitelisted for use with False Start according to the Security 191 Considerations in Section 5.2. 193 o The key exchange method defined by the cipher suite negotiated in 194 this handshake and, if applicable, its parameters have been 195 whitelisted for use with False Start according to the Security 196 Considerations in Section 5.3. 198 o In the case of a handshake with client authentication, the client 199 certificate type has been whitelisted for use with False Start 200 according to the Security Considerations in Section 5.3. 202 The rules for receiving data from the server remain unchanged. 204 Note that the TLS client cannot infer the presence of an 205 authenticated server until all handshake messages have been received. 206 With False Start, unlike with the default handshake behavior, 207 applications are able to send data before this point has been 208 reached: from an application point of view, being able to send data 209 does not imply that an authenticated peer is present. Accordingly, 210 it is recommended that TLS implementations allow the application 211 layer to query whether the handshake has completed. 213 5. Security Considerations 215 In a TLS handshake, the "Finished" messages serve to validate the 216 entire handshake. These messages are based on a hash of the 217 handshake so far processed by a PRF keyed with the new master secret 218 (serving as a MAC), and are also sent under the new Cipher Spec with 219 its keyed MAC, where the MAC key again is derived from the master 220 secret. The protocol design relies on the assumption that any server 221 and/or client authentication done during the handshake carries over 222 to this. While an attacker could, for example, have changed the 223 cipher suite list sent by the client to the server and thus 224 influenced cipher suite selection (presumably towards a less secure 225 choice) or could have made other modifications to handshake messages 226 in transmission, the attacker would not be able to round off the 227 modified handshake with a valid "Finished" message: every TLS cipher 228 suite is presumed to key the PRF appropriately to ensure 229 unforgeability. Once the handshake has been validated by verifying 230 the "Finished" messages, this confirms that the handshake has not 231 been tampered with, thus bootstrapping secure encryption (using 232 algorithms as negotiated) from secure authentication. 234 Using False Start interferes with this approach of bootstrapping 235 secure encryption from secure authentication, as application data may 236 have already been sent before "Finished" validation confirms that the 237 handshake has not been tampered with -- so there is generally no hope 238 to be sure that communication with the expected peer is indeed taking 239 place during the False Start. Instead, the security goal is to 240 ensure that if anyone at all can decrypt the application data sent in 241 a False Start, this must be the legitimate peer: while an attacker 242 could be influencing the handshake (restricting cipher suite 243 selection, modifying key exchange messages, etc.), the attacker 244 should not be able to benefit from this. The TLS protocol already 245 relies on such a security property for authentication -- with False 246 Start, the same is needed for encryption. This motivates the rules 247 put forth in the following subsections. 249 It is prudent for applications to be even more restrictive. If 250 heuristically a small list of cipher suites and a single protocol 251 version is found to be sufficient for the majority of TLS handshakes 252 in practice, it could make sense to forego False Start for any 253 handshake that does not match this expected pattern, even if there is 254 no concrete reason to assume a cryptographic weakness. Similarly, if 255 handshakes almost always use ephemeral ECDH over one of a few named 256 curves, it could make sense to disallow False Start with any other 257 supported curve. 259 5.1. Symmetric Cipher 261 Clients MUST NOT use the False Start protocol modification in a 262 handshake unless the cipher suite uses a symmetric cipher that is 263 considered cryptographically strong. 265 Implementations may have their own classification of ciphers (and may 266 additionally allow the application layer to provide a 267 classification), but generally only symmetric ciphers with an 268 effective key length of 128 bits or more can be considered strong. 269 Also, various ciphers specified for use with TLS are known to have 270 cryptographic weaknesses regardless of key length (none of the 271 ciphers specified in [RFC4492] and [RFC5246] can be recommended for 272 use with False Start). The AES_128_GCM_SHA256 or AES_256_GCM_SHA384 273 ciphers specified in [RFC5288] and [RFC5289] can be considered 274 sufficiently strong for most uses. Implementations that support 275 additional cipher suites have to be careful to whitelist only 276 suitable symmetric ciphers; if in doubt, False Start should not be 277 used with a given symmetric cipher. 279 While an attacker can change handshake messages to force a downgrade 280 to a less secure symmetric cipher than otherwise would have been 281 chosen, this rule ensures that in such a downgrade attack no 282 application data will be sent under an insecure symmetric cipher. 284 5.2. Protocol Version 286 Clients MUST NOT use the False Start protocol modification in a 287 handshake unless the protocol version chosen by 288 ServerHello.server_version has been whitelisted for this use. 290 Generally, to avoid potential protocol downgrade attacks, 291 implementations should whitelist only their latest (highest-valued) 292 supported TLS protocol version (and, if applicable, any earlier 293 protocol versions that they would use in fallback retries without 294 TLS_FALLBACK_SCSV [RFC7507]). 296 The details of nominally identical cipher suites can differ between 297 protocol versions, so this reinforces Section 5.1. 299 5.3. Key Exchange and Client Certificate Type 301 Clients MUST NOT use the False Start protocol modification in a 302 handshake unless the cipher suite uses a key exchange method that has 303 been whitelisted for this use. Also, clients MUST NOT use the False 304 Start protocol modification unless any parameters to the key exchange 305 methods (such as ServerDHParams, ServerECDHParams) have been 306 whitelisted for this use. Furthermore, when using client 307 authentication, clients MUST NOT use the False Start protocol 308 modification unless the client certificate type has been whitelisted 309 for this use. 311 Implementations may have their own whitelists of key exchange 312 methods, parameters, and client certificate types (and may 313 additionally allow the application layer to specify whitelists). 314 Generally, out of the options from [RFC5246] and [RFC4492], the 315 following whitelists are recommended: 317 o Key exchange methods: DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA 319 o Parameters: well-known DH groups (at least 3,072 bits), named 320 curves (at least 256 bits) 322 o Client certificate types: none 323 However, if an implementation that supports only key exchange methods 324 from [RFC5246] and [RFC4492] does not support any of the above key 325 exchange methods, all of its supported key exchange methods can be 326 whitelisted for False Start use. Care is required with any 327 additional key exchange methods, as these may not have similar 328 properties. 330 The recommended whitelists are such that if cryptographic algorithms 331 suitable for forward secrecy would possibly be negotiated, no False 332 Start will take place if the current handshake fails to provide 333 forward secrecy. (Forward secrecy can be achieved using ephemeral 334 Diffie-Hellman or ephemeral Elliptic-Curve Diffie-Hellman; there is 335 no forward secrecy when a using key exchange method of RSA, RSA_PSK, 336 DH_DSS, DH_RSA, ECDH_ECDSA, or ECDH_RSA, or a client certificate type 337 of rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, or ecdsa_fixed_ecdh.) 338 As usual, the benefits of forward secrecy may need to be balanced 339 against efficiency, and accordingly even implementations that support 340 the above key exchange methods might whitelist further key exchange 341 methods and client certificate types. 343 Client certificate types rsa_sign, dss_sign, and ecdsa_sign do allow 344 forward security, but using False Start with any of these means 345 sending application data tied to the client's signature before the 346 server's authenticity (and, thus, the CertificateRequest message) has 347 been completely verified, so these too are not generally suitable for 348 the client certificate type whitelist. 350 6. Acknowledgments 352 The authors wish to thank Wan-Teh Chang, Ben Laurie, Martin Thomson, 353 Eric Rescorla, and Brian Smith for their input. 355 7. IANA Considerations 357 None. 359 8. References 361 8.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, March 1997. 366 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 367 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 368 for Transport Layer Security (TLS)", RFC 4492, May 2006. 370 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 371 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 373 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 374 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 375 August 2008. 377 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with 378 SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 379 August 2008. 381 8.2. Informative References 383 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 384 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 385 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 387 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 388 Suite Value (SCSV) for Preventing Protocol Downgrade 389 Attacks", RFC 7507, April 2015. 391 [tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 392 Version 1.3", Work in Progress, draft-ietf-tls-tls13-10, 393 October 2015. 395 Appendix A. Implementation Notes 397 TLS False Start is a modification to the TLS protocol, and some 398 implementations that conform to [RFC5246] may have problems 399 interacting with implementations that use the False Start 400 modification. If the peer uses a False Start, application data 401 records may be received directly following the peer's "Finished" 402 message, before the TLS implementation has sent its own "Finished" 403 message. False Start compatibility as defined in Section 3 ensures 404 that these records with application data will simply remain buffered 405 for later processing. 407 A False Start compatible TLS implementation does not have to be aware 408 of the False Start concept, and is certainly not expected to detect 409 whether a False Start handshake is currently taking place: thanks to 410 transport layer buffering, typical implementations will be False 411 Start compatible without having been designed for it. 413 Authors' Addresses 414 Adam Langley 415 Google Inc. 416 345 Spear St 417 San Francisco, CA 94105 418 USA 420 Email: agl@google.com 422 Nagendra Modadugu 423 Google Inc. 424 1600 Amphitheatre Parkway 425 Mountain View, CA 94043 426 USA 428 Email: nagendra@cs.stanford.edu 430 Bodo Moeller 431 Google Switzerland GmbH 432 Brandschenkestrasse 110 433 Zurich 8002 434 Switzerland 436 Email: bmoeller@acm.org