idnits 2.17.1 draft-ray-tls-encrypted-handshake-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 04, 2012) is 4369 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 5246' is mentioned on line 70, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Missing Reference: 'RFC 6066' is mentioned on line 107, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 494, but not defined == Missing Reference: 'TBD' is mentioned on line 237, but not defined == Missing Reference: 'TLS' is mentioned on line 342, but not defined == Missing Reference: 'RFC 4492' is mentioned on line 344, but not defined ** Obsolete undefined reference: RFC 4492 (Obsoleted by RFC 8422) == Missing Reference: 'RFC 5746' is mentioned on line 551, but not defined == Unused Reference: 'RFC4492' is defined on line 834, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 838, but no explicit reference was found in the text == Unused Reference: 'RFC5746' is defined on line 841, but no explicit reference was found in the text == Unused Reference: 'RFC6066' is defined on line 845, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Ray 3 Internet-Draft PhoneFactor, Inc. 4 Intended status: Informational May 04, 2012 5 Expires: November 03, 2012 7 Transport Layer Security (TLS) Encrypted Handshake Extension 8 draft-ray-tls-encrypted-handshake-00 10 Abstract 12 This specification defines a Transport Layer Security (TLS) extension 13 which allows endpoints to negotiate the use of encryption with 14 forward secrecy at the beginning of the handshake. Two levels of 15 functionality are defined. Implementations are free to support one 16 or both levels, with the first level incurring no additional 17 computational or round-trip overhead. The TLS cryptographic 18 calculations are unchanged. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 03, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Functional Overview . . . . . . . . . . . . . . . . . . . . . 3 55 3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5 56 4. ServerHello2a handshake message . . . . . . . . . . . . . . . 7 57 5. ServerHello2b handshake message . . . . . . . . . . . . . . . 8 58 6. ClientHello2 handshake message . . . . . . . . . . . . . . . . 9 59 7. Session resumption . . . . . . . . . . . . . . . . . . . . . . 9 60 8. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 61 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 14 62 10. Other Considerations . . . . . . . . . . . . . . . . . . . . . 15 63 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 64 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 65 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 68 1. Introduction 70 Although TLS [RFC 5246] provides a variety of cryptographic options 71 for securing application data it exposes an unnecessarily large 72 amount of plaintext during its initial handshake. The server's 73 identity, session resumption data, and session ticket data are all 74 sent in the clear. When client cert authentication is used, the 75 client's identity and the server's list of trusted root CAs is also 76 exposed. Typically the leaked information is sufficient to allow a 77 passive observer to fingerprint the TLS client and server 78 applications in use, and even to learn something about the connection 79 history of the user. This is arguably not a characteristic of an 80 ideal data security protocol. 82 Currently, the only defined way to fully encrypt a TLS handshake is 83 to first perform an unencrypted TLS handshake as an anonymous client 84 and server and then immediately renegotiate the connection all over 85 again in the new encrypted channel. The overhead this imposes is 86 significant, effectively doubling the number of (relatively 87 expensive) public key operations and requiring several additional 88 round trips. Furthermore, implementations often completely forbid 89 both the initial anon-anon TLS connection as well as client-initiated 90 renegotiation. Consequently, renegotiation is of limited use to 91 endpoints desiring greater protection for their handshake data. 93 The amount of interesting information sent in the clear will continue 94 to increase as new protocol features and applications are enabled by 95 new TLS extensions. But some interesting new applications may be 96 limited by the lack of encryption during the initial handshake. 98 In the unmodified TLS handshake, encryption of the record layer 99 begins seemingly as late in the process as possible. The reasons for 100 this design decision are unclear but it seems likely to be an 101 artifact of the historical under-use of ephemeral Diffie-Hellman 102 (DHE) cipher suites at the time (SSLv2 did not support them at all). 103 At the time, the need for the additional computation required by 104 traditional Diffie-Hellman key exchange was considered expensive and 105 for the RC4 cipher (very popular for its efficiency) DHE cipher 106 suites have never even been defined. Before the Server Name 107 Indication (SNI) extension [RFC 6066], it was not possible to serve 108 multiple HTTPS sites from a single IP address, so the specific site 109 to which the user was connecting was effectively already known. 110 There were no TLS extensions to carry interesting plaintext, so there 111 was little interesting plaintext to protect (client certs being a 112 notable exception). 114 Today we have a greater amount of interesting information present in 115 the handshake, faster hardware, and the far more efficient Elliptic 116 Curve DH algorithms. Some very high-traffic sites are configured to 117 select (EC)DHE cipher suites whenever the option is presented by the 118 client.[XXX cite] There are new extensions being proposed that would 119 benefit from encryption in the handshake.[XXX cite NP(N)] So this 120 appears to be an appropriate time to introduce early encryption via 121 ephemeral key exchange into the handshake. 123 1.1. Requirements Language 125 XXX reference presentation language in 5246 here? 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 2. Functional Overview 133 The Encrypted Handshake (EH) extension allows endpoints to perform a 134 key exchange and begin record layer encryption as early in the 135 handshake as possible. Two levels of protection provide flexibility 136 for the client and server (and the implementation) to manage 137 practical considerations and level of effort. 139 While in general it is not possible to protect pre-authentication 140 data from an active man-in-the-middle type attacker, this extension 141 hides the bulk of the handshake data from a passive observer and can 142 detect active attacks as a failed handshake. 144 Level one provides encryption with forward secrecy for all data in 145 the Server Hello message (including Server Hello extensions) and all 146 data following. This level incurs no additional computational or 147 round-trip overhead over the traditional handshake and is intended to 148 require minimal changes to the implementation of existing libraries, 149 but it has the limitation that data sent by the client in the Client 150 Hello continues to be sent in the clear. 152 The second level of implementation encrypts all the same handshake 153 data as the first and additionally encrypts the most interesting 154 parts of the Client Hello (e.g. the extensions), but it requires an 155 additional round trip to the server. 157 Note that in the following diagrams, an asterisk (*) is used to 158 indicate a optional or situation-dependent messages, while square 159 brackets are placed around the [ChangeCipherSpec] message to reflect 160 its distinct record type. 162 For reference, the traditional TLS full handshake without Encrypted 163 Handshake looks like this: 165 Client Server 167 ClientHello --------> 168 ServerHello 169 Certificate* 170 ServerKeyExchange* 171 CertificateRequest* 172 <-------- ServerHelloDone 173 Certificate* 174 ClientKeyExchange 175 CertificateVerify* 176 [ChangeCipherSpec] 177 Finished --------> 178 [ChangeCipherSpec] 179 <-------- Finished 180 Application Data <-------> Application Data 182 Figure 1. Unencrypted TLS full handshake. 184 When the use of EH level one has been negotiated, the ServerHello 185 message is split to allow the ChangeCipherSpec record to be sent as 186 soon as possible: 188 Client Server 190 ClientHello (with EH ext) --------> 191 ServerHello2a 192 [ChangeCipherSpec] 193 ServerHello2b 194 Certificate* 195 ServerKeyExchange* 196 CertificateRequest* 197 <-------- ServerHelloDone 198 [ChangeCipherSpec] 199 Certificate* 200 ClientKeyExchange 201 CertificateVerify* 202 Finished --------> 203 <-------- Finished 204 Application Data <-------> Application Data 205 Figure 2. TLS full handshake using EH level one. 207 When the use of EH level two has been negotiated, the ServerHello 208 message is split and the ChangeCipherSpec record is sent early (as in 209 level one). The protocol then performs an additional round-trip in 210 order to allow the complete ClientHello2 to be transmitted within the 211 encrypted channel: 213 Client Server 215 ClientHello (with EH ext) --------> 216 ServerHello2a 217 <-------- [ChangeCipherSpec] 218 [ChangeCipherSpec] 219 ClientHello2 --------> 220 ServerHello2b 221 Certificate* 222 ServerKeyExchange* 223 CertificateRequest* 224 <-------- ServerHelloDone 225 Certificate* 226 ClientKeyExchange 227 CertificateVerify* 228 Finished --------> 229 <-------- Finished 230 Application Data <-------> Application Data 232 Figure 3. TLS full handshake using EH level two. 234 3. Extension Definition 236 This document defines a new TLS extension, "encrypted_handshake" 237 (having extension type [TBD]), which both negotiates the level of EH 238 implementation used for this handshake as well as transmits the 239 (EC)DH parameters necessary for early key exchange. This extension 240 is sent in both the client-to-server and server-to-client directions, 241 however server acceptance of the use of EH is also indicated by the 242 presence of a ServerHello2a message in response. The "extension 243 data" field of this extension contains one of two different 244 structures, or is empty, depending on the type of the message 245 carrying it. 247 Levels of support are indicated by the following enumeration. 248 However, levels higher than are defined here are reserved for future 249 use and receivers should treat them accordingly. 251 enum { 252 zero(0), one(1), two(2), inquire(255) 253 } EncryptedHandshakeLevel; 255 When the extension is carried on the Client Hello message it contains 256 an EncryptedHandshakeInfoCH structure: 258 struct { 259 EncryptedHandshakeLevel client_requested; 260 EncryptedHandshakeLevel client_required; 261 ClientDHParamSet client_dh_params_sets<0..2^16-1>; 262 Extension conditional_extensions<0..2^16-1>; 263 } EncryptedHandshakeInfoCH; 265 client_requested 266 The highest EH level being requested by the client. 268 client_required 269 The lowest EH level acceptable by the client. 271 client_dh_params_sets 272 Contains a set of (EC)DH(E) parameters for all 273 KeyExchangeAlgorithms used by any of the cipher_suites specified 274 in the ClientHello. The element type is defined below. 276 conditional_extensions 277 ClientHello-type extensions which are sent in the clear, but to be 278 processed by the server only if the server interprets the EH 279 extension and agrees to EH level one or higher. The definition of 280 'Extension' is from [TLS]. 282 When the extension is carried on the Server Hello message it contains 283 an EncryptedHandshakeInfoSH structure: 285 struct { 286 EncryptedHandshakeLevel server_max_supported; 287 } EncryptedHandshakeInfoSH; 289 server_max_supported 290 The max EH level provided by the server, for informational 291 purposes. 293 The EH extension MAY be included on the ServerHello2a or 294 ServerHello2b message, or it may be omitted. If present, it MUST be 295 empty. 297 The ClientDHParamSet structure represents a set of (EC)DH parameters 298 and specifies with which cipher suites they may be used: 300 struct { 301 CipherSuite cipher_suites<2..2^16-2>; 302 uint16 params_size; 303 select (KeyExchangeAlgorithm) { 304 case dh_anon: // [TLS] 305 case dhe_dss: 306 case dhe_rsa: 307 DHParams params; 308 case ec_diffie_hellman: // [RFC 4492] 309 ClientECDiffieHellmanPublic params; 310 }; 311 } ClientDHParamSet; 313 cipher_suites 314 The set of cipher suite(s) to which this ClientDHParamSet applies. 316 params_size 317 Number of bytes to follow in the params field. 319 params 320 The set of Diffie-Hellman parameters to be used for the specified 321 cipher suites. 323 4. ServerHello2a handshake message 325 This message forms the (unencrypted) first part of the modified 326 Server Hello handshake message when the use of EH level one or level 327 two has been accepted. Its purpose is to transmit to the client the 328 minimum information necessary to complete the key exchange subsequent 329 to a Client Hello which proposed the use of EH. 331 struct { 332 ProtocolVersion server_version; 333 Random random; 334 CipherSuite cipher_suite; 335 EncryptedHandshakeLevel server_accepted; 336 CompressionMethod compression_method; 337 uint16 params_size; 338 select (KeyExchangeAlgorithm) { 339 case dh_anon: 340 case dhe_dss: 341 case dhe_rsa: 342 ServerDHParams params; // [TLS] 343 case ec_diffie_hellman: 344 ServerECDHParams params; // [RFC 4492] 345 }; 346 Extension extensions<0..2^16-1>; 347 } ServerHello2a; 349 server_version, random, compression_method 350 Defined identically to the corresponding field in the Server Hello 351 message of the TLS version in use. 353 cipher_suite 354 Defined identically to the corresponding field in the Server Hello 355 message of the TLS version in use. On a ServerHello2a message, 356 the selected cipher suite MUST be some type of DH cipher suite. 358 server_accepted 359 The Encrypted Handshake level accepted by the server for this 360 handshake. On a ServerHello2a message, this field must indicate 361 level one or level two. 363 extensions 364 ServerHello-type extensions included on the ServerHello2a 365 handshake message. Most extensions SHOULD sent under encryption 366 on a subsequent message, but if any are needed to establish the 367 cipher state they MUST be included here. 369 params_size 370 Number of bytes in the immediately following params field, not 371 including the params_size field itself. 373 params 374 Defined identically to the corresponding field in the Server Key 375 Exchange message. However, note that in this structure the 376 parameters are not signed. 378 5. ServerHello2b handshake message 380 This message forms the (encrypted) second part of the modified 381 ServerHello handshake message. Its purpose is to transmit to the 382 client the information present in an ordinary ServerHello that was 383 not transmitted in the ServerHello1a. 385 It is sent by the server subsequent to receiving from the client 386 either: 388 1. a ServerHello1a accepting EH level one behavior and 389 ChangeCipherSpec, or 391 2. a ServerHello1a accepting EH level two behavior ChangeCipherSpec, 392 and after the client's ClientHello2. 394 struct { 395 EncryptedHandshakeLevel server_max_supported; 396 SessionID session_id; 397 select (extensions_present) { 398 case false: 399 struct {}; 400 case true: 401 Extension extensions<0..2^16-1>; 402 }; 403 } ServerHello2b; 405 server_max_supported 406 The max EH level provided by the server, for informational 407 purposes. 409 session_id, extensions 410 Defined identically to the corresponding field in the Server Hello 411 message of the TLS version in use. Ordinarily the EH extension is 412 omitted, must be empty if present. 414 6. ClientHello2 handshake message 416 This message is used to transmit information under encryption that 417 would have otherwise been sent in the clear in the ClientHello. 418 Certain fields such as protocol_version, client_random, and 419 cipher_suite are always necessary in order to proceed with any type 420 of handshake. However, in anticipation of successful negotiation of 421 EH level two, a client MAY elect to leave the session_id field empty 422 and extensions absent in the ClientHello in order to supply them 423 later under encryption in ClientHello2. 425 struct { 426 SessionID session_id; 427 select (extensions_present) { 428 case false: 429 struct {}; 430 case true: 431 Extension extensions<0..2^16-1>; 432 }; 433 } ClientHello2; 435 session_id, extensions 436 Defined identically to the corresponding field in the Client Hello 437 message of the TLS version in use. Ordinarily the EH extension is 438 omitted, must be empty if present. 440 7. Session resumption 442 TLS provides a means to efficiently resume a previously established 443 session without having to perform any asymmetric crypto or cert 444 validation operations (often referred to as an "abbreviated 445 handshake"). Session resumption generally involves the presence of 446 the same Client/ServerHello extensions as a full handshake, so it has 447 equal need of encryption. EH levels one and two are both compatible 448 with session resumption. 450 Traditional TLS session resumption without EH looks like this: 452 Client Server 454 ClientHello --------> 455 ServerHello 456 [ChangeCipherSpec] 457 <-------- Finished 458 [ChangeCipherSpec] 459 Finished --------> 460 Application Data <-------> Application Data 462 Figure 4. Unencrypted TLS abbreviated handshake. 464 When the use of EH level one has been negotiated a handshake with 465 session resumption looks like this: 467 Client Server 469 ClientHello (with EH ext) --------> 470 ServerHello2a 471 [ChangeCipherSpec] 472 ServerHello2b 473 <-------- Finished 474 [ChangeCipherSpec] 475 Finished --------> 476 Application Data <-------> Application Data 478 Figure 5. TLS abbreviated handshake with EH level one. 480 With EH level two, the client MAY leave the session_id field empty 481 when it is transmitted in the clear on the ClientHello, and still 482 perform resumption based on the session_id field on ClientHello2. 483 However, if client withholds the session_id value and the server then 484 declines EH level two session resumption will not be possible. But 485 because session resumption depends on the client having had recent 486 prior interaction with the server anyway, this unpredictability is 487 thought unlikely to become an issue in practice. 489 Client Server 491 ClientHello (with EH ext) --------> 492 ServerHello2a 493 <-------- [ChangeCipherSpec] 494 [ChangeCipherSpec] 495 ClientHello2 --------> 496 ServerHello2b 497 <-------- Finished 498 Finished --------> 499 Application Data <-------> Application Data 501 Figure 6. TLS abbreviated handshake with EH level two. 503 XXX TODO possible optimization: the client could indicate that it 504 wants to allow resumption without involving the key exchange. This 505 would seem to leave any ServerHello extensions completely in the 506 clear. But many extensions seem to be ignored or are required to 507 hold identical values on resumption, if they could be shown to be 508 redundant perhaps they could simply be eliminated. 510 8. Client Behavior 512 The client initiates the connection and begins the handshake using 513 the following sequence, after which the connection generally follows 514 the TLS specification. 516 1. The client constructs and sends the Client Hello message and EH 517 extension: 519 * A client that simply wishes to query a server for its level of 520 support SHOULD send a Client Hello containing an EH extension 521 with a client_required value of 'inquire'. The client SHOULD 522 set client_requested to the highest level that it supports 523 (which may be zero). Other than this specfic case, a client 524 SHOULD NOT set the client_required value higher than the 525 client_requested value. 527 * A client wishing not to use EH SHOULD send an EH extension on 528 the Client Hello with the client_requested and client_required 529 fields set to zero. This is semantically equivalent to 530 sending no EH extension at all, except that the Server Hello 531 may contain an EH extension in reply. 533 * A client wishing to use level one EH support only SHOULD send 534 an EH extension on the Client Hello with the client_requested 535 field set to one. The client SHOULD set the client_required 536 field to zero or one as appropriate. 538 * A client which desires level two EH support but will accept 539 level one as a fallback SHOULD send an EH extension on the 540 Client Hello with the client_requested field set to two and 541 the client_required field set to one. Since the protocol may 542 fall back to level one, the client SHOULD continue send all 543 necessary session_id and extensions on the initial Client 544 Hello. 546 * A client which requires level two EH support SHOULD set the 547 client_requested and client_required fields to two. Such a 548 client SHOULD NOT set any session_id or extension data on the 549 ClientHello, or send extensions other than EH and those 550 necessary for the key exchange and the integrity of the 551 connection. Renegotiation Info [RFC 5746] is an example of 552 such an extension. 554 2. If a client, requesting level one or higher, anticipates that 555 sensitive data could be returned via some ServerHello extension 556 in reply, and would prefer that extension not be evaluated at all 557 rather than have that reply transmitted in the clear, the client 558 MUST put the requesting ClientHello extension inside the 559 conditional_extensions section of the EH extension instead of 560 putting it in the usual ClientHello extension section. 562 3. The server's response to the ClientHello informs the client of 563 the EH level that will be in effect for the remainder of the 564 handshake: 566 * If the server's response is a standard Server Hello message, 567 the server is providing EH level zero. If any EH extension is 568 present, it MUST be ignored. 570 * If the server's response is a ServerHello2a message, this the 571 handshake is proceeding at EH level one or higher. The client 572 MUST proceed with the handshake at the level indicated by the 573 server_accepted field. (Level zero here represents an 574 unrecoverable protocol error.) 576 4. Now, depending on the negotiated level: 578 * If the client required an EH level higher than what was 579 accepted by the server, the client SHOULD continue with the 580 connection at least to the point of validating the server's 581 Finished message (in order to authenticate this information). 582 As the client continues the handshake it MUST avoid disclosing 583 any potentially interesting info (such as a client 584 certificate). After the server's Finished message has been 585 received and validated the client MUST close the connection 586 gracefully without transmitting any application data. The 587 remainder of this section does not apply. 589 * If EH level zero was negotiated (and no higher value was 590 required by the client) the client continues the TLS 591 connection as usual and the remainder of this section does not 592 apply. 594 * If EH level one or two was negotiated, the client handles the 595 TLS-defined fields and extensions on the ServerHello2a in the 596 usual way. Additionally, the client MUST examine the server- 597 selected cipher suite and confirm that it was (a) a cipher 598 suite the client proposed and (b) a cipher suite for which the 599 client had provided a ClientDHParamSet in the ClientHello EH 600 extension. 602 5. By combining data from the Client Hello and the ServerHello2a, 603 the client now has everything necessary to generate the 604 key_block. 606 * If EH level one is in use the client SHOULD NOT send his own 607 Change Cipher Spec record at this time, even though he could. 608 This somewhat artificial rule is to simply to promote 609 consistency among implementations. However, the client MUST 610 send his CCS and switch to the new cipher state before sending 611 any other handshake records. 613 * If EH level two is in use, the client MUST send a Change 614 Cipher Spec record, switch to the new cipher state, and 615 generate and send a ClientHello2 handshake message. The 616 session_id field SHOULD be populated with the appropriate 617 value if it was withheld from the original ClientHello, 618 otherwise it MUST be empty. Likewise, any ClientHello 619 extensions not sent in the original ClientHello (either in the 620 ClientHello extension area or in the EH extension 621 conditional_extensions area) SHOULD be included. The normal 622 rule of at most one of any specific type of extension MUST be 623 followed, but it now applies to the union of all three 624 possible ClientHello-type extension areas. 626 6. The client receives a ChangeCipherSpec record from the server and 627 and the new cipher state becomes active on the server-to-client 628 channel. 630 7. The client receives a ServerHello2b handshake message. The 631 client MUST interpret the session_id and extensions the usual 632 way, as defined for a normal ServerHello. The client MAY look at 633 the server_max_supported value for informational purposes, but 634 there is no guarantee that this value will remain valid for any 635 length of time. If any EH extension is present, it MUST be 636 ignored. 638 8. The remainder of the handshake proceeds as usual, with just these 639 annotations: 641 * We've already received the Change Cipher Spec from the server, 642 so we don't expect to receive another. 644 * In level one, the client will need to send a Change Cipher 645 Spec before his next handshake message, typically a 646 Certificate or Client Key Exchange message. In level two the 647 client will have already sent it. 649 * When the (EC)DH parameters are received again (at the expected 650 point in a non-EH handshake, e.g. the Server Key Exchange 651 message), they MUST be compared with the server params used in 652 the early key exchange. If the data covered by the server's 653 signature is not byte-for-byte the same as that used to 654 establish the current effective cipher state, the client MUST 655 treat this condition as it would an invalid signature on the 656 signed data itself. Even if the handshake was anonymous- 657 anonymous, these parameters MUST be compared. 659 9. Server Behavior 661 From the server's perspective, the handshake proceeds as follows: 663 1. The server receives a Client Hello message from the client and 664 looks for an EH extension: 666 * If no EH extension is present, the negotiated EH level is zero 667 server continues the TLS connection as usual. The remainder 668 of this section does not apply. 670 * If an EH extension is present, the server uses the smaller of 671 the client_requested value and the server's own maximum 672 supported implementation level as the EH level for the 673 handshake. The server MAY consider the client_required level 674 in this process. For example, a server might claim to only 675 support level zero or one, but could actually use level two if 676 the client "required" it, i.e., threatened to waste the 677 handshake. 679 2. If the negotiated EH level is zero and an EH extension was 680 present on the Client Hello, the server SHOULD include an EH 681 extension on the Server Hello in reply. The server SHOULD set 682 the server_max_supported field honestly. The server MUST NOT 683 process any extensions in the conditional_extensions. The TLS 684 handshake continues as usual and the remainder of this section 685 does not apply. 687 3. If the received client_required value is higher than the 688 client_requested value, or it is higher than that supported by 689 the server, the server SHOULD continue the handshake at the 690 smaller of the client_requested and max_server_supported values. 691 In such a case, the server's goal should be to transmit its 692 Finished message while disclosing a minimum of information. For 693 example, the Server Hello MUST NOT transmit a nonempty session_id 694 (except to indicate session resumption) and it MUST NOT include 695 extensions other than EH and those necessary for the integrity of 696 the connection. Renegotiation Info is an example of such an 697 extension. The server MUST NOT request client authentication. 698 Immediately after transmitting the Server Finished message the 699 server MUST close the connection gracefully without transferring 700 any application data. 702 4. At this point, the EH level is known to be at least one. The 703 server selects a cipher suite from those that (a) the server 704 supports, (b) are listed in the Client Hello cipher_suites, (c) 705 permit this type of key exchange, and (c) the client has provided 706 a valid set of (EC)DH parameters in the EH extension. If no 707 cipher suites of this type can be selected, the handshake fails. 709 5. The server generates its (EC)DH parameters and transmits a 710 ServerHello2a. Most of the fields correspond directly to those 711 of ServerHello, the others carry the server's (EC)DH params. The 712 server MUST NOT include extensions other than EH and those 713 necessary for the integrity of the connection. Renegotiation 714 Info is an example of such an extension. 716 6. The server transmits its Change Cipher Spec record and switches 717 to the new cipher state in the transmit direction. 719 7. If the negotiated EH level is two, the server receives a Change 720 Cipher Spec record from the client, switches to the new cipher 721 state in the receive direction and receives and processes a 722 ClientHello2 message from the client. 724 8. Any not-yet-processed extensions from the ClientHello and 725 ClientHello2, including those in the conditional_extensions 726 field, should be processed at this time. 728 9. The server constructs and transmits a ServerHello2b message. The 729 server SHOULD set the server_max_supported field honestly. The 730 server SHOULD include any ServerHello-type extensions in reply 731 that were not already sent on the ServerHello2a. 733 10. The remainder of the handshake proceeds as usual, with just 734 these annotations: 736 * In level two, we've already received the Change Cipher Spec 737 from the client so we don't expect to receive another. 739 * When the (EC)DH parameters are received again (at the 740 expected point in a non-EH handshake, e.g. the Client Key 741 Exchange message), they MUST be compared with the client 742 params used in the early key exchange. If the data covered 743 here is not byte-for-byte the same as that used to establish 744 the current effective cipher state, the server MUST treat 745 this condition as it would an invalid signature on a 746 Certificate Verify or an invalid verify_data in the client's 747 Finished message. Even if the handshake did not involve 748 client authentication, these parameters MUST be compared. 750 10. Other Considerations 751 Implementers of TLS libraries that allow configuration of cipher 752 suites (e.g. a permitted cipher suites list ordered by preference) 753 are encouraged provide a means to configure this list separately for 754 EH-requesting clients. This is to prevent a situation where server 755 support of this extension is restricted by a simple server preference 756 for non-DHE cipher suites. 758 There are reportedly some defective servers [XXX cite?] that fail in 759 an ungraceful manner if sent a Client Hello message larger than a 760 certain size which is smaller than the defined maximum. Clients 761 wishing to minimize the risk of interoperability with such servers 762 may consider limiting the number of parameter sets they include in 763 the Client Hello, or sending only the smaller ECDH types. It is 764 possible that these noncompliant servers are older and less well- 765 maintained implementations and tend not to support newer features 766 such as ECDH. 768 11. IANA Considerations 770 XXX allocation of encrypted_handshake Hello extension 772 XXX allocation of ServerHello2a handshake message id 774 XXX allocation of ServerHello2b handshake message id 776 XXX allocation of ClientHello2 handshake message id 778 12. Security Considerations 780 Insofar as TLS is inherently a data security protocol, this entire 781 document is about security. However, a few points of concern are 782 probably worth mentioning. 784 o It cannot be repeated often enough that the early encryption 785 negotiated by the EH extension *only* provides protection from 786 passive eavesdropper. It *can not* resist a man-in-the-middle 787 type active attacker who wishes to steal a sample of the plaintext 788 the client and server intended to exchange (doing so will break 789 the handshake however). Like TLS without EH, full protection from 790 an active attacker only begins after the Finished messages are 791 received and validated by each side. 793 o It could happen that the handshake encryption so obvious in a 794 packet capture will give users a false sense of security. The 795 difference between unauthenticated encryption and an authenticated 796 (and properly bound) encrypted channel is a subtle distinction 797 even to protocol professionals. We must be vigilant to inform 798 users of this extension of these limits and to not rely on it for 799 protections beyond what it can deliver. 801 o This extension is not expected to introduce any significant new 802 computational Denial of Service (DoS) vulnerabilities. TLS 803 without this extension allows an attacker to obligate the server 804 to three or more useless asymmetric crypto operations (ephemeral 805 key exchange, server DH parameter signing, client cert signature 806 verification, and possibly client cert signature chain validation) 807 with no significant computation required on the part of the 808 attacker. This extension adds no new crypto operations to an 809 existing DHE handshake. In fact, an attacker who negotiates its 810 use finds himself now obligated to perform an asymmetric crypto 811 operation in order to proceed further. 813 However, EH level two introduces an additional round trip from 814 server to client and back. Under conditions of severe packet loss 815 (e.g., during a DDoS event) these additional handshake packets may 816 translate into a reduced success rate for clients. Facing a worst 817 case scenario, a server operator may feel desperate to reduce load 818 by disabling any excess features. Forward secrecy and client 819 privacy being relatively abstract benefits, in the face of a very 820 concrete service outage features such as Diffie-Hellman and EH 821 level two will be tempting targets. 823 o Although this extension does not modify the TLS cryptographic 824 calculations, it does change the order of certain messages. The 825 author does not (currently :-) believe that this introduces any 826 new weaknesses (and it may even mitigate some) but this is 827 certainly in need of careful expert review. XXX 829 13. References 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, March 1997. 834 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C. and B. 835 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 836 for Transport Layer Security (TLS)", RFC 4492, May 2006. 838 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 839 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 841 [RFC5746] Rescorla, E., Ray, M., Dispensa, S. and N. Oskov, 842 "Transport Layer Security (TLS) Renegotiation Indication 843 Extension", RFC 5746, February 2010. 845 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 846 Extension Definitions", RFC 6066, January 2011. 848 Author's Address 849 Marsh Ray 850 PhoneFactor, Inc. 851 7301 W 129th Street 852 Overland Park, KS 66213 853 USA 855 Email: marsh@extendedsubset.com