idnits 2.17.1 draft-rescorla-tls13-new-flows-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 5, 2013) is 3819 days in the past. Is this intentional? 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: 'ChangeCipherSpec' is mentioned on line 698, but not defined == Missing Reference: 'PEDAGOGICAL' is mentioned on line 478, but not defined -- Looks like a reference, but probably isn't: '1' on line 697 -- Looks like a reference, but probably isn't: '2' on line 600 -- Looks like a reference, but probably isn't: '3' on line 601 == Missing Reference: 'TODO' is mentioned on line 808, but not defined == Unused Reference: 'RFC2119' is defined on line 832, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-tls-cached-info-15 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-01) exists of draft-bmoeller-tls-falsestart-00 == Outdated reference: A later version (-05) exists of draft-ietf-tls-applayerprotoneg-03 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft Mozilla 4 Intended status: Standards Track November 5, 2013 5 Expires: May 9, 2014 7 New Handshake Flows for TLS 1.3 8 draft-rescorla-tls13-new-flows-00 10 Abstract 12 This document sketches some potential new handshake flows for TLS 13 1.3. 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 May 9, 2014. 32 Copyright Notice 34 Copyright (c) 2013 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 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages other 57 than English. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Handshake Flows . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Handshake Latency . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Plaintext Data in the Handshake . . . . . . . . . . . . . 5 66 3. Basic Assumptions . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Challenging Issues . . . . . . . . . . . . . . . . . . . . . . 7 68 5. New Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.1. Reduced RTT Handshakes w/o Server-Side State . . . . . . . 8 70 5.1.1. Improving Privacy . . . . . . . . . . . . . . . . . . 12 71 5.1.1.1. A Partially Private Handshake . . . . . . . . . . 12 72 5.1.1.2. Partially Private Fallback . . . . . . . . . . . . 13 73 5.2. Reduced RTT Handshakes with Server-Side State . . . . . . 15 74 5.2.1. Zero Round-Trip Resumed Handshake . . . . . . . . . . 15 75 5.2.2. Zero Round-Trip Non-Resumed Handshake . . . . . . . . 15 76 5.2.3. Fallback from 0-RTT handshakes . . . . . . . . . . . . 16 77 5.2.4. Zero Round Trip (sort-of) with PFS . . . . . . . . . . 17 78 5.2.5. Anti-Replay Options . . . . . . . . . . . . . . . . . 17 79 5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 18 80 5.4. Some other questions to think about . . . . . . . . . . . 18 81 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 18 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 87 Appendix A. Summary of Existing Extensions . . . . . . . . . . . 19 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 1. Introduction 92 DISCLAIMER: THIS IS A VERY ROUGH DRAFT. EVERYTHING HERE IS SUPER- 93 HANDWAVY AND HASN'T REALLY HAD ANY SECURITY ANALYSIS. I DON'T 94 PROMISE IT'S NOT VERY VERY WRONG BUT I WANTED TO BE ABLE TO HAVE AN 95 EARLY DISCUSSION ABOUT DIRECTION. 97 The TLS WG is specifying TLS 1.3, a revision to the TLS protocol. 98 The two major design goals for TLS 1.3 are: 100 o Reduce the number of round trips in the handshake, providing at 101 least "zero round-trip" mode where the client can send its first 102 data message immediately without waiting for any response from the 103 server. 104 o Encrypt as much of the handshake as possible in order to protect 105 against monitoring of the handshake contents. 107 This document proposes revisions to the handshake to achieve these 108 objectives. They are being described in a separate document and in 109 somewhat schematic form for ease of analysis and discussion. If they 110 are considered acceptable, some of them may be elaborated and 111 integrated into the main TLS document. 113 2. Background 115 In this section we briefly review the properties of TLS 1.2 [RFC5246] 117 2.1. Handshake Flows 119 As a reminder, this section reproduces the two major TLS handshake 120 variants, from [RFC5246]. For clarity, data which is 121 cryptographically protected by the record protocol (i.e., encrypted 122 and integrity protected) are shown in braces, as in {Finished}. 124 Client Server 126 ClientHello --------> 127 ServerHello 128 Certificate* 129 ServerKeyExchange* 130 CertificateRequest* 131 <-------- ServerHelloDone 132 Certificate* 133 ClientKeyExchange 134 CertificateVerify* 135 [ChangeCipherSpec] 136 {Finished} --------> 137 [ChangeCipherSpec] 138 <-------- {Finished} 139 {Application Data} <-------> {Application Data} 141 Figure 1: TLS 1.2 Full Handshake 143 Client Server 145 ClientHello --------> 146 ServerHello 147 [ChangeCipherSpec] 148 <-------- {Finished} 149 [ChangeCipherSpec] 150 {Finished} --------> 151 {Application Data} <-------> {Application Data} 153 Figure 2: TLS 1.2 Resumed Handshake 155 2.2. Handshake Latency 157 The TLS "Full Handshake" shown above incurs 2RTT of latency: the 158 client waits for the server Finished prior to sending his first 159 application data record. The purpose of the Finished is to allow the 160 client to verify that the handshake has not been tampered with, for 161 instance that the server has not mounted a downgrade attack on the 162 cipher suite negotiation. However, if the client is satisfied with 163 the handshake results (e.g., the server has selected the strongest 164 parameters offered by the client), then the client can safely send 165 its first application data immediately after its own Finished (this 166 is often called either "False Start" or "Cut Through" 167 [I-D.bmoeller-tls-falsestart]), thus reducing the handshake latency 168 to 1RTT for a full handshake. 170 Client Server 172 ClientHello --------> 173 ServerHello 174 Certificate* 175 ServerKeyExchange* 176 CertificateRequest* 177 <-------- ServerHelloDone 178 Certificate* 179 ClientKeyExchange 180 CertificateVerify* 181 [ChangeCipherSpec] 182 {Finished} 183 {Application Data} --------> 185 [ChangeCipherSpec] 186 <-------- {Finished} 187 {Application Data} <-------> {Application Data} 189 TLS 1.2 with False Start 191 This technique is not explicitly authorized by the TLS specification 192 but neither is it explicitly forbidden. A number of client 193 implementations (e.g., Chrome, Firefox, and IE) already do False 194 Start. However, because some servers fail if they receive the 195 Finished early, it is common to use some kind of heuristic to 196 determine whether a server is likely to fail and therefore whether 197 this optimization can be used. 199 The abbreviated handshake already succeeds in 1RTT from the client's 200 perspective. 202 There have been proposals to take advantage of cached state between 203 the client and server to reduce the handshake latency to 0RTT 204 [I-D.agl-tls-snapstart]. However, they have not been widely adopted. 206 2.3. Plaintext Data in the Handshake 208 As shown in the figures above, essentially the entire handshake is in 209 the clear. Some of these values are potentially sensitive, 210 including: 212 o The client certificate. 213 o The server name indication (i.e., which server the client is 214 trying to contact. 215 o The server certificate (this is only interesting when SNI is used) 216 o The next protocol in use [I-D.ietf-tls-applayerprotoneg]. 217 o The channel ID [REF: Channel ID] 218 o The client cipher suite list (potentially usable for client 219 fingerprinting.) 221 There have been proposals to address this just for extensions 222 [I-D.agl-tls-nextprotoneg] as well as for the handshake as a whole 223 [I-D.ray-tls-encrypted-handshake]. In general, the amount of privacy 224 protection which can be provided is somewhat limited by four factors: 226 o A fair amount of information can be gathered from traffic analysis 227 based on message size and the like. 228 o Because the existing mechanisms do not encrypt these values, an 229 active attacker can generally simulate being a server which does 230 not accept whatever new handshake protection mechanisms are 231 offered and force the client back to the old, unprotected 232 mechanism. This form of active attack can be mitigated by 233 refusing to use the old mechanism, however that is not always 234 possible if one wishes to retain backward compatibility. 235 o Many inspection devices mount a man-in-the-middle attack on the 236 connection and therefore will be able to inspect information even 237 if it is encrypted. 238 o It's very hard to avoid attackers learning the server's 239 capabilities because they generally fall into an easily probe- 240 aoble/enumerable set and in most cases the clients are anonymous 241 (and thus indistinguishable from attackers). Probably the best we 242 can do is prevent attackers from learning which of a server's 243 capabilities a given client is exercising. 245 However, there are still advantages to providing protection against 246 passive inspection. The flows in this document attempt to provide 247 this service to the extent possible. 249 3. Basic Assumptions 251 This section lays out the basic assumptions that motivate the designs 252 in this document (aside from the objectives in Section 1. 254 Retain Basic TLS Structure: The intent of this document is to retain 255 the basic TLS structure and messages, tweaking them as minimally 256 as necessary to accomplish the objectives in Section 1. 257 Conservative design is good when working with security protocols. 259 Backward Compatibility is Required: It must be possible for TLS 1.3 260 implementations to interoperate with TLS 1.2 and below. 262 Minimize Variation: TLS already has a very large number of variant 263 handshakes which makes it confusing to analyze. We would like to 264 avoid multiplying this unnecessarily. We will probably deprecate 265 some of the old flows in TLS 1.3. 267 PFS is important but not mandatory: Perfect Forward Secrecy is an 268 important security property, but it it exists in tension with low 269 latency (as existing mechanisms depend on contributions from both 270 sides). Accordingly, we should provide PFS-compatible modes but 271 not mandate them. 273 0-RTT modes require server-side state: The existing TLS anti-replay 274 mechanism involves the server and client jointly contributing 275 nonces and therefore can be stateless on the server (as long as a 276 fresh nonce can be generated.) Any 0-RTT mode in which the client 277 sends data along with his initial handshake message must use some 278 other mechanism to prevent replay, and this involves the server 279 keeping some state. 281 Latency is often more important than bandwidth: Because networks are 282 getting faster but the speed of light is not, it is often more 283 important to minimize the number of round trips than the number of 284 bits on the wire. 286 Client-side computation is often cheap: In many (but not all) cases, 287 clients can afford to do a lot of cryptographic operations very 288 cheaply. 290 Clients can and should be optimistic: When we put together the 291 previous points, we come to the conclusion that it's OK for 292 clients to be optimistic that things will succeed. So, for 293 instance, it's OK to send messages to the server that might need 294 to be retransmitted or recomputed if the server's state is not as 295 expected. This is a key element of a number of round-trip 296 reducing strategies. 298 4. Challenging Issues 300 This section previews some known challenging issues to keep in mind 301 in the text below. 303 SNI privacy versus round-trips and variant server configuration: SNI 304 is intended to alter the behavior of the server, but it also leaks 305 information about the intended server identity. These demands are 306 in tension. In situations where the server uses incompatible 307 cryptography for the different SNIs (e.g., the servers use only 308 RSA and use different keys) it is not possible to hide the SNI. 309 In other cases, e.g., where DHE is used but authenticated with 310 different keys, it is possible to have distinct configurations but 311 at the cost of multiple RTs in order to first exchange keys and 312 then to send the encrypted SNI and then respond the server's 313 response. 315 Round-trips required for PFS: It's clearly not possible to do a 316 0-RTT handshake while also providing PFS. The two basic 317 alternatives are (1) abandon PFS for 0-RTT handshake (maybe using 318 re-handshakes on the same connection to get PFS) (2) Have a two- 319 stage crypto exchange where the client initially uses a key 320 generated using a cached server DH share and then and then later 321 uses a key generated from a fresh server DH share. 323 5. New Flows 325 This document includes a number of strategies for improving latency 326 and privacy, including: 328 o Move the CCS up in the handshake with respect to other messages so 329 that more of the handshake can be encrypted, thus improving 330 protection against passive handshake inspection. 331 o Allow the client to send at least some of his second flight of 332 messages (ClientKeyExchange, Finished, CCS, etc.) together with 333 the first flight in the full handshake, thus improving latency. 334 o Allow the client to send data prior to receiving the server's 335 messages, thus improving latency. 337 In addition, where prior versions of TLS generally assume that the 338 client is totally ignorant of the server's capabilities (e.g., 339 certificate and supported cipher suites) we assume that the client 340 either knows them or can make a good guess (see [REF: Fast Track]) 341 for an early example of this.) 343 5.1. Reduced RTT Handshakes w/o Server-Side State 345 NOTE: THIS SECTION IS PEDAGOGICAL. The flows in this section are 346 not flows we probably want to adopt, but they provide a somewhat 347 easier introduction into what we are trying to do. 349 The basic idea behind doing a 1RTT handshake is that the client has 350 some information about the server's likely parameters. Specifically, 351 it believes it knows: 353 o The server's preferred cipher suite. 354 o The server's certificate and persistent ServerKeyExchange 355 parameters. 357 For starters, let's look at what we can accomplish if we don't care 358 about improving privacy. 360 The handshake below, modelled on Fast Track and some suggestions from 361 Brian Smith, exploits this fact to reduce handshake latency. 363 Client Server 365 ClientHello + CI 366 ClientKeyExchange --------> 367 ServerHello + CI 368 Certificate* 369 ServerKeyExchange* 370 ServerHelloDone 371 [ChangeCipherSpec] 372 <-------- {Finished} 374 [ChangeCipherSpec] 375 {Finished} 376 {Application Data} --------> 377 {Application Data} <-------> {Application Data} 379 Figure 3: Full handshake (fast track-ish) [PEDAGOGICAL] 381 In this diagram, "CI" refers to the cached info extension 382 [I-D.ietf-tls-cached-info] which allows the client and the server to 383 jointly agree that the client knows the servers parameters. Note 384 that currently cached info includes the server's certificate but not 385 the server's DH or ECDH parameters (Fast-Track included both) and 386 would need to be modified to support this usage. However, the 387 modification is straightforward. [[IMPORTANT PRESENTATION NOTE: We 388 are showing the ClientKeyExchange as a separate message, but 389 obviously this is bad news for a pre-TLS 1.3 server (see Section 5.3 390 on compatibility, We really need to stuff any extra messages sent 391 with the ClientHello in an extension as done in 392 [I-D.agl-tls-snapstart], but that makes the diagrams too clumsy. 393 Please imagine that change where appropriate below.]] 395 This handshake allows the client and the server to establish keys in 396 1RTT (from the client's perspective) and the server to start 397 transmitting upon receiving the client's first message. Note that 398 the client need not have encountered the server before, especially 399 with ECDHE. If many servers support a common parameter set the 400 client can just send a key valid for that parameter set, at the cost 401 of some additional, potentially unnecessary, computation. 403 Obviously, there is some risk that the client is incorrect about the 404 server's keying material, either because it has made a mistake or the 405 server has changed it. In this case, the server responds with a 406 ServerHello w/o the CI extension and the client is forced back to the 407 usual TLS 1.2-style handshake, as below. 409 Client Server 411 ClientHello + CI 412 ClientKeyExchange --------> 413 ServerHello 414 Certificate* 415 ServerKeyExchange* 416 CertificateRequest* 417 <-------- ServerHelloDone 418 Certificate* 419 ClientKeyExchange 420 CertificateVerify* 421 [ChangeCipherSpec] 422 {Finished} --------> 423 [ChangeCipherSpec] 424 <-------- {Finished} 425 {Application Data} <-------> {Application Data} 427 Figure 4: Fallback to full handshake [PEDAGOGICAL] 429 This design has two major drawbacks: 431 o It's not possible to do client authentication strictly in 1RT 432 (which is why the client authentication modes are not shown in 433 Figure 3). 434 o We still haven't done anything to encrypt much of the handshake. 436 The ultimate reason for both of these problems is replay protection 437 for the server. Specifically, we need the ServerHello containing the 438 server's Random value before we can generate the keying material 439 needed to encrypt the handshake messages. Similarly, because the 440 CertificateVerify incorporates a random challenge provided by the 441 server, it can't be generated before the CertificateRequest has been 442 provided, which adds a second round-trip. 444 Let's look at the client authentication problem first. One 445 possibility would be to just leave the handshake as shown above and 446 just add the CertificateRequest in the server's first flight and the 447 Certificate/CertificateVerify in the client's second flight. 448 Unfortunately, this changes the semantics of Finished so that the 449 server's Finished message no longer covers the entire handshake. 450 It's not clear what security issues this introduces, but it seems 451 undesirable. 453 A better approach seems to be to introduce another server message 454 that just confirms the first phase of the handshake. This can have 455 the same calculation as the Finished message, but would appear 456 (unencrypted) in the server's first flight, as shown below: 458 Client Server 460 ClientHello + CI 461 ClientKeyExchange --------> 462 ServerHello + CI 463 Certificate* 464 ServerKeyExchange* 465 CertificateRequest* 466 ServerHelloDone 467 <-------- AlmostFinished 468 Certificate* 469 CertificateVerify* 470 [ChangeCipherSpec] 471 {Finished} 472 {Application Data} --------> 473 [ChangeCipherSpec] 474 <-------- {Finished} 475 {Application Data} <-------> {Application Data} 477 Figure 5: Full handshake (fast track-ish with client auth) 478 [PEDAGOGICAL] 480 Note: this handshake is not compatible with key exchange mechanisms 481 which require a static client-side key. However, these are not 482 widely used in any case. It is compatible with PFS cipher suites as 483 long as the server uses stable parameters, because the client sends 484 his share prior to seeing the ServerKeyExchange. 486 [[OPEN ISSUE: Should we move the server's CCS up to before the 487 AlmostFinished? Doesn't seem to add much value.]] [[OPEN ISSUE: 488 Need a better name for AlmostFinished.]] 490 5.1.1. Improving Privacy 492 We still have not done anything to improve the privacy of the 493 handshake, however, it is possible to improve it a fair bit by 494 splitting the ServerHello and moving the ServerKeyExchange and CCS 495 messages (and hence the encryption boundary) upward in a fashion 496 similar to that suggested by Ray [I-D.ray-tls-encrypted-handshake]. 498 5.1.1.1. A Partially Private Handshake 500 Client Server 502 ClientHello + CI 503 ClientKeyExchange --------> 504 ServerHello[1] + CI 505 ServerKeyExchange* 506 [ChangeCipherSpec] 507 {ServerHello[2]} 508 {Certificate*} 509 {CertificateRequest*} 510 {ServerHelloDone} 511 <-------- {AlmostFinished} 513 [ChangeCipherSpec] 514 {Certificate*} 515 {CertificateVerify*} 516 {Finished} 517 {Application Data} --------> 518 <-------- {Finished} 519 {Application Data} <-------> {Application Data} 521 Figure 6: 1RTT handshake with partial privacy 523 Note that this handshake contains two ServerHellos, which I have 524 labelled ServerHello[1] and ServerHello[2]. The first ServerHello 525 contains just the minimal information to indicate that the client's 526 proposed parameters are acceptable (mostly what Fast Track calls the 527 "determining parameters") with most of the information (i.e., the 528 server's cert, most extensions, etc.) being in the second 529 ServerHello. Thus, nearly all the information which we consider 530 sensitive is encrypted, with the exception of information which 531 appears in the client hello, which obviously cannot be protected (see 532 below). As an example, if ALPN is in use, the clients offered list 533 of next protocols is visible but the server's selection is not. 535 [[OPEN ISSUE: Should these ServerHellos have different names/code 536 points as in [I-D.ray-tls-encrypted-handshake] There is some 537 redundant data in the second ServerHello (e.g., the random values), 538 so that's annoying, but it might be nice to have the same messages so 539 that we can have it appear in a bunch of different places without 540 inventing new message names. This is a second-order issue.]] 542 Notably, both certificates are encrypted, but the SNI is in the 543 clear, so a passive attacker can infer the server's identity. This 544 is not ideal (see below) but is a compromise to remove round trips. 545 In addition, because the ServerKeyExchange includes a signature over 546 the keys, an attacker can verify whether a given known certificate 547 was used. 549 5.1.1.2. Partially Private Fallback 551 If the client is incorrect about the server's parameters (e.g., he 552 guesses the wrong DH parameters) then the client gets forced into a 553 slow-path handshake, as shown in Figure 7. 555 Client Server 557 ClientHello[1] + CI 558 ClientKeyExchange --------> 559 ServerHello[1] 560 <-------- ServerKeyExchange* 561 ClientHello[2] + CI 562 ClientKeyExchange 563 [ChangeCipherSpec] 564 {ClientHello[3]} --------> 565 [ChangeCipherSpec] 566 {ServerHello} 567 {Certificate*} 568 {ServerKeySignature*} 569 {CertificateRequest*} 570 {ServerHelloDone} 571 <-------- {AlmostFinished} 573 {Certificate*} 574 {CertificateVerify*} 575 {Finished} 576 {Application Data} --------> 577 <-------- {Finished} 578 {Application Data} <-------> {Application Data} 580 Figure 7: Falling back from 1RTT handshake with partial privacy 582 This should be familiar from Figure 4: the client sends a 583 ClientHello but incorrectly predicts the server's parameters; the 584 server responds with a correction indicating the parameters he wants 585 to negotiate. This also includes a ServerKeyExchange to carry the 586 server's DHE/ECDHE public key (i.e., not just the parameters). Note 587 that the SKE must be unsigned because otherwise that reveals the 588 server's certificate. At this point, the client adopts the new 589 information about the server's state and sends a ClientHello[2] which 590 hopefully has a more accurate prediction. [[OPEN ISSUE: Should we 591 let this cycle repeat again if the client is still somehow wrong? 592 Probably generate an alert.]] 594 As before, the client can now send a ClientKeyExchange, but because 595 the client now has the server's public keying material, at this point 596 it has established a joint key which it can use for encryption. It 597 can therefore send a ClientHello[3] with the extensions information 598 it considers sensitive (see Appendix A.) [[OPEN ISSUE: Again, we 599 should consider giving these different names, though here 600 ClientHello[1] and ClientHello[2] probably should both be 601 ClientHellos and ClientHello[3] is mostly extensions.]] 603 The server responds with his true second flight which is mostly 604 encrypted but otherwise mostly as normal. The major change here is 605 that it now includes a ServerKeySignature which covers the 606 ServerKeyExchange from the first flight. 608 Note that we've actually killed two birds with one stone here. 609 First, we've dealt with the case where the client is incorrect about 610 the server's capabilities, providing ourself with a fallback 611 mechanism. Second, we've provided privacy for nearly the entire 612 handshake. Thus, a client which wishes to conceal the extensions in 613 his handshake just sends a ClientHello with a non-matching CI 614 extension, thus eliciting the server's key, and can then use that to 615 encrypt the rest of the handshake. 617 There is one important limitation to mention regarding the use of SNI 618 here. The handshake described in this section only works if all of 619 the SNI values served by the server can use the same public key, 620 either because they have the same RSA public key for all of their 621 certificates and static RSA is used (not clear how likely this is) or 622 because they all share the same DH/ECDH parameters (this seems 623 reasonably likely). In cases where different SNI values require 624 different determining parameters, then it is not possible to protect 625 SNI and the server must somehow indicate that the client should 626 simply retry with an ordinary handshake with SNI. There are probably 627 a number of ways to indicate this, but (for instance) we could invent 628 a new extension value or nonfatal alert (recall that this is only 629 needed once the client has indicated TLS 1.3 so there is no 630 compatibility issue.) 632 5.2. Reduced RTT Handshakes with Server-Side State 634 Without server-side state, the best-case scenario is one round trip. 635 If we are willing to assume that the server has state, we can shorten 636 this to zero round trips (though at the cost of PFS). The general 637 principle is that each client handshake contains a unique value 638 (e.g., the ClientRandom) and the server memorizes a list of which 639 handshakes have occurred and thus can detect replay by simply 640 checking to see if a given handshake is a replay or not. This idea 641 appears in (for instance) [I-D.agl-tls-snapstart]. See Section 5.2.5 642 for some options here. 644 If everything goes well (the server has not changed its 645 configuration, rebooted and lost its state, etc.) the client can 646 follow its initial message flight (ClientHello, etc.) with encrypted 647 data which the server will process. However, as with the handshakes 648 in Section 5.1, there is some possibility that the server will reject 649 the client's parameters, in which case the client will need to fall 650 back to the slow-path. 652 5.2.1. Zero Round-Trip Resumed Handshake 654 The resumed fast-path flow is shown below. 656 Client Server 658 ClientHello + CI + AR 659 [ChangeCipherSpec] 660 {Finished} 661 {Application Data} --------> 662 ServerHello + CI + AR 663 [ChangeCipherSpec] 664 <-------- {Finished} 665 {Application Data} <-------> {Application Data} 667 Figure 8: Zero Round-trip resumed handshake 669 The new "AR" field indicates an anti-replay indicator. See 670 Section 5.2.5 for details. 672 5.2.2. Zero Round-Trip Non-Resumed Handshake 674 In the handshake shown in Figure 8, because the client's SessionID 675 (or SessionTicket) is carried in the clear, it is possible to link 676 multiple handshakes initiated by the same client. This obviously 677 isn't an ideal property and can be addressed by not doing resumption 678 and instead doing a 0-RTT key exchange. 680 The idea here is that the server's public key (i.e., not just the DH/ 681 ECDH parameters) is reasonably static (either it's an RSA key or a 682 reasonably stable DHE key). The client can then send a 683 ClientKeyExchange message which, combined with the stateful anti- 684 replay information, is enough to set up the entire connection, as 685 shown in Figure 9. 687 Client Server 689 ClientHello[1] + CI + AR 690 ClientKeyExchange 691 {ClientHello[2]} 692 [ChangeCipherSpec] 693 {Certificate*} 694 {CertificateVerify*} 695 {Finished} 696 {Application Data} --------> 697 ServerHello[1] 698 [ChangeCipherSpec] 699 {ServerHello[2]} 700 {ServerHelloDone} 701 <-------- {Finished} 702 {Application Data} <-------> {Application Data} 704 Figure 9: Zero Round-Trip non-resumed handshake 706 NOTE 1: This (potentially) includes the client's Certificate and 707 CertificateVerify because the client still needs to prove himself to 708 the server, but the server doesn't need to prove himself to the 709 client since the client has memorized the server's information. 711 NOTE 2: As usual, we need the client's Finished message to cover the 712 server's expected messages. We will need to use some Snap Start- 713 style trick to have the client include that. I believe we can solve 714 this by shoving it in the CI, but the details need to be worked out. 716 If the client's predictions of the server data are incorrect, then 717 you fall back as in previous sections. 719 5.2.3. Fallback from 0-RTT handshakes 721 In either of the handshakes shown in the two preceding sections, 722 there is a risk that the client will be wrong about the server's 723 parameters. The question then becomes how aggressive we want to be 724 about fallback. One attitude would be to say that we want minimum 725 protocol complexity and that therefore we want to fall back to the 726 slowest possible path, namely the 2-RTT handshake im Figure 7. 728 The other attitude is to say that we want things to be as fast as 729 possible, in which case we might want to fall back from the resumed 730 0-RTT handshake in Figure 8 to the non-resumed 0-RTT handshake in 731 Figure 9 to the 1-RTT handshake in Figure 6 or to Figure 9, and then 732 only to the 2-RTT handshake in Figure 7. This should be technically 733 possible, at the cost of the client having to optimistically include 734 a pile of extra stuff and having some way to phrase "use this data in 735 this condition" in the protocol. On the other hand, it's also 736 obviously pretty complicated. 738 5.2.4. Zero Round Trip (sort-of) with PFS 740 Obviously, the handshake shown in Figure 9 does not provide PFS. 741 This can be partly worked around by having the server use short-lived 742 DH keys, but at the cost of increasing the number of times you fall 743 back to a slower handshake (because the client is wrong about the 744 key.) Obviously if the client wants total PFS, he can just initiate 745 one of the 1RTT handshakes, but there are two main options for 746 getting PFS for some of the data but not all: 748 o Do a complete rehandshake with a full DH exchange immediately 749 after the resumed handshake. This gives you PFS coverage for some 750 of the data but at some not-entirely-deterministic time. 751 o Have the client do two key exchanges, one with the semi-stable 752 server key and one with a new key supplied by the server in his 753 response. So, in Figure 9 we would add a ServerKeyExchange. The 754 server's application data would be encrypted with the new PFS key 755 and the client's application data after receiving the server's 756 response would be as well. However, the client's initial data 757 would be encrypted with a non-PFS key. [[OPEN ISSUE: how does 758 the server determine what is what? Trial decryption? Client 759 sentinel message?]] 761 5.2.5. Anti-Replay Options 763 There are a number of potential mechanisms for detecting replay on 764 the server side. This section lists the main ones I know of: 766 o Memorize arbitrary client values, typically within some scope, (as 767 in [I-D.agl-tls-snapstart]) 768 o Force the client to use an identifier + values in some ordered way 769 (e.g., by using a sliding anti-replay bitmask) 770 o Give the client some finite number of tokens that you remember 771 until they are used (as an enhancement, these could be DH public 772 keys) 774 Each of these approaches has costs and benefits; generally the exact 775 form of the anti-replay mechanism is orthogonal to the design of 776 0-RTT handshake. 778 5.3. Compatibility 780 The high-order compatibility issue for any change to TLS is whether 781 the ClientHello is compatible with old servers. To a first order, we 782 deal with this by putting any new information in extensions. This is 783 ugly, but mostly works. 785 However, a secondary problem becomes that some servers/accelerators 786 are unhappy with large ClientHello messages (see 787 https://www.imperialviolet.org/2013/10/07/f5update.html). As we 788 optimistically put more stuff in the ClientHello, including keys and 789 even data, we are likely to start running into problems here. 790 Generally, we can avoid putting data into the ClientHello unless the 791 server has indicated somehow that it is able to accept it, which 792 should help minimize problems except if people's configurations 793 change or they have truly broken/mixed configurations. Nevertheless, 794 we need to take care here or else decide we are willing to deal with 795 some level of incompatibility. 797 5.4. Some other questions to think about 799 [TODO] 801 o Should we get rid of resumption? 802 o Should we get rid of renegotiation? 803 o Standardized DH parameters? 804 o Should we get rid of static RSA entirely? 806 6. Backward Compatibility 808 [TODO] 810 7. Security Considerations 812 Everything in this document needs further analysis to determine if it 813 is OK. 815 8. Acknowledgements 817 This document borrows ideas from a large number of people, including 818 Dan Boneh, Wan-Teh Chang, Cullen Jennings, Adam Langley, Nagendra 819 Modadugu, Bodo Moeller, Marsh Ray, Hovav Shacham, Martin Thomson, and 820 Brian Smith. 822 9. References 824 9.1. Normative References 826 [I-D.ietf-tls-cached-info] 827 Santesson, S. and H. Tschofenig, "Transport Layer Security 828 (TLS) Cached Information Extension", 829 draft-ietf-tls-cached-info-15 (work in progress), 830 October 2013. 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, March 1997. 835 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 836 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 838 9.2. Informative References 840 [I-D.agl-tls-nextprotoneg] 841 Langley, A., "Transport Layer Security (TLS) Next Protocol 842 Negotiation Extension", draft-agl-tls-nextprotoneg-04 843 (work in progress), May 2012. 845 [I-D.agl-tls-snapstart] 846 Langley, A., "Transport Layer Security (TLS) Snap Start", 847 draft-agl-tls-snapstart-00 (work in progress), June 2010. 849 [I-D.bmoeller-tls-falsestart] 850 Langley, A., Modadugu, N., and B. Moeller, "Transport 851 Layer Security (TLS) False Start", 852 draft-bmoeller-tls-falsestart-00 (work in progress), 853 June 2010. 855 [I-D.ietf-tls-applayerprotoneg] 856 Friedl, S., Popov, A., Langley, A., and S. Emile, 857 "Transport Layer Security (TLS) Application Layer Protocol 858 Negotiation Extension", draft-ietf-tls-applayerprotoneg-03 859 (work in progress), October 2013. 861 [I-D.ray-tls-encrypted-handshake] 862 Ray, M., "Transport Layer Security (TLS) Encrypted 863 Handshake Extension", draft-ray-tls-encrypted-handshake-00 864 (work in progress), May 2012. 866 Appendix A. Summary of Existing Extensions 868 Many of the flows in this document have Extensions appear both both 869 in the clear and encrypted. This section attempts to provide a 870 first-cut proposal (in table form) of which should appear where. 872 Extension Privacy level Proposed Location 873 -------------------------------------------------------------- 874 server_name Medium Server chooses (*) 875 max_fragment_length Low Clear 876 client_certificate_url High Encrypted 877 trusted_ca_keys Low Server chooses (*) 878 truncated_hmac Low Clear 879 status_request Low Encrypted 880 user_mapping ? ? 881 client_authz ? ? 882 server_authz ? ? 883 cert_type Low Server chooses (*) 884 elliptic_curves Low Clear 885 ec_point_formats Low Clear 886 srp High ???? 887 signature_algorithms Low Clear 888 use_srtp Low Encrypted 889 heartbeat Low Encrypted 890 alpn Medium Encrypted 891 status_request_v2 Low Encrypted 892 signed_certificate_timetamp ? ? 893 SessionTicket TLS Medium Encrypted/Clear *** 894 renegotiation_info Low Encrypted 896 * The server may need these in the clear but the client 897 would prefer them encrypted. 899 *** The SessionTicket must appear in the clear when resuming but 900 can be encrypted when being set up. 902 The general principle here is that things should be encrypted where 903 possible; extensions generally are proposed to be in the Clear part 904 of handshake only if it seems they must be there to make the rest of 905 the handshake work. The things that seem problematic are those which 906 leak information about the client's dynamic state (as opposed to 907 implementation fingerprinting) but are potentially needed by the 908 server for ciphersuite selection. These are labelled "Server 909 Chooses" in this table. 911 It's possible we can make life somewhat simpler by deprecating some 912 unused extensions, but based on the table above, it looks like the 913 extensions that make life complicated are not the ones that can be 914 easily removed. 916 Author's Address 918 Eric Rescorla 919 Mozilla 920 2064 Edgewood Drive 921 Palo Alto, CA 94303 922 USA 924 Phone: +1 650 678 2350 925 Email: ekr@rtfm.com