idnits 2.17.1 draft-ietf-tls-hybrid-design-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 359: '...in this document MUST explicitly be de...' RFC 2119 keyword, line 364: '... KEM public keys MUST ensure that the ...' RFC 2119 keyword, line 366: '...lyses. Implementations MUST NOT reuse...' RFC 2119 keyword, line 462: '... KeyShareEntry MUST be generated ind...' RFC 2119 keyword, line 467: '...erent algorithms MUST be generated ind...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (11 January 2022) is 829 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Stebila 3 Internet-Draft University of Waterloo 4 Intended status: Informational S. Fluhrer 5 Expires: 15 July 2022 Cisco Systems 6 S. Gueron 7 U. Haifa, Amazon Web Services 8 11 January 2022 10 Hybrid key exchange in TLS 1.3 11 draft-ietf-tls-hybrid-design-04 13 Abstract 15 Hybrid key exchange refers to using multiple key exchange algorithms 16 simultaneously and combining the result with the goal of providing 17 security even if all but one of the component algorithms is broken. 18 It is motivated by transition to post-quantum cryptography. This 19 document provides a construction for hybrid key exchange in the 20 Transport Layer Security (TLS) protocol version 1.3. 22 Discussion of this work is encouraged to happen on the TLS IETF 23 mailing list tls@ietf.org or on the GitHub repository which contains 24 the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 15 July 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Revision history . . . . . . . . . . . . . . . . . . . . 2 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.3. Motivation for use of hybrid key exchange . . . . . . . . 5 63 1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1.5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2. Key encapsulation mechanisms . . . . . . . . . . . . . . . . 7 66 3. Construction for hybrid key exchange . . . . . . . . . . . . 8 67 3.1. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.2. Transmitting public keys and ciphertexts . . . . . . . . 9 69 3.3. Shared secret calculation . . . . . . . . . . . . . . . . 11 70 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 8.2. Informative References . . . . . . . . . . . . . . . . . 14 77 Appendix A. Related work . . . . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 This document gives a construction for hybrid key exchange in TLS 83 1.3. The overall design approach is a simple, "concatenation"-based 84 approach: each hybrid key exchange combination should be viewed as a 85 single new key exchange method, negotiated and transmitted using the 86 existing TLS 1.3 mechanisms. 88 This document does not propose specific post-quantum mechanisms; see 89 Section 1.4 for more on the scope of this document. 91 1.1. Revision history 93 *RFC Editor's Note:* Please remove this section prior to 94 publication of a final version of this document. 96 Earlier versions of this document categorized various design 97 decisions one could make when implementing hybrid key exchange in TLS 98 1.3. 100 * Since draft-ietf-tls-hybrid-design-03: 102 - Some wording changes 104 - Remove design considerations appendix 106 * draft-ietf-tls-hybrid-design-03: 108 - Remove specific code point examples and requested codepoint 109 range for hybrid private use 111 - Change "Open questions" to "Discussion" 113 - Some wording changes 115 * draft-ietf-tls-hybrid-design-02: 117 - Bump to version -02 to avoid expiry 119 * draft-ietf-tls-hybrid-design-01: 121 - Forbid variable-length secret keys 123 - Use fixed-length KEM public keys/ciphertexts 125 * draft-ietf-tls-hybrid-design-00: 127 - Allow key_exchange values from the same algorithm to be reused 128 across multiple KeyShareEntry records in the same ClientHello. 130 * draft-stebila-tls-hybrid-design-03: 132 - Add requirement for KEMs to provide protection against key 133 reuse. 135 - Clarify FIPS-compliance of shared secret concatenation method. 137 * draft-stebila-tls-hybrid-design-02: 139 - Design considerations from draft-stebila-tls-hybrid-design-00 140 and draft-stebila-tls-hybrid-design-01 are moved to the 141 appendix. 143 - A single construction is given in the main body. 145 * draft-stebila-tls-hybrid-design-01: 147 - Add (Comb-KDF-1) and (Comb-KDF-2) options. 149 - Add two candidate instantiations. 151 * draft-stebila-tls-hybrid-design-00: Initial version. 153 1.2. Terminology 155 For the purposes of this document, it is helpful to be able to divide 156 cryptographic algorithms into two classes: 158 * "Traditional" algorithms: Algorithms which are widely deployed 159 today, but which may be deprecated in the future. In the context 160 of TLS 1.3 in 2019, examples of traditional key exchange 161 algorithms include elliptic curve Diffie-Hellman using secp256r1 162 or x25519, or finite-field Diffie-Hellman. 164 * "Next-generation" (or "next-gen") algorithms: Algorithms which are 165 not yet widely deployed, but which may eventually be widely 166 deployed. An additional facet of these algorithms may be that we 167 have less confidence in their security due to them being 168 relatively new or less studied. This includes "post-quantum" 169 algorithms. 171 "Hybrid" key exchange, in this context, means the use of two (or 172 more) key exchange algorithms based on different cryptographic 173 assumptions, e.g., one traditional algorithm and one next-gen 174 algorithm, with the purpose of the final session key being secure as 175 long as at least one of the component key exchange algorithms remains 176 unbroken. We use the term "component" algorithms to refer to the 177 algorithms combined in a hybrid key exchange. 179 We note that some authors prefer the phrase "composite" to refer to 180 the use of multiple algorithms, to distinguish from "hybrid public 181 key encryption" in which a key encapsulation mechanism and data 182 encapsulation mechanism are combined to create public key encryption. 184 The primary motivation of this document is preparing for post-quantum 185 algorithms. However, it is possible that public key cryptography 186 based on alternative mathematical constructions will be required 187 independent of the advent of a quantum computer, for example because 188 of a cryptanalytic breakthrough. As such we opt for the more generic 189 term "next-generation" algorithms rather than exclusively "post- 190 quantum" algorithms. 192 Note that TLS 1.3 uses the phrase "groups" to refer to key exchange 193 algorithms - for example, the supported_groups extension - since all 194 key exchange algorithms in TLS 1.3 are Diffie-Hellman-based. As a 195 result, some parts of this document will refer to data structures or 196 messages with the term "group" in them despite using a key exchange 197 algorithm that is not Diffie-Hellman-based nor a group. 199 1.3. Motivation for use of hybrid key exchange 201 A hybrid key exchange algorithm allows early adopters eager for post- 202 quantum security to have the potential of post-quantum security 203 (possibly from a less-well-studied algorithm) while still retaining 204 at least the security currently offered by traditional algorithms. 205 They may even need to retain traditional algorithms due to regulatory 206 constraints, for example FIPS compliance. 208 Ideally, one would not use hybrid key exchange: one would have 209 confidence in a single algorithm and parameterization that will stand 210 the test of time. However, this may not be the case in the face of 211 quantum computers and cryptanalytic advances more generally. 213 Many (though not all) post-quantum algorithms currently under 214 consideration are relatively new; they have not been subject to the 215 same depth of study as RSA and finite-field or elliptic curve Diffie- 216 Hellman, and thus the security community does not necessarily have as 217 much confidence in their fundamental security, or the concrete 218 security level of specific parameterizations. 220 Moreover, it is possible that after next-generation algorithms are 221 defined, and for a period of time thereafter, conservative users may 222 not have full confidence in some algorithms. 224 Some users may want to accelerate adoption of post-quantum 225 cryptography due the threat of retroactive decryption: if a 226 cryptographic assumption is broken due to the advent of a quantum 227 computer or some other cryptanalytic breakthrough, confidentiality of 228 information can be broken retroactively by any adversary who has 229 passively recorded handshakes and encrypted communications. Hybrid 230 key exchange enables potential security against retroactive 231 decryption while not fully abandoning classical cryptosystems. 233 As such, there may be users for whom hybrid key exchange is an 234 appropriate step prior to an eventual transition to next-generation 235 algorithms. 237 1.4. Scope 239 This document focuses on hybrid ephemeral key exchange in TLS 1.3 240 [TLS13]. It intentionally does not address: 242 * Selecting which next-generation algorithms to use in TLS 1.3, or 243 algorithm identifiers or encoding mechanisms for next-generation 244 algorithms. This selection will be based on the recommendations 245 by the Crypto Forum Research Group (CFRG), which is currently 246 waiting for the results of the NIST Post-Quantum Cryptography 247 Standardization Project [NIST]. 249 * Authentication using next-generation algorithms. While quantum 250 computers could retroactively decrypt previous sessions, session 251 authentication cannot be retroactively broken. 253 1.5. Goals 255 The primary goal of a hybrid key exchange mechanism is to facilitate 256 the establishment of a shared secret which remains secure as long as 257 as one of the component key exchange mechanisms remains unbroken. 259 In addition to the primary cryptographic goal, there may be several 260 additional goals in the context of TLS 1.3: 262 * *Backwards compatibility:* Clients and servers who are "hybrid- 263 aware", i.e., compliant with whatever hybrid key exchange standard 264 is developed for TLS, should remain compatible with endpoints and 265 middle-boxes that are not hybrid-aware. The three scenarios to 266 consider are: 268 1. Hybrid-aware client, hybrid-aware server: These parties should 269 establish a hybrid shared secret. 271 2. Hybrid-aware client, non-hybrid-aware server: These parties 272 should establish a traditional shared secret (assuming the 273 hybrid-aware client is willing to downgrade to traditional- 274 only). 276 3. Non-hybrid-aware client, hybrid-aware server: These parties 277 should establish a traditional shared secret (assuming the 278 hybrid-aware server is willing to downgrade to traditional- 279 only). 281 Ideally backwards compatibility should be achieved without extra 282 round trips and without sending duplicate information; see below. 284 * *High performance:* Use of hybrid key exchange should not be 285 prohibitively expensive in terms of computational performance. In 286 general this will depend on the performance characteristics of the 287 specific cryptographic algorithms used, and as such is outside the 288 scope of this document. See [PST] for preliminary results about 289 performance characteristics. 291 * *Low latency:* Use of hybrid key exchange should not substantially 292 increase the latency experienced to establish a connection. 293 Factors affecting this may include the following. 295 - The computational performance characteristics of the specific 296 algorithms used. See above. 298 - The size of messages to be transmitted. Public key and 299 ciphertext sizes for post-quantum algorithms range from 300 hundreds of bytes to over one hundred kilobytes, so this impact 301 can be substantial. See [PST] for preliminary results in a 302 laboratory setting, and [LANGLEY] for preliminary results on 303 more realistic networks. 305 - Additional round trips added to the protocol. See below. 307 * *No extra round trips:* Attempting to negotiate hybrid key 308 exchange should not lead to extra round trips in any of the three 309 hybrid-aware/non-hybrid-aware scenarios listed above. 311 * *Minimal duplicate information:* Attempting to negotiate hybrid 312 key exchange should not mean having to send multiple public keys 313 of the same type. 315 2. Key encapsulation mechanisms 317 This document models key agreement as key encapsulation mechanisms 318 (KEMs), which consist of three algorithms: 320 * KeyGen() -> (pk, sk): A probabilistic key generation algorithm, 321 which generates a public key pk and a secret key sk. 323 * Encaps(pk) -> (ct, ss): A probabilistic encapsulation algorithm, 324 which takes as input a public key pk and outputs a ciphertext ct 325 and shared secret ss. 327 * Decaps(sk, ct) -> ss: A decapsulation algorithm, which takes as 328 input a secret key sk and ciphertext ct and outputs a shared 329 secret ss, or in some cases a distinguished error value. 331 The main security property for KEMs is indistinguishability under 332 adaptive chosen ciphertext attack (IND-CCA2), which means that shared 333 secret values should be indistinguishable from random strings even 334 given the ability to have other arbitrary ciphertexts decapsulated. 335 IND-CCA2 corresponds to security against an active attacker, and the 336 public key / secret key pair can be treated as a long-term key or 337 reused. A common design pattern for obtaining security under key 338 reuse is to apply the Fujisaki-Okamoto (FO) transform [FO] or a 339 variant thereof [HHK]. 341 A weaker security notion is indistinguishability under chosen 342 plaintext attack (IND-CPA), which means that the shared secret values 343 should be indistinguishable from random strings given a copy of the 344 public key. IND-CPA roughly corresponds to security against a 345 passive attacker, and sometimes corresponds to one-time key exchange. 347 Key exchange in TLS 1.3 is phrased in terms of Diffie-Hellman key 348 exchange in a group. DH key exchange can be modeled as a KEM, with 349 KeyGen corresponding to selecting an exponent x as the secret key and 350 computing the public key g^x; encapsulation corresponding to 351 selecting an exponent y, computing the ciphertext g^y and the shared 352 secret g^(xy), and decapsulation as computing the shared secret 353 g^(xy). See [I-D.irtf-cfrg-hpke] for more details of such Diffie- 354 Hellman-based key encapsulation mechanisms. 356 TLS 1.3 does not require that ephemeral public keys be used only in a 357 single key exchange session; some implementations may reuse them, at 358 the cost of limited forward secrecy. As a result, any KEM used in 359 the manner described in this document MUST explicitly be designed to 360 be secure in the event that the public key is reused, such as 361 achieving IND-CCA2 security or having a transform like the Fujisaki- 362 Okamoto transform [FO] [HHK] applied. While it is recommended that 363 implementations avoid reuse of KEM public keys, implementations that 364 do reuse KEM public keys MUST ensure that the number of reuses of a 365 KEM public key abides by any bounds in the specification of the KEM 366 or subsequent security analyses. Implementations MUST NOT reuse 367 randomness in the generation of KEM ciphertexts. 369 3. Construction for hybrid key exchange 371 3.1. Negotiation 373 Each particular combination of algorithms in a hybrid key exchange 374 will be represented as a NamedGroup and sent in the supported_groups 375 extension. No internal structure or grammar is implied or required 376 in the value of the identifier; they are simply opaque identifiers. 378 Each value representing a hybrid key exchange will correspond to an 379 ordered pair of two algorithms. For example, a future document could 380 specify that one codepoint corresponds to secp256r1+PQALG1, and 381 another corresponds to x25519+PQALG1. (We note that this is 382 independent from future documents standardizing solely post-quantum 383 key exchange methods, which would have to be assigned their own 384 identifier.) 386 Specific values shall be standardized by IANA in the TLS Supported 387 Groups registry. 389 enum { 391 /* Elliptic Curve Groups (ECDHE) */ 392 secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), 393 x25519(0x001D), x448(0x001E), 395 /* Finite Field Groups (DHE) */ 396 ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), 397 ffdhe6144(0x0103), ffdhe8192(0x0104), 399 /* Hybrid Key Exchange Methods */ 400 TBD(0xTBD), ..., 402 /* Reserved Code Points */ 403 ffdhe_private_use(0x01FC..0x01FF), 404 ecdhe_private_use(0xFE00..0xFEFF), 405 (0xFFFF) 406 } NamedGroup; 408 3.2. Transmitting public keys and ciphertexts 410 We take the relatively simple "concatenation approach": the messages 411 from the two algorithms being hybridized will be concatenated 412 together and transmitted as a single value, to avoid having to change 413 existing data structures. The values are directly concatenated, 414 without any additional encoding or length fields; this assumes that 415 the representation and length of elements is fixed once the algorithm 416 is fixed. If concatenation were to be used with values that are not 417 fixed-length, a length prefix or other unambiguous encoding must be 418 used to ensure that the composition of the two values is injective 419 and requires a mechanism different from that specified in this 420 document. 422 Recall that in TLS 1.3 a KEM public key or KEM ciphertext is 423 represented as a KeyShareEntry: 425 struct { 426 NamedGroup group; 427 opaque key_exchange<1..2^16-1>; 428 } KeyShareEntry; 430 These are transmitted in the extension_data fields of 431 KeyShareClientHello and KeyShareServerHello extensions: 433 struct { 434 KeyShareEntry client_shares<0..2^16-1>; 435 } KeyShareClientHello; 437 struct { 438 KeyShareEntry server_share; 439 } KeyShareServerHello; 441 The client's shares are listed in descending order of client 442 preference; the server selects one algorithm and sends its 443 corresponding share. 445 For a hybrid key exchange, the key_exchange field of a KeyShareEntry 446 is the concatenation of the key_exchange field for each of the 447 constituent algorithms. The order of shares in the concatenation is 448 the same as the order of algorithms indicated in the definition of 449 the NamedGroup. 451 For the client's share, the key_exchange value contains the 452 concatenation of the pk outputs of the corresponding KEMs' KeyGen 453 algorithms, if that algorithm corresponds to a KEM; or the (EC)DH 454 ephemeral key share, if that algorithm corresponds to an (EC)DH 455 group. For the server's share, the key_exchange value contains 456 concatenation of the ct outputs of the corresponding KEMs' Encaps 457 algorithms, if that algorithm corresponds to a KEM; or the (EC)DH 458 ephemeral key share, if that algorithm corresponds to an (EC)DH 459 group. 461 [TLS13] requires that ``The key_exchange values for each 462 KeyShareEntry MUST be generated independently.'' In the context of 463 this document, since the same algorithm may appear in multiple named 464 groups, we relax the above requirement to allow the same key_exchange 465 value for the same algorithm to be reused in multiple KeyShareEntry 466 records sent in within the same ClientHello. However, key_exchange 467 values for different algorithms MUST be generated independently. 469 3.3. Shared secret calculation 471 Here we also take a simple "concatenation approach": the two shared 472 secrets are concatenated together and used as the shared secret in 473 the existing TLS 1.3 key schedule. Again, we do not add any 474 additional structure (length fields) in the concatenation procedure: 475 among all Round 3 finalists and alternate candidates, once the 476 algorithm and variant are specified, the shared secret output length 477 is fixed. 479 In other words, the shared secret is calculated as 481 concatenated_shared_secret = shared_secret_1 || shared_secret_2 483 and inserted into the TLS 1.3 key schedule in place of the (EC)DHE 484 shared secret: 486 0 487 | 488 v 489 PSK -> HKDF-Extract = Early Secret 490 | 491 +-----> Derive-Secret(...) 492 +-----> Derive-Secret(...) 493 +-----> Derive-Secret(...) 494 | 495 v 496 Derive-Secret(., "derived", "") 497 | 498 v 499 concatenated_shared_secret -> HKDF-Extract = Handshake Secret 500 ^^^^^^^^^^^^^^^^^^^^^^^^^^ | 501 +-----> Derive-Secret(...) 502 +-----> Derive-Secret(...) 503 | 504 v 505 Derive-Secret(., "derived", "") 506 | 507 v 508 0 -> HKDF-Extract = Master Secret 509 | 510 +-----> Derive-Secret(...) 511 +-----> Derive-Secret(...) 512 +-----> Derive-Secret(...) 513 +-----> Derive-Secret(...) 515 *FIPS-compliance of shared secret concatenation.* [NIST-SP-800-56C] 516 or [NIST-SP-800-135] give NIST recommendations for key derivation 517 methods in key exchange protocols. Some hybrid combinations may 518 combine the shared secret from a NIST-approved algorithm (e.g., ECDH 519 using the nistp256/secp256r1 curve) with a shared secret from a non- 520 approved algorithm (e.g., post-quantum). [NIST-SP-800-56C] lists 521 simple concatenation as an approved method for generation of a hybrid 522 shared secret in which one of the constituent shared secret is from 523 an approved method. 525 4. Discussion 527 *Larger public keys and/or ciphertexts.* The HybridKeyExchange struct 528 in Section 3.2 limits public keys and ciphertexts to 2^16-1 bytes; 529 this is bounded by the same (2^16-1)-byte limit on the key_exchange 530 field in the KeyShareEntry struct. Some post-quantum KEMs have 531 larger public keys and/or ciphertexts; for example, Classic 532 McEliece's smallest parameter set has public key size 261,120 bytes. 533 Hence this draft can not accommodate all current NIST Round 3 534 candidates. 536 *Duplication of key shares.* Concatenation of public keys in the 537 HybridKeyExchange struct as described in Section 3.2 can result in 538 sending duplicate key shares. For example, if a client wanted to 539 offer support for two combinations, say "secp256r1+sikep503" and 540 "x25519+sikep503", it would end up sending two sikep503 public keys, 541 since the KeyShareEntry for each combination contains its own copy of 542 a sikep503 key. This duplication may be more problematic for post- 543 quantum algorithms which have larger public keys. 545 *Failures.* Some post-quantum key exchange algorithms have non-zero 546 probability of failure, meaning two honest parties may derive 547 different shared secrets. This would cause a handshake failure. All 548 current NIST Round 3 candidates have either 0 or cryptographically 549 small failure rate; if other algorithms are used, implementers should 550 be aware of the potential of handshake failure. Clients can retry if 551 a failure is encountered. 553 5. IANA Considerations 555 Identifiers for specific key exchange algorithm combinations will be 556 defined in later documents. 558 6. Security Considerations 560 The shared secrets computed in the hybrid key exchange should be 561 computed in a way that achieves the "hybrid" property: the resulting 562 secret is secure as long as at least one of the component key 563 exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an 564 investigation of these issues. Under the assumption that shared 565 secrets are fixed length once the combination is fixed, the 566 construction from Section 3.3 corresponds to the dual-PRF combiner of 567 [BINDEL] which is shown to preserve security under the assumption 568 that the hash function is a dual-PRF. 570 As noted in Section 2, KEMs used in the manner described in this 571 document MUST explicitly be designed to be secure in the event that 572 the public key is reused, such as achieving IND-CCA2 security or 573 having a transform like the Fujisaki-Okamoto transform applied. Some 574 IND-CPA-secure post-quantum KEMs (i.e., without countermeasures such 575 as the FO transform) are completely insecure under public key reuse; 576 for example, some lattice-based IND-CPA-secure KEMs are vulnerable to 577 attacks that recover the private key after just a few thousand 578 samples [FLUHRER]. 580 *Public keys, ciphertexts, and secrets should be constant length.* 581 This document assumes that the length of each public key, ciphertext, 582 and shared secret is fixed once the algorithm is fixed. This is the 583 case for all Round 3 finalists and alternate candidates. 585 Note that variable-length secrets are, generally speaking, dangerous. 586 In particular, when using key material of variable length and 587 processing it using hash functions, a timing side channel may arise. 588 In broad terms, when the secret is longer, the hash function may need 589 to process more blocks internally. In some unfortunate 590 circumstances, this has led to timing attacks, e.g. the Lucky 591 Thirteen [LUCKY13] and Raccoon [RACCOON] attacks. 593 Furthermore, [AVIRAM] identified a risk of using variable-length 594 secrets when the hash function used in the key derivation function is 595 no longer collision-resistant. 597 Therefore, this specification MUST only be used with algorithms which 598 have fixed-length shared secrets (after the variant has been fixed by 599 the algorithm identifier in the NamedGroup negotiation in 600 Section 3.1). 602 7. Acknowledgements 604 These ideas have grown from discussions with many colleagues, 605 including Christopher Wood, Matt Campagna, Eric Crockett, authors of 606 the various hybrid Internet-Drafts and implementations cited in this 607 document, and members of the TLS working group. The immediate 608 impetus for this document came from discussions with attendees at the 609 Workshop on Post-Quantum Software in Mountain View, California, in 610 January 2019. Daniel J. Bernstein and Tanja Lange commented on the 611 risks of reuse of ephemeral public keys. Matt Campagna and the team 612 at Amazon Web Services provided additional suggestions. Nimrod 613 Aviram proposed restricting to fixed-length secrets. 615 8. References 617 8.1. Normative References 619 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 620 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 621 . 623 8.2. Informative References 625 [AVIRAM] Nimrod Aviram, ., Benjamin Dowling, ., Ilan Komargodski, 626 ., Kenny Paterson, ., Eyal Ronen, ., and . Eylon Yogev, 627 "[TLS] Combining Secrets in Hybrid Key Exchange in TLS 628 1.3", 1 September 2021, 629 . 632 [BCNS15] Bos, J., Costello, C., Naehrig, M., and D. Stebila, "Post- 633 Quantum Key Exchange for the TLS Protocol from the Ring 634 Learning with Errors Problem", 2015 IEEE Symposium on 635 Security and Privacy, DOI 10.1109/sp.2015.40, May 2015, 636 . 638 [BERNSTEIN] 639 "Post-Quantum Cryptography", Springer Berlin 640 Heidelberg book, DOI 10.1007/978-3-540-88702-7, 2009, 641 . 643 [BINDEL] Bindel, N., Brendel, J., Fischlin, M., Goncalves, B., and 644 D. Stebila, "Hybrid Key Encapsulation Mechanisms and 645 Authenticated Key Exchange", Post-Quantum Cryptography pp. 646 206-226, DOI 10.1007/978-3-030-25510-7_12, 2019, 647 . 649 [CAMPAGNA] Campagna, M. and E. Crockett, "Hybrid Post-Quantum Key 650 Encapsulation Methods (PQ KEM) for Transport Layer 651 Security 1.2 (TLS)", Work in Progress, Internet-Draft, 652 draft-campagna-tls-bike-sike-hybrid-07, 2 September 2021, 653 . 656 [CECPQ1] Braithwaite, M., "Experimenting with Post-Quantum 657 Cryptography", 7 July 2016, 658 . 661 [CECPQ2] Langley, A., "CECPQ2", 12 December 2018, 662 . 664 [DODIS] Dodis, Y. and J. Katz, "Chosen-Ciphertext Security of 665 Multiple Encryption", Theory of Cryptography pp. 188-209, 666 DOI 10.1007/978-3-540-30576-7_11, 2005, 667 . 669 [ETSI] Campagna, M., Ed. and . others, "Quantum safe cryptography 670 and security: An introduction, benefits, enablers and 671 challengers", ETSI White Paper No. 8 , June 2015, 672 . 675 [EVEN] Even, S. and O. Goldreich, "On the Power of Cascade 676 Ciphers", Advances in Cryptology pp. 43-50, 677 DOI 10.1007/978-1-4684-4730-9_4, 1984, 678 . 680 [EXTERN-PSK] 681 Housley, R., "TLS 1.3 Extension for Certificate-Based 682 Authentication with an External Pre-Shared Key", RFC 8773, 683 DOI 10.17487/RFC8773, March 2020, 684 . 686 [FLUHRER] Fluhrer, S., "Cryptanalysis of ring-LWE based key exchange 687 with key share reuse", Cryptology ePrint Archive, Report 688 2016/085 , January 2016, 689 . 691 [FO] Fujisaki, E. and T. Okamoto, "Secure Integration of 692 Asymmetric and Symmetric Encryption Schemes", Journal of 693 Cryptology Vol. 26, pp. 80-101, 694 DOI 10.1007/s00145-011-9114-1, December 2011, 695 . 697 [FRODO] Bos, J., Costello, C., Ducas, L., Mironov, I., Naehrig, 698 M., Nikolaenko, V., Raghunathan, A., and D. Stebila, 699 "Frodo: Take off the Ring! Practical, Quantum-Secure Key 700 Exchange from LWE", Proceedings of the 2016 ACM SIGSAC 701 Conference on Computer and Communications Security, 702 DOI 10.1145/2976749.2978425, October 2016, 703 . 705 [GIACON] Giacon, F., Heuer, F., and B. Poettering, "KEM Combiners", 706 Public-Key Cryptography - PKC 2018 pp. 190-218, 707 DOI 10.1007/978-3-319-76578-5_7, 2018, 708 . 710 [HARNIK] Harnik, D., Kilian, J., Naor, M., Reingold, O., and A. 711 Rosen, "On Robust Combiners for Oblivious Transfer and 712 Other Primitives", Lecture Notes in Computer Science pp. 713 96-113, DOI 10.1007/11426639_6, 2005, 714 . 716 [HHK] Hofheinz, D., Hovelmanns, K., and E. Kiltz, "A Modular 717 Analysis of the Fujisaki-Okamoto Transformation", Theory 718 of Cryptography pp. 341-371, 719 DOI 10.1007/978-3-319-70500-2_12, 2017, 720 . 722 [HOFFMAN] Hoffman, P., "The Transition from Classical to Post- 723 Quantum Cryptography", Work in Progress, Internet-Draft, 724 draft-hoffman-c2pq-07, 26 May 2020, 725 . 728 [I-D.irtf-cfrg-hpke] 729 Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 730 "Hybrid Public Key Encryption", Work in Progress, 731 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 732 . 735 [IKE-HYBRID] 736 Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S., 737 Geest, D. V., Garcia-Morchon, O., and V. Smyslov, 738 "Framework to Integrate Post-quantum Key Exchanges into 739 Internet Key Exchange Protocol Version 2 (IKEv2)", Work in 740 Progress, Internet-Draft, draft-tjhai-ipsecme-hybrid-qske- 741 ikev2-04, 9 July 2019, . 744 [IKE-PSK] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, 745 "Mixing Preshared Keys in the Internet Key Exchange 746 Protocol Version 2 (IKEv2) for Post-quantum Security", 747 RFC 8784, DOI 10.17487/RFC8784, June 2020, 748 . 750 [KIEFER] Kiefer, F. and K. Kwiatkowski, "Hybrid ECDHE-SIDH Key 751 Exchange for TLS", Work in Progress, Internet-Draft, 752 draft-kiefer-tls-ecdhe-sidh-00, 5 November 2018, 753 . 756 [LANGLEY] Langley, A., "Post-quantum confidentiality for TLS", 11 757 April 2018, . 760 [LUCKY13] Al Fardan, N.J. and K.G. Paterson, "Lucky Thirteen: 761 Breaking the TLS and DTLS record protocols", n.d., 762 . 765 [NIELSEN] Nielsen, M.A. and I.L. Chuang, "Quantum Computation and 766 Quantum Information", Cambridge University Press , 2000. 768 [NIST] National Institute of Standards and Technology (NIST), 769 "Post-Quantum Cryptography", n.d., 770 . 772 [NIST-SP-800-135] 773 National Institute of Standards and Technology (NIST), 774 "Recommendation for Existing Application-Specific Key 775 Derivation Functions", December 2011, 776 . 778 [NIST-SP-800-56C] 779 National Institute of Standards and Technology (NIST), 780 "Recommendation for Key-Derivation Methods in Key- 781 Establishment Schemes", August 2020, 782 . 784 [OQS-102] Open Quantum Safe Project, "OQS-OpenSSL-1-0-2_stable", 785 November 2018, . 788 [OQS-111] Open Quantum Safe Project, "OQS-OpenSSL-1-1-1_stable", 789 January 2022, . 792 [PST] Paquin, C., Stebila, D., and G. Tamvada, "Benchmarking 793 Post-quantum Cryptography in TLS", Post-Quantum 794 Cryptography pp. 72-91, DOI 10.1007/978-3-030-44223-1_5, 795 2020, . 797 [RACCOON] Merget, R., Brinkmann, M., Aviram, N., Somorovsky, J., 798 Mittmann, J., and J. Schwenk, "Raccoon Attack: Finding and 799 Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)", 800 September 2020, . 802 [S2N] Amazon Web Services, "Post-quantum TLS now supported in 803 AWS KMS", 4 November 2019, 804 . 807 [SCHANCK] Schanck, J. M. and D. Stebila, "A Transport Layer Security 808 (TLS) Extension For Establishing An Additional Shared 809 Secret", Work in Progress, Internet-Draft, draft-schanck- 810 tls-additional-keyshare-00, 17 April 2017, 811 . 814 [WHYTE12] Schanck, J. M., Whyte, W., and Z. Zhang, "Quantum-Safe 815 Hybrid (QSH) Ciphersuite for Transport Layer Security 816 (TLS) version 1.2", Work in Progress, Internet-Draft, 817 draft-whyte-qsh-tls12-02, 22 July 2016, 818 . 821 [WHYTE13] Whyte, W., Zhang, Z., Fluhrer, S., and O. Garcia-Morchon, 822 "Quantum-Safe Hybrid (QSH) Key Exchange for Transport 823 Layer Security (TLS) version 1.3", Work in Progress, 824 Internet-Draft, draft-whyte-qsh-tls13-06, 3 October 2017, 825 . 828 [XMSS] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. 829 Mohaisen, "XMSS: eXtended Merkle Signature Scheme", 830 RFC 8391, DOI 10.17487/RFC8391, May 2018, 831 . 833 [ZHANG] Zhang, R., Hanaoka, G., Shikata, J., and H. Imai, "On the 834 Security of Multiple Encryption or CCA-security+CCA- 835 security=CCA-security?", Public Key Cryptography - PKC 836 2004 pp. 360-374, DOI 10.1007/978-3-540-24632-9_26, 2004, 837 . 839 Appendix A. Related work 841 Quantum computing and post-quantum cryptography in general are 842 outside the scope of this document. For a general introduction to 843 quantum computing, see a standard textbook such as [NIELSEN]. For an 844 overview of post-quantum cryptography as of 2009, see [BERNSTEIN]. 845 For the current status of the NIST Post-Quantum Cryptography 846 Standardization Project, see [NIST]. For additional perspectives on 847 the general transition from classical to post-quantum cryptography, 848 see for example [ETSI] and [HOFFMAN], among others. 850 There have been several Internet-Drafts describing mechanisms for 851 embedding post-quantum and/or hybrid key exchange in TLS: 853 * Internet-Drafts for TLS 1.2: [WHYTE12], [CAMPAGNA] 855 * Internet-Drafts for TLS 1.3: [KIEFER], [SCHANCK], [WHYTE13] 857 There have been several prototype implementations for post-quantum 858 and/or hybrid key exchange in TLS: 860 * Experimental implementations in TLS 1.2: [BCNS15], [CECPQ1], 861 [FRODO], [OQS-102], [S2N] 863 * Experimental implementations in TLS 1.3: [CECPQ2], [OQS-111], 864 [PST] 866 These experimental implementations have taken an ad hoc approach and 867 not attempted to implement one of the drafts listed above. 869 Unrelated to post-quantum but still related to the issue of combining 870 multiple types of keying material in TLS is the use of pre-shared 871 keys, especially the recent TLS working group document on including 872 an external pre-shared key [EXTERN-PSK]. 874 Considering other IETF standards, there is work on post-quantum 875 preshared keys in IKEv2 [IKE-PSK] and a framework for hybrid key 876 exchange in IKEv2 [IKE-HYBRID]. The XMSS hash-based signature scheme 877 has been published as an informational RFC by the IRTF [XMSS]. 879 In the academic literature, [EVEN] initiated the study of combining 880 multiple symmetric encryption schemes; [ZHANG], [DODIS], and [HARNIK] 881 examined combining multiple public key encryption schemes, and 882 [HARNIK] coined the term "robust combiner" to refer to a compiler 883 that constructs a hybrid scheme from individual schemes while 884 preserving security properties. [GIACON] and [BINDEL] examined 885 combining multiple key encapsulation mechanisms. 887 Authors' Addresses 889 Douglas Stebila 890 University of Waterloo 892 Email: dstebila@uwaterloo.ca 894 Scott Fluhrer 895 Cisco Systems 897 Email: sfluhrer@cisco.com 899 Shay Gueron 900 University of Haifa and Amazon Web Services 902 Email: shay.gueron@gmail.com