Hybrid key exchange in TLS 1.3
University of Waterloo
dstebila@uwaterloo.ca
Cisco Systems
sfluhrer@cisco.com
University of Haifa and Amazon Web Services
shay.gueron@gmail.com
InternetDraft
Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to postquantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3.
Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draftietftlshybriddesign.
Introduction
This document gives a construction for hybrid key exchange in TLS 1.3. The overall design approach is a simple, "concatenation"based approach: each hybrid key exchange combination should be viewed as a single new key exchange method, negotiated and transmitted using the existing TLS 1.3 mechanisms.
This document does not propose specific postquantum mechanisms; see for more on the scope of this document.
Revision history

RFC Editor's Note: Please remove this section prior to publication of a final version of this document.
Earlier versions of this document categorized various design decisions one could make when implementing hybrid key exchange in TLS 1.3. These have been moved to the appendix of the current draft, and will be eventually be removed.

draftietftlshybriddesign03:
 Remove specific code point examples and requested codepoint range for hybrid private use
 Change "Open questions" to "Discussion"
 Some wording changes

draftietftlshybriddesign02:
 Bump to version 02 to avoid expiry

draftietftlshybriddesign01:
 Forbid variablelength secret keys
 Use fixedlength KEM public keys/ciphertexts

draftietftlshybriddesign00:
 Allow key_exchange values from the same algorithm to be reused across multiple KeyShareEntry records in the same ClientHello.

draftstebilatlshybriddesign03:
 Add requirement for KEMs to provide protection against key reuse.
 Clarify FIPScompliance of shared secret concatenation method.

draftstebilatlshybriddesign02:
 Design considerations from draftstebilatlshybriddesign00 and draftstebilatlshybriddesign01 are moved to the appendix.
 A single construction is given in the main body.

draftstebilatlshybriddesign01:
 Add (CombKDF1) and (CombKDF2) options.
 Add two candidate instantiations.
 draftstebilatlshybriddesign00: Initial version.
Terminology
For the purposes of this document, it is helpful to be able to divide cryptographic algorithms into two classes:
 "Traditional" algorithms: Algorithms which are widely deployed today, but which may be deprecated in the future. In the context of TLS 1.3 in 2019, examples of traditional key exchange algorithms include elliptic curve DiffieHellman using secp256r1 or x25519, or finitefield DiffieHellman.
 "Nextgeneration" (or "nextgen") algorithms: Algorithms which are not yet widely deployed, but which may eventually be widely deployed. An additional facet of these algorithms may be that we have less confidence in their security due to them being relatively new or less studied. This includes "postquantum" algorithms.
"Hybrid" key exchange, in this context, means the use of two (or more) key exchange algorithms based on different cryptographic assumptions, e.g., one traditional algorithm and one nextgen algorithm, with the purpose of the final session key being secure as long as at least one of the component key exchange algorithms remains unbroken. We use the term "component" algorithms to refer to the algorithms combined in a hybrid key exchange.
We note that some authors prefer the phrase "composite" to refer to the use of multiple algorithms, to distinguish from "hybrid public key encryption" in which a key encapsulation mechanism and data encapsulation mechanism are combined to create public key encryption.
The primary motivation of this document is preparing for postquantum algorithms. However, it is possible that public key cryptography based on alternative mathematical constructions will be required independent of the advent of a quantum computer, for example because of a cryptanalytic breakthrough. As such we opt for the more generic term "nextgeneration" algorithms rather than exclusively "postquantum" algorithms.
Note that TLS 1.3 uses the phrase "groups" to refer to key exchange algorithms  for example, the supported_groups extension  since all key exchange algorithms in TLS 1.3 are DiffieHellmanbased. As a result, some parts of this document will refer to data structures or messages with the term "group" in them despite using a key exchange algorithm that is not DiffieHellmanbased nor a group.
Motivation for use of hybrid key exchange
A hybrid key exchange algorithm allows early adopters eager for postquantum security to have the potential of postquantum security (possibly from a lesswellstudied algorithm) while still retaining at least the security currently offered by traditional algorithms. They may even need to retain traditional algorithms due to regulatory constraints, for example FIPS compliance.
Ideally, one would not use hybrid key exchange: one would have confidence in a single algorithm and parameterization that will stand the test of time. However, this may not be the case in the face of quantum computers and cryptanalytic advances more generally.
Many (though not all) postquantum algorithms currently under consideration are relatively new; they have not been subject to the same depth of study as RSA and finitefield or elliptic curve DiffieHellman, and thus the security community does not necessarily have as much confidence in their fundamental security, or the concrete security level of specific parameterizations.
Moreover, it is possible that after nextgeneration algorithms are defined, and for a period of time thereafter, conservative users may not have full confidence in some algorithms.
As such, there may be users for whom hybrid key exchange is an appropriate step prior to an eventual transition to nextgeneration algorithms.
Scope
This document focuses on hybrid ephemeral key exchange in TLS 1.3 . It intentionally does not address:
 Selecting which nextgeneration algorithms to use in TLS 1.3, nor algorithm identifiers nor encoding mechanisms for nextgeneration algorithms. This selection will be based on the recommendations by the Crypto Forum Research Group (CFRG), which is currently waiting for the results of the NIST PostQuantum Cryptography Standardization Project .
 Authentication using nextgeneration algorithms. If a cryptographic assumption is broken due to the advent of a quantum computer or some other cryptanalytic breakthrough, confidentiality of information can be broken retroactively by any adversary who has passively recorded handshakes and encrypted communications. In contrast, session authentication cannot be retroactively broken.
