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