idnits 2.17.1 draft-ietf-tls-falsestart-00.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 (May 7, 2015) is 3274 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 112, 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: November 8, 2015 Google 6 May 7, 2015 8 Transport Layer Security (TLS) False Start 9 draft-ietf-tls-falsestart-00 11 Abstract 13 This document specifies an optional behavior of TLS implementations, 14 dubbed False Start. It affects only protocol timing, not on-the-wire 15 protocol data, and can be implemented unilaterally. The TLS False 16 Start feature leads to a latency reduction of one round trip for 17 certain handshakes. 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 November 8, 2015. 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 . . . . . . . . . . . . . . . . . . 5 56 4. Client-side False Start . . . . . . . . . . . . . . . . . . . 5 57 5. Server-side False Start . . . . . . . . . . . . . . . . . . . 6 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 6.1. Symmetric Cipher . . . . . . . . . . . . . . . . . . . . 7 60 6.2. Protocol Version . . . . . . . . . . . . . . . . . . . . 8 61 6.3. Key Exchange and Client Certificate Type . . . . . . . . 8 62 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 9.2. Informative References . . . . . . . . . . . . . . . . . 10 67 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Requirements Notation 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [RFC2119]. 76 2. Introduction 78 A full TLS handshake as specified in [RFC5246] requires two full 79 protocol rounds (four flights) before the handshake is complete and 80 the protocol parties may begin to send application data. Thus, using 81 TLS can add a latency penalty of two network round-trip times for 82 application protocols in which the client sends data first, such as 83 HTTP [RFC2616]. An abbreviated handshake (resuming an earlier TLS 84 session) is complete after three flights, thus adding just one round- 85 trip time if the client sends application data first. 87 Client Server 89 ClientHello --------> 90 ServerHello 91 Certificate* 92 ServerKeyExchange* 93 CertificateRequest* 94 <-------- ServerHelloDone 95 Certificate* 96 ClientKeyExchange 97 CertificateVerify* 98 [ChangeCipherSpec] 99 Finished --------> 100 [ChangeCipherSpec] 101 <-------- Finished 102 Application Data <-------> Application Data 104 Figure 1 [RFC5246]. Message flow for a full handshake 106 Client Server 108 ClientHello --------> 109 ServerHello 110 [ChangeCipherSpec] 111 <-------- Finished 112 [ChangeCipherSpec] 113 Finished --------> 114 Application Data <-------> Application Data 116 Figure 2 [RFC5246]. Message flow for an abbreviated handshake 118 This document describes a technique that alleviates the latency 119 burden imposed by TLS: the TLS False Start. If certain conditions 120 are met, application data can be sent when the handshake is only 121 partially complete -- i.e., when the sender has sent its own 122 "ChangeCipherSpec" and "Finished" messages (thus having updated its 123 TLS Record Protocol write state as negotiated in the handshake), but 124 has yet to receive the other side's "ChangeCipherSpec" and "Finished" 125 messages. (By section 7.4.9 of [RFC5246], each party would have to 126 delay sending application data until it has received and validated 127 the other side's "Finished" message.) This achieves an improvement 128 of one round-trip time 130 o for full handshakes if the client sends application data first, 132 o for abbreviated handshakes if the server sends application data 133 first. 135 Accordingly, the latency penalty for using TLS with HTTP can be kept 136 at one round-trip time regardless of whether a full handshake or an 137 abbreviated handshake takes place. 139 In a False Start, when a party sends application data before it has 140 received and verified the other party's "Finished" message, there are 141 two possible outcomes: 143 o The handshake completes successfully: Once both "Finished" 144 messages have been received and verified, this retroactively 145 validates the handshake. In this case, the transcript of protocol 146 data carried over the transport underlying TLS will look as usual, 147 apart from the different timing. 149 o The handshake fails: If a party does not receive the other side's 150 "Finished" message, or if the "Finished" message's contents are 151 not correct, the handshake never gets validated. This means that 152 an attacker may have removed, changed, or injected handshake 153 messages. In this case, data has been sent over the underlying 154 transport that would not have been sent without the False Start. 156 The latter scenario makes it necessary to restrict when a False Start 157 is allowed, as described in this document. Section 3 considers basic 158 requirements for using False Start. Section 4 and Section 5 specify 159 the behavior for clients and servers, respectively, referring to 160 important security considerations in Section 6. 162 3. False Start Compatibility 164 TLS False Start as described in detail in the subsequent sections, if 165 implemented, is an optional feature. 167 A TLS implementation (not necessarily offering the False Start option 168 itself) is defined to be "False Start compatible" if it tolerates 169 receiving TLS records on the transport connection early, before the 170 protocol has reached the state to process these. To successfully use 171 False Start in a TLS connection, the other side has to be False Start 172 compatible. Out-of-band knowledge that the peer is False Start 173 compatible may be available, e.g. if this is mandated by specific 174 application profile standards. As discussed in Appendix A, the 175 requirement for False Start compatibility does not pose a hindrance 176 in practice. 178 4. Client-side False Start 180 This section specifies a change to the behavior of TLS client 181 implementations in full TLS handshakes. 183 When the client has sent its "ChangeCipherSpec" and "Finished" 184 messages, its default behavior following [RFC5246] is to not send 185 application data until it has received the server's 186 "ChangeCipherSpec" and "Finished" messages, which completes the 187 handshake. With the False Start protocol modification, the client 188 MAY send application data earlier (under the new Cipher Spec) if each 189 of the following conditions is satisfied: 191 o The application layer has requested the TLS False Start option. 193 o The symmetric cipher defined by the cipher suite negotiated in 194 this handshake has been whitelisted for use with False Start 195 according to the Security Considerations in Section 6.1. 197 o The protocol version chosen by ServerHello.server_version has been 198 whitelisted for use with False Start according to the Security 199 Considerations in Section 6.2. 201 o The key exchange method defined by the cipher suite negotiated in 202 this handshake has been whitelisted for use with False Start 203 according to the Security Considerations in Section 6.3. 205 o In the case of a handshake with client authentication, the client 206 certificate type has been whitelisted for use with False Start 207 according to the Security Considerations in Section 6.3. 209 The rules for receiving application data from the server remain 210 unchanged. 212 Note that the TLS client cannot infer the presence of an 213 authenticated server until all handshake messages have been received. 214 With False Start, unlike with the default handshake behavior, 215 applications are able to send data before this point has been 216 reached: from an application point of view, being able to send data 217 does not imply that an authenticated peer is present. Accordingly, 218 it is recommended that TLS implementations allow the application 219 layer to query whether the handshake has completed. 221 5. Server-side False Start 223 This section specifies a change to the behavior of TLS server 224 implementations in abbreviated TLS handshakes. 226 When the server has sent its "ChangeCipherSpec" and "Finished" 227 messages, its default behavior following [RFC5246] is not to send 228 application data until it has received the client's 229 "ChangeCipherSpec" and "Finished" messages, which completes the 230 handshake. With the False Start protocol modification, the server 231 MAY send application data earlier (under the new Cipher Spec) if each 232 of the following conditions is satisfied: 234 o The application layer has requested the TLS False Start option. 236 o The symmetric cipher defined by the cipher suite of the session 237 being resumed has been whitelisted for use with False Start 238 according to the Security Considerations in Section 6.1. 240 The rules for receiving application data from the client remain 241 unchanged. 243 Note that the TLS server cannot infer the presence of an 244 authenticated client until all handshake messages have been received. 245 With False Start, unlike with the default handshake behavior, 246 applications are able to send data before this point has been 247 reached: from an application point of view, being able to send data 248 does not imply that an authenticated peer is present. Accordingly, 249 it is recommended that TLS implementations allow the application 250 layer to query whether the handshake has completed. 252 6. Security Considerations 254 In a TLS handshake, the "Finished" messages serve to validate the 255 entire handshake. These messages are based on a hash of the 256 handshake so far processed by a PRF keyed with the new master secret 257 (serving as a MAC), and are also sent under the new Cipher Spec with 258 its keyed MAC, where the MAC key again is derived from the master 259 secret. The protocol design relies on the assumption that any server 260 and/or client authentication done during the handshake carries over 261 to this. While an attacker could, for example, have changed the 262 cipher suite list sent by the client to the server and thus 263 influenced cipher suite selection (presumably towards a less secure 264 choice) or could have made other modifications to handshake messages 265 in transmission, the attacker would not be able to round off the 266 modified handshake with a valid "Finished" message: every TLS cipher 267 suite is presumed to key the PRF appropriately to ensure 268 unforgeability. Once the handshake has been validated by verifying 269 the "Finished" messages, this confirms that the handshake has not 270 been tampered with, thus bootstrapping secure encryption (using 271 algorithms as negotiated) from secure authentication. 273 Using False Start interferes with this approach of bootstrapping 274 secure encryption from secure authentication, as application data may 275 have already been sent before "Finished" validation confirms that the 276 handshake has not been tampered with -- so there is generally no hope 277 to be sure that communication with the expected peer is indeed taking 278 place during the False Start. Instead, the security goal is to 279 ensure that if anyone at all can decrypt the application data sent in 280 a False Start, this must be the legitimate peer: while an attacker 281 could be influencing the handshake (restricting cipher suite 282 selection, modifying key exchange messages, etc.), the attacker 283 should not be able to benefit from this. The TLS protocol already 284 relies on such a security property for authentication -- with False 285 Start, the same is needed for encryption. This motivates the 286 following rules. 288 6.1. Symmetric Cipher 290 Clients and servers MUST NOT use the False Start protocol 291 modification in a handshake unless the cipher suite uses a symmetric 292 cipher that is considered cryptographically strong. 294 Implementations may have their own classification of ciphers (and may 295 additionally allow the application layer to provide a 296 classification), but generally only symmetric ciphers with an 297 effective key length of 128 bits or more can be considered strong. 298 Also, various ciphers specified for use with TLS are known to have 299 cryptographic weaknesses regardless of key length (none of the 300 ciphers specified in [RFC4492] and [RFC5246] can be recommended for 301 use with False Start). The AES_128_GCM_SHA256 or AES_256_GCM_SHA384 302 ciphers specified in [RFC5288] and [RFC5289] can be considered 303 sufficiently strong for most uses. Implementations that support 304 additional cipher suites have to be careful to whitelist only 305 suitable symmetric ciphers; if in doubt, False Start should not be 306 used with a given symmetric cipher. 308 While an attacker can change handshake messages to force a downgrade 309 to a less secure symmetric cipher than otherwise would have been 310 chosen, this rule ensures that in such a downgrade attack no 311 application data will be sent under an insecure symmetric cipher. 312 With respect to server-side False Start, if a client has negotiated a 313 TLS session using weak symmetric cryptography, this rule prevents 314 attackers from seeing the server encrypt more data under this session 315 than normally (if an attacker makes up a "ClientHello" message asking 316 to resume such a session, no False Start will happen). 318 6.2. Protocol Version 320 Clients MUST NOT use the False Start protocol modification in a 321 handshake unless the protocol version chosen by 322 ServerHello.server_version has been whitelisted for this use. 324 Generally, implementations should whitelist only the protocol 325 version(s) for which they would not send TLS_FALLBACK_SCSV [RFC7507]. 327 The details of nominally identical cipher suites can differ between 328 protocol versions, so this reinforces Section 6.1. 330 6.3. Key Exchange and Client Certificate Type 332 Clients MUST NOT use the False Start protocol modification in a 333 handshake unless the cipher suite uses a key exchange method that has 334 been whitelisted for this use. Furthermore, when using client 335 authentication, clients MUST NOT use the False Start protocol 336 modification unless the client certificate type has been whitelisted 337 for this use. 339 Implementations may have their own whitelists of key exchange methods 340 and client certificate types (and may additionally allow the 341 application layer to specify whitelists). Generally, out of the 342 options from [RFC5246] and [RFC4492], the following whitelists are 343 recommended: 345 o Key exchange methods: DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA 347 o Client certificate types: rsa_sign, dss_sign, ecdsa_sign (or no 348 client authentication) 350 However, if an implementation that supports only key exchange methods 351 from [RFC5246] and [RFC4492] does not support any of the above key 352 exchange methods, all of its supported key exchange methods can be 353 whitelisted for False Start use. Care is required with any 354 additional key exchange methods or client certificate types, as these 355 may not have similar properties. 357 The recommended whitelists are such that if cryptographic algorithms 358 suitable for forward secrecy would possibly be negotiated, no False 359 Start will take place if the current handshake fails to provide 360 forward secrecy. (Forward secrecy can be achieved using ephemeral 361 Diffie-Hellman or ephemeral Elliptic-Curve Diffie-Hellman; there is 362 no forward secrecy when a using key exchange method of RSA, RSA_PSK, 363 DH_DSS, DH_RSA, ECDH_ECDSA, or ECDH_RSA, or a client certificate type 364 of rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, or ecdsa_fixed_ecdh.) 365 As usual, the benefits of forward secrecy may need to be balanced 366 against efficiency, and accordingly even implementations that support 367 the above key exchange methods might whitelist further key exchange 368 methods and client certificate types from [RFC5246] and [RFC4492]. 370 7. Acknowledgments 372 The authors wish to thank Wan-Teh Chang, Ben Laurie, Eric Rescorla, 373 and Brian Smith for their input. 375 8. IANA Considerations 377 None. 379 9. References 381 9.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 387 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 388 for Transport Layer Security (TLS)", RFC 4492, May 2006. 390 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 391 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 393 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 394 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 395 August 2008. 397 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with 398 SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 399 August 2008. 401 9.2. Informative References 403 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 404 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 405 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 407 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 408 Suite Value (SCSV) for Preventing Protocol Downgrade 409 Attacks", RFC 7507, April 2015. 411 Appendix A. Implementation Notes 413 TLS False Start is a modification to the TLS protocol, and some 414 implementations that conform to [RFC5246] may have problems 415 interacting with implementations that use the False Start 416 modification. If the peer uses a False Start, application data 417 records may be received directly following the peer's "Finished" 418 message, before the TLS implementation has sent its own "Finished" 419 message. False Start compatibility as defined in Section 3 ensures 420 that these records with application data will simply remain buffered 421 for later processing. 423 A False Start compatible TLS implementation does not have to be aware 424 of the False Start concept, and is certainly not expected to detect 425 whether a False Start handshake is currently taking place: thanks to 426 transport layer buffering, typical implementations will be False 427 Start compatible without having been designed for it. 429 Authors' Addresses 431 Adam Langley 432 Google Inc. 433 345 Spear St 434 San Francisco, CA 94105 435 USA 437 Email: agl@google.com 438 Nagendra Modadugu 439 Google Inc. 440 1600 Amphitheatre Parkway 441 Mountain View, CA 94043 442 USA 444 Email: nagendra@cs.stanford.edu 446 Bodo Moeller 447 Google Switzerland GmbH 448 Brandschenkestrasse 110 449 Zurich 8002 450 Switzerland 452 Email: bmoeller@acm.org