idnits 2.17.1 draft-rescorla-tls13-new-flows-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 : ---------------------------------------------------------------------------- ** 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 == Line 938 has weird spacing: '...HParams par...' == Line 953 has weird spacing: '...HParams par...' == Line 1018 has weird spacing: '... opaque orbit...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (February 17, 2014) is 3721 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 1268, but not defined -- Looks like a reference, but probably isn't: '8' on line 1018 == Unused Reference: 'I-D.ietf-tls-cached-info' is defined on line 1099, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1105, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-tls-cached-info-16 ** 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-04 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 2 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 February 17, 2014 5 Expires: August 21, 2014 7 New Handshake Flows for TLS 1.3 8 draft-rescorla-tls13-new-flows-01 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 August 21, 2014. 32 Copyright Notice 34 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Handshake Flows . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Handshake Latency . . . . . . . . . . . . . . . . . . . . 5 65 2.3. Plaintext Data in the Handshake . . . . . . . . . . . . . 6 66 3. Basic Assumptions . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Challenging Issues . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Design Principles . . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Backward Compatibility is Required . . . . . . . . . . . . 9 70 5.2. Remove Static Key Exchange . . . . . . . . . . . . . . . . 9 71 5.3. Protect SNI But Require Common Crypto Parameters . . . . . 10 72 6. New Handshake Modes . . . . . . . . . . . . . . . . . . . . . 10 73 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 6.2. New Behaviors . . . . . . . . . . . . . . . . . . . . . . 12 75 6.2.1. Client Behavior for First Flight . . . . . . . . . . . 12 76 6.2.1.1. No Knowledge . . . . . . . . . . . . . . . . . . . 12 77 6.2.1.2. Server Keying Material . . . . . . . . . . . . . . 13 78 6.2.1.3. Anti-Replay Token . . . . . . . . . . . . . . . . 13 79 6.2.2. Server Behavior For First Flight . . . . . . . . . . . 14 80 6.2.2.1. Non-Optimistic Handshakes . . . . . . . . . . . . 15 81 6.2.2.2. Predicted Parameters Correct . . . . . . . . . . . 15 82 6.2.3. Client Processing of First Flight . . . . . . . . . . 17 83 6.2.3.1. Successful first Flight But No Anti-Replay . . . . 17 84 6.2.3.2. Complete 0-RTT Handshake . . . . . . . . . . . . . 18 85 6.2.4. Session Resumption . . . . . . . . . . . . . . . . . . 18 86 6.3. Example Flows . . . . . . . . . . . . . . . . . . . . . . 18 87 6.4. New/Modified Messages . . . . . . . . . . . . . . . . . . 20 88 6.4.1. EarlyData Extension . . . . . . . . . . . . . . . . . 20 89 6.4.2. EncryptedExtensions . . . . . . . . . . . . . . . . . 21 90 6.4.3. PredictedParameters . . . . . . . . . . . . . . . . . 21 91 6.4.4. ServerKeyExchange . . . . . . . . . . . . . . . . . . 22 92 6.4.5. ServerParameters . . . . . . . . . . . . . . . . . . . 23 93 6.4.6. Anti-Replay Token . . . . . . . . . . . . . . . . . . 23 94 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 25 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 96 8.1. Limits Of Identity Hiding . . . . . . . . . . . . . . . . 25 97 8.2. Partial PFS . . . . . . . . . . . . . . . . . . . . . . . 25 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 100 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 101 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 102 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 27 103 A.1. EarlyData Extension . . . . . . . . . . . . . . . . . . . 27 104 A.2. Always Encrypt Client Parameters . . . . . . . . . . . . . 27 105 A.3. Always Restarting Non-Optimistic Handshakes . . . . . . . 28 106 A.4. Still TODO... . . . . . . . . . . . . . . . . . . . . . . 28 107 Appendix B. Summary of Existing Extensions . . . . . . . . . . . 28 108 Appendix C. Non-recommended Flows . . . . . . . . . . . . . . . . 29 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 111 1. Introduction 113 DISCLAIMER: THIS IS A ROUGH DRAFT. EVERYTHING HERE IS SOMEWHAT 114 HANDWAVY AND HASN'T REALLY HAD ANY SECURITY ANALYSIS. 116 The TLS WG is specifying TLS 1.3, a revision to the TLS protocol. 117 The two major design goals for TLS 1.3 are: 119 o Reduce the number of round trips in the handshake, providing at 120 least "zero round-trip" mode where the client can send its first 121 data message immediately without waiting for any response from the 122 server. 123 o Encrypt as much of the handshake as possible in order to protect 124 against monitoring of the handshake contents. 126 This document proposes revisions to the handshake to achieve these 127 objectives. They are being described in a separate document and for 128 ease of analysis and discussion. If they are considered acceptable, 129 some of them may be integrated into the main TLS document. 131 2. Background 133 In this section we briefly review the properties of TLS 1.2 [RFC5246] 135 2.1. Handshake Flows 137 As a reminder, this section reproduces the two major TLS handshake 138 variants, from [RFC5246]. For clarity, data which is 139 cryptographically protected by the record protocol (i.e., encrypted 140 and integrity protected) are shown in braces, as in {Finished}. 142 Client Server 144 ClientHello --------> 145 ServerHello 146 Certificate* 147 ServerKeyExchange* 148 CertificateRequest* 149 <-------- ServerHelloDone 150 Certificate* 151 ClientKeyExchange 152 CertificateVerify* 153 [ChangeCipherSpec] 154 {Finished} --------> 155 [ChangeCipherSpec] 156 <-------- {Finished} 157 {Application Data} <-------> {Application Data} 159 Figure 1: TLS 1.2 Full Handshake 161 Client Server 163 ClientHello --------> 164 ServerHello 165 [ChangeCipherSpec] 166 <-------- {Finished} 167 [ChangeCipherSpec] 168 {Finished} --------> 169 {Application Data} <-------> {Application Data} 171 Figure 2: TLS 1.2 Resumed Handshake 173 2.2. Handshake Latency 175 The TLS "Full Handshake" shown above incurs 2RTT of latency: the 176 client waits for the server Finished prior to sending his first 177 application data record. The purpose of the Finished is to allow the 178 client to verify that the handshake has not been tampered with, for 179 instance that the server has not mounted a downgrade attack on the 180 cipher suite negotiation. However, if the client is satisfied with 181 the handshake results (e.g., the server has selected the strongest 182 parameters offered by the client), then the client can safely send 183 its first application data immediately after its own Finished (this 184 is often called either "False Start" or "Cut Through" 185 [I-D.bmoeller-tls-falsestart]), thus reducing the handshake latency 186 to 1RTT for a full handshake. 188 Client Server 190 ClientHello --------> 191 ServerHello 192 Certificate* 193 ServerKeyExchange* 194 CertificateRequest* 195 <-------- ServerHelloDone 196 Certificate* 197 ClientKeyExchange 198 CertificateVerify* 199 [ChangeCipherSpec] 200 {Finished} 201 {Application Data} --------> 203 [ChangeCipherSpec] 204 <-------- {Finished} 205 {Application Data} <-------> {Application Data} 207 TLS 1.2 with False Start 209 This technique is not explicitly authorized by the TLS specification 210 but neither is it explicitly forbidden. A number of client 211 implementations (e.g., Chrome, Firefox, and IE) already do False 212 Start. However, because some servers fail if they receive the 213 application data early, it is common to use some kind of heuristic to 214 determine whether a server is likely to fail and therefore whether 215 this optimization can be used. 217 The abbreviated handshake already succeeds in 1RTT from the client's 218 perspective. 220 There have been proposals to take advantage of cached state between 221 the client and server to reduce the handshake latency to 0RTT 222 [I-D.agl-tls-snapstart]. However, they have not been widely adopted. 224 2.3. Plaintext Data in the Handshake 226 As shown in the figures above, essentially the entire handshake is in 227 the clear. Some of these values are potentially sensitive, 228 including: 230 o The client certificate. 231 o The server name indication (i.e., which server the client is 232 trying to contact. 233 o The server certificate (this is only interesting when the server 234 supports name-based virtual hosting via SNI) 236 o The next protocol in use [I-D.ietf-tls-applayerprotoneg]. 237 o The channel ID [REF: Channel ID] 238 o The client cipher suite list (potentially usable for client 239 fingerprinting.) 241 There have been proposals to address this just for extensions 242 [I-D.agl-tls-nextprotoneg] as well as for the handshake as a whole 243 [I-D.ray-tls-encrypted-handshake]. In general, the amount of privacy 244 protection which can be provided is somewhat limited by four factors: 246 o A fair amount of information can be gathered from traffic analysis 247 based on message size and the like. 248 o Because the existing mechanisms do not encrypt these values, an 249 active attacker can generally simulate being a server which does 250 not accept whatever new handshake protection mechanisms are 251 offered and force the client back to the old, unprotected 252 mechanism. This form of active attack can be mitigated by 253 refusing to use the old mechanism, however that is not always 254 possible if one wishes to retain backward compatibility. 255 o Many inspection devices mount a man-in-the-middle attack on the 256 connection and therefore will be able to inspect information even 257 if it is encrypted. 258 o It's very hard to avoid attackers learning the server's 259 capabilities because they generally fall into an easily probable/ 260 enumerable set and in most cases the clients are anonymous (and 261 thus indistinguishable from attackers). Probably the best we can 262 do is prevent attackers from learning which of a server's 263 capabilities a given client is exercising. 265 However, there are still advantages to providing protection against 266 passive inspection. The flows in this document attempt to provide 267 this service to the extent possible. 269 3. Basic Assumptions 271 This section lays out the basic assumptions that motivate the designs 272 in this document (aside from the objectives in Section 1. 274 Retain Basic TLS Structure: The intent of this document is to retain 275 the basic TLS structure and messages, tweaking them as minimally 276 as necessary to accomplish the objectives in Section 1. 277 Conservative design is good when working with security protocols. 279 Backward Compatibility is Required: It must be possible for TLS 1.3 280 implementations to interoperate with TLS 1.2 and below. 282 Minimize Variation: TLS already has a very large number of variant 283 handshakes which makes it confusing to analyze. We would like to 284 avoid multiplying this unnecessarily. We will probably deprecate 285 some of the old flows in TLS 1.3. 287 0-RTT modes require server-side state: The existing TLS anti-replay 288 mechanism involves the server and client jointly contributing 289 nonces and therefore can be stateless on the server (as long as a 290 fresh nonce can be generated.) Any 0-RTT mode in which the client 291 sends data along with his initial handshake message must use some 292 other mechanism to prevent replay, and this involves the server 293 keeping some state. 295 Latency is often more important than bandwidth: Because networks are 296 getting faster but the speed of light is not, it is often more 297 important to minimize the number of round trips than the number of 298 bits on the wire. 300 Client-side computation is often cheap: In many (but not all) cases, 301 clients can afford to do a lot of cryptographic operations very 302 cheaply. 304 Clients can and should be optimistic: When we put together the 305 previous points, we come to the conclusion that it's OK for 306 clients to be optimistic that things will succeed. So, for 307 instance, it's OK to send messages to the server that might need 308 to be retransmitted or recomputed if the server's state is not as 309 expected. This is a key element of a number of round-trip 310 reducing strategies. 312 4. Challenging Issues 314 This section previews some known challenging issues to keep in mind 315 in the text below. 317 SNI privacy versus round-trips and variant server configuration: SNI 318 is intended to alter the behavior of the server, but it also leaks 319 information about the intended server identity. These demands are 320 in tension. In situations where the server uses incompatible 321 cryptography for the different SNIs (e.g., the servers use only 322 RSA and use different keys) it is not possible to hide the SNI. 323 In other cases, e.g., where DHE is used but authenticated with 324 different keys, it is possible to have distinct configurations but 325 at the cost of multiple RTs in order to first exchange keys and 326 then to send the encrypted SNI and then respond to the server's 327 response. 329 Round-trips required for PFS: It's clearly not possible to do a 330 0-RTT handshake while also providing PFS. The two basic 331 alternatives are (1) abandon PFS for 0-RTT handshake (maybe using 332 re-handshakes on the same connection to get PFS) (2) Have a two- 333 stage crypto exchange where the client initially uses a key 334 generated using a cached server DH share and then and then later 335 uses a key generated from a fresh server DH share. The latter 336 approach seems too expensive to do on a regular basis. 338 5. Design Principles 340 5.1. Backward Compatibility is Required 342 It must be possible for TLS 1.3 implementations to interoperate with 343 TLS 1.2 and below. In the vast majority of cases this has to happen 344 cleanly and without a whole pile of extra round trips. This means 345 that, for instance, you can't just unconditionally send a ClientHello 346 that no TLS 1.2 server can accept and then do application layer 347 fallback. It may be acceptable to do so with a server you have good 348 reason to believe knows TLS 1.3, but that must not happen frequently 349 and there must be a fast way to fall back that never (or almost 350 never) fails. 352 5.2. Remove Static Key Exchange 354 We propose to eliminate all the static key exchange modes; this 355 principally means RSA since that is widely used (whereas static DH 356 and ECDH is not). The two major arguments for this change are: 358 o Static cipher suites are inherently non-forward secure. Modern 359 practice favors forward-secure algorithms. 360 o They add protocol complexity because we need to handle both 361 ephemeral and static modes. 363 In addition, RSA has a much worse performance/nominal security 364 profile than the ECDHE modes which we are likely to use for ephemeral 365 keying. 367 The major argument for continuing to allow static RSA is performance, 368 but ECDHE is fast enough that RSA + ECDHE is only marginally slower 369 than static RSA. Note that ephemeral keying can be used with the 370 existing RSA certificates, so there is no new deployment cost for 371 servers. 373 5.3. Protect SNI But Require Common Crypto Parameters 375 If you want to encrypt SNI data, then the server needs to be willing 376 to do encryption with the same keying material for all the virtual 377 servers; since we have banned static RSA above, that means 378 effectively the same DHE/ECDHE group. Also, encrypted SNI is 379 inherently incompatible with TLS 1.2 and below, since those servers 380 need to be able to see the SNI in order to know what certificate to 381 choose. Thus, any use of encrypted SNI will either need to come with 382 some sort of at least semi-graceful fallback to non-encrypted SNI or 383 accept that encrypted SNI can only be used with known TLS 1.3 384 servers. This does not mean, however, that the server cannot use a 385 different certificate; it merely needs to be willing to advertise and 386 use the same initial ephemeral key for each virtual server. 388 6. New Handshake Modes 390 This document includes a number of strategies for improving latency 391 and privacy, including: 393 o Move the CCS up in the handshake with respect to other messages so 394 that more of the handshake can be encrypted, thus improving 395 protection against passive handshake inspection. 396 o Allow the client to send at least some of his second flight of 397 messages (ClientKeyExchange, CCS, Finished, etc.) together with 398 the first flight in the full handshake, thus improving latency. 399 o Allow the client to send data prior to receiving the server's 400 messages, thus improving latency. 402 In addition, where prior versions of TLS generally assume that the 403 client is totally ignorant of the server's capabilities (e.g., 404 certificate and supported cipher suites) we assume that the client 405 has prior information about the server, either from prior contact or 406 some discovery mechanism such as DNS. 408 6.1. Overview 410 Our basic target is a 1-RTT handshake predicated on the assumption 411 that the client has a semi-static DHE/ECDHE key for the server. This 412 key can have been acquired in a number of possible ways, including a 413 prior interaction, a DNS lookup, or via an extra round trip in the 414 same handshake. Assuming that the client knows this key, you end up 415 with the handshake shown in Figure 3. 417 Client Server 419 ClientHello 420 + PredictedParameters 421 ClientKeyExchange 422 [ChangeCipherSpec] 423 {EncryptedExtensions} ---------> 424 ServerHello 425 ServerKeyExchange 426 [ChangeCipherSpec] 427 {EncryptedExtensions} 428 {Certificate*} 429 {CertificateRequest*} 430 {ServerParameters*} 431 {CertificateVerify*} 432 <--------- {Finished} 433 {[ChangeCipherSpec]} 434 {Certificate*} 435 {CertificateVerify*} 436 {Finished} ---------> 437 <--------- {Finished ???} 439 Figure 3: Basic 1-RTT Handshake 441 The most important thing to note about this handshake is that because 442 the client has initial knowledge of the server's key, the client 443 sends data to the server using two different cryptographic contexts. 444 The first is established by pairing the server's previously-known key 445 pair with the client's key and is used only to encrypt the client's 446 in the first flight. These messsages do not get PFS. The second 447 context is based on the server's ephemeral key found in the 448 ServerKeyExchange and the client's ephemeral key share and is used to 449 encrypt the rest of the handshake messages and any subsequent data. 450 These messages can have PFS. Note that the client sends two 451 ChangeCipherSpec messages in order to delineate the transition 452 between cleartext and the first context and then between the first 453 and second contexts. 455 This basic handshake can be extended with two major variants: 457 o If the client has no knowledge of the server's parameters, it 458 sends an initial ClientHello to solicit the server's DHE/ECDHE 459 key. Once it has the server's key, it simply sends the same 460 handshake messages as shown above. This is shown in Figure 4 461 o Once the client and server have communicated once, they can 462 establish an anti-replay token which can be used by the client to 463 do a 0-RTT handshake with the server in future. This is shown in 464 Figure 5. 466 [[OPEN ISSUE: This document does not currently discuss 467 renegotiation. It is an open question whether we should do so.]] 469 6.2. New Behaviors 471 6.2.1. Client Behavior for First Flight 473 The contents of the client's initial flight (what would be the 474 ClientHello in TLS 1.2 and below) depend on the client's knowledge -- 475 or at least beliefs -- about the server. The remainder of this 476 section describes appropriate client behavior in each of the major 477 cases. Note that these cases are described in sequence of increasing 478 client knowledge. The client may of course be wrong about the 479 server's state. 481 6.2.1.1. No Knowledge 483 In the simplest case, the client has no knowledge of the server's 484 state and does not wish to do anything speculative. In that case, 485 the client simply generates a standard TLS ClientHello with 486 essentially the same contents as would be in TLS 1.2 (though with a 487 TLS 1.3 version number). This ClientHello is backward compatible 488 with existing TLS 1.2 servers, modulo any issues with version 489 negotiation. 491 The client has two options here vis-a-vis sensitive information in 492 the extensions (principally SNI and/or ALPN). 494 o Send a message without SNI and ALPN. This will be compatible with 495 any TLS 1.3 server because that server will respond with its DHE 496 key, but may have compatibility issues with TLS 1.2 servers which 497 have differential behavior for SNI and ALPN. 498 o Send a message with SNI and/or ALPN. This will be compatible with 499 TLS 1.2 servers as well as TLS 1.3 but leaks some potentially 500 sensitive information. 502 If the client has strong reason to believe that the server supports 503 TLS 1.3, it SHOULD use the first option. [[OPEN ISSUE: Is there a 504 way to have clean fallback if the client doesn't provide SNI? Need 505 to determine how TLS 1.2 and below servers behave if you (a) offer a 506 high version of TLS and (b) don't offer SNI. I suspect they offer a 507 default certificate in which case you could detect this case. This 508 is not an issue for ALPN, since you just won't negotiate the next 509 protocol.]] 511 In either case, a TLS 1.3 server will respond to this message with a 512 ServerKeyExchange, as in Section 6.2.2.1. The client then knows the 513 server's keying material and so can restart the handshake as 514 described in the next section. 516 6.2.1.2. Server Keying Material 518 Once the client knows a valid DHE/ECDHE share for the server, it can 519 start to send encrypted handshake data (but not application data) 520 immediately. In order to do so, it SHOULD send along with its 521 ClientHello: 523 o A PredictedParameters (Section 6.4.3) message containing the 524 expected server selected parameters based on previous negotiations 525 or other out of band information. Note that the client is not 526 selecting out of server preferences; it is attempting to predict 527 the cipher suites the server will select out of the client's 528 advertised preferences. 529 o A ClientKeyExchange message containing an appropriate DHE/ECDHE 530 share. 531 o A ChangeCipherSpec message to indicate that it is now sending 532 encrypted data. 533 o An EncryptedExtensions (Section 6.4.2) message containing any 534 extensions which should be transmitted confidentially such as SNI 535 or ALPN. 537 In order to preserve compatibility with pre TLS 1.3 intermediaries 538 all of this data is packed into an EarlyData extension 539 (Section 6.4.1). 541 The encryption keys for the encrypted messages are computed using the 542 ordinary PRF construction but with an all-zero ServerRandom value. 543 Thus implies that there is no guarantee of freshness from the 544 server's side but that the client knows that the keying material is 545 fresh provided it generated the ClientRandom correctly. [[OPEN 546 ISSUE: If the client and server have previously exchanged messages 547 (see Section 6.2.1.1) then we could use that ServerRandom, but this 548 just makes the security properties more confusing.]] 550 6.2.1.3. Anti-Replay Token 552 If the client also has an anti-replay token (see Section 6.4.6 for 553 details) it can act as in the previous section but also include the 554 anti-replay information in the EncryptedExtensions message (the 555 information is encrypted here to avoid linkage between multiple 556 handshakes by the same client). 558 If previous interactions with the same server indicate that client 559 authentication is required [[TODO: provide an explicit signal for 560 this in either ServerParameters or CertificateRequest]], the client 561 MUST also provide Certificate and CertificateVerify messages. 563 In addition, a client MAY include one or more encrypted 564 application_data records containing data for the server to process. 565 These records MUST follow the Finished message. 567 [[TODO: We need to tie the CertificateVerify to the server 568 certificate. In the other handshakes, this binding is a side effect 569 of having the server certificate supplied in the handshake. Here, 570 the certificate is implicit, so the client's signature doesn't cover 571 it automatically. One option is to have the client replay the 572 server's Certificate message after the AntiReplayToken. The 573 cached_information extension could allow this to be replaced with a 574 hash of the same.]] 576 6.2.2. Server Behavior For First Flight 578 Upon receiving the client's first flight, the server must examine 579 both the ClientHello information and the EarlyData information to 580 determine the extent to which the client has optimistically added 581 information and the extent to which the client's optimism is 582 warranted. The server SHOULD follow the following algorithm or an 583 equivalent one: 585 1. If the client's maximum version number is less than 1.3, then 586 proceed as defined in [RFC5246]. 587 2. Perform cipher suite negotiation and extension negotiation as 588 specified in [RFC5246] and remember the results and the resultant 589 ServerHello. NOTE: This is why SNI requires the cryptographic 590 parameters to be identical for each virtual host. 591 3. If the client has not included a ClientKeyExchange in the 592 ClientHello, this is a non-optimistic handshake, proceed as 593 described Section 6.2.2.1. Send a ServerHello and 594 ServerKeyExchange to give the client the server's parameters. 595 4. If the ClientKeyExchange message is incompatible with the 596 negotiated parameters, then this is a failed optimistic handshake 597 Proceed as in Section 6.2.2.1. 598 5. If a PredictedParameters message is present, check that it 599 matches the negotiated parameters from step 2. Note that this 600 means that the client must predict *exactly* the cipher suite and 601 compression parameters that the server selects. If there is a 602 failed match, this is a failed optimistic handshake so proceed as 603 if it were not optimistic (See Section 6.2.2.1.) Otherwise, this 604 is a successful optimistic handshake, so proceed as in 605 Section 6.2.2.2. 606 6. Anything else is an error. 608 [[TODO: rewrite the logic here for more clarity??]] 610 6.2.2.1. Non-Optimistic Handshakes 612 In the case where the client has not been optimistic or has been 613 optimistic but wrong, the server simply sets the client's 614 expectations so that the client can try again. Specifically, this 615 means that the server responds with the following messages: 617 o ServerHello indicating the negotiated parameters. 618 o ServerKeyExchange (Section 6.4.4) 619 o ServerHelloDone 621 [[OPEN ISSUE: This looks a lot like the of the messages described in 622 Section 6.2.2.2, so the client needs to infer that he needs to 623 restart based on the ServerHelloDone being present and Finished being 624 absent. This works, but it might be better to make it more explicit 625 by adding a new message such as HelloRequest.]] 627 The server MUST ignore any client extensions which are not necessary 628 to negotiate the cryptographic parameters. This does not mean that 629 they will not be used, merely that they will be negotiated in a 630 subsequent exchange. Note that TLS 1.2-compatible clients generally 631 will need to put SNI and perhaps ALPN in their ClientHello. Because 632 TLS 1.3 servers MUST use common cryptographic parameters regardless 633 of these extensions (see Section 5.3), the server MUST ignore these 634 values. The client responds to these messages by sending a new 635 Clienthello that conforms to the servers known expectations, as in 636 Section 6.2.1.2. The original round-trip messages MUST be included 637 in the handshake hashes for the Finished to tie them to the rest of 638 the handshake. 640 [[OPEN ISSUE: This is a deliberately missed opportunity for a modest 641 optimization. If the client has already provided a full ClientHello 642 as would be needed for TLS 1.2, then the server could do a TLS 1.2- 643 style handshake including sending its Certificate, 644 CertificateRequest, etc., whereas we now have to have a full round 645 trip. However, in the name of reducing protocol complexity, we are 646 eschewing this. An alternate choice would be to simply fall back to 647 the TLS 1.2 behavior and do a TLS 1.2-style handshake.]] 649 6.2.2.2. Predicted Parameters Correct 651 If the client has correctly predicted the server parameters (i.e., 652 the cipher suite, compression, etc. that the server would have 653 selected based on the ClientHello), then the client and server now 654 share a PreMaster Secret based on the client's ClientKeyExchange and 655 the previously provided ServerParameters. The server computes the 656 PMS, Master Secret, and traffic keys and decrypts the rest of the 657 client's handshake messages. If any non-handshake messages are 658 present, this is an error and the server MUST fail with a fatal 659 "unexpected_message" alert. 661 Once the server has generated the keys, it MUST process the client's 662 EncryptedExtensions, which contains any extensions it wants 663 protected. The EncryptedExtensions MAY contain an Anti-Replay Token 664 (ART) (Section 6.4.6), which may either be valid or invalid. 666 6.2.2.2.1. Missing or Invalid ART 668 If the ART is missing or invalid, then this is a basic 1-RTT 669 handshake. The server ignores any application_data records as well 670 as client handshake messages other than those specified in 671 Section 6.2.1.2 and sends his first flight of messages in the 672 following order: 674 o ServerHello 675 o ServerKeyExchange (Section 6.4.4) 676 o ChangeCipherSpec 677 o EncryptedExtensions (Section 6.4.2) 678 o Certificate* 679 o CertificateRequest* 680 o ServerParameters* Section 6.4.5 681 o CertificateVerify* (if Certificate provided) 682 o Finished [[TODO:AlmostFinished??]] 684 The use of the CertificateVerify is new in this context. In prior 685 versions of TLS, the CertificateVerify was only used to authenticate 686 the client. Here it is also used to authenticate the server. This 687 usage has the side benefit that it authenticates the entire handshake 688 up to this point, not just the server's key. 690 Note that everything after the ServerKeyExchange and ChangeCipherSpec 691 is encrypted, thus this mode provides limited privacy. All 692 extensions other than those required to establish the cryptographic 693 parameters MUST be in the EncryptedExtensions, not the ServerHello. 694 Specifically, it protects the server's certificate (but not SNI) and 695 the selected ALPN data. 697 6.2.2.2.2. Valid ART 699 If the ART is valid, then this is a 0-RTT handshake. The server MUST 700 verify that the client sent the appropriate handshake messages, 701 including Certificate and CertificateVerify if required by server 702 policy, as well as a valid Finished message. The server then 703 generates and sends its own first flight which is exactly the same as 704 above but MUST omit the CertificateRequest, since the client MUST 705 already have provided its certificate if required. 707 The EncryptedExtensions MUST include an ART indicator that matches 708 the client's ART so that the client knows that the 0-RTT handshake 709 was successful and that the client's application_data was accepted. 710 The details of how this works are TBD. (See Section 6.4.6.) 712 The server MUST also process any application_data records in the 713 client's initial flight. 715 [[TODO: Open issue: should we require Certificate and 716 CertificateVerify for 0-RTT handshakes? The client in principle has 717 the server's parameters, but it would make life more consistent to 718 have less options and the signature isn't that big a deal any more. 719 The cost here is the computation and the message size.]] 721 6.2.3. Client Processing of First Flight 723 Upon receiving the server's first flight, the client must examine the 724 server's messages to determine what happened. The client SHOULD 725 follow an algorithm equivalent to the following. 727 1. If the server version is 1.2 or below, then follow the processing 728 rules for [RFC5246]. 729 2. If the server has provided only a ServerHello, ServerKeyExchange, 730 and ServerHelloDone, then all optimistic key exchange has failed. 731 Re-send a ClientHello with the provided server key and negotiated 732 parameters as in Section 6.2.1.2 733 3. If the server provided a full flight of messages but no anti- 734 replay token in the EncryptedExtensions then the client needs to 735 process the messages and send his second flight as described in 736 Section 6.2.3.1. 737 4. If the server responds with an anti-replay token as well as a 738 full flight of messages the handshake is finished and the client 739 can assume that any data it sent was processed. See 740 Section 6.2.3.2 741 5. If the server supplies a ServerParameters message, the client 742 SHOULD remember those parameters for use with future handshakes 743 and forget any previous ServerParameters for this server. The 744 ServerParameters are not used for this connection. 746 6.2.3.1. Successful first Flight But No Anti-Replay 748 If the server's first flight is complete but has no anti-replay 749 token, then the handshake is not quite complete: the client 750 processes the messages and generates its second flight, consisting 751 of: 753 o ChangeCipherSpec (to indicate either the key change) 754 o Certificate and CertificateVerify (if client authentication was 755 requested) 756 o Finished 758 At this point, the client can start sending application_data. If any 759 application data was sent with the original ClientHello, the server 760 will have discarded it and it must be retransmitted. 762 [[OPEN ISSUE: Do we need a final Finished from the server. The only 763 thing it does is confirm the server's receipt of the client 764 certificate, but at the cost of an RT if the client actually checks 765 it.]] 767 6.2.3.2. Complete 0-RTT Handshake 769 If the server has provided an anti-replay token that matches the 770 client's, the handshake is complete. The client MUST then send a 771 ChangeCipherSpec and Finished to acknowledge the new key provided by 772 the server in the ServerKeyExchange. [[OPEN ISSUE: Can we remove 773 Finished here?]] 775 6.2.4. Session Resumption 777 While resumption adds significant complexity, there are going to be 778 low-end devices which still need to support resumption. This is 779 particularly relevant for the Internet-Of-Things type devices. Note 780 that this question is orthogonal to the non-resumed handshake flows. 782 [TODO: This section still needs to be written depending on if people 783 want to do resumption. It should be straightforward.] 785 6.3. Example Flows 786 Client Server 788 ClientHello --------> 789 ServerHello 790 ServerKeyExchange 791 <-------- ServerHelloDone 792 ClientHello 793 + PredictedParameters 794 ClientKeyExchange 795 [ChangeCipherSpec] 796 {EncryptedExtensions} ---------> 797 ServerHello 798 [ChangeCipherSpec] 799 {EncryptedExtensions} 800 {Certificate*} 801 {CertificateRequest*} 802 {ServerParameters*} 803 {CertificateVerify*} 804 <--------- {Finished} 805 {Certificate*} 806 {CertificateVerify*} 807 {Finished} ---------> 808 <--------- {Finished ???} 810 Figure 4: Non-Optimistic Handshake 812 [TODO: Can we remove the first finished rather than the second 813 finished. Could we remove a RT.]] 814 Client Server 816 ClientHello 817 + PredictedParameters 818 ClientKeyExchange 819 [ChangeCipherSpec] 820 {EncryptedExtensions 821 + AntiReplayToken} 822 {Certificate*} 823 {CertificateVerify*} 824 {Finished} 825 {ApplicationData} ---------> 826 ServerHello 827 ServerKeyExchange 828 [ChangeCipherSpec] 829 {EncryptedExtensions 830 + AntiReplayToken} 831 {Certificate*} 832 {CertificateRequest*} 833 {ServerParameters*} 834 {CertificateVerify*} 835 <--------- {Finished} 836 {[ChangeCipherSpec]} 837 {Finished???} ---------> 839 Figure 5: Handshake With Anti-Replay 841 6.4. New/Modified Messages 843 6.4.1. EarlyData Extension 845 In order to comply with TLS 1.2, any messages which we wish to be in 846 the client's first flight must be packaged as extensions to the 847 ClientHello. The EarlyData extension is usable for this purpose. 849 struct { 850 TLSCipherText messages<5 .. 2^24-1>; 851 } EarlyDataExtension; 853 The client may include no more than one EarlyData extension in its 854 ClientHello. The extension simply contains the TLS records which 855 would otherwise have been included in the client's first flight. Any 856 data included in EarlyData is not integrated into the handshake 857 hashes directly. Instead, it is hashed in as marshalled into the 858 extension. Note that this may include application_data traffic. 859 Because this is an extension, the server is explicitly permitted to 860 ignore these messages and the client must be prepared to continue 861 properly. However, TLS 1.3 servers SHOULD process any messages in 862 the EarlyData extension, though it may not ultimately be able to use 863 them. 865 [[Open Issue: in this version, we never send EarlyData unless we 866 have evidence that the server is TLS 1.3. In principle we might be 867 able to just send the messages directly, but what about middleboxes 868 which have appeared in the path since we discovered that. In that 869 case, we would need a ClientHelloDone]] 871 6.4.2. EncryptedExtensions 873 struct { 874 Extension extensions<0..2^16-1>; 875 } EncryptedExtensions; 877 The EncryptedExtensions message simply contains any extensions which 878 should be protected, i.e., any which are not needed to establish the 879 cryptographic context. It MUST only be sent after the switch to 880 protected operations. See Appendix B for guidance on which 881 extensions go where. 883 6.4.3. PredictedParameters 885 struct { 886 ProtocolVersion version; 887 CipherSuite cipher_suite; 888 CompressionMethod compression_method; 889 opaque server_key_label<0..2^16-1>; 890 Extension extensions<0..2^16-1>; 891 } PredictedParameters; 893 The PredictedParameters message contains the clients prediction of 894 the parameters that the server will select and therefore which the 895 client is optimistically using for the connection. The values here 896 are: 898 version 899 The negotiated TLS version. 901 cipher_suite 902 The selected cipher suite. 904 compression_method 905 The negotiated TLS compression method. [[OPEN ISSUE: Should we 906 just remove compression.]]. 908 server_key_label 909 The label for the server key (provided in a Section 6.4.5 910 message). 912 extensions 913 Any extensions which form part of the SecurityParameters, such as 914 "truncated_hmac" or "max_fragment_length". 916 6.4.4. ServerKeyExchange 918 In the existing TLS handshake, if the server is authenticated (the 919 most common case) the ServerKeyExchange contains a digital signature 920 over the server's ephemeral public keying material. However, this 921 obviously leaks the identity that the server is using; even if the 922 server certificate is encrypted an attacker can simply iterate over 923 the server's certificates until it finds one that allows verification 924 of the signature (at least in the case where each SNI uses a 925 different certificate). 927 In order to remove this issue, we remove the signature from the 928 ServerKeyExchange and use the CertificateVerify message (which was 929 previously only used for client certificate verification). 931 struct { 932 select (KeyExchangeAlgorithm) { 933 case dhe_dss: 934 case dhe_rsa: 935 ServerDHParams params; 937 case ec_diffie_hellman: 938 ServerECDHParams params; 939 } 940 } ServerKeyExchange; 942 6.4.5. ServerParameters 944 struct { 945 opaque label<0..2^16-1>; 946 uint32 lifetime; 947 select (KeyExchangeAlgorithm) { 948 case dhe_dss: 949 case dhe_rsa: 950 ServerDHParams params; 952 case ec_diffie_hellman: 953 ServerECDHParams params; 954 }; 955 } ServerParameters; 957 The ServerParameters message is used to indicate the server's "long- 958 term" (really medium-term) parameters, specifically a DHE/ECDHE key 959 pair which can potentially be used by the client for future 960 connections, thus shortcutting the round-trip to discover the 961 server's DH key. [[OPEN ISSUE: Should we add other policy-like 962 stuff like whether we expect client auth? This would make the 963 behavior expected for 0-RTT handshakes explicit rather than implicit. 964 I am leaning towards this.]] The params are the same fields as in 965 the ServerKeyExchange [[OPEN ISSUE: Merge these?]]. The other 966 fields are as follows. 968 label 969 A label for these parameters which can be re-sent by the client in 970 the PredictedParameters messages. Note that this is left 971 potentially quite large to allow the server to pack data into it, 972 though this may have an impact on performance. 974 lifetime 975 The expected useful lifetime of these parameters in seconds from 976 now. 978 6.4.6. Anti-Replay Token 980 There are a number of potential mechanisms for detecting replay on 981 the server side. Generally all of them require the server to give 982 the client some identifier which is later replayed to the server to 983 help it recover state and detect replays. 985 This section lists the main ones I know of: 987 o Memorize arbitrary client values, typically within some scope, (as 988 in [I-D.agl-tls-snapstart]) 989 o Force the client to use an identifier + values in some ordered way 990 (e.g., by using a sliding anti-replay bitmask) 991 o Give the client some finite number of tokens that you remember 992 until they are used (as an enhancement, these could be DH public 993 keys) 995 Each of these approaches has costs and benefits; generally the exact 996 form of the anti-replay mechanism is orthogonal to the design of 997 0-RTT handshake. 999 As an example, consider the mechanism used by Snap Start, which 1000 assumes roughly synchronized clocks between the client and the 1001 server. The server maintains a list of all the ClientRandom values 1002 offered within a given time window (recall that the TLS ClientRandom 1003 value contains a timestamp) and rejects any ClientRandoms which 1004 appear to be outside that window. The server also provides the 1005 client with an 8-byte "orbit" value (which would serve here as the 1006 Anti-Replay Token) which can be used to separate the anti-replay 1007 lists from distinct servers. If a server sees a duplicate 1008 ClientRandom, one from a different orbit, or one from a time outside 1009 the window, it rejects it and forces the client to complete the 1010 handshake with a fresh server nonce. 1012 If we were to follow this model, we would have something like the 1013 following. [[OPEN ISSUE: The following is extremely handwavy and 1014 presented as one possibility. It needs to be gone over more 1015 carefully.]] 1017 struct { 1018 opaque orbit[8]; 1019 uint64 time; 1021 select (ConnectionEnd) { 1022 case Client: 1023 opaque certificate_hash; 1024 case Server: 1025 ; // Empty 1027 }; 1028 } AntiReplayToken; 1030 These fields would be something like: 1032 orbit 1033 An arbitrary 64-bit quantity selected by the server. 1035 time 1036 The current time in microseconds since the UNIX epoch. 1038 certificate_hash 1039 A digest of the server's expected Certificate message using the 1040 Hash from the PRF. This would need to be checked by the server to 1041 verify that the client is trying to talk to the right server. 1042 [[OPEN ISSUE: This still seems like kind of a mess.]] 1044 7. Backward Compatibility 1046 The high-order compatibility issue for any change to TLS is whether 1047 the ClientHello is compatible with old servers. To a first order, we 1048 deal with this by putting any new information in extensions. This is 1049 ugly, but mostly works. 1051 8. Security Considerations 1053 Everything in this document needs further analysis to determine if it 1054 is OK. Comments on some known issues below. 1056 8.1. Limits Of Identity Hiding 1058 If the SNI and ALPN information are only sent encrypted (i.e., are 1059 not included in an initial unencrypted ClientHello) then they are 1060 secure from a passive attacker, and thus so is the server's identity. 1061 An active attacker can, however, force the client to reveal them by 1062 simulating a non-optimistic handshake (even if the client has a 1063 previous ServerParameters value) and sending his own DHE/ECDHE share, 1064 thus eliciting a version of the extensions encrypted to him. This 1065 cannot be done transparently to the client, however, since it will 1066 generate a handshake failure. 1068 By contrast, since the server authenticates first and the client only 1069 encrypts its certificate under keying material which has been 1070 authenticated by the server, the attacker does not learn the client's 1071 identity. 1073 8.2. Partial PFS 1075 If the client opts to use an optimistic handshake, any messages the 1076 client sends before the ServerKeyExchange will not have PFS, as they 1077 will be encrypted with a key which is necessarily somewhat long-term. 1078 The server can of course limit the exposure of the data by limiting 1079 the lifetime of keys, but at the cost of reducing the success 1080 probability of optimistic handshakes. 1082 Servers can opt to always require PFS by never supplying 1083 ServerParameters, thus forcing the client to go through a full 1084 handshake. Clients can opt to always require PFS by never offering 1085 an optimistic handshake. 1087 9. Acknowledgements 1089 This document borrows ideas and/or has benefitted from feedback from 1090 a large number of people, including Dan Boneh, Wan-Teh Chang, Steve 1091 Checkoway, Matt Green, Cullen Jennings, Adam Langley, Nagendra 1092 Modadugu, Bodo Moeller, Andrei Popov, Marsh Ray, Hovav Shacham, 1093 Martin Thomson, and Brian Smith. 1095 10. References 1097 10.1. Normative References 1099 [I-D.ietf-tls-cached-info] 1100 Santesson, S. and H. Tschofenig, "Transport Layer Security 1101 (TLS) Cached Information Extension", 1102 draft-ietf-tls-cached-info-16 (work in progress), 1103 February 2014. 1105 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1106 Requirement Levels", BCP 14, RFC 2119, March 1997. 1108 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1109 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1111 10.2. Informative References 1113 [I-D.agl-tls-nextprotoneg] 1114 Langley, A., "Transport Layer Security (TLS) Next Protocol 1115 Negotiation Extension", draft-agl-tls-nextprotoneg-04 1116 (work in progress), May 2012. 1118 [I-D.agl-tls-snapstart] 1119 Langley, A., "Transport Layer Security (TLS) Snap Start", 1120 draft-agl-tls-snapstart-00 (work in progress), June 2010. 1122 [I-D.bmoeller-tls-falsestart] 1123 Langley, A., Modadugu, N., and B. Moeller, "Transport 1124 Layer Security (TLS) False Start", 1125 draft-bmoeller-tls-falsestart-00 (work in progress), 1126 June 2010. 1128 [I-D.ietf-tls-applayerprotoneg] 1129 Friedl, S., Popov, A., Langley, A., and S. Emile, 1130 "Transport Layer Security (TLS) Application Layer Protocol 1131 Negotiation Extension", draft-ietf-tls-applayerprotoneg-04 1132 (work in progress), January 2014. 1134 [I-D.ray-tls-encrypted-handshake] 1135 Ray, M., "Transport Layer Security (TLS) Encrypted 1136 Handshake Extension", draft-ray-tls-encrypted-handshake-00 1137 (work in progress), May 2012. 1139 Appendix A. Design Rationale 1141 This section attempts to explain some of the design decisions in this 1142 document. 1144 A.1. EarlyData Extension 1146 In TLS 1.2, the client's first flight consists solely of the 1147 ClientHello message. In TLS 1.3, we allow other handshake messages, 1148 but these are likely to cause incompatibilities. Specifically, if 1149 the client sends other messages besides the ClientHello it will cause 1150 handshake failures. In prior versions of this document, this was 1151 necessary because the client could optimistically send messages even 1152 if it did not know that the server supported TLS 1.3. In the current 1153 version of the document, this is not possible, but there may still be 1154 intermediaries in the path which enforce pre TLS 1.3 semantics. 1155 These intermediaries may have been added after the client's last 1156 contact with the server. For that reason, we continue to keep these 1157 extra messages in an extension. This may change if research 1158 indicates it is unnecessary. 1160 A.2. Always Encrypt Client Parameters 1162 If there is a commonly-recognized DHE/ECDHE group, the client can 1163 just offer its DHE/ECDHE key in the ClientHello and hope that the 1164 server supports it, as shown in Figure 6. This mode would protect 1165 only the server's response to the client but not the client's 1166 extensions, etc. We want to have a mode which does protect the 1167 client's extensions (principally SNI) and supporting both modes adds 1168 complexity, so we opted not to provide the partially-encrypted mode. 1169 If the WG wanted to add it, we could do so. 1171 A.3. Always Restarting Non-Optimistic Handshakes 1173 The non-optimistic handshake shown in Figure 4 requires the client to 1174 restart with a new ClientHello even if the server could actually have 1175 sent a full first flight as in TLS 1.2. This case could occur either 1176 because the client sent SNI and ALPN for backwards compatibility or 1177 because the server doesn't have behavior contingent on SNI/ALPN. The 1178 result is that the handshake takes an extra round trip when compared 1179 to TLS 1.2 with False Start. 1181 The alternative would be to allow a server to do a TLS 1.2-style 1182 handshake if the client had supplied enough information to do so 1183 (though we could encrypt the client's Certificate if we chose). This 1184 would shorten the round trip time in the case where the client and 1185 server had no previous contact (though with the known security 1186 restrictions of The major argument against this alternative is that 1187 it is yet another mode in an already complex protocol. 1189 A.4. Still TODO... 1191 [[TODO: Explain the following]] 1193 o Server-side parameter selection versus client-side parameter 1194 selection. 1195 o Public semi-static server parameters versus client-specific 1196 parameters. 1197 o Correction instead of negotiation 1199 Appendix B. Summary of Existing Extensions 1201 Many of the flows in this document have Extensions appear both both 1202 in the clear and encrypted. This section attempts to provide a 1203 first-cut proposal (in table form) of which should appear where. 1205 Extension Privacy level Proposed Location 1206 -------------------------------------------------------------- 1207 server_name Medium Server chooses (*) 1208 max_fragment_length Low Clear 1209 client_certificate_url High Encrypted 1210 trusted_ca_keys Low Server chooses (*) 1211 truncated_hmac Low Clear 1212 status_request Low Encrypted 1213 user_mapping ? ? 1214 client_authz ? ? 1215 server_authz ? ? 1216 cert_type Low Server chooses (*) 1217 elliptic_curves Low Clear 1218 ec_point_formats Low Clear 1219 srp High ???? 1220 signature_algorithms Low Clear 1221 use_srtp Low Encrypted 1222 heartbeat Low Encrypted 1223 alpn Medium Encrypted 1224 status_request_v2 Low Encrypted 1225 signed_certificate_timetamp ? ? 1226 SessionTicket TLS Medium Encrypted/Clear *** 1227 renegotiation_info Low Encrypted 1229 * The server may need these in the clear but the client 1230 would prefer them encrypted. 1232 *** The SessionTicket must appear in the clear when resuming but 1233 can be encrypted when being set up. 1235 The general principle here is that things should be encrypted where 1236 possible; extensions generally are proposed to be in the Clear part 1237 of handshake only if it seems they must be there to make the rest of 1238 the handshake work. The things that seem problematic are those which 1239 leak information about the client's dynamic state (as opposed to 1240 implementation fingerprinting) but are potentially needed by the 1241 server for ciphersuite selection. These are labelled "Server 1242 Chooses" in this table. 1244 It's possible we can make life somewhat simpler by deprecating some 1245 unused extensions, but based on the table above, it looks like the 1246 extensions that make life complicated are not the ones that can be 1247 easily removed. 1249 Appendix C. Non-recommended Flows 1251 The flow below is the only one in which we don't protect client 1252 extensions. It complicates things and doesn't seem to meet our goals 1253 in terms of protecting that sort of information from traffic 1254 analysis. 1256 Client Server 1258 ClientHello 1259 + ClientKeyExchange ---------> 1260 ServerHello 1261 [ChangeCipherSpec] 1262 {EncryptedServerHello} 1263 {Certificate*} 1264 {CertificateRequest*} 1265 {ServerParameters*} 1266 {CertificateVerify*} 1267 <--------- {Finished} 1268 [ChangeCipherSpec] 1269 {Certificate*} 1270 {CertificateVerify*} 1271 {Finished} ---------> 1272 <--------- {Finished ???} 1274 Figure 6: Handshake With Known Group 1276 Author's Address 1278 Eric Rescorla 1279 Mozilla 1280 2064 Edgewood Drive 1281 Palo Alto, CA 94303 1282 USA 1284 Phone: +1 650 678 2350 1285 Email: ekr@rtfm.com