Goals
The primary goal of a hybrid key exchange mechanism is to facilitate the establishment of a shared secret which remains secure as long as as one of the component key exchange mechanisms remains unbroken.
In addition to the primary cryptographic goal, there may be several additional goals in the context of TLS 1.3:

Backwards compatibility: Clients and servers who are "hybridaware", i.e., compliant with whatever hybrid key exchange standard is developed for TLS, should remain compatible with endpoints and middleboxes that are not hybridaware. The three scenarios to consider are:
 Hybridaware client, hybridaware server: These parties should establish a hybrid shared secret.
 Hybridaware client, nonhybridaware server: These parties should establish a traditional shared secret (assuming the hybridaware client is willing to downgrade to traditionalonly).
 Nonhybridaware client, hybridaware server: These parties should establish a traditional shared secret (assuming the hybridaware server is willing to downgrade to traditionalonly).
Ideally backwards compatibility should be achieved without extra round trips and without sending duplicate information; see below.

High performance: Use of hybrid key exchange should not be prohibitively expensive in terms of computational performance. In general this will depend on the performance characteristics of the specific cryptographic algorithms used, and as such is outside the scope of this document. See , , for preliminary results about performance characteristics.

Low latency: Use of hybrid key exchange should not substantially increase the latency experienced to establish a connection. Factors affecting this may include the following.
 The computational performance characteristics of the specific algorithms used. See above.
 The size of messages to be transmitted. Public key and ciphertext sizes for postquantum algorithms range from hundreds of bytes to over one hundred kilobytes, so this impact can be substantial. See , for preliminary results in a laboratory setting, and for preliminary results on more realistic networks.
 Additional round trips added to the protocol. See below.

No extra round trips: Attempting to negotiate hybrid key exchange should not lead to extra round trips in any of the three hybridaware/nonhybridaware scenarios listed above.

Minimal duplicate information: Attempting to negotiate hybrid key exchange should not mean having to send multiple public keys of the same type.
Key encapsulation mechanisms
This document models key agreement as key encapsulation mechanisms (KEMs), which consist of three algorithms:

KeyGen() > (pk, sk): A probabilistic key generation algorithm, which generates a public key pk and a secret key sk.

Encaps(pk) > (ct, ss): A probabilistic encapsulation algorithm, which takes as input a public key pk and outputs a ciphertext ct and shared secret ss.

Decaps(sk, ct) > ss: A decapsulation algorithm, which takes as input a secret key sk and ciphertext ct and outputs a shared secret ss, or in some cases a distinguished error value.
The main security property for KEMs is indistinguishability under adaptive chosen ciphertext attack (INDCCA2), which means that shared secret values should be indistinguishable from random strings even given the ability to have arbitrary ciphertexts decapsulated. INDCCA2 corresponds to security against an active attacker, and the public key / secret key pair can be treated as a longterm key or reused. A common design pattern for obtaining security under key reuse is to apply the FujisakiOkamoto (FO) transform or a variant thereof .
A weaker security notion is indistinguishability under chosen plaintext attack (INDCPA), which means that the shared secret values should be indistinguishable from random strings given a copy of the public key. INDCPA roughly corresponds to security against a passive attacker, and sometimes corresponds to onetime key exchange.
Key exchange in TLS 1.3 is phrased in terms of DiffieHellman key exchange in a group. DH key exchange can be modeled as a KEM, with KeyGen corresponding to selecting an exponent x as the secret key and computing the public key g^x; encapsulation corresponding to selecting an exponent y, computing the ciphertext g^y and the shared secret g^(xy), and decapsulation as computing the shared secret g^(xy). See for more details of such DiffieHellmanbased key encapsulation mechanisms.
TLS 1.3 does not require that ephemeral public keys be used only in a single key exchange session; some implementations may reuse them, at the cost of limited forward secrecy. As a result, any KEM used in the manner described in this document MUST explicitly be designed to be secure in the event that the public key is reused, such as achieving INDCCA2 security or having a transform like the FujisakiOkamoto transform applied. While it is recommended that implementations avoid reuse of KEM public keys, implementations that do reuse KEM public keys MUST ensure that the number of reuses of a KEM public key abides by any bounds in the specification of the KEM or subsequent security analyses. Implementations MUST NOT reuse randomness in the generation of KEM ciphertexts.
Construction for hybrid key exchange
Negotiation
Each particular combination of algorithms in a hybrid key exchange will be represented as a NamedGroup and sent in the supported_groups extension. No internal structure or grammar is implied or required in the value of the identifier; they are simply opaque identifiers.
Each value representing a hybrid key exchange will correspond to an ordered pair of two algorithms. For example, a future document could specify that one codepoint corresponds to secp256r1+ntruhrss701, and another corresponds to x25519+ntruhrss701. (We note that this is independent from future documents standardizing solely postquantum key exchange methods, which would have to be assigned their own identifier.)
Specific values shall be standardized by IANA in the TLS Supported Groups registry.
Transmitting public keys and ciphertexts
We take the relatively simple "concatenation approach": the messages from the two algorithms being hybridized will be concatenated together and transmitted as a single value, to avoid having to change existing data structures. The values are directly concatenated, without any additional encoding or length fields; this assumes that the representation and length of elements is fixed once the algorithm is fixed. If concatenation were to be used with values that are not fixedlength, a length prefix or other unambiguous encoding must be used to ensure that the composition of the two values is injective. See for a discussion of the concatenation combiner.
Recall that in TLS 1.3 a KEM public key or KEM ciphertext is represented as a KeyShareEntry:
;
} KeyShareEntry;
]]>
These are transmitted in the extension_data fields of KeyShareClientHello and KeyShareServerHello extensions:
;
} KeyShareClientHello;
struct {
KeyShareEntry server_share;
} KeyShareServerHello;
]]>
The client's shares are listed in descending order of client preference; the server selects one algorithm and sends its corresponding share.
For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the concatenation of the key_exchange field for each of the constituent algorithms. The order of shares in the concatenation is the same as the order of algorithms indicated in the definition of the NamedGroup.
For the client's share, the key_exchange are the pk outputs of the corresponding KEMs' KeyGen algorithms, if that algorithm corresponds to a KEM; or the (EC)DH ephemeral key share, if that algorithm corresponds to an (EC)DH group. For the server's share, the key_exchange values are the ct outputs of the corresponding KEMs' Encaps algorithms, if that algorithm corresponds to a KEM; or the (EC)DH ephemeral key share, if that algorithm corresponds to an (EC)DH group.
requires that ``The key_exchange values for each KeyShareEntry MUST be generated independently.'' In the context of this document, since the same algorithm may appear in multiple named groups, we relax the above requirement to allow the same key_exchange value for the same algorithm to be reused in multiple KeyShareEntry records sent in within the same ClientHello. However, key_exchange values for different algorithms MUST be generated independently.
Shared secret calculation
Here we also take a simple "concatenation approach": the two shared secrets are concatenated together and used as the shared secret in the existing TLS 1.3 key schedule. Again, we do not add any additional structure (length fields) in the concatenation procedure: among all Round 3 finalists and alternate candidates, once the algorithm and variant are specified, the shared secret output length is fixed.
In other words, the shared secret is calculated as
and inserted into the TLS 1.3 key schedule in place of the (EC)DHE shared secret:
HKDFExtract = Early Secret

