idnits 2.17.1 draft-bmoeller-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 (June 2, 2010) is 5075 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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) 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 N. Modadugu 4 Intended status: Informational B. Moeller 5 Expires: December 4, 2010 Google 6 June 2, 2010 8 Transport Layer Security (TLS) False Start 9 draft-bmoeller-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 December 4, 2010. 36 Copyright Notice 38 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 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. Key Exchange and Client Certificate Type . . . . . . . . . 8 61 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 66 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 67 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 9 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 not to 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 key exchange method defined by the cipher suite negotiated in 198 this handshake, has been whitelisted for use with False Start 199 according to the Security Considerations in Section 6.2. 201 o In the case of a handshake with client authentication, the client 202 certificate type has been whitelisted for use with False Start 203 according to the Security Considerations in Section 6.2. 205 The rules for receiving application data from the server remain 206 unchanged. 208 Note that the TLS client cannot infer the presence of an 209 authenticated server until all handshake messages have been received. 210 With False Start, unlike with the default handshake behavior, 211 applications are able to send data before this point has been 212 reached: from an application point of view, being able to send data 213 does not imply that an authenticated peer is present. Accordingly, 214 it is recommended that TLS implementations allow the application 215 layer to query whether the handshake has completed. 217 5. Server-side False Start 219 This section specifies a change to the behavior of TLS server 220 implementations in abbreviated TLS handshakes. 222 When the server has sent its "ChangeCipherSpec" and "Finished" 223 messages, its default behavior following [RFC5246] is not to send 224 application data until it has received the client's 225 "ChangeCipherSpec" and "Finished" messages, which completes the 226 handshake. With the False Start protocol modification, the server 227 MAY send application data earlier (under the new Cipher Spec) if each 228 of the following conditions is satisfied: 230 o The application layer has requested the TLS False Start option. 232 o The symmetric cipher defined by the cipher suite of the session 233 being resumed has been whitelisted for use with False Start 234 according to the Security Considerations in Section 6.1. 236 The rules for receiving application data from the client remain 237 unchanged. 239 Note that the TLS server cannot infer the presence of an 240 authenticated client until all handshake messages have been received. 241 With False Start, unlike with the default handshake behavior, 242 applications are able to send data before this point has been 243 reached: from an application point of view, being able to send data 244 does not imply that an authenticated peer is present. Accordingly, 245 it is recommended that TLS implementations allow the application 246 layer to query whether the handshake has completed. 248 6. Security Considerations 250 In a TLS handshake, the "Finished" messages serve to validate the 251 entire handshake. These messages are based on a hash of the 252 handshake so far processed by a PRF keyed with the new master secret 253 (serving as a MAC), and are also sent under the new Cipher Spec with 254 its keyed MAC, where the MAC key again is derived from the master 255 secret. The protocol design relies on the assumption that any server 256 and/or client authentication done during the handshake carries over 257 to this. While an attacker could, for example, have changed the 258 cipher suite list sent by the client to the server and thus 259 influenced cipher suite selection (presumably towards a less secure 260 choice) or could have made other modifications to handshake messages 261 in transmission, the attacker would not be able to round off the 262 modified handshake with a valid "Finished" message: every TLS cipher 263 suite is presumed to key the PRF appropriately to ensure 264 unforgeability. Once the handshake has been validated by verifying 265 the "Finished" messages, this confirms that the handshake has not 266 been tampered with, thus bootstrapping secure encryption (using 267 algorithms as negotiated) from secure authentication. 269 Using False Start interferes with this approach of bootstrapping 270 secure encryption from secure authentication, as application data may 271 have already been sent before "Finished" validation confirms that the 272 handshake has not been tampered with -- so there is generally no hope 273 to be sure that communication with the expected peer is indeed taking 274 place during the False Start. Instead, the security goal is to 275 ensure that if anyone at all can decrypt the application data sent in 276 a False Start, this must be the legitimate peer: while an attacker 277 could be influencing the handshake (restricting cipher suite 278 selection, modifying key exchange messages, etc.), the attacker 279 should not be able to benefit from this. The TLS protocol already 280 relies on such a security property for authentication -- with False 281 Start, the same is needed for encryption. This motivates the 282 following rules. 284 6.1. Symmetric Cipher 286 Clients and servers MUST NOT use the False Start protocol 287 modification in a handshake unless the cipher suite uses a symmetric 288 cipher that is considered cryptographically strong. 290 Implementations may have their own classification of ciphers (and may 291 additionally allow the application layer to provide a 292 classification), but generally symmetric ciphers with an effective 293 key length of 128 bits or more can be considered strong. In 294 [RFC5246], this allows all cipher suites except those using the NULL 295 or 3DES_EDE_CBC ciphers (specifically, it allows the cipher suites 296 using RC4_128, AES_128_CBC, or AES_256_CBC). Implementations that 297 support additional cipher suites have to be careful to whitelist only 298 suitable symmetric ciphers; if in doubt, False Start should not be 299 used with a given symmetric cipher. 301 While an attacker can change handshake messages to force a downgrade 302 to a less secure symmetric cipher than otherwise would have been 303 chosen, this rule ensures that in such a downgrade attack no 304 application data will be sent under an insecure symmetric cipher. 305 With respect to server-side False Start, if a client has negotiated a 306 TLS session using weak symmetric cryptography, this rule prevents 307 attackers from seeing the server encrypt more data under this session 308 than normally (if an attacker makes up a "ClientHello" message asking 309 to resume such a session, no False Start will happen). 311 6.2. Key Exchange and Client Certificate Type 313 Clients MUST NOT use the False Start protocol modification in a 314 handshake unless the cipher suite uses a key exchange method that has 315 been whitelisted for this use. Furthermore, when using client 316 authentication, clients MUST NOT use the False Start protocol 317 modification unless the client certificate type has been whitelisted 318 for this use. 320 Implementations may have their own whitelists of key exchange methods 321 and client certificate types (and may additionally allow the 322 application layer to specify whitelists). Generally, out of the 323 options from [RFC5246] and [RFC4492], the following whitelists are 324 recommended: 326 o Key exchange methods: DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA 328 o Client certificate types: rsa_sign, dss_sign, ecdsa_sign (or no 329 client authentication) 331 However, if an implementation that supports only key exchange methods 332 from [RFC5246] and [RFC4492] does not support any of the above key 333 exchange methods, all of its supported key exchange methods can be 334 whitelisted for False Start use. Care is required with any 335 additional key exchange methods or client certificate types, as these 336 may not have similar properties. 338 The recommended whitelists are such that if cryptographic algorithms 339 suitable for forward secrecy would possibly be negotiated, no False 340 Start will take place if the current handshake fails to provide 341 forward secrecy. (Forward secrecy can be achieved using ephemeral 342 Diffie-Hellman or ephemeral Elliptic-Curve Diffie-Hellman; there is 343 no forward secrecy when a using key exchange method of RSA, RSA_PSK, 344 DH_DSS, DH_RSA, ECDH_ECDSA, or ECDH_RSA, or a client certificate type 345 of rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, or ecdsa_fixed_ecdh.) 346 As usual, the benefits of forward secrecy may need to be balanced 347 against efficiency, and accordingly even implementations that support 348 the above key exchange methods might whitelist further key exchange 349 methods and client certificate types from [RFC5246] and [RFC4492]. 351 7. Contributors 353 Wan-Teh Chang and Ben Laurie have contributed to this document. 355 8. Acknowledgments 357 The authors wish to thank Eric Rescorla for his comments on an 358 earlier draft. 360 9. IANA Considerations 362 None. 364 10. References 366 10.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 372 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 373 for Transport Layer Security (TLS)", RFC 4492, May 2006. 375 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 376 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 378 10.2. Informative References 380 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 381 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 382 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 384 Appendix A. Implementation Notes 386 TLS False Start is a modification to the TLS protocol, and some 387 implementations that conform to [RFC5246] may have problems 388 interacting with implementations that use the False Start 389 modification. If the peer uses a False Start, application data 390 records may be received directly following the peer's "Finished" 391 message, before the TLS implementation has sent its own "Finished" 392 message. False Start compatibility as defined in Section 3 ensures 393 that these records with application data will simply remain buffered 394 for later processing. 396 A False Start compatible TLS implementation does not have to be aware 397 of the False Start concept, and is certainly not expected to detect 398 whether a False Start handshake is currently taking place: thanks to 399 transport layer buffering, typical implementations will be False 400 Start compatible without having been designed for it. 402 At the time of writing, the authors are not aware of any deployed TLS 403 implementation that is not False Start compatible (with one single 404 host still pending investigation). However, if an implementation 405 uses a strategy of receiving as many bytes as available from the 406 underlying transport during the handshake (expecting to find only 407 handshake messages), achieving False Start compatibility would likely 408 require special care. 410 Authors' Addresses 412 Adam Langley 413 Google Inc. 414 1600 Amphitheatre Parkway 415 Mountain View, CA 94043 416 USA 418 Email: agl@google.com 420 Nagendra Modadugu 421 Google Inc. 422 1600 Amphitheatre Parkway 423 Mountain View, CA 94043 424 USA 426 Email: nagendra@cs.stanford.edu 427 Bodo Moeller 428 Google Switzerland GmbH 429 Brandschenkestrasse 110 430 Zurich 8002 431 Switzerland 433 Email: bmoeller@acm.org