idnits 2.17.1 draft-campagna-tls-bike-sike-hybrid-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 477 has weird spacing: '...blicKey publi...' == Line 506 has weird spacing: '...MParams pq_k...' == Line 593 has weird spacing: '...nPublic ecd...' == Unrecognized Status in 'Intended status: Experimental Protocol', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (July 06, 2020) is 1384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 199, but not defined == Missing Reference: 'KEM' is mentioned on line 614, but not defined -- Looks like a reference, but probably isn't: '32' on line 515 -- Looks like a reference, but probably isn't: '48' on line 633 == Missing Reference: 'DRAFT' is mentioned on line 680, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'GJS' -- Possible downref: Non-RFC (?) normative reference: ref. 'BIKEr1' -- Possible downref: Non-RFC (?) normative reference: ref. 'BIKEr2' -- Possible downref: Non-RFC (?) normative reference: ref. 'KYBERr2' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIKEr1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIKEr2' Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 9 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 Protocol AWS 5 Expires: January 12, 2021 July 06, 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-04 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 all authors at 37 mcampagna@amazon.com. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on January 12, 2021. 56 Copyright Notice 58 Copyright (c) 2020 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Simplified BSD License text 67 as described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as 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] . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Hybrid Premaster Secret . . . . . . . . . . . . . . . . . . . 6 78 4. TLS Extension for Supported PQ KEM Parameters . . . . . . . . 6 79 5. Data Structures and Computations . . . . . . . . . . . . . . . 7 80 5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 7 81 5.1.1. When these extensions are sent . . . . . . . . . . . . 7 82 5.1.2. Meaning of these extensions . . . . . . . . . . . . . 7 83 5.1.3. Structure of these extensions . . . . . . . . . . . . 7 84 5.1.4. Actions of the sender . . . . . . . . . . . . . . . . 7 85 5.1.5. Actions of the receiver . . . . . . . . . . . . . . . 7 86 5.1.6. Supported PQ KEM Parameters Extension . . . . . . . . 8 87 5.2. Server Key Exchange . . . . . . . . . . . . . . . . . . . 9 88 5.2.1. When this message is sent . . . . . . . . . . . . . . 9 89 5.2.2. Meaning of this message . . . . . . . . . . . . . . . 9 90 5.2.3. Structure of this message . . . . . . . . . . . . . . 9 91 5.2.4. Actions of the sender . . . . . . . . . . . . . . . . 10 92 5.2.5. Actions of the receiver . . . . . . . . . . . . . . . 11 93 5.3. Client Key Exchange . . . . . . . . . . . . . . . . . . . 11 94 5.3.1. When this message is sent . . . . . . . . . . . . . . 11 95 5.3.2. Meaning of the message . . . . . . . . . . . . . . . . 11 96 5.3.3. Structure of this message . . . . . . . . . . . . . . 11 97 5.3.4. Actions of the sender . . . . . . . . . . . . . . . . 12 98 5.3.5. Actions of the receiver . . . . . . . . . . . . . . . 12 99 5.4. Derivation of the master secret for hybrid key agreement . 12 100 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 13 101 7. Security Considerations [DRAFT] . . . . . . . . . . . . . . . 13 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 103 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 105 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 15 106 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 109 1. Introduction 111 Quantum-safe (or post-quantum) key exchanges are being developed in 112 order to provide secure key establishment against an adversary with 113 access to a quantum computer. Under such a threat model, the current 114 key exchange mechanisms would be vulnerable. BIKE [BIKEr2], Kyber 115 [KYBERr2] and SIKE [SIKEr2] are post-quantum candidates which were 116 submitted to the NIST Call for Proposals for Post-Quantum 117 Cryptographic Schemes. While these schemes are still being analyzed 118 as part of that process, there is already a need to protect the 119 confidentiality of today's TLS connections against a future adversary 120 with a quantum computer. Hybrid key exchanges are designed to 121 provide two parallel key exchanges: one which is classical (e.g., 122 ECDHE) and the other which is quantum-safe (e.g., SIKE). The hybrid 123 schemes we propose are at least as secure as ECDH against a classical 124 adversary, and at least as secure as the PQ KEM against a quantum 125 adversary. This strategy is emerging as a method to speculatively 126 provide additional security to existing protocols. 128 This document describes additions to TLS to support PQ Hybrid Key 129 Exchanges, applicable to TLS Version 1.2 [RFC5246]. These additions 130 are designed to support most of the second-round candidates in the 131 NIST Call for Proposals, but this document only defines ciphersuites 132 for a small subset of possible hybrid key agreement methods. In 133 particular, it defines the use of the ECDHE together with BIKE, Kyber 134 or SIKE, as a hybrid key agreement method. 136 The remainder of this document is organized as follows. [kexalgs] 137 provides an overview of PQ KEM-based key exchange algorithms for TLS. 138 [hybridpms] describes how a PQ KEM can be combined with ECDHE to form 139 a premaster secret. In [tlsexts], we present a TLS extension that 140 allow a client to negotiate the use of specific PQ schemes and 141 parameters. [structs] specifies various data structures needed for a 142 BIKE-, Kyber- or SIKE-based hybrid key exchange handshake, their 143 encoding in TLS messages, and the processing of those messages. 144 [ciphersuites] defines two new PQ KEM hybrid-based cipher suites and 145 identifies a small subset of these as recommended for all 146 implementations of this specification. [security] discusses some 147 security considerations. [iana] describes IANA considerations for 148 the name spaces created by this document. [ack] gives 149 acknowledgments. 151 Implementation of this specification requires familiarity with TLS 152 [RFC5246], BIKE [BIKEr2], Kyber [KYBERr2], and SIKE [SIKEr2]. 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 [RFC2119]. 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, Kyber 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. While this specification only defines 169 the use of a PQ KEM hybrid key exchange with BIKE, Kyber or SIKE, it 170 is specifically designed so that it can be easily extended to include 171 additional PQ KEM methods. 173 The table below summarizes the new hybrid key exchange schemes. 175 +---------------------------------+------------------+ 176 | Hybrid Key Exchange Scheme Name | Description | 177 +---------------------------------+------------------+ 178 | ECDHE_BIKE | ECDHE and BIKE. | 179 | ECDHE_KYBER | ECDHE and Kyber. | 180 | ECDHE_SIKE | ECDHE and SIKE. | 181 +---------------------------------+------------------+ 183 These schemes are intended to provide quantum-safe forward secrecy. 185 Client Server 186 ------ ------ 188 ClientHello --------> 189 ServerHello 190 Certificate 191 ServerKeyExchange 192 CertificateRequest*+ 193 <-------- ServerHelloDone 194 Certificate*+ 195 ClientKeyExchange 196 CertificateVerify*+ 197 [ChangeCipherSpec] 198 Finished --------> 199 [ChangeCipherSpec] 200 <-------- Finished 202 Application Data <-------> Application Data 204 * message is not sent under some conditions 205 + message is not sent unless client authentication 206 is desired 208 [hybrid_protocol] shows the messages involved in the TLS key 209 establishment protocol (aka full handshake). The addition of hybrid 210 key exchanges has direct impact on the ClientHello, the ServerHello, 211 the ServerKeyExchange, and the ClientKeyExchange messages. Next, we 212 describe each hybrid key exchange scheme in greater detail in terms 213 of the content and processing of these messages. For ease of 214 exposition, we defer discussion of the optional extension for 215 specifying the parameters supported by an implementation until 216 [tlsexts]. 218 2.1. Key Encapsulation Method (KEM) 220 A key encapsulation mechanism (KEM) is a set of three algorithms 222 o key generation (KeyGen) 224 o encapsulation (Encaps) 226 o decapsulation (Decaps) 228 and a defined key space, where 230 o "KeyGen()": returns a public and a secret key (pk, sk). 232 o "Encaps(pk)": takes pk as input and outputs ciphertext c and a key 233 K from the key space. 235 o "Decaps(sk, c)": takes sk and c as input, and returns a key K or 236 ERROR. K is called the session key. 238 The security of a KEM is discussed in [security]. BIKE, Kyber and 239 SIKE are KEMs. 241 2.2. ECDHE_[KEM] 243 This section describes the nearly identical hybrid key exchanges 244 ECDHE_BIKE, ECDHE_KYBER and ECDHE_SIKE. For the remainder of this 245 section [KEM] refers to either BIKE, Kyber or SIKE. The server sends 246 its ephemeral ECDH public key and an ephemeral [KEM] public key 247 generated using the corresponding curve and [KEM] parameters in the 248 ServerKeyExchange message. This specification requires that these 249 parameters MUST be signed using a signature algorithm corresponding 250 to the public key in the server's certificate. 252 The client generates an ECDHE key pair on the same curve as the 253 server's ephemeral ECDH key, and computes a ciphertext value based on 254 the [KEM] public key provided by the server, and sends them in the 255 ClientKeyExchange message. The client computes and holds the PQ KEM- 256 encapsulated key (K) as a contribution to the premaster secret. 258 Both client and server perform an ECDH operation and use the 259 resultant shared secret (Z) as part of the premaster secret. The 260 server computes the PQ KEM decapsulation routine to compute the 261 encapsulated key (K), or to produce an error message in case the 262 decapsulation fails. 264 3. Hybrid Premaster Secret 266 This section defines the mechanism for combining the ECDHE and [KEM] 267 secrets into a TLS 1.2 [RFC5246] pre-master secret. In the hybrid 268 key exchange, both the server and the client compute two shared 269 secrets: the previously defined ECDHE shared secret Z from RFC 8422 270 [RFC8422], and another shared secret K from the underlying PQ key 271 encapsulation method. 273 Form the premaster secret for ECDHE_[KEM] hybrid key exchanges as the 274 concatenation of the ECDHE shared secret Z with the KEM key K to form 275 the opaque data value "premaster_secret = Z || K". 277 4. TLS Extension for Supported PQ KEM Parameters 279 A new TLS extension for post-quantum key encapsulation methods is 280 defined in this specification. 282 This allows negotiating the use of specific PQ KEM parameter sets 283 during a handshake starting a new session. The extension is 284 especially relevant for constrained clients that may only support a 285 limited number of PQ KEM parameter sets. They follow the general 286 approach outlined in RFC 5246 [RFC5246]; message details are 287 specified in [structs]. The client enumerates the BIKE, Kyber and 288 SIKE parameters it supports by including the PQ KEM extension in its 289 ClientHello message. 291 A TLS client that proposes PQ KEM cipher suites in its ClientHello 292 message SHOULD include this extension. Servers implementing a PQ KEM 293 cipher suite MUST support this extension, and when a client uses this 294 extension, servers MUST NOT negotiate the use of a PQ KEM parameter 295 set unless they can complete the handshake while respecting the 296 choice of parameters specified by the client. This eliminates the 297 possibility that a negotiated hybrid handshake will be subsequently 298 aborted due to a client's inability to deal with the server's PQ KEM 299 key. 301 The client MUST NOT include the PQ KEM extension in the ClientHello 302 message if it does not propose any PQ KEM cipher suites. 303 Additionally, the client MUST NOT include parameters in the PQ KEM 304 extension for PQ KEM cipher suites it does not propose. That is, if 305 a client does not support BIKE, it must not include the BIKE 306 parameters in the extension, similarly for Kyber and SIKE. A client 307 that proposes a PQ KEM scheme may choose not to include this 308 extension. In this case, the server is free to choose any one of the 309 parameter sets listed in [structs]. That section also describes the 310 structure and processing of this extension in greater detail. 312 In the case of session resumption, the server simply ignores the 313 Supported PQ KEM Parameters extension appearing in the current 314 ClientHello message. These extensions only play a role during 315 handshakes negotiating a new session. 317 5. Data Structures and Computations 319 This section specifies the data structures and computations used by 320 PQ KEM hybrid-key agreement mechanisms specified in Sections 2 321 [kexalgs], 3 [hybridpms], and 4 [tlsexts]. The presentation language 322 used here is the same as that used in TLS 1.2 [RFC5246]. 324 5.1. Client Hello Extensions 326 This section specifies the Supported PQ KEM Parameters extension that 327 can be included with the ClientHello message as described in RFC 5246 328 [RFC5246]. 330 5.1.1. When these extensions are sent 332 The extensions SHOULD be sent along with any ClientHello message that 333 proposes the associated PQ KEM cipher suites. 335 5.1.2. Meaning of these extensions 337 These extensions allow a client to enumerate the PQ KEM parameters 338 sets it supports for any supported PQ KEM. 340 5.1.3. Structure of these extensions 342 The general structure of TLS extensions is described in RFC 5246 343 [RFC5246], and this specification adds a new type to ExtensionType. 345 enum { 346 pq_kem_parameters(0xFE01) 347 } ExtensionType; 349 where 351 o "pq_kem_parameters" (Supported PQ KEM Parameters extension): 352 Indicates the set of post-quantum KEM parameters supported by the 353 client. For this extension, the opaque extension_data field 354 contains PQKEMParametersExtension. See [pqkemxts] for details. 356 5.1.4. Actions of the sender 358 A client that proposes PQ KEM hybrid key exchange cipher suites in 359 its ClientHello message appends these extensions (along with any 360 others), enumerating the parameters it supports. Clients SHOULD send 361 the PQ KEM parameter sets it supports if it supports PQ KEM hybrid 362 key exchange cipher suites. 364 5.1.5. Actions of the receiver 365 A server that receives a ClientHello containing this extension MUST 366 use the client's enumerated capabilities to guide its selection of an 367 appropriate cipher suite. One of the proposed PQ KEM cipher suites 368 must be negotiated only if the server can successfully complete the 369 handshake while using the PQ KEM parameters supported by the client 370 (cf. [pqkemxts].) 372 If a server does not understand the Supported PQ KEM Parameters 373 extension, or is unable to complete the PQ KEM handshake while 374 restricting itself to the enumerated parameters, it MUST NOT 375 negotiate the use of the corresponding PQ KEM cipher suite. 376 Depending on what other cipher suites are proposed by the client and 377 supported by the server, this may result in a fatal handshake failure 378 alert due to the lack of common cipher suites. 380 5.1.6. Supported PQ KEM Parameters Extension 382 This section defines the contents of the Supported PQ KEM Parameters 383 extension. In the language of RFC 5246 [RFC5246], the 384 "extension_data" is the "PQKEMParametersExtension" type defined 385 below. 387 enum { 388 BIKE1-L1-R1 (1), 389 BIKE1-L3-R1 (2), 390 BIKE1-L5-R1 (3), 391 BIKE2-L1-R1 (4), 392 BIKE2-L3-R1 (5), 393 BIKE2-L5-R1 (6), 394 BIKE3-L1-R1 (7), 395 BIKE3-L3-R1 (8), 396 BIKE3-L5-R1 (9), 397 SIKE-P503-R1 (10), 398 SIKE-P751-R1 (11), 399 SIKE-p964-R1 (12), 400 BIKE1-CCA-L1-R2 (13), 401 BIKE1-CCA-L3-R2 (14), 402 BIKE1-CCA-L5-R2 (15), 403 BIKE2-CCA-L1-R2 (16), 404 BIKE2-CCA-L3-R2 (17), 405 BIKE2-CCA-L5-R2 (18), 406 SIKE-P434-R2 (19), 407 SIKE-P503-R2 (20), 408 SIKE-P610-R2 (21), 409 SIKE-P751-R2 (22), 410 KYBER-512-R2 (23), 411 KYBER-512-90s-R2 (24) 412 } NamedPQKEM (2^16-1); 414 "BIKE1-L1-R1", etc: Indicates support of the corresponding BIKE 415 parameters defined in BIKE Round 1 [BIKEr1], the round 1 candidate to 416 the NIST Post-Quantum Cryptography Standardization Process. (NIST 417 PQC) 418 "BIKE1-CCA-L1-R2", etc: Indicates support of the corresponding BIKE 419 CCA parameters defined in BIKE Round 2 [BIKEr2], the latest revision 420 of the round 2 CCA candidate submitted to NIST PQC available at the 421 time of this draft specification. 423 "SIKE1-P503-R1", etc: Indicates support of the corresponding SIKE 424 parameters defined in SIKE Round 1 [SIKEr1], the round 1 candidate to 425 NIST PQC. 427 "SIKE1-P434-R2", etc: Indicates support of the corresponding SIKE 428 parameters defined in SIKE Round 2 [SIKEr2], the round 2 candidate to 429 NIST PQC. 431 "KYBER-512-R2", etc: Indicates support of the corresponding KYBER 432 parameters defined in Kyber [KYBERr2], the round 2 candidate to NIST 433 PQC. 435 struct { 436 NamedPQKEM pq_kem_parameters_list <1..2^16-1> 437 } PQKEMParametersExtension; 439 Items in "pq_kem_parameters_list" are ordered according to the 440 client's preferences (favorite choice first). 442 As an example, a client that only supports BIKE1-L1-R1 ( value 1 = 443 0x0001), BIKE2-L1-R1 ( value 4 = 0x0004) and SIKE-P434-R2 ( value 19 444 = 0x0013) and prefers to use SIKE-P434-R2 would include a TLS 445 extension consisting of the following octets: 447 FE 01 00 08 00 06 00 13 00 01 00 04 449 Note that the first two octets (FE 01) indicate the extension type 450 (Supported PQ KEM Parameters extension), the next two octets 451 indicates the length of the extension in bytes (00 08), and the next 452 two octets indicate the length of enumerated values in bytes (00 06). 454 5.2. Server Key Exchange 456 5.2.1. When this message is sent 458 This message is sent when using an ECDHE_[KEM] hybrid key exchange 459 algorithms. 461 5.2.2. Meaning of this message 463 This message is used to convey the server's ephemeral ECDH and [KEM] 464 public keys to the client. 466 5.2.3. Structure of this message 468 struct { 469 opaque public_key <1,...,2^24 - 1>; 470 } PQKEMPublicKey; 472 public_key: This is a byte string representation of the [KEM] public 473 key following the conversion defined by the [KEM] implementation. 475 struct { 476 NamedPQKEM named_params; 477 PQKEMPublicKey public; 478 } ServerPQKEMParams; 480 The ServerKeyExchange message is extended as follows: 482 struct { 483 ServerECDHParams ecdh_params; 484 ServerPQKEMParams pq_kem_params; 485 Signature signed_params; 486 } ServerKeyExchange; 488 where 490 o "ecdh_params": Specifies the ECDHE public key and associated 491 domain parameters. 493 o "pq_kem_params": Specifies the [KEM] public key and associated 494 parameters. 496 o "signed_params": a signature over the server's key exchange 497 parameters. Note that only ciphersuites which include a signature 498 algorithm are supported; see [ciphersuites]. The private key 499 corresponding to the certified public key in the server's 500 Certificate message is used for signing. 502 digitally-signed struct { 503 opaque client_random[32]; 504 opaque server_random[32]; 505 ServerDHParams ecdh_params; 506 ServerPQKEMParams pq_kem_params; 507 } Signature; 509 The parameters are hashed as part of the signing algorithm as 510 follows, where H is the hash function used for generating the 511 signature: 513 For ECDHE_[KEM]: 515 "H( client_random[32] + server_random[32] + ecdh_params + 516 pq_kem_params)." 518 NOTE: This specification only defines hybrid ciphersuites with RSA 519 and ECDSA signatures. See [RFC5246] and RFC 8422 [RFC8422], 520 respectively, for details on their use in TLS 1.2. 522 5.2.4. Actions of the sender 523 The server selects elliptic curve domain parameters and an ephemeral 524 ECDH public key corresponding to these parameters according to RFC 525 8422 [RFC8422]. The server SHOULD generate a fresh ephemeral ECDH 526 key for each key exchange so that the hybrid key exchange scheme 527 provides forward secrecy. The server selects a PQ KEM parameter set, 528 and uses "KeyGen()" for the corresponding parameters of BIKE Round 1 529 [BIKEr1], BIKE Round 2 [BIKEr2], Kyber [KYBERr2], SIKE Round 1 530 [SIKEr1], or SIKE Round 2 [SIKEr2] to generate an ephemeral public 531 key pair. The server MUST generate a fresh PQ KEM key for each key 532 exchange. A server that receives a Supported PQ KEM Parameters 533 extension MUST use the client's enumerated capabilities to guide its 534 selection of an appropriate cipher suite. The server MUST NOT 535 negotiate the use of a PQ KEM parameter set unless they can complete 536 the handshake while respecting the choice of parameters specified by 537 the client (cf. [pqkemxts]). If the client does not include the PQ 538 KEM Parameters extension, the server is free to choose any one of the 539 parameters listed in [pqkemxts]. 541 If a server is unable to complete the PQ KEM handshake while 542 restricting itself to the enumerated parameters, it MUST NOT 543 negotiate the use of the corresponding PQ KEM cipher suite. 544 Depending on what other cipher suites are proposed by the client and 545 supported by the server, this may result in a fatal handshake failure 546 alert due to the lack of common cipher suites. 548 After selecting a ciphersuite and appropriate parameters, the server 549 conveys this information to the client in the ServerKeyExchange 550 message using the format defined above. 552 5.2.5. Actions of the receiver 554 The client verifies the signature and retrieves the server's elliptic 555 curve domain parameters and ephemeral ECDH public key and the [KEM] 556 parameter set and public key from the ServerKeyExchange message. 558 A possible reason for a fatal handshake failure is that the client's 559 capabilities for handling elliptic curves and point formats are 560 exceeded (see RFC 8422 [RFC8422]), the PQ KEM parameters are not 561 supported (see [chello]), or the signature does not verify. 563 5.3. Client Key Exchange 565 5.3.1. When this message is sent 567 This message is sent in all key exchange algorithms. In the key 568 exchanges defined in this document, it contains the client's 569 ephemeral ECDH public key and the [KEM] ciphertext value. 571 5.3.2. Meaning of the message 573 This message is used to convey ephemeral data relating to the key 574 exchange belonging to the client (such as its ephemeral ECDH public 575 key and the [KEM] ciphertext value). 577 5.3.3. Structure of this message 578 The TLS ClientKeyExchange message is extended as follows. 580 struct { 581 opaque ciphertext <1,..., 2^24 - 1>; 582 } PQKEMCiphertext; 584 where 586 o "ciphertext": This is a byte string representation of the PQ 587 ciphertext of the KEM construction. Since the underlying calling 588 convention of the KEM API handles the ciphertext byte string 589 directly it is sufficient to pass this as single byte string array 590 in the protocol. 592 struct { 593 ClientECDiffieHellmanPublic ecdh_public; 594 PQKEMCiphertext ciphertext; 595 } ClientKeyExchange; 597 5.3.4. Actions of the sender 599 The client selects an ephemeral ECDH public key corresponding to the 600 parameters it received from the server according to RFC 8422 601 [RFC8422]. The client SHOULD generate a fresh ephemeral ECDH key for 602 each key exchange so that the hybrid key exchange scheme provides 603 forward secrecy. Using the "Encaps(pk)" function corresponding to 604 the PQ KEM and named parameters in ServerKeyExchange message, the 605 client computes a [KEM] ciphertext. It conveys this information to 606 the server in the ClientKeyExchange message using the format defined 607 above. 609 5.3.5. Actions of the receiver 611 The server retrieves the client's ephemeral ECDH public key and the 612 [KEM] ciphertext from the ClientKeyExchange message and checks that 613 it is on the same elliptic curve as the server's ECDHE key, and that 614 the [KEM] ciphertexts conform to the domain parameters selected by 615 the server. The server uses the "Decaps(pk)" function corresponding 616 to the PQ KEM and named parameters in ServerKeyExchange message to 617 compute the KEM shared secret. 619 In the case of BIKE and Kyber there is a decapsulation failure rate 620 no greater than 10^(-7). In the case of a decapsulation failure, an 621 implementation MUST abort the handshake. 623 5.4. Derivation of the master secret for hybrid key agreement 625 This section defines a new hybrid master secret derivation. It is 626 defined under the assumption that we use the concatenated premaster 627 secret defined in Section 3.1 [hybridpms]. Recall in this case the 628 premaster_secret = Z || K, where Z it the ECDHE shared secret, and K 629 is the KEM shared secret. 631 We define the master secret as follows: 633 master_secret[48] = TLS-PRF(secret, label, seed) 635 where 637 o "secret": the premaster_secret, 639 o "label": the string "hybrid master secret", and 641 o "seed": the concatenation of "ClientHello.random || 642 ServerHello.random || ClientKeyExchange" 644 6. Cipher Suites 646 The table below defines new hybrid key exchange cipher suites that 647 use the key exchange algorithms specified in Section 2 [kexalgs]. 649 +----------------------------------------------------------------+ 650 | Ciphersuite | 651 +----------------------------------------------------------------+ 652 | TLS_ECDHE_BIKE_ECDSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x01 } | 653 | TLS_ECDHE_BIKE_ECDSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x02 } | 654 | TLS_ECDHE_BIKE_RSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x03 } | 655 | TLS_ECDHE_BIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x04 } | 656 | TLS_ECDHE_SIKE_ECDSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x05 } | 657 | TLS_ECDHE_SIKE_ECDSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x06 } | 658 | TLS_ECDHE_SIKE_RSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x07 } | 659 | TLS_ECDHE_SIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x08 } | 660 | TLS_ECDHE_KYBER_ECDSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x09 } | 661 | TLS_ECDHE_KYBER_ECDSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x0A } | 662 | TLS_ECDHE_KYBER_RSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x0B } | 663 | TLS_ECDHE_KYBER_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x0C } | 664 +----------------------------------------------------------------+ 666 The key exchange method, signature algorithm, cipher, and hash 667 algorithm for each of these cipher suites are easily determined by 668 examining the name. Ciphers and hash algorithms are defined in RFC 669 5288 [RFC5288]. 671 It is recommended that any implementation of this specification 672 include both of the following ciphersuites: 674 o TLS_ECDHE_BIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x04 } 676 o TLS_ECDHE_SIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x08 } 678 using the parameters BIKE1-CCA-L1-R2 and SIKE-P434-R2. 680 7. Security Considerations [DRAFT] 682 The security considerations in TLS 1.2 [RFC5246] and RFC 8422 683 [RFC8422] apply to this document as well. In addition, as described 684 in RFC 5288 [RFC5288] and RFC 5289 [RFC5289], these cipher suites may 685 only be used with TLS 1.2 or greater. 687 The description of a KEM is provided in [kems]. The security of the 688 KEM is defined through the indistinguishability against a chosen- 689 plaintext (IND-CPA) and against a chosen-ciphertext (IND-CCA) 690 adversary. We are focused here on the IND-CPA security of the KEM. 691 As a result, implementations MUST NOT use a KEM key more than once, 692 as reusing keys with IND-CPA KEMs can result in chosen ciphertext 693 attacks like the GJS attack against BIKE [GJS]. 695 In the IND-CPA experiment of KEMs, an oracle generates keys (sk, pk) 696 with "KeyGen()", computes (c, K) with "Encaps(pk)", and draws 697 uniformly at random a value R from the key space, and a random bit b. 698 The adversary is an algorithm A that is given (pk, c, K) if b=1, and 699 (pk, c, R) if b=0. Algorithm A outputs a bit b' as a guess for b, 700 and wins if b' = b. 702 All of the ciphersuites described in this document are intended to 703 provide forward secrecy. The hybrid key exchange mechanism described 704 in this specification achieves forward secrecy when all ephemeral 705 keys are single-use. This specification requires single-use PQ KEM 706 keys, so ephemeral ECDH keys SHOULD also be single-use so that 707 forward secrecy is achieved. 709 8. IANA Considerations 711 This document describes three new name spaces for use with the TLS 712 protocol: 714 9. Acknowledgements 716 This specification is based on ideas discussed with Ian Goldberg, 717 Michele Mosca, Douglas Stebila and William Whyte during preparations 718 for the first ETSI-IQC Quantum Safe Cryptography Workshop in 2013. 719 The specification was developed through collaboration on the open 720 source s2n project with Nicholas Allen, Nir Drucker, Shay Gueron, 721 Andrew Hopkins, Colm MacCarthaigh and Alex Weibel. 723 10. References 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 727 RFC2119, March 1997, . 730 [RFC8422] Nir, Y., Josefsson, S. and M. Pegourie-Gonnard, "Elliptic 731 Curve Cryptography (ECC) Cipher Suites for Transport Layer 732 Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 733 10.17487/RFC8422, August 2018, . 736 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 737 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 738 RFC5246, August 2008, . 741 [RFC5288] Salowey, J., Choudhury, A. and D. McGrew, "AES Galois 742 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, DOI 743 10.17487/RFC5288, August 2008, . 746 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with 747 SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 748 DOI 10.17487/RFC5289, August 2008, . 751 [GJS] Guo, Q, Johansson, T and P Stankovski, "A Key Recovery 752 Attack on MDPC with CCA Security Using Decoding Failures", 753 2016, . 755 [BIKEr1] Misoczki, R, Aragon, N, Barreto, P, Bettaieb, S, Bidoux, 756 L, Blazy, O, Deneuville, J, Gaborit, P, Gueron, S, 757 Guneysu, T, Melchor, C, Persichetti, E, Sendrier, N, 758 Tillich, J and G Zemor, "BIKE: Bit Flipping Key 759 Encapsulation", November 2017, . 762 [BIKEr2] Misoczki, R, Aragon, N, Barreto, P, Bettaieb, S, Bidoux, 763 L, Blazy, O, Deneuville, J, Gaborit, P, Gueron, S, 764 Guneysu, T, Melchor, C, Persichetti, E, Sendrier, N, 765 Tillich, J, Vasseur, V and G Zemor, "BIKE: Bit Flipping 766 Key Encapsulation, version 3.2 ", February 2020, . 770 [KYBERr2] Avanzi, R, Bos, J, Ducas, L, Kiltz, E, Lepoint, T, 771 Lyubashevsky, V, Schanck, J, Schwabe, P, Seiler, G and D 772 Stehle, "CRYSTALS-Kyber", March 2019, . 777 [SIKEr1] Jao, D, Azarderakhsh, R, Campagna, M, Costello, C, De Feo, 778 L, Hess, B, Jalali, A, Koziel, B, LaMacchia, B, Longa, P, 779 Naehrig, M, Renes, J, Soukharev, V and D Urbanik, 780 "Supersingular Isogeny Key Encapsulation", November 2017, 781 . 784 [SIKEr2] Jao, D, Azarderakhsh, R, Campagna, M, Costello, C, De Feo, 785 L, Hess, B, Jalali, A, Koziel, B, LaMacchia, B, Longa, P, 786 Naehrig, M, Pereira, G, Renes, J, Soukharev, V and D 787 Urbanik, "Supersingular Isogeny Key Encapsulation", April 788 2019, . 792 Appendix A. Additional Stuff 794 This becomes an Appendix. 796 Index 798 Authors' Addresses 800 Matt Campagna 801 AWS 803 Email: campagna@amazon.com 805 Eric Crockett 806 AWS 808 Email: ericcro@amazon.com