+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)

v
DeriveSecret(., "derived", "")

v
concatenated_shared_secret > HKDFExtract = Handshake Secret
^^^^^^^^^^^^^^^^^^^^^^^^^^ 
+> DeriveSecret(...)
+> DeriveSecret(...)

v
DeriveSecret(., "derived", "")

v
0 > HKDFExtract = Master Secret

+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)
]]>
FIPScompliance of shared secret concatenation.
or give NIST recommendations for key derivation methods in key exchange protocols. Some hybrid combinations may combine the shared secret from a NISTapproved algorithm (e.g., ECDH using the nistp256/secp256r1 curve) with a shared secret from a nonapproved algorithm (e.g., postquantum). lists simple concatenation as an approved method for generation of a hybrid shared secret in which one of the constituent shared secret is from an approved method.
Discussion
Larger public keys and/or ciphertexts.
The HybridKeyExchange struct in limits public keys and ciphertexts to 2^161 bytes; this is bounded by the same (2^161)byte limit on the key_exchange field in the KeyShareEntry struct. Some postquantum KEMs have larger public keys and/or ciphertexts; for example, Classic McEliece's smallest parameter set has public key size 261,120 bytes. Hence this draft can not accommodate all current NIST Round 3 candidates.
Duplication of key shares.
Concatenation of public keys in the HybridKeyExchange struct as described in can result in sending duplicate key shares. For example, if a client wanted to offer support for two combinations, say "secp256r1+sikep503" and "x25519+sikep503", it would end up sending two sikep503 public keys, since the KeyShareEntry for each combination contains its own copy of a sikep503 key. This duplication may be more problematic for postquantum algorithms which have larger public keys.
Failures.
Some postquantum key exchange algorithms have nonzero probability of failure, meaning two honest parties may derive different shared secrets. This would cause a handshake failure. All current NIST Round 3 candidates have either 0 or cryptographically small failure rate; if other algorithms are used, implementers should be aware of the potential of handshake failure. Clients can retry if a failure is encountered.
IANA Considerations
Identifiers for specific key exchange algorithm combinations will be defined in later documents.
Security Considerations
The shared secrets computed in the hybrid key exchange should be computed in a way that achieves the "hybrid" property: the resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken. See and for an investigation of these issues. Under the assumption that shared secrets are fixed length once the combination is fixed, the construction from corresponds to the dualPRF combiner of which is shown to preserve security under the assumption that the hash function is a dualPRF.
As noted in , KEMs used in the manner described in this document MUST explicitly be designed to be secure in the event that the public key is reused, such as achieving INDCCA2 security or having a transform like the FujisakiOkamoto transform applied. Some INDCPAsecure postquantum KEMs (i.e., without countermeasures such as the FO transform) are completely insecure under public key reuse; for example, some latticebased INDCPAsecure KEMs are vulnerable to attacks that recover the private key after just a few thousand samples .
Public keys, ciphertexts, and secrets should be constant length.
This document assumes that the length of each public key, ciphertext, and shared secret is fixed once the algorithm is fixed. This is the case for all Round 3 finalists and alternate candidates.
Note that variablelength secrets are, generally speaking, dangerous. In particular, when using key material of variable length and processing it using hash functions, a timing side channel may arise. In broad terms, when the secret is longer, the hash function may need to process more blocks internally. In some unfortunate circumstances, this has led to timing attacks, e.g. the Lucky Thirteen and Raccoon attacks.
Therefore, this specification MUST only be used with algorithms which have fixedlength shared secrets (after the variant has been fixed by the algorithm identifier in the NamedGroup negotiation in ).
Acknowledgements
These ideas have grown from discussions with many colleagues, including Christopher Wood, Matt Campagna, Eric Crockett, authors of the various hybrid InternetDrafts and implementations cited in this document, and members of the TLS working group. The immediate impetus for this document came from discussions with attendees at the Workshop on PostQuantum Software in Mountain View, California, in January 2019. Martin Thomson suggested the (CombKDF1) approach. Daniel J. Bernstein and Tanja Lange commented on the risks of reuse of ephemeral public keys. Matt Campagna and the team at Amazon Web Services provided additional suggestions. Nimrod Aviram proposed restricting to fixedlength secrets.
References
Normative References
The Transport Layer Security (TLS) Protocol Version 1.3
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.
Informative References
PostQuantum Key Exchange for the TLS Protocol from the Ring Learning with Errors Problem
PostQuantum Cryptography
Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange
Hybrid PostQuantum Key Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2 (TLS)
AWS
AWS
Hybrid key exchange refers to executing two independent key exchanges
and feeding the two resulting shared secrets into a Pseudo Random
Function (PRF), with the goal of deriving a secret which is as secure
as the stronger of the two key exchanges. This document describes
new hybrid key exchange schemes for the Transport Layer Security 1.2
(TLS) protocol. The key exchange schemes are based on combining
Elliptic Curve DiffieHellman (ECDH) with a postquantum key
encapsulation method (PQ KEM) using the existing TLS PRF.
Experimenting with PostQuantum Cryptography
CECPQ2
ChosenCiphertext Security of Multiple Encryption
Quantum safe cryptography and security: An introduction, benefits, enablers and challengers
On the Power of Cascade Ciphers
TLS 1.3 Extension for CertificateBased Authentication with an External PreShared Key
This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external preshared key (PSK).
Cryptanalysis of ringLWE based key exchange with key share reuse
Secure Integration of Asymmetric and Symmetric Encryption Schemes
Frodo: Take off the Ring! Practical, QuantumSecure Key Exchange from LWE
KEM Combiners
On Robust Combiners for Oblivious Transfer and Other Primitives
The Transition from Classical to PostQuantum Cryptography
ICANN
Quantum computing is the study of computers that use quantum features
in calculations. For over 20 years, it has been known that if very
large, specialized quantum computers could be built, they could have
a devastating effect on asymmetric classical cryptographic algorithms
such as RSA and elliptic curve signatures and key exchange, as well
as (but in smaller scale) on symmetric cryptographic algorithms such
as block ciphers, MACs, and hash functions. There has already been a
great deal of study on how to create algorithms that will resist
large, specialized quantum computers, but so far, the properties of
those algorithms make them onerous to adopt before they are needed.
Small quantum computers are being built today, but it is still far
from clear when large, specialized quantum computers will be built
that can recover private or secret keys in classical algorithms at
the key sizes commonly used today. It is important to be able to
predict when large, specialized quantum computers usable for
cryptanalysis will be possible so that organization can change to
postquantum cryptographic algorithms well before they are needed.
This document describes quantum computing, how it might be used to
attack classical cryptographic algorithms, and possibly how to
predict when large, specialized quantum computers will become
feasible.
A Modular Analysis of the FujisakiOkamoto Transformation
Framework to Integrate Postquantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2)
PostQuantum
PostQuantum
Cisco Systems
Cisco Systems
ISARA Corporation
Philips
ELVISPLUS
This document describes how to extend Internet Key Exchange Protocol
Version 2 (IKEv2) so that the shared secret exchanged between peers
has resistance against quantum computer attacks. The basic idea is
to exchange one or more postquantum key exchange payloads in
conjunction with the existing (Elliptic Curve) DiffieHellman
payload.
Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Postquantum Security
The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantumsecure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys.
Hybrid ECDHESIDH Key Exchange for TLS
Mozilla
Cloudflare
This draft specifies a TLS key exchange that combines the post
quantum key exchange, Supersingular elliptic curve isogenie diffie
hellman (SIDH), with elliptic curve DiffieHellman (ECDHE) key
exchange.
Postquantum confidentiality for TLS
Lucky Thirteen: Breaking the TLS and DTLS record protocols
n.d.
Quantum Computation and Quantum Information
PostQuantum Cryptography
National Institute of Standards and Technology (NIST)
n.d.
Recommendation for KeyDerivation Methods in KeyEstablishment Schemes
National Institute of Standards and Technology (NIST)
Recommendation for Existing ApplicationSpecific Key Derivation Functions
National Institute of Standards and Technology (NIST)
OQSOpenSSL102_stable
Open Quantum Safe Project
OQSOpenSSL111_stable
Open Quantum Safe Project
Raccoon Attack: Finding and Exploiting MostSignificantBitOracles in TLSDH(E)
Postquantum TLS now supported in AWS KMS
Amazon Web Services
A Transport Layer Security (TLS) Extension For Establishing An Additional Shared Secret
This document defines a Transport Layer Security (TLS) extension that
allows parties to establish an additional shared secret using a
second key exchange algorithm and incorporates this shared secret
into the TLS key schedule.
QuantumSafe Hybrid (QSH) Ciphersuite for Transport Layer Security (TLS) version 1.2
This document describes the QuantumSafe Hybrid ciphersuite, a new
cipher suite providing modular design for quantumsafe cryptography
to be adopted in the handshake for the Transport Layer Security (TLS)
protocol version 1.2. In particular, it specifies the use of the
NTRUEncrypt encryption scheme in a TLS handshake.
QuantumSafe Hybrid (QSH) Key Exchange for Transport Layer Security (TLS) version 1.3
Onboard Security
Onboard Security
Cisco Systems
Philips
This document describes the QuantumSafe Hybrid Key Exchange, a
mechanism for providing modular design for quantumsafe cryptography
to be adopted in the handshake for the Transport Layer Security (TLS)
protocol version 1.3.
XMSS: eXtended Merkle Signature Scheme
This note describes the eXtended Merkle Signature Scheme (XMSS), a hashbased digital signature system that is based on existing descriptions in scientific literature. This note specifies Winternitz OneTime Signature Plus (WOTS+), a onetime signature scheme; XMSS, a singletree scheme; and XMSS^MT, a multitree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists sidechannel attacks. Unlike most other signature systems, hashbased signatures can so far withstand known attacks using quantum computers.
On the Security of Multiple Encryption or CCAsecurity+CCAsecurity=CCAsecurity?
Hybrid Public Key Encryption
Cisco
Inria
Inria
Cloudflare
This document describes a scheme for hybrid publickey encryption
(HPKE). This scheme provides a variant of publickey encryption of
arbitrarysized plaintexts for a recipient public key. It also
includes three authenticated variants, including one which
authenticates possession of a preshared key, and two optional ones
which authenticate possession of a KEM private key. HPKE works for
any combination of an asymmetric key encapsulation mechanism (KEM),
key derivation function (KDF), and authenticated encryption with
additional data (AEAD) encryption function. Some authenticated
variants may not be supported by all KEMs. We provide instantiations
of the scheme using widely used and efficient primitives, such as
Elliptic Curve DiffieHellman key agreement, HKDF, and SHA2.
This document is a product of the Crypto Forum Research Group (CFRG)
in the IRTF.
Related work
Quantum computing and postquantum cryptography in general are outside the scope of this document. For a general introduction to quantum computing, see a standard textbook such as . For an overview of postquantum cryptography as of 2009, see . For the current status of the NIST PostQuantum Cryptography Standardization Project, see . For additional perspectives on the general transition from classical to postquantum cryptography, see for example and , among others.
There have been several InternetDrafts describing mechanisms for embedding postquantum and/or hybrid key exchange in TLS:
 InternetDrafts for TLS 1.2: ,
 InternetDrafts for TLS 1.3: , ,
