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