idnits 2.17.1 draft-campagna-tls-bike-sike-hybrid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 509 has weird spacing: '...blicKey publi...' == Line 524 has weird spacing: '...blicKey publi...' == Line 542 has weird spacing: '...MParams bike...' == Line 546 has weird spacing: '...MParams sike...' == Line 571 has weird spacing: '...MParams bike...' == (3 more instances...) -- The document date (March 27, 2019) is 1857 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 207, but not defined == Missing Reference: 'KEM' is mentioned on line 677, but not defined -- Looks like a reference, but probably isn't: '32' on line 582 -- Looks like a reference, but probably isn't: '48' on line 694 == Missing Reference: 'DRAFT' is mentioned on line 755, but not defined == Unused Reference: 'BIKE' is defined on line 783, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 790, but no explicit reference was found in the text == Unused Reference: 'RFC5288' is defined on line 800, but no explicit reference was found in the text == Unused Reference: 'RFC5289' is defined on line 805, but no explicit reference was found in the text == Unused Reference: 'RFC8422' is defined on line 815, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Campagna 3 Internet-Draft E. Crockett 4 Intended status: Experimental AWS 5 Expires: September 28, 2019 March 27, 2019 7 BIKE and SIKE Hybrid Key Exchange Cipher Suites for Transport Layer 8 Security (TLS) 9 draft-campagna-tls-bike-sike-hybrid-00 11 Abstract 13 This document describes new hybrid key exchange schemes for the 14 Transport Layer Security (TLS) protocol, which are based on combining 15 Elliptic Curve Diffie Hellman (ECDH) with one of the Bit Flipping Key 16 Exchange (BIKE) or the Supersingular Isogeny Key Exchange (SIKE) 17 schemes. In particular, this document specifies the use of BIKE or 18 SIKE in combination with ECDHE as a hybrid key agreement in a TLS 1.2 19 handshake, together with the use of ECDSA or RSA for authentication. 20 Hybrid key exchange refers to executing two separate key exchanges 21 and subsequently feeding the two resulting shared secrets into the 22 existing TLS Pseudo Random Function (PRF), in order to derive a 23 master secret. 25 Context 27 This draft is experimental. It is intended to define hybrid key 28 exchanges in sufficient detail to allow independent experimentations 29 to interoperate. While the NIST standardization process is still a 30 few years away from being complete, we know that many TLS users have 31 highly sensitive workloads that would benefit from the speculative 32 additional protections provided by quantum-safe key exchanges. These 33 key exchanges are likely to change through the standardization 34 process. Early experiments serve to understand the real-world 35 performance characteristics of these quantum-safe schemes as well as 36 provide speculative additional confidentiality assurances against a 37 future adversary with a large-scale quantum computer. 39 Comments are solicited and can be sent to all authors at 40 mcampagna@amazon.com. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on September 28, 2019. 59 Copyright Notice 61 Copyright (c) 2019 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 78 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . 4 79 2.1. Key Encapsulation Method (KEM) . . . . . . . . . . . . . 5 80 2.2. ECDHE_BIKE_[SIG] . . . . . . . . . . . . . . . . . . . . 6 81 2.3. ECDHE_SIKE_[SIG] . . . . . . . . . . . . . . . . . . . . 6 82 3. Hybrid Premaster Secret . . . . . . . . . . . . . . . . . . . 7 83 3.1. Concatenated premaster secret . . . . . . . . . . . . . . 7 84 4. TLS Extensions for BIKE and SIKE . . . . . . . . . . . . . . 7 85 5. Data Structures and Computations . . . . . . . . . . . . . . 8 86 5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 8 87 5.1.1. When these extensions are sent . . . . . . . . . . . 8 88 5.1.2. Meaning of these extensions . . . . . . . . . . . . . 8 89 5.1.3. Structure of these extensions . . . . . . . . . . . . 8 90 5.1.4. Actions of the sender . . . . . . . . . . . . . . . . 9 91 5.1.5. Actions of the receiver . . . . . . . . . . . . . . . 9 92 5.1.6. Supported BIKE Parameter Extension . . . . . . . . . 9 93 5.1.7. Supported SIKE Parameter Extension . . . . . . . . . 10 94 5.2. Server Key Exchange . . . . . . . . . . . . . . . . . . . 11 95 5.2.1. When this message is sent . . . . . . . . . . . . . . 11 96 5.2.2. Meaning of this message . . . . . . . . . . . . . . . 11 97 5.2.3. Structure of this message . . . . . . . . . . . . . . 11 98 5.2.4. Actions of the sender . . . . . . . . . . . . . . . . 13 99 5.2.5. Actions of the receiver . . . . . . . . . . . . . . . 13 100 5.3. Client Key Exchange . . . . . . . . . . . . . . . . . . . 13 101 5.3.1. When this message is sent . . . . . . . . . . . . . . 13 102 5.3.2. Meaning of the message . . . . . . . . . . . . . . . 13 103 5.3.3. Structure of this message . . . . . . . . . . . . . . 14 104 5.3.4. Actions of the sender . . . . . . . . . . . . . . . . 14 105 5.3.5. Actions of the receiver . . . . . . . . . . . . . . . 15 106 5.4. Derivation of the master secret for hybrid key agreement 15 107 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 15 108 7. Security Considerations [DRAFT] . . . . . . . . . . . . . . . 17 109 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 110 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 111 10. Normative References . . . . . . . . . . . . . . . . . . . . 17 112 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 18 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 115 1. Introduction 117 Quantum-safe (or post-quantum) key exchanges are being developed in 118 order to provide secure key establishment against an adversary with 119 access to a quantum computer. Under such a threat model, the current 120 key exchange mechanisms would be vulnerable. BIKE and SIKE are two 121 such schemes which were submitted to the NIST Call for Proposals for 122 Post Quantum Cryptographic Schemes. While these schemes are still 123 being analyzed as part of that process, there is already a need to 124 protect the confidentiality of today's TLS connections against a 125 future adversary with a quantum computer. Hybrid key exchanges are 126 designed to provide two parallel key exchanges: one which is 127 classical (e.g., ECDHE) and the other which is quantum-safe (e.g., 128 BIKE or SIKE). This strategy is emerging as a method to 129 speculatively provide additional security to existing protocols. 131 This document describes additions to TLS to support BIKE and SIKE 132 Hybrid Key Exchanges, applicable to TLS Version 1.2 [RFC5246]. In 133 particular, it defines the use of the ECDH together with BIKE or 134 SIKE, as a hybrid key agreement method. 136 The remainder of this document is organized as follows. Section 2 137 provides an overview of BIKE- and SIKE-based key exchange algorithms 138 for TLS. Section 3 describes how BIKE and SIKE can be combined with 139 ECDHE to form a premaster secret. TLS extensions that allow a client 140 to negotiate the use of specific BIKE and SIKE parameters are 141 presented in Section 4. Section 5 specifies various data structures 142 needed for a BIKE- or SIKE-based hybrid key exchange handshake, their 143 encoding in TLS messages, and the processing of those messages. 144 Section 6 defines new BIKE and SIKE hybrid-based cipher suites and 145 identifies a small subset of these as recommended for all 146 implementations of this specification. Section 7 discusses some 147 security considerations. Section 8 describes IANA considerations for 148 the name spaces created by this document. Section 9 gives 149 acknowledgments. 151 Implementation of this specification requires familiarity with TLS 152 [RFC5246], TLS extensions [RFC6066], BIKE, and SIKE. 154 1.1. Requirements Language 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119. 160 2. Key Exchange Algorithms 162 This document introduces two new hybrid-based key exchange methods 163 for TLS. They use ECDHE with either BIKE or SIKE, in order to 164 compute the TLS premaster secret. The master secret derivation is 165 augmented to include the ClientKeyExchange message. The derivation 166 of the encryption/MAC keys and initialization vectors is independent 167 of the key exchange algorithm and not impacted by the introduction of 168 these hybrid key exchanges. 170 The table below summarizes the new hybrid key exchange schemes. 172 +-------------------------------+-----------------------------------+ 173 | Hybrid Key Exchange Scheme | Description | 174 | Name | | 175 +-------------------------------+-----------------------------------+ 176 | ECDHE_BIKE_RSA | ECDHE and BIKE with RSA | 177 | | signatures. | 178 | | | 179 | ECDHE_BIKE_ECDSA | ECDHE and BIKE with ECDSA | 180 | | signatures. | 181 | | | 182 | ECDHE_SIKE_RSA | ECDHE and SIKE with RSA | 183 | | signatures. | 184 | | | 185 | ECDHE_SIKE_ECDSA | ECDHE and SIKE with ECDSA | 186 | | signatures. | 187 +-------------------------------+-----------------------------------+ 189 Table 1: BIKE and SIKE Hybrid Key Exchange Schemes 191 These schemes are intended to provide quantum-safe forward secrecy. 193 Client Server 194 ------ ------ 196 ClientHello --------> 197 ServerHello 198 Certificate 199 ServerKeyExchange 200 CertificateRequest*+ 201 <-------- ServerHelloDone 202 Certificate*+ 203 ClientKeyExchange 204 CertificateVerify*+ 205 [ChangeCipherSpec] 206 Finished --------> 207 [ChangeCipherSpec] 208 <-------- Finished 210 Application Data <-------> Application Data 212 * message is not sent under some conditions 213 + message is not sent unless client authentication 214 is desired 216 Figure 1: Message flow in a hybrid TLS handshake 218 Figure 1 shows the messages involved in the TLS key establishment 219 protocol (aka full handshake). The addition of hybrid key exchanges 220 has direct impact on the ClientHello, the ServerHello, the 221 ServerKeyExchange, and the ClientKeyExchange messages. Next, we 222 describe each hybrid key exchange scheme in greater detail in terms 223 of the content and processing of these messages. For ease of 224 exposition, we defer discussion of the optional BIKE- and SIKE- 225 specific extensions (which impact the Hello messages) until 226 Section 4. 228 2.1. Key Encapsulation Method (KEM) 230 A key encapsulation mechanism (KEM) is a set of three algorithms 232 o key generation (KeyGen) 234 o encapsulation (Encaps) 236 o decapsulation (Decaps) 238 and a defined key space, where 240 o "KeyGen()": returns a public and a secret key (pk, sk). 242 o "Encaps(pk)": takes pk as input and outputs ciphertext c and a key 243 K from the key space. 245 o "Decaps(sk, c)": takes sk and c as input, and returns a key K or 246 ERROR. K is called the session key. 248 The security of a KEM is discussed in Section 7. BIKE and SIKE are 249 two examples of a KEM. 251 2.2. ECDHE_BIKE_[SIG] 253 This section describes the two nearly identical hybrid key exchanges 254 ECDHE_BIKE_RSA and ECDHE_BIKE_ECDSA. For the remainder of this 255 section SIG refers to either RSA or ECDSA. The server sends its 256 ephemeral ECDH public key and ephemeral BIKE public key generated 257 using the BIKE Key Encapsulation Method (KEM) and a specification of 258 the corresponding curve and BIKE parameters in the ServerKeyExchange 259 message. These parameters MUST be signed with the signature 260 algorithm SIG using the private key corresponding to the public key 261 in the server's certificate. 263 The client generates an ECDHE key pair on the same curve as the 264 server's ephemeral ECDH key, and computes a ciphertext value based on 265 the BIKE public key provided by the server, and sends them in the 266 ClientKeyExchange message. The client computes and holds the BIKE- 267 encapsulated key (K) as a contribution to the premaster secret. 269 Both client and server perform an ECDH operation and use the 270 resultant shared secret (Z) as part of the premaster secret. The 271 server computes the BIKE decapsulation routine to compute the 272 encapsulated key (K), or to produce an error message in case the 273 decapsulation fails. 275 2.3. ECDHE_SIKE_[SIG] 277 This section describes the two nearly identical hybrid key exchanges 278 ECDHE_SIKE_RSA and ECDHE_SIKE_ECDSA. For the remainder of this 279 section SIG refers to either RSA or ECDSA. ECDHE_SIKE_[SIG] is 280 nearly identical to ECDHE_BIKE_[SIG]. The server sends its ephemeral 281 ECDH public key and ephemeral SIKE public key generated using the 282 SIKE Key Encapsulation Method (KEM) and a specification of the 283 corresponding ECDH curve and SIKE parameters in the ServerKeyExchange 284 message. These parameters MUST be signed with the signature 285 algorithm SIG using the private key corresponding to the public key 286 in the server's certificate. 288 3. Hybrid Premaster Secret 290 This section defines new hybrid key exchanges for TLS 1.2 [RFC5246]. 291 Here, both the server and the client compute two shared secrets: the 292 previously defined ECDHE shared secret Z from RFC 6066, and another 293 shared secret K from the underlying BIKE or SIKE key encapsulation 294 method. 296 To simplify the text when we speak about BIKE or SIKE interchangeably 297 we will simply denote this as [KEM]. 299 3.1. Concatenated premaster secret 301 Form the premaster secret for ECDHE_[KEM]_[SIG] hybrid key exchanges 302 as the concatenation of the ECDHE shared secret Z with the KEM key K 303 to form the opaque data value "premaster_secret = Z || K". 305 4. TLS Extensions for BIKE and SIKE 307 Two new TLS extensions are defined in this specification: 309 1. the Supported BIKE Parameters Extension, and 311 2. the Supported SIKE Parameters Extension. 313 These allow negotiating the use of specific [KEM] parameter sets 314 during a handshake starting a new session. These extensions are 315 especially relevant for constrained clients that may only support a 316 limited number of [KEM] parameter sets. They follow the general 317 approach outlined in RFC 6066; message details are specified in 318 Section 5. The client enumerates the BIKE and SIKE parameters it 319 supports by including the appropriate extensions in its ClientHello 320 message. 322 A TLS client that proposes [KEM] cipher suites in its ClientHello 323 message SHOULD include these extensions. Servers implementing a 324 [KEM] cipher suite MUST support these extensions, and when a client 325 uses these extensions, servers MUST NOT negotiate the use of a [KEM] 326 parameter set unless they can complete the handshake while respecting 327 the choice of parameters specified by the client. This eliminates 328 the possibility that a negotiated hybrid handshake will be 329 subsequently aborted due to a client's inability to deal with the 330 server's [KEM] key. 332 The client MUST NOT include these extensions in the ClientHello 333 message if it does not propose any [KEM] cipher suites. That is, if 334 a client does not support BIKE, it must not include the BIKE 335 parameters extension, and if the client does not support SIKE, it 336 must not include the SIKE parameter extension. A client that 337 proposes a [KEM] scheme may choose not to include these extensions. 338 In this case, the server is free to choose any one of the parameter 339 sets listed in Section 5. That section also describes the structure 340 and processing of these extensions in greater detail. 342 In the case of session resumption, the server simply ignores the 343 Supported [KEM] Parameter Extension appearing in the current 344 ClientHello message. These extensions only play a role during 345 handshakes negotiating a new session. 347 5. Data Structures and Computations 349 This section specifies the data structures and computations used by 350 [KEM] hybrid-key agreement mechanisms specified in Sections 2, 3, and 351 4. The presentation language used here is the same as that used in 352 TLS 1.2 [RFC5246]. 354 5.1. Client Hello Extensions 356 This section specifies two TLS extensions that can be included with 357 the ClientHello message as described in RFC 6066, and the Supported 358 [KEM] Parameters Extension. 360 5.1.1. When these extensions are sent 362 The extensions SHOULD be sent along with any ClientHello message that 363 proposes the associated [KEM] cipher suites. 365 5.1.2. Meaning of these extensions 367 These extensions allow a client to enumerate the BIKE or SIKE 368 parameters sets it supports. 370 5.1.3. Structure of these extensions 372 The general structure of TLS extensions is described in RFC 6066, and 373 this specification adds two new types to ExtensionType. 375 enum { 376 bike_parameters(0xFE01), 377 sike_parameters(0xFE02) 378 } ExtensionType; 380 where 382 o "bike_parameters" (Supported BIKE Parameters Extension): Indicates 383 the set of BIKE parameters supported by the client. For this 384 extension, the opaque extension_data field contains 385 BIKEParameterList. See Section 5.1.6 for details. 387 o "sike_parameters" (Supported SIKE Parameters Extension): Indicates 388 the set of SIKE parameters supported by the client. For this 389 extension, the opaque extension_data field contains 390 SIKEParameterList. See Section 5.1.7 for details. 392 5.1.4. Actions of the sender 394 A client that proposes a [KEM] hybrid key exchange cipher suites in 395 its ClientHello message appends these extensions (along with any 396 others), enumerating the parameters it supports. Clients SHOULD send 397 the Supported BIKE Parameters Extension if it supports a BIKE hybrid 398 key exchange cipher suite, and it SHOULD send the Supported SIKE 399 Parameters Extension if it supports a SIKE hybrid key exchange cipher 400 suite. 402 5.1.5. Actions of the receiver 404 A server that receives a ClientHello containing one or both of these 405 extensions MUST use the client's enumerated capabilities to guide its 406 selection of an appropriate cipher suite. One of the proposed [KEM] 407 cipher suites must be negotiated only if the server can successfully 408 complete the handshake while using the [KEM] parameters supported by 409 the client (cf. Section 5.1.6 and Section 5.1.7.) 411 If a server does not understand the Supported [KEM] Parameters 412 Extension, or is unable to complete the [KEM] handshake while 413 restricting itself to the enumerated parameters, it MUST NOT 414 negotiate the use of the corresponding [KEM] cipher suite. Depending 415 on what other cipher suites are proposed by the client and supported 416 by the server, this may result in a fatal handshake failure alert due 417 to the lack of common cipher suites. 419 5.1.6. Supported BIKE Parameter Extension 421 enum { 422 BIKE1r1-Level1 (1), 423 BIKE1r1-Level3 (2), 424 BIKE1r1-Level5 (3), 425 BIKE2r1-Level1 (4), 426 BIKE2r1-Level3 (5), 427 BIKE2r1-Level5 (6), 428 BIKE3r1-Level1 (7), 429 BIKE3r1-Level3 (8), 430 BIKE3r1-Level5 (9) 431 } NamedBIKEKEM (2^8-1); 433 "BIKE1r1-Level1", etc: Indicates support of the corresponding BIKE 434 parameters defined in BIKE, the round 1 candidate to the NIST Post 435 Quantum Cryptography Standardization Process. 437 struct { 438 NamedBIKEKEM bike_parameter_list <1..2^8-1> 439 } BIKEParameterList; 441 Items in "bike_parameter_list" are ordered according to the client's 442 preferences (favorite choice first). 444 As an example, a client that only supports BIKE1r1-Level1 ( value 1 = 445 0x01) and BIKE2-Level1 ( value 4 = 0x04) and prefers to use 446 BIKE1r1-Level1 would include a TLS extension consisting of the 447 following octets: 449 FE 01 00 03 02 01 04 451 Note that the first two octets indicate the extension type (Supported 452 BIKE Parameter Extension), the next two octets indicates the length 453 of the extension (00 03), and the next octet indicates the length of 454 enumerated values (02). 456 5.1.7. Supported SIKE Parameter Extension 458 enum { 459 SIKEp503r1-KEM (1), 460 SIKEp751r1-KEM (2), 461 SIKEp964r1-KEM (3) 462 } NamedSIKEKEM (2^8-1); 464 SIKEp503r1-KEM, etc.: Indicates support of the corresponding SIKE 465 parameters defined in SIKE, the round 1 candidate to the NIST Post 466 Quantum Cryptography Standardization Process. 468 struct { 469 NamedSIKEKEM sike_parameter_list <1,..., 2^8 - 1> 470 } SIKEParameterList; 472 Items in sike_parameter_list are ordered according to the client's 473 preferences (favorite choice first). 475 As an example, a client that only supports SIKEp503r1-KEM ( value 1 = 476 0x01) and SIKEp751r1-KEM ( value 2 = 0x02) and prefers to use 477 SIKEp503r1-KEM would include a TLS extension consisting of the 478 following octets: 480 FE 02 00 03 02 01 02 481 Note that the first two octets indicate the extension type (Supported 482 SIKE Parameter Extension), the next two octets indicates the length 483 of the extension (00 03), and the next octet indicates the length of 484 enumerated values (02). 486 5.2. Server Key Exchange 488 5.2.1. When this message is sent 490 This message is sent when using the ECDHE_[KEM]_ECDSA and 491 ECDHE_[KEM]_RSA hybrid key exchange algorithms. 493 5.2.2. Meaning of this message 495 This message is used to convey the server's ephemeral ECDH and BIKE 496 or SIKE public key to the client. 498 5.2.3. Structure of this message 500 struct { 501 opaque public_key <1,...,2^16 - 1>; 502 } BIKEKEMPublicKey; 504 public_key: This is a byte string representation of the BIKE public 505 key following the conversion defined by the BIKE implementation. 507 struct { 508 NamedBIKEKEM bike_params; 509 BIKEKEMPublicKey public; 510 } ServerBIKEKEMParams; 512 struct { 513 opaque public_key <1,...,2^16 - 1>; 514 } SIKEKEMPublicKey; 516 where 518 o "public_key": This is a byte string representation of the SIKE 519 public key following the conversion routines of Section 1.2.9 of 520 the SIKE specification [SIKE]. 522 struct { 523 NamedSIKEKEM sike_params; 524 SIKEKEMPublicKey public; 525 } ServerSIKEKEMParams; 527 The ServerKeyExchange message is extended as follows: 529 enum { 530 ecdh_bike, 531 ecdh_sike 532 } KeyExchangeAlgorithm; 534 "ecdh_bike": Indicates the ServerKeyExchange message contains an ECDH 535 public key and the server's BIKE parameters. "ecdh_sike": Indicates 536 the ServerKeyExchange message contains an ECDH public key and the 537 server's SIKE parameters. 539 select (KeyExchangeAlgorithm) { 540 case ecdh_bike: 541 ServerECDHParams ecdh_params; 542 ServerBIKEKEMParams bike_params; 543 Signature signed_params; 544 case ecdh_sike: 545 ServerECDHParams ecdh_params; 546 ServerSIKEKEMParams sike_params; 547 Signature signed_params; 548 } ServerKeyExchange; 550 where 552 o "ecdh_params": Specifies the ECDH public key and associated domain 553 parameters. 555 o "bike_params": Specifies the BIKE public key and associated 556 parameters. 558 o "sike_params": Specifies the SIKE public key and associated 559 parameters. 561 o "signed_params": a signature over the server's key exchange 562 parameters. The private key corresponding to the certified public 563 key in the server's Certificate message is used for signing. 565 digitally-signed struct { 566 opaque client_random[32]; 567 opaque server_random[32]; 568 ServerDHParams ecdh_params; 569 select (KeyExchangeAlgorithm) { 570 case ecdh_bike: 571 ServerBIKEKEMParams bike_params; 572 case ecdh_sike: 573 ServerSIKEKEMParams sike_params; 574 } signed_params; 576 The parameters are hashed as part of the signing algorithm as 577 follows, where H is the hash function used for generating the 578 signature: 580 For ECDHE_[KEM]_[SIG]: 582 "H( client_random[32] + server_random[32] + ecdh_params + 583 [KEM]_params)." 585 NOTE: SignatureAlgorithm is "rsa" for the ECDHE_[KEM]_RSA and hybrid 586 key exchange schemes. These cases are defined for TLS 1.2 [RFC5246]. 587 SignatureAlgorithm is "ecdsa" for ECDHE_[KEM]_ECDSA. ECDSA 588 signatures are generated and verified as described in RFC 8422. 590 5.2.4. Actions of the sender 592 The server selects elliptic curve domain parameters and an ephemeral 593 ECDH public key corresponding to these parameters according to 594 RFC 8422. The server selects BIKE or SIKE parameters and an 595 ephemeral public key corresponding to the parameters according to 596 BIKE or SIKE respectively. It conveys this information to the client 597 in the ServerKeyExchange message using the format defined above. 599 5.2.5. Actions of the receiver 601 The client verifies the signature and retrieves the server's elliptic 602 curve domain parameters and ephemeral ECDH public key and the [KEM] 603 parameters and public key from the ServerKeyExchange message. 605 A possible reason for a fatal handshake failure is that the client's 606 capabilities for handling elliptic curves and point formats are 607 exceeded (see RFC 8422), the [KEM] parameters are not supported (see 608 Section 5.1), or the signature does not verify. 610 5.3. Client Key Exchange 612 5.3.1. When this message is sent 614 This message is sent in all key exchange algorithms. In the key 615 exchanges defined in this document, it contains the client's 616 ephemeral ECDH public key and the [KEM] ciphertext value. 618 5.3.2. Meaning of the message 620 This message is used to convey ephemeral data relating to the key 621 exchange belonging to the client (such as its ephemeral ECDH public 622 key and the [KEM] ciphertext value). 624 5.3.3. Structure of this message 626 The TLS ClientKeyExchange message is extended as follows. 628 struct { 629 opaque ciphertext <1,..., 2^16 - 1>; 630 } BIKEKEMCiphertext; 632 where 634 o "ciphertext": This is a byte string representation of the BIKE 635 ciphertext of the KEM construction. Since the underlying calling 636 convention of the KEM API handles the ciphertext byte string 637 directly it is sufficient to pass this as single byte string array 638 in the protocol. 640 struct { 641 opaque ciphertext <1,..., 2^16 - 1>; 642 } SIKEKEMCiphertext; 644 where 646 o "ciphertext": This is a byte string representation of the SIKE 647 ciphertext of the KEM construction. It is the concatenation of a 648 public_key with a fixed-length masked secret value. Since the 649 underlying calling convention of the KEM API handles the 650 ciphertext byte string directly it is sufficient to pass this as 651 single byte string array in the protocol. 653 struct { 654 select (KeyExchangeAlgorithm) { 655 case ecdh_bike: 656 ClientECDiffieHellmanPublic ecdh_public; 657 BIKEKEMCiphertext ciphertext; 658 case ecdh_sike: 659 ClientECDiffieHellmanPublic ecdh_public; 660 SIKEKEMCiphertext ciphertext; 661 } exchange_keys; 662 } ClientKeyExchange; 664 5.3.4. Actions of the sender 666 The client selects an ephemeral ECDH public key corresponding to the 667 parameters it received from the server according to RFC 8422 and 668 [KEM] ciphertexts according to BIKE or SIKE respectively. It conveys 669 this information to the client in the ClientKeyExchange message using 670 the format defined above. 672 5.3.5. Actions of the receiver 674 The server retrieves the client's ephemeral ECDH public key and the 675 [KEM] ciphertext from the ClientKeyExchange message and checks that 676 it is on the same elliptic curve as the server's ECDH key, and that 677 the [KEM] ciphertexts conform to the domain parameters selected by 678 the server. 680 In the case of BIKE there is a decapsulation failure rate no greater 681 than 10^(-7). In the case of a decapsulation failure, an 682 implementation MUST abort the handshake. 684 5.4. Derivation of the master secret for hybrid key agreement 686 This section defines a new hybrid master secret derivation. It is 687 defined under the assumption that we use the concatenated premaster 688 secret defined in Section 3.1 (Section 3.1). Recall in this case the 689 premaster_secret = Z || K, where Z it the ECDHE shared secret, and K 690 is the KEM shared secret. 692 We define the master secret as follows: 694 master_secret[48] = TLS-PRF(secret, label, seed) 696 where 698 o "secret": the premaster_secret, 700 o "label": the string "hybrid master secret", and 702 o "seed": the concatenation of ClientHello.random || 703 ServerHello.random || ClientKeyExchange 705 6. Cipher Suites 707 The table below defines new hybrid key exchange cipher suites that 708 use the key exchange algorithms specified in Section 2 (Section 2). 710 +-------------------------------------------------------------------+ 711 | Ciphersuite | 712 +-------------------------------------------------------------------+ 713 | CipherSuite TLS_ECDHE_BIKE_ECDSA_WITH_AES_128_GCM_SHA256 = { | 714 | 0xFF, 0x01 } | 715 | | 716 | CipherSuite TLS_ECDHE_BIKE_ECDSA_WITH_AES_256_GCM_SHA384 = { | 717 | 0xFF, 0x02 } | 718 | | 719 | CipherSuite TLS_ECDHE_BIKE_RSA_WITH_AES_128_GCM_SHA256 = { | 720 | 0xFF, 0x03 } | 721 | | 722 | CipherSuite TLS_ECDHE_BIKE_RSA_WITH_AES_256_GCM_SHA384 = { | 723 | 0xFF, 0x04 } | 724 | | 725 | CipherSuite TLS_ECDHE_SIKE_ECDSA_WITH_AES_128_GCM_SHA256 = { | 726 | 0xFF, 0x05 } | 727 | | 728 | CipherSuite TLS_ECDHE_SIKE_ECDSA_WITH_AES_256_GCM_SHA384 = { | 729 | 0xFF, 0x06 } | 730 | | 731 | CipherSuite TLS_ECDHE_SIKE_RSA_WITH_AES_128_GCM_SHA256 = { | 732 | 0xFF, 0x07 } | 733 | | 734 | CipherSuite TLS_ECDHE_SIKE_RSA_WITH_AES_256_GCM_SHA384 = { | 735 | 0xFF, 0x08 } | 736 +-------------------------------------------------------------------+ 738 Table 2: TLS hybrid key exchange cipher suites 740 The key exchange method, cipher, and hash algorithm for each of these 741 cipher suites are easily determined by examining the name. Ciphers 742 and hash algorithms are defined in RFC 5288. 744 It is recommended that any implementation of this specification 745 include at least one of 747 o CipherSuite TLS_ECDHE_BIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 748 0x04 } 750 o CipherSuite TLS_ECDHE_SIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 751 0x08 } 753 using the parameters BIKE1r1-Level1 or SIKEp503r1-KEM. 755 7. Security Considerations [DRAFT] 757 The security considerations in TLS 1.2 [RFC5246] and RFC 8422 apply 758 to this document as well. In addition, as described in RFC 5288 and 759 RFC 5289, these cipher suites may only be used with TLS 1.2 or 760 greater. 762 The description of a KEM is provided in Section 2.1. The security of 763 the KEM is defined through the indistinguishability K against a 764 chosen-plaintext (IND-CPA) and against a chosen-ciphertext (IND-CCA) 765 adversary. We are focused here on the IND-CPA security of the KEM. 767 In the IND-CPA experiment of KEMs, an oracle generates keys (sk, pk) 768 with "KeyGen()", computes (c, K) with "Encaps(pk)", and draws 769 uniformly at random a value R from the key space, and a random bit b. 770 The adversary is an algorithm A that is given (pk, c, K) if b=1, and 771 (pk, c, R) if b=0. Algorithm A outputs a bit b' as a guess for b, 772 and wins if b' = b. 774 8. IANA Considerations 776 This document describes three new name spaces for use with the TLS 777 protocol: 779 9. Acknowledgements 781 10. Normative References 783 [BIKE] Misoczki, R., Aragon, N., Barreto, P., Bettaieb, S., 784 Bidoux, L., Blazy, O., Deneuville, J., Gaborit, P., 785 Gueron, S., Guneysu, T., Melchor, C., Persichetti, E., 786 Sendrier, N., Tillich, J., and G. Zemor, "BIKE: Bit 787 Flipping Key Encapsulation", March 2018, 788 . 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, 792 DOI 10.17487/RFC2119, March 1997, 793 . 795 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 796 (TLS) Protocol Version 1.2", RFC 5246, 797 DOI 10.17487/RFC5246, August 2008, 798 . 800 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 801 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 802 DOI 10.17487/RFC5288, August 2008, 803 . 805 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 806 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 807 DOI 10.17487/RFC5289, August 2008, 808 . 810 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 811 Extensions: Extension Definitions", RFC 6066, 812 DOI 10.17487/RFC6066, January 2011, 813 . 815 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 816 Curve Cryptography (ECC) Cipher Suites for Transport Layer 817 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 818 DOI 10.17487/RFC8422, August 2018, 819 . 821 [SIKE] Jao, D., Azarderakhsh, R., Campagna, M., Costello, C., De 822 Feo, L., Hess, B., Jalali, A., Koziel, B., LaMacchia, B., 823 Longa, P., Naehrig, M., Renes, J., Soukharev, V., and D. 824 Urbanik, "Supersingular Isogeny Key Encapsulation", 825 November 2017, . 827 Appendix A. Additional Stuff 829 This becomes an Appendix. 831 Authors' Addresses 833 Matt Campagna 834 AWS 836 Email: campagna@amazon.com 838 Eric Crockett 839 AWS 841 Email: ericcro@amazon.com