There have been several prototype implementations for postquantum and/or hybrid key exchange in TLS:
 Experimental implementations in TLS 1.2: , , , ,
 Experimental implementations in TLS 1.3: ,
These experimental implementations have taken an ad hoc approach and not attempted to implement one of the drafts listed above.
Unrelated to postquantum but still related to the issue of combining multiple types of keying material in TLS is the use of preshared keys, especially the recent TLS working group document on including an external preshared key .
Considering other IETF standards, there is work on postquantum preshared keys in IKEv2 and a framework for hybrid key exchange in IKEv2 . The XMSS hashbased signature scheme has been published as an informational RFC by the IRTF .
In the academic literature, initiated the study of combining multiple symmetric encryption schemes; , , and examined combining multiple public key encryption schemes, and coined the term "robust combiner" to refer to a compiler that constructs a hybrid scheme from individual schemes while preserving security properties. and examined combining multiple key encapsulation mechanisms.
Design Considerations
This appendix discusses choices one could make along four distinct axes when integrating hybrid key exchange into TLS 1.3:
 How to negotiate the use of hybridization in general and component algorithms specifically?
 How many component algorithms can be combined?
 How should multiple key shares (public keys / ciphertexts) be conveyed?
 How should multiple shared secrets be combined?
The construction in the main body illustrates one selection along each of these axes. The remainder of this appendix outlines various options we have identified for each of these choices. Immediately below we provide a summary list. Options are labelled with a short code in parentheses to provide easy crossreferencing.

