idnits 2.17.1 draft-campagna-tls-bike-sike-hybrid-05.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 480 has weird spacing: '...blicKey publi...' == Line 509 has weird spacing: '...MParams pq_k...' == Line 597 has weird spacing: '...nPublic ecd...' -- The document date (September 10, 2020) is 1321 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 202, but not defined == Missing Reference: 'KEM' is mentioned on line 618, but not defined -- Looks like a reference, but probably isn't: '32' on line 518 -- Looks like a reference, but probably isn't: '48' on line 637 == Missing Reference: 'DRAFT' is mentioned on line 697, but not defined == Unused Reference: 'BIKEr1' is defined on line 742, but no explicit reference was found in the text == Unused Reference: 'BIKEr2' is defined on line 749, but no explicit reference was found in the text == Unused Reference: 'KYBERr2' is defined on line 761, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 768, but no explicit reference was found in the text == Unused Reference: 'RFC5288' is defined on line 778, but no explicit reference was found in the text == Unused Reference: 'RFC5289' is defined on line 783, but no explicit reference was found in the text == Unused Reference: 'RFC8422' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'SIKEr1' is defined on line 794, but no explicit reference was found in the text == Unused Reference: 'SIKEr2' is defined on line 802, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 16 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: March 14, 2021 September 10, 2020 7 Hybrid Post-Quantum Key Encapsulation Methods (PQ KEM) for Transport 8 Layer Security 1.2 (TLS) 9 draft-campagna-tls-bike-sike-hybrid-05 11 Abstract 13 Hybrid key exchange refers to executing two independent key exchanges 14 and feeding the two resulting shared secrets into a Pseudo Random 15 Function (PRF), with the goal of deriving a secret which is as secure 16 as the stronger of the two key exchanges. This document describes 17 new hybrid key exchange schemes for the Transport Layer Security 1.2 18 (TLS) protocol. The key exchange schemes are based on combining 19 Elliptic Curve Diffie-Hellman (ECDH) with a post-quantum key 20 encapsulation method (PQ KEM) using the existing TLS PRF. 22 Context 24 This draft is experimental. It is intended to define hybrid key 25 exchanges in sufficient detail to allow independent experimentations 26 to interoperate. While the NIST standardization process is still a 27 few years away from being complete, we know that many TLS users have 28 highly sensitive workloads that would benefit from the speculative 29 additional protections provided by quantum-safe key exchanges. These 30 key exchanges are likely to change through the standardization 31 process. Early experiments serve to understand the real-world 32 performance characteristics of these quantum-safe schemes as well as 33 provide speculative additional confidentiality assurances against a 34 future adversary with a large-scale quantum computer. 36 Comments are solicited and can be sent to the authors. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on March 14, 2021. 55 Copyright Notice 57 Copyright (c) 2020 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 74 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . 4 75 2.1. Key Encapsulation Method (KEM) . . . . . . . . . . . . . 5 76 2.2. ECDHE_[KEM] . . . . . . . . . . . . . . . . . . . . . . . 6 77 3. Hybrid Premaster Secret . . . . . . . . . . . . . . . . . . . 6 78 4. TLS Extension for Supported PQ KEM Parameters . . . . . . . . 7 79 5. Data Structures and Computations . . . . . . . . . . . . . . 7 80 5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 8 81 5.1.1. When these extensions are sent . . . . . . . . . . . 8 82 5.1.2. Meaning of these extensions . . . . . . . . . . . . . 8 83 5.1.3. Structure of these extensions . . . . . . . . . . . . 8 84 5.1.4. Actions of the sender . . . . . . . . . . . . . . . . 8 85 5.1.5. Actions of the receiver . . . . . . . . . . . . . . . 8 86 5.1.6. Supported PQ KEM Parameters Extension . . . . . . . . 9 87 5.2. Server Key Exchange . . . . . . . . . . . . . . . . . . . 10 88 5.2.1. When this message is sent . . . . . . . . . . . . . . 10 89 5.2.2. Meaning of this message . . . . . . . . . . . . . . . 10 90 5.2.3. Structure of this message . . . . . . . . . . . . . . 11 91 5.2.4. Actions of the sender . . . . . . . . . . . . . . . . 12 92 5.2.5. Actions of the receiver . . . . . . . . . . . . . . . 12 93 5.3. Client Key Exchange . . . . . . . . . . . . . . . . . . . 13 94 5.3.1. When this message is sent . . . . . . . . . . . . . . 13 95 5.3.2. Meaning of the message . . . . . . . . . . . . . . . 13 96 5.3.3. Structure of this message . . . . . . . . . . . . . . 13 97 5.3.4. Actions of the sender . . . . . . . . . . . . . . . . 13 98 5.3.5. Actions of the receiver . . . . . . . . . . . . . . . 14 99 5.4. Derivation of the master secret for hybrid key agreement 14 100 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 14 101 7. Security Considerations [DRAFT] . . . . . . . . . . . . . . . 16 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 103 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 104 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 105 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 18 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 108 1. Introduction 110 Quantum-safe (or post-quantum) key exchanges are being developed in 111 order to provide secure key establishment against an adversary with 112 access to a quantum computer. Under such a threat model, the current 113 key exchange mechanisms would be vulnerable. BIKE, Kyber and SIKE 114 are post-quantum candidates which were submitted to the NIST Call for 115 Proposals for Post-Quantum Cryptographic Schemes. While these 116 schemes are still being analyzed as part of that process, there is 117 already a need to protect the confidentiality of today's TLS 118 connections against a future adversary with a quantum computer. 119 Hybrid key exchanges are designed to provide two parallel key 120 exchanges: one which is classical (e.g., ECDHE) and the other which 121 is quantum-safe (e.g., SIKE). The hybrid schemes we propose are at 122 least as secure as ECDH against a classical adversary, and at least 123 as secure as the PQ KEM against a quantum adversary. This strategy 124 is emerging as a method to speculatively provide additional security 125 to existing protocols. 127 This document describes additions to TLS to support PQ Hybrid Key 128 Exchanges, applicable to TLS Version 1.2 [RFC5246]. These additions 129 are designed to support most of the second-round candidates in the 130 NIST Call for Proposals, but this document only defines ciphersuites 131 for a small subset of possible hybrid key agreement methods. In 132 particular, it defines the use of the ECDHE together with BIKE, Kyber 133 or SIKE, as a hybrid key agreement method. 135 The remainder of this document is organized as follows. Section 2 136 provides an overview of PQ KEM-based key exchange algorithms for TLS. 137 Section 3 describes how a PQ KEM can be combined with ECDHE to form a 138 premaster secret. In Section 4, we present a TLS extension that 139 allow a client to negotiate the use of specific PQ schemes and 140 parameters. Section 5 specifies various data structures needed for a 141 BIKE-, Kyber- or SIKE-based hybrid key exchange handshake, their 142 encoding in TLS messages, and the processing of those messages. 143 Section 6 defines two new PQ KEM hybrid-based cipher suites and 144 identifies a small subset of these as recommended for all 145 implementations of this specification. Section 7 discusses some 146 security considerations. Section 8 describes IANA considerations for 147 the name spaces created by this document. Section 9 gives 148 acknowledgments. 150 Implementation of this specification requires familiarity with TLS 151 [RFC5246], BIKE, Kyber, and SIKE. 153 1.1. Requirements Language 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119. 159 2. Key Exchange Algorithms 161 This document introduces two new hybrid-based key exchange methods 162 for TLS. They use ECDHE with either BIKE, Kyber or SIKE in order to 163 compute the TLS premaster secret. The master secret derivation is 164 augmented to include the ClientKeyExchange message. The derivation 165 of the encryption/MAC keys and initialization vectors is independent 166 of the key exchange algorithm and not impacted by the introduction of 167 these hybrid key exchanges. While this specification only defines 168 the use of a PQ KEM hybrid key exchange with BIKE, Kyber or SIKE, it 169 is specifically designed so that it can be easily extended to include 170 additional PQ KEM methods. 172 The table below summarizes the new hybrid key exchange schemes. 174 +---------------------------------+------------------+ 175 | Hybrid Key Exchange Scheme Name | Description | 176 +---------------------------------+------------------+ 177 | ECDHE_BIKE | ECDHE and BIKE. | 178 | | | 179 | ECDHE_KYBER | ECDHE and Kyber. | 180 | | | 181 | ECDHE_SIKE | ECDHE and SIKE. | 182 +---------------------------------+------------------+ 184 Table 1: Hybrid Key Exchange Schemes 186 These schemes are intended to provide quantum-safe forward secrecy. 188 Client Server 189 ------ ------ 191 ClientHello --------> 192 ServerHello 193 Certificate 194 ServerKeyExchange 195 CertificateRequest*+ 196 <-------- ServerHelloDone 197 Certificate*+ 198 ClientKeyExchange 199 CertificateVerify*+ 200 [ChangeCipherSpec] 201 Finished --------> 202 [ChangeCipherSpec] 203 <-------- Finished 205 Application Data <-------> Application Data 207 * message is not sent under some conditions 208 + message is not sent unless client authentication 209 is desired 211 Figure 1: Message flow in a hybrid TLS handshake 213 Figure 1 shows the messages involved in the TLS key establishment 214 protocol (aka full handshake). The addition of hybrid key exchanges 215 has direct impact on the ClientHello, the ServerHello, the 216 ServerKeyExchange, and the ClientKeyExchange messages. Next, we 217 describe each hybrid key exchange scheme in greater detail in terms 218 of the content and processing of these messages. For ease of 219 exposition, we defer discussion of the optional extension for 220 specifying the parameters supported by an implementation until 221 Section 4. 223 2.1. Key Encapsulation Method (KEM) 225 A key encapsulation mechanism (KEM) is a set of three algorithms 227 o key generation (KeyGen) 229 o encapsulation (Encaps) 231 o decapsulation (Decaps) 233 and a defined key space, where 235 o "KeyGen()": returns a public and a secret key (pk, sk). 237 o "Encaps(pk)": takes pk as input and outputs ciphertext c and a key 238 K from the key space. 240 o "Decaps(sk, c)": takes sk and c as input, and returns a key K or 241 ERROR. K is called the session key. 243 The security of a KEM is discussed in Section 7. BIKE, Kyber and 244 SIKE are KEMs. 246 2.2. ECDHE_[KEM] 248 This section describes the nearly identical hybrid key exchanges 249 ECDHE_BIKE, ECDHE_KYBER and ECDHE_SIKE. For the remainder of this 250 section [KEM] refers to either BIKE, Kyber or SIKE. The server sends 251 its ephemeral ECDH public key and an ephemeral [KEM] public key 252 generated using the corresponding curve and [KEM] parameters in the 253 ServerKeyExchange message. This specification requires that these 254 parameters MUST be signed using a signature algorithm corresponding 255 to the public key in the server's certificate. 257 The client generates an ECDHE key pair on the same curve as the 258 server's ephemeral ECDH key, and computes a ciphertext value based on 259 the [KEM] public key provided by the server, and sends them in the 260 ClientKeyExchange message. The client computes and holds the PQ KEM- 261 encapsulated key (K) as a contribution to the premaster secret. 263 Both client and server perform an ECDH operation and use the 264 resultant shared secret (Z) as part of the premaster secret. The 265 server computes the PQ KEM decapsulation routine to compute the 266 encapsulated key (K), or to produce an error message in case the 267 decapsulation fails. 269 3. Hybrid Premaster Secret 271 This section defines the mechanism for combining the ECDHE and [KEM] 272 secrets into a TLS 1.2 [RFC5246] pre-master secret. In the hybrid 273 key exchange, both the server and the client compute two shared 274 secrets: the previously defined ECDHE shared secret Z from RFC 8422, 275 and another shared secret K from the underlying PQ key encapsulation 276 method. 278 Form the premaster secret for ECDHE_[KEM] hybrid key exchanges as the 279 concatenation of the ECDHE shared secret Z with the KEM key K to form 280 the opaque data value "premaster_secret = Z || K". 282 4. TLS Extension for Supported PQ KEM Parameters 284 A new TLS extension for post-quantum key encapsulation methods is 285 defined in this specification. 287 This allows negotiating the use of specific PQ KEM parameter sets 288 during a handshake starting a new session. The extension is 289 especially relevant for constrained clients that may only support a 290 limited number of PQ KEM parameter sets. They follow the general 291 approach outlined in RFC 5246; message details are specified in 292 Section 5. The client enumerates the BIKE, Kyber and SIKE parameters 293 it supports by including the PQ KEM extension in its ClientHello 294 message. 296 A TLS client that proposes PQ KEM cipher suites in its ClientHello 297 message SHOULD include this extension. Servers implementing a PQ KEM 298 cipher suite MUST support this extension, and when a client uses this 299 extension, servers MUST NOT negotiate the use of a PQ KEM parameter 300 set unless they can complete the handshake while respecting the 301 choice of parameters specified by the client. This eliminates the 302 possibility that a negotiated hybrid handshake will be subsequently 303 aborted due to a client's inability to deal with the server's PQ KEM 304 key. 306 The client MUST NOT include the PQ KEM extension in the ClientHello 307 message if it does not propose any PQ KEM cipher suites. 308 Additionally, the client MUST NOT include parameters in the PQ KEM 309 extension for PQ KEM cipher suites it does not propose. That is, if 310 a client does not support BIKE, it must not include the BIKE 311 parameters in the extension, similarly for Kyber and SIKE. A client 312 that proposes a PQ KEM scheme may choose not to include this 313 extension. In this case, the server is free to choose any one of the 314 parameter sets listed in Section 5. That section also describes the 315 structure and processing of this extension in greater detail. 317 In the case of session resumption, the server simply ignores the 318 Supported PQ KEM Parameters extension appearing in the current 319 ClientHello message. These extensions only play a role during 320 handshakes negotiating a new session. 322 5. Data Structures and Computations 324 This section specifies the data structures and computations used by 325 PQ KEM hybrid-key agreement mechanisms specified in Sections 2, 3, 326 and 4. The presentation language used here is the same as that used 327 in TLS 1.2 [RFC5246]. 329 5.1. Client Hello Extensions 331 This section specifies the Supported PQ KEM Parameters extension that 332 can be included with the ClientHello message as described in 333 RFC 5246. 335 5.1.1. When these extensions are sent 337 The extensions SHOULD be sent along with any ClientHello message that 338 proposes the associated PQ KEM cipher suites. 340 5.1.2. Meaning of these extensions 342 These extensions allow a client to enumerate the PQ KEM parameters 343 sets it supports for any supported PQ KEM. 345 5.1.3. Structure of these extensions 347 The general structure of TLS extensions is described in RFC 5246, and 348 this specification adds a new type to ExtensionType. 350 enum { 351 pq_kem_parameters(0xFE01) 352 } ExtensionType; 354 where 356 o "pq_kem_parameters" (Supported PQ KEM Parameters extension): 357 Indicates the set of post-quantum KEM parameters supported by the 358 client. For this extension, the opaque extension_data field 359 contains PQKEMParametersExtension. See Section 5.1.6 for details. 361 5.1.4. Actions of the sender 363 A client that proposes PQ KEM hybrid key exchange cipher suites in 364 its ClientHello message appends these extensions (along with any 365 others), enumerating the parameters it supports. Clients SHOULD send 366 the PQ KEM parameter sets it supports if it supports PQ KEM hybrid 367 key exchange cipher suites. 369 5.1.5. Actions of the receiver 371 A server that receives a ClientHello containing this extension MUST 372 use the client's enumerated capabilities to guide its selection of an 373 appropriate cipher suite. One of the proposed PQ KEM cipher suites 374 must be negotiated only if the server can successfully complete the 375 handshake while using the PQ KEM parameters supported by the client 376 (cf. Section 5.1.6.) 377 If a server does not understand the Supported PQ KEM Parameters 378 extension, or is unable to complete the PQ KEM handshake while 379 restricting itself to the enumerated parameters, it MUST NOT 380 negotiate the use of the corresponding PQ KEM cipher suite. 381 Depending on what other cipher suites are proposed by the client and 382 supported by the server, this may result in a fatal handshake failure 383 alert due to the lack of common cipher suites. 385 5.1.6. Supported PQ KEM Parameters Extension 387 This section defines the contents of the Supported PQ KEM Parameters 388 extension. In the language of RFC 5246, the "extension_data" is the 389 "PQKEMParametersExtension" type defined below. 391 enum { 392 BIKE1-L1-R1 (1), 393 BIKE1-L3-R1 (2), 394 BIKE1-L5-R1 (3), 395 BIKE2-L1-R1 (4), 396 BIKE2-L3-R1 (5), 397 BIKE2-L5-R1 (6), 398 BIKE3-L1-R1 (7), 399 BIKE3-L3-R1 (8), 400 BIKE3-L5-R1 (9), 401 SIKE-P503-R1 (10), 402 SIKE-P751-R1 (11), 403 SIKE-p964-R1 (12), 404 BIKE1-CCA-L1-R2 (13), 405 BIKE1-CCA-L3-R2 (14), 406 BIKE1-CCA-L5-R2 (15), 407 BIKE2-CCA-L1-R2 (16), 408 BIKE2-CCA-L3-R2 (17), 409 BIKE2-CCA-L5-R2 (18), 410 SIKE-P434-R2 (19), 411 SIKE-P503-R2 (20), 412 SIKE-P610-R2 (21), 413 SIKE-P751-R2 (22), 414 KYBER-512-R2 (23), 415 KYBER-512-90s-R2 (24) 416 } NamedPQKEM (2^16-1); 418 "BIKE1-L1-R1", etc: Indicates support of the corresponding BIKE 419 parameters defined in BIKE Round 1, the round 1 candidate to the NIST 420 Post-Quantum Cryptography Standardization Process. (NIST PQC) 422 "BIKE1-CCA-L1-R2", etc: Indicates support of the corresponding BIKE 423 CCA parameters defined in BIKE Round 2, the latest revision of the 424 round 2 CCA candidate submitted to NIST PQC available at the time of 425 this draft specification. 427 "SIKE1-P503-R1", etc: Indicates support of the corresponding SIKE 428 parameters defined in SIKE Round 1, the round 1 candidate to NIST 429 PQC. 431 "SIKE1-P434-R2", etc: Indicates support of the corresponding SIKE 432 parameters defined in SIKE Round 2, the round 2 candidate to NIST 433 PQC. 435 "KYBER-512-R2", etc: Indicates support of the corresponding KYBER 436 parameters defined in Kyber, the round 2 candidate to NIST PQC. 438 struct { 439 NamedPQKEM pq_kem_parameters_list <1..2^16-1> 440 } PQKEMParametersExtension; 442 Items in "pq_kem_parameters_list" are ordered according to the 443 client's preferences (favorite choice first). 445 As an example, a client that only supports BIKE1-L1-R1 ( value 1 = 446 0x0001), BIKE2-L1-R1 ( value 4 = 0x0004) and SIKE-P434-R2 ( value 19 447 = 0x0013) and prefers to use SIKE-P434-R2 would include a TLS 448 extension consisting of the following octets: 450 FE 01 00 08 00 06 00 13 00 01 00 04 452 Note that the first two octets (FE 01) indicate the extension type 453 (Supported PQ KEM Parameters extension), the next two octets 454 indicates the length of the extension in bytes (00 08), and the next 455 two octets indicate the length of enumerated values in bytes (00 06). 457 5.2. Server Key Exchange 459 5.2.1. When this message is sent 461 This message is sent when using an ECDHE_[KEM] hybrid key exchange 462 algorithms. 464 5.2.2. Meaning of this message 466 This message is used to convey the server's ephemeral ECDH and [KEM] 467 public keys to the client. 469 5.2.3. Structure of this message 471 struct { 472 opaque public_key <1,...,2^24 - 1>; 473 } PQKEMPublicKey; 475 public_key: This is a byte string representation of the [KEM] public 476 key following the conversion defined by the [KEM] implementation. 478 struct { 479 NamedPQKEM named_params; 480 PQKEMPublicKey public; 481 } ServerPQKEMParams; 483 The ServerKeyExchange message is extended as follows: 485 struct { 486 ServerECDHParams ecdh_params; 487 ServerPQKEMParams pq_kem_params; 488 Signature signed_params; 489 } ServerKeyExchange; 491 where 493 o "ecdh_params": Specifies the ECDHE public key and associated 494 domain parameters. 496 o "pq_kem_params": Specifies the [KEM] public key and associated 497 parameters. 499 o "signed_params": a signature over the server's key exchange 500 parameters. Note that only ciphersuites which include a signature 501 algorithm are supported; see Section 6. The private key 502 corresponding to the certified public key in the server's 503 Certificate message is used for signing. 505 digitally-signed struct { 506 opaque client_random[32]; 507 opaque server_random[32]; 508 ServerDHParams ecdh_params; 509 ServerPQKEMParams pq_kem_params; 510 } Signature; 512 The parameters are hashed as part of the signing algorithm as 513 follows, where H is the hash function used for generating the 514 signature: 516 For ECDHE_[KEM]: 518 "H( client_random[32] + server_random[32] + ecdh_params + 519 pq_kem_params)." 521 NOTE: This specification only defines hybrid ciphersuites with RSA 522 and ECDSA signatures. See [RFC5246] and RFC 8422, respectively, for 523 details on their use in TLS 1.2. 525 5.2.4. Actions of the sender 527 The server selects elliptic curve domain parameters and an ephemeral 528 ECDH public key corresponding to these parameters according to 529 RFC 8422. The server SHOULD generate a fresh ephemeral ECDH key for 530 each key exchange so that the hybrid key exchange scheme provides 531 forward secrecy. The server selects a PQ KEM parameter set, and uses 532 "KeyGen()" for the corresponding parameters of BIKE Round 1, BIKE 533 Round 2, Kyber, SIKE Round 1, or SIKE Round 2 to generate an 534 ephemeral public key pair. The server MUST generate a fresh PQ KEM 535 key for each key exchange. A server that receives a Supported PQ KEM 536 Parameters extension MUST use the client's enumerated capabilities to 537 guide its selection of an appropriate cipher suite. The server MUST 538 NOT negotiate the use of a PQ KEM parameter set unless they can 539 complete the handshake while respecting the choice of parameters 540 specified by the client (cf. Section 5.1.6). If the client does not 541 include the PQ KEM Parameters extension, the server is free to choose 542 any one of the parameters listed in Section 5.1.6. 544 If a server is unable to complete the PQ KEM handshake while 545 restricting itself to the enumerated parameters, it MUST NOT 546 negotiate the use of the corresponding PQ KEM cipher suite. 547 Depending on what other cipher suites are proposed by the client and 548 supported by the server, this may result in a fatal handshake failure 549 alert due to the lack of common cipher suites. 551 After selecting a ciphersuite and appropriate parameters, the server 552 conveys this information to the client in the ServerKeyExchange 553 message using the format defined above. 555 5.2.5. Actions of the receiver 557 The client verifies the signature and retrieves the server's elliptic 558 curve domain parameters and ephemeral ECDH public key and the [KEM] 559 parameter set and public key from the ServerKeyExchange message. 561 A possible reason for a fatal handshake failure is that the client's 562 capabilities for handling elliptic curves and point formats are 563 exceeded (see RFC 8422), the PQ KEM parameters are not supported (see 564 Section 5.1), or the signature does not verify. 566 5.3. Client Key Exchange 568 5.3.1. When this message is sent 570 This message is sent in all key exchange algorithms. In the key 571 exchanges defined in this document, it contains the client's 572 ephemeral ECDH public key and the [KEM] ciphertext value. 574 5.3.2. Meaning of the message 576 This message is used to convey ephemeral data relating to the key 577 exchange belonging to the client (such as its ephemeral ECDH public 578 key and the [KEM] ciphertext value). 580 5.3.3. Structure of this message 582 The TLS ClientKeyExchange message is extended as follows. 584 struct { 585 opaque ciphertext <1,..., 2^24 - 1>; 586 } PQKEMCiphertext; 588 where 590 o "ciphertext": This is a byte string representation of the PQ 591 ciphertext of the KEM construction. Since the underlying calling 592 convention of the KEM API handles the ciphertext byte string 593 directly it is sufficient to pass this as single byte string array 594 in the protocol. 596 struct { 597 ClientECDiffieHellmanPublic ecdh_public; 598 PQKEMCiphertext ciphertext; 599 } ClientKeyExchange; 601 5.3.4. Actions of the sender 603 The client selects an ephemeral ECDH public key corresponding to the 604 parameters it received from the server according to RFC 8422. The 605 client SHOULD generate a fresh ephemeral ECDH key for each key 606 exchange so that the hybrid key exchange scheme provides forward 607 secrecy. Using the "Encaps(pk)" function corresponding to the PQ KEM 608 and named parameters in ServerKeyExchange message, the client 609 computes a [KEM] ciphertext. It conveys this information to the 610 server in the ClientKeyExchange message using the format defined 611 above. 613 5.3.5. Actions of the receiver 615 The server retrieves the client's ephemeral ECDH public key and the 616 [KEM] ciphertext from the ClientKeyExchange message and checks that 617 it is on the same elliptic curve as the server's ECDHE key, and that 618 the [KEM] ciphertexts conform to the domain parameters selected by 619 the server. The server uses the "Decaps(pk)" function corresponding 620 to the PQ KEM and named parameters in ServerKeyExchange message to 621 compute the KEM shared secret. 623 In the case of BIKE and Kyber there is a decapsulation failure rate 624 no greater than 10^(-7). In the case of a decapsulation failure, an 625 implementation MUST abort the handshake. 627 5.4. Derivation of the master secret for hybrid key agreement 629 This section defines a new hybrid master secret derivation. It is 630 defined under the assumption that we use the concatenated premaster 631 secret defined in Section 3.1 (Section 3). Recall in this case the 632 premaster_secret = Z || K, where Z it the ECDHE shared secret, and K 633 is the KEM shared secret. 635 We define the master secret as follows: 637 master_secret[48] = TLS-PRF(secret, label, seed) 639 where 641 o "secret": the premaster_secret, 643 o "label": the string "hybrid master secret", and 645 o "seed": the concatenation of "ClientHello.random || 646 ServerHello.random || ClientKeyExchange" 648 6. Cipher Suites 650 The table below defines new hybrid key exchange cipher suites that 651 use the key exchange algorithms specified in Section 2 (Section 2). 653 +----------------------------------------------------------------+ 654 | Ciphersuite | 655 +----------------------------------------------------------------+ 656 | TLS_ECDHE_BIKE_ECDSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x01 } | 657 | | 658 | TLS_ECDHE_BIKE_ECDSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x02 } | 659 | | 660 | TLS_ECDHE_BIKE_RSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x03 } | 661 | | 662 | TLS_ECDHE_BIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x04 } | 663 | | 664 | TLS_ECDHE_SIKE_ECDSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x05 } | 665 | | 666 | TLS_ECDHE_SIKE_ECDSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x06 } | 667 | | 668 | TLS_ECDHE_SIKE_RSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x07 } | 669 | | 670 | TLS_ECDHE_SIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x08 } | 671 | | 672 | TLS_ECDHE_KYBER_ECDSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x09 } | 673 | | 674 | TLS_ECDHE_KYBER_ECDSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x0A } | 675 | | 676 | TLS_ECDHE_KYBER_RSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x0B } | 677 | | 678 | TLS_ECDHE_KYBER_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x0C } | 679 +----------------------------------------------------------------+ 681 Table 2: TLS hybrid key exchange cipher suites 683 The key exchange method, signature algorithm, cipher, and hash 684 algorithm for each of these cipher suites are easily determined by 685 examining the name. Ciphers and hash algorithms are defined in 686 RFC 5288. 688 It is recommended that any implementation of this specification 689 include both of the following ciphersuites: 691 o TLS_ECDHE_BIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x04 } 693 o TLS_ECDHE_SIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x08 } 695 using the parameters BIKE1-CCA-L1-R2 and SIKE-P434-R2. 697 7. Security Considerations [DRAFT] 699 The security considerations in TLS 1.2 [RFC5246] and RFC 8422 apply 700 to this document as well. In addition, as described in RFC 5288 and 701 RFC 5289, these cipher suites may only be used with TLS 1.2 or 702 greater. 704 The description of a KEM is provided in Section 2.1. The security of 705 the KEM is defined through the indistinguishability against a chosen- 706 plaintext (IND-CPA) and against a chosen-ciphertext (IND-CCA) 707 adversary. We are focused here on the IND-CPA security of the KEM. 708 As a result, implementations MUST NOT use a KEM key more than once, 709 as reusing keys with IND-CPA KEMs can result in chosen ciphertext 710 attacks like the GJS attack against BIKE [GJS]. 712 In the IND-CPA experiment of KEMs, an oracle generates keys (sk, pk) 713 with "KeyGen()", computes (c, K) with "Encaps(pk)", and draws 714 uniformly at random a value R from the key space, and a random bit b. 715 The adversary is an algorithm A that is given (pk, c, K) if b=1, and 716 (pk, c, R) if b=0. Algorithm A outputs a bit b' as a guess for b, 717 and wins if b' = b. 719 All of the ciphersuites described in this document are intended to 720 provide forward secrecy. The hybrid key exchange mechanism described 721 in this specification achieves forward secrecy when all ephemeral 722 keys are single-use. This specification requires single-use PQ KEM 723 keys, so ephemeral ECDH keys SHOULD also be single-use so that 724 forward secrecy is achieved. 726 8. IANA Considerations 728 This document describes three new name spaces for use with the TLS 729 protocol: 731 9. Acknowledgements 733 This specification is based on ideas discussed with Ian Goldberg, 734 Michele Mosca, Douglas Stebila and William Whyte during preparations 735 for the first ETSI-IQC Quantum Safe Cryptography Workshop in 2013. 736 The specification was developed through collaboration on the open 737 source s2n project with Nicholas Allen, Nir Drucker, Shay Gueron, 738 Andrew Hopkins, Colm MacCarthaigh and Alex Weibel. 740 10. Normative References 742 [BIKEr1] Misoczki, R., Aragon, N., Barreto, P., Bettaieb, S., 743 Bidoux, L., Blazy, O., Deneuville, J., Gaborit, P., 744 Gueron, S., Guneysu, T., Melchor, C., Persichetti, E., 745 Sendrier, N., Tillich, J., and G. Zemor, "BIKE: Bit 746 Flipping Key Encapsulation", November 2017, 747 . 749 [BIKEr2] Misoczki, R., Aragon, N., Barreto, P., Bettaieb, S., 750 Bidoux, L., Blazy, O., Deneuville, J., Gaborit, P., 751 Gueron, S., Guneysu, T., Melchor, C., Persichetti, E., 752 Sendrier, N., Tillich, J., Vasseur, V., and G. Zemor, 753 "BIKE: Bit Flipping Key Encapsulation, version 3.2", 754 February 2020, . 757 [GJS] Guo, Q., Johansson, T., and P. Stankovski, "A Key Recovery 758 Attack on MDPC with CCA Security Using Decoding Failures", 759 2016, . 761 [KYBERr2] Avanzi, R., Bos, J., Ducas, L., Kiltz, E., Lepoint, T., 762 Lyubashevsky, V., Schanck, J., Schwabe, P., Seiler, G., 763 and D. Stehle, "CRYSTALS-Kyber", March 2019, 764 . 768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 769 Requirement Levels", BCP 14, RFC 2119, 770 DOI 10.17487/RFC2119, March 1997, 771 . 773 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 774 (TLS) Protocol Version 1.2", RFC 5246, 775 DOI 10.17487/RFC5246, August 2008, 776 . 778 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 779 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 780 DOI 10.17487/RFC5288, August 2008, 781 . 783 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 784 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 785 DOI 10.17487/RFC5289, August 2008, 786 . 788 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 789 Curve Cryptography (ECC) Cipher Suites for Transport Layer 790 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 791 DOI 10.17487/RFC8422, August 2018, 792 . 794 [SIKEr1] Jao, D., Azarderakhsh, R., Campagna, M., Costello, C., De 795 Feo, L., Hess, B., Jalali, A., Koziel, B., LaMacchia, B., 796 Longa, P., Naehrig, M., Renes, J., Soukharev, V., and D. 797 Urbanik, "Supersingular Isogeny Key Encapsulation", 798 November 2017, . 802 [SIKEr2] Jao, D., Azarderakhsh, R., Campagna, M., Costello, C., De 803 Feo, L., Hess, B., Jalali, A., Koziel, B., LaMacchia, B., 804 Longa, P., Naehrig, M., Pereira, G., Renes, J., Soukharev, 805 V., and D. Urbanik, "Supersingular Isogeny Key 806 Encapsulation", April 2019, 807 . 811 Appendix A. Additional Stuff 813 This becomes an Appendix. 815 Authors' Addresses 817 Matt Campagna 818 AWS 820 Email: campagna@amazon.com 822 Eric Crockett 823 AWS 825 Email: ericcro@amazon.com