(Neg) How to negotiate the use of hybridization in general and component algorithms specifically?

(NegInd) Negotiating component algorithms individually

(NegInd1) Traditional algorithms in ClientHello supported_groups extension, nextgen algorithms in another extension

(NegInd2) Both types of algorithms in supported_groups with external mapping to tradition/nextgen.

(NegInd3) Both types of algorithms in supported_groups separated by a delimiter.

(NegComb) Negotiating component algorithms as a combination

(NegComb1) Standardize NamedGroup identifiers for each desired combination.

(NegComb2) Use placeholder identifiers in supported_groups with an extension defining the combination corresponding to each placeholder.

(NegComb3) List combinations by inserting grouping delimiters into supported_groups list.

(Num) How many component algorithms can be combined?

(Num2) Two.

(Num2+) Two or more.

(Shares) How should multiple key shares (public keys / ciphertexts) be conveyed?

(SharesConcat) Concatenate each combination of key shares.

(SharesMultiple) Send individual key shares for each algorithm.

(SharesExtAdditional) Use an extension to convey key shares for component algorithms.

(Comb) How should multiple shared secrets be combined?

(CombConcat) Concatenate the shared secrets then use directly in the TLS 1.3 key schedule.

(CombKDF1) and (CombKDF2) KDF the shared secrets together, then use the output in the TLS 1.3 key schedule.

(CombXOR) XOR the shared secrets then use directly in the TLS 1.3 key schedule.

(CombChain) Extend the TLS 1.3 key schedule so that there is a stage of the key schedule for each shared secret.

(CombAltInput) Use the second shared secret in an alternate (otherwise unused) input in the TLS 1.3 key schedule.
(Neg) How to negotiate hybridization and component algorithms?
Key exchange negotiation in TLS 1.3
Recall that in TLS 1.3, the key exchange mechanism is negotiated via the supported_groups extension. The NamedGroup enum is a list of standardized groups for DiffieHellman key exchange, such as secp256r1, x25519, and ffdhe2048.
The client, in its ClientHello message, lists its supported mechanisms in the supported_groups extension. The client also optionally includes the public key of one or more of these groups in the key_share extension as a guess of which mechanisms the server might accept in hopes of reducing the number of round trips.
If the server is willing to use one of the client's requested mechanisms, it responds with a key_share extension containing its public key for the desired mechanism.
If the server is not willing to use any of the client's requested mechanisms, the server responds with a HelloRetryRequest message that includes an extension indicating its preferred mechanism.
(NegInd) Negotiating component algorithms individually
In these three approaches, the parties negotiate which traditional algorithm and which nextgen algorithm to use independently. The NamedGroup enum is extended to include algorithm identifiers for each nextgen algorithm.
(NegInd1)
The client advertises two lists to the server: one list containing its supported traditional mechanisms (e.g. via the existing ClientHello supported_groups extension), and a second list containing its supported nextgeneration mechanisms (e.g., via an additional ClientHello extension). A server could then select one algorithm from the traditional list, and one algorithm from the nextgeneration list. (This is the approach in .)
(NegInd2)
The client advertises a single list to the server which contains both its traditional and nextgeneration mechanisms (e.g., all in the existing ClientHello supported_groups extension), but with some external table provides a standardized mapping of those mechanisms as either "traditional" or "nextgeneration". A server could then select two algorithms from this list, one from each category.
(NegInd3)
The client advertises a single list to the server delimited into sublists: one for its traditional mechanisms and one for its nextgeneration mechanisms, all in the existing ClientHello supported_groups extension, with a special code point serving as a delimiter between the two lists. For example, supported_groups = secp256r1, x25519, delimiter, nextgen1, nextgen4.
(NegComb) Negotiating component algorithms as a combination
In these three approaches, combinations of key exchange mechanisms appear as a single monolithic block; the parties negotiate which of several combinations they wish to use.
(NegComb1)
The NamedGroup enum is extended to include algorithm identifiers for each combination of algorithms desired by the working group. There is no "internal structure" to the algorithm identifiers for each combination, they are simply new code points assigned arbitrarily. The client includes any desired combinations in its ClientHello supported_groups list, and the server picks one of these. This is the approach in and .
(NegComb2)
The NamedGroup enum is extended to include algorithm identifiers for each nextgen algorithm. Some additional field/extension is used to convey which combinations the parties wish to use. For example, in , there are distinguished NamedGroup called hybrid_marker 0, hybrid_marker 1, hybrid_marker 2, etc. This is complemented by a HybridExtension which contains mappings for each numbered hybrid_marker to the set of component key exchange algorithms (2 or more) for that proposed combination.
(NegComb3)
The client lists combinations in supported_groups list, using a special delimiter to indicate combinations. For example,
supported_groups = combo_delimiter, secp256r1, nextgen1, combo_delimiter, secp256r1, nextgen4, standalone_delimiter, secp256r1, x25519 would indicate that the client's highest preference is the combination secp256r1+nextgen1, the next highest preference is the combination secp2561+nextgen4, then the single algorithm secp256r1, then the single algorithm x25519. A hybridaware server would be able to parse these; a hybridunaware server would see unknown, secp256r1, unknown, unknown, secp256r1, unknown, unknown, secp256r1, x25519, which it would be able to process, although there is the potential that every "projection" of a hybrid list that is tolerable to a client does not result in list that is tolerable to the client.
Benefits and drawbacks
Combinatorial explosion. (NegComb1) requires new identifiers to be defined for each desired combination. The other 4 options in this section do not.
Extensions. (NegInd1) and (NegComb2) require new extensions to be defined. The other options in this section do not.
New logic. All options in this section except (NegComb1) require new logic to process negotiation.
Matching security levels. (NegInd1), (NegInd2), (NegInd3), and (NegComb2) allow algorithms of different claimed security level from their corresponding lists to be combined. For example, this could result in combining ECDH secp256r1 (classical security level 128) with NewHope1024 (classical security level 256). Implementations dissatisfied with a mismatched security levels must either accept this mismatch or attempt to renegotiate. (NegInd1), (NegInd2), and (NegInd3) give control over the combination to the server; (NegComb2) gives control over the combination to the client. (NegComb1) only allows standardized combinations, which could be set by TLS working group to have matching security (provided security estimates do not evolve separately).
Backwardscompability. TLS 1.3compliant hybridunaware servers should ignore unreocgnized elements in supported_groups (NegInd2), (NegInd3), (NegComb1), (NegComb2) and unrecognized ClientHello extensions (NegInd1), (NegComb2). In (NegInd3) and (NegComb3), a server that is hybridunaware will ignore the delimiters in supported_groups, and thus might try to negotiate an algorithm individually that is only meant to be used in combination; depending on how such an implementation is coded, it may also encounter bugs when the same element appears multiple times in the list.
(Num) How many component algorithms to combine?
(Num2) Two
Exactly two algorithms can be combined together in hybrid key exchange. This is the approach taken in and .
(Num2+) Two or more
Two or more algorithms can be combined together in hybrid key exchange. This is the approach taken in .
Benefits and Drawbacks
Restricting the number of component algorithms that can be hybridized to two substantially reduces the generality required. On the other hand, some adopters may want to further reduce risk by employing multiple nextgen algorithms built on different cryptographic assumptions.
(Shares) How to convey key shares?
In ECDH ephmeral key exchange, the client sends its ephmeral public key in the key_share extension of the ClientHello message, and the server sends its ephmeral public key in the key_share extension of the ServerHello message.
For a general key encapsulation mechanism used for ephemeral key exchange, we imagine that that client generates a fresh KEM public key / secret pair for each connection, sends it to the client, and the server responds with a KEM ciphertext. For simplicity and consistency with TLS 1.3 terminology, we will refer to both of these types of objects as "key shares".
In hybrid key exchange, we have to decide how to convey the client's two (or more) key shares, and the server's two (or more) key shares.
(SharesConcat) Concatenate key shares
The client concatenates the bytes representing its two key shares and uses this directly as the key_exchange value in a KeyShareEntry in its key_share extension. The server does the same thing. Note that the key_exchange value can be an octet string of length at most 2^161. This is the approach taken in , , and .
(SharesMultiple) Send multiple key shares
The client sends multiple key shares directly in the client_shares vectors of the ClientHello key_share extension. The server does the same. (Note that while the existing KeyShareClientHello struct allows for multiple key share entries, the existing KeyShareServerHello only permits a single key share entry, so some modification would be required to use this approach for the server to send multiple key shares.)
(SharesExtAdditional) Extension carrying additional key shares
The client sends the key share for its traditional algorithm in the original key_share extension of the ClientHello message, and the key share for its nextgen algorithm in some additional extension in the ClientHello message. The server does the same thing. This is the approach taken in .
Benefits and Drawbacks
Backwards compatibility. (SharesMultiple) is fully backwards compatible with nonhybridaware servers. (SharesExtAdditional) is backwards compatible with nonhybridaware servers provided they ignore unrecognized extensions. (SharesConcat) is backwardscompatible with nonhybrid aware servers, but may result in duplication / additional round trips (see below).
Duplication versus additional round trips. If a client wants to offer multiple key shares for multiple combinations in order to avoid retry requests, then the client may ended up sending a key share for one algorithm multiple times when using (SharesExtAdditional) and (SharesConcat). (For example, if the client wants to send an ECDHsecp256r1 + McEliece123 key share, and an ECDHsecp256r1 + NewHope1024 key share, then the same ECDH public key may be sent twice. If the client also wants to offer a traditional ECDHonly key share for nonhybridaware implementations and avoid retry requests, then that same ECDH public key may be sent another time.) (SharesMultiple) does not result in duplicate key shares.
(Comb) How to use keys?
Each component key exchange algorithm establishes a shared secret. These shared secrets must be combined in some way that achieves the "hybrid" property: the resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken.
(CombConcat) Concatenate keys
Each party concatenates the shared secrets established by each component algorithm in an agreedupon order, then feeds that through the TLS key schedule. In the context of TLS 1.3, this would mean using the concatenated shared secret in place of the (EC)DHE input to the second call to HKDFExtract in the TLS 1.3 key schedule:
HKDFExtract = Early Secret

+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)

v
DeriveSecret(., "derived", "")

v
concatenated_shared_secret > HKDFExtract = Handshake Secret
^^^^^^^^^^^^^^^^^^^^^^^^^^ 
+> DeriveSecret(...)
+> DeriveSecret(...)

v
DeriveSecret(., "derived", "")

v
0 > HKDFExtract = Master Secret

+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)
]]>
This is the approach used in , , and .
analyzes the security of applying a KDF to concatenated KEM shared secrets, but their analysis does not exactly apply here since the transcript of ciphertexts is included in the KDF application (though it should follow relatively straightforwardly).
analyzes the security of the (CombConcat) approach as abstracted in their dualPRF combiner. They show that, if the component KEMs are INDCPAsecure (or INDCCAsecure), then the values output by DeriveSecret are INDCPAsecure (respectively, INDCCAsecure). An important aspect of their analysis is that each ciphertext is input to the final PRF calls; this holds for TLS 1.3 since the DeriveSecret calls that derive output keys (application traffic secrets, and exporter and resumption master secrets) include the transcript hash as input.
(CombKDF1) KDF keys
Each party feeds the shared secrets established by each component algorithm in an agreedupon order into a KDF, then feeds that through the TLS key schedule. In the context of TLS 1.3, this would mean first applying HKDFExtract to the shared secrets, then using the output in place of the (EC)DHE input to the second call to HKDFExtract in the TLS 1.3 key schedule:
HKDFExtract = Early Secret

+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)
NextGen 
 v
(EC)DHE > HKDFExtract DeriveSecret(., "derived", "")
 
v v
output > HKDFExtract = Handshake Secret
^^^^^^ 
+> DeriveSecret(...)
+> DeriveSecret(...)

v
DeriveSecret(., "derived", "")

v
0 > HKDFExtract = Master Secret

+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)
]]>
(CombKDF2) KDF keys
Each party concatenates the shared secrets established by each component algorithm in an agreedupon order then feeds that into a KDF, then feeds the result through the TLS key schedule.
Compared with (CombKDF1), this method concatenates the (2 or more) shared secrets prior to input to the KDF, whereas (CombKDF1) puts the (exactly 2) shared secrets in the two different input slots to the KDF.
Compared with (CombConcat), this method has an extract KDF application. While this adds computational overhead, this may provide a cleaner abstraction of the hybridization mechanism for the purposes of formal security analysis.
HKDFExtract = Early Secret

+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)

v
concatenated 0
shared 
secret > HKDFExtract DeriveSecret(., "derived", "")
^^^^^^  
v v
output > HKDFExtract = Handshake Secret
^^^^^^ 
+> DeriveSecret(...)
+> DeriveSecret(...)

v
DeriveSecret(., "derived", "")

v
0 > HKDFExtract = Master Secret

+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)
]]>
(CombXOR) XOR keys
Each party XORs the shared secrets established by each component algorithm (possibly after padding secrets of different lengths), then feeds that through the TLS key schedule. In the context of TLS 1.3, this would mean using the XORed shared secret in place of the (EC)DHE input to the second call to HKDFExtract in the TLS 1.3 key schedule.
analyzes the security of applying a KDF to the XORed KEM shared secrets, but their analysis does not quite apply here since the transcript of ciphertexts is included in the KDF application (though it should follow relatively straightforwardly).
(CombChain) Chain of KDF applications for each key
Each party applies a chain of key derivation functions to the shared secrets established by each component algorithm in an agreedupon order; roughly speaking: F(k1  F(k2)). In the context of TLS 1.3, this would mean extending the key schedule to have one round of the key schedule applied for each component algorithm's shared secret:
HKDFExtract = Early Secret

+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)

v
DeriveSecret(., "derived", "")

v
traditional_shared_secret > HKDFExtract
^^^^^^^^^^^^^^^^^^^^^^^^^ 
DeriveSecret(., "derived", "")

v
next_gen_shared_secret > HKDFExtract = Handshake Secret
^^^^^^^^^^^^^^^^^^^^^^ 
+> DeriveSecret(...)
+> DeriveSecret(...)

v
DeriveSecret(., "derived", "")

v
0 > HKDFExtract = Master Secret

+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)
]]>
This is the approach used in .
analyzes the security of this approach as abstracted in their nested dualPRF N combiner, showing a similar result as for the dualPRF combiner that it preserves INDCPA (or INDCCA) security. Again their analysis depends on each ciphertext being input to the final PRF (DeriveSecret) calls, which holds for TLS 1.3.
(CombAltInput) Second shared secret in an alternate KDF input
In the context of TLS 1.3, the nextgeneration shared secret is used in place of a currently unused input in the TLS 1.3 key schedule, namely replacing the 0 "IKM" input to the final HKDFExtract:
HKDFExtract = Early Secret

+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)

v
DeriveSecret(., "derived", "")

v
traditional_shared_secret > HKDFExtract = Handshake Secret
^^^^^^^^^^^^^^^^^^^^^^^^^ 
+> DeriveSecret(...)
+> DeriveSecret(...)

v
DeriveSecret(., "derived", "")

v
next_gen_shared_secret > HKDFExtract = Master Secret
^^^^^^^^^^^^^^^^^^^^^^ 
+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)
+> DeriveSecret(...)
]]>
This approach is not taken in any of the known postquantum/hybrid TLS drafts. However, it bears some similarities to the approach for using external PSKs in .
Benefits and Drawbacks
New logic. While (CombConcat), (CombKDF1), and (CombKDF2) require new logic to compute the concatenated shared secret, this value can then be used by the TLS 1.3 key schedule without changes to the key schedule logic. In contrast, (CombChain) requires the TLS 1.3 key schedule to be extended for each extra component algorithm.
Philosophical. The TLS 1.3 key schedule already applies a new stage for different types of keying material (PSK versus (EC)DHE), so (CombChain) continues that approach.
Efficiency. (CombKDF1), (CombKDF2), and (CombChain) increase the number of KDF applications for each component algorithm, whereas (CombConcat) and (CombAltInput) keep the number of KDF applications the same (though with potentially longer inputs).
Extensibility. (CombAltInput) changes the use of an existing input, which might conflict with other future changes to the use of the input.
More than 2 component algorithms. The techniques in (CombConcat) and (CombChain) can naturally accommodate more than 2 component shared secrets since there is no distinction to how each shared secret is treated. (CombAltInput) would have to make some distinct, since the 2 component shared secrets are used in different ways; for example, the first shared secret is used as the "IKM" input in the 2nd HKDFExtract call, and all subsequent shared secrets are concatenated to be used as the "IKM" input in the 3rd HKDFExtract call.