rfc9954.original.xml   rfc9954.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.1. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
3) --> -ietf-tls-hybrid-design-16" number="9954" updates="" obsoletes="" category="info
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft " submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version
-ietf-tls-hybrid-design-16" category="info" submissionType="IETF" tocInclude="tr ="3" xml:lang="en" consensus="true">
ue" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.25.0 -->
<front> <front>
<title abbrev="ietf-tls-hybrid-design">Hybrid key exchange in TLS 1.3</title
> <!-- [rfced] Note that we have updated the short title, which appears
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-hybrid-design-16"/> in the running header in the PDF output, as follows.
Original:
ietf-tls-hybrid-design
Current:
Hybrid Key Exchange in TLS 1.3
-->
<title abbrev="Hybrid Key Exchange in TLS 1.3">Hybrid Key Exchange in TLS 1.
3</title>
<seriesInfo name="RFC" value="9954"/>
<author initials="D." surname="Stebila" fullname="Douglas Stebila"> <author initials="D." surname="Stebila" fullname="Douglas Stebila">
<organization>University of Waterloo</organization> <organization>University of Waterloo</organization>
<address> <address>
<email>dstebila@uwaterloo.ca</email> <email>dstebila@uwaterloo.ca</email>
</address> </address>
</author> </author>
<author initials="S." surname="Fluhrer" fullname="Scott Fluhrer"> <author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<email>sfluhrer@cisco.com</email> <email>sfluhrer@cisco.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Gueron" fullname="Shay Gueron"> <author initials="S." surname="Gueron" fullname="Shay Gueron">
<organization abbrev="U. Haifa &amp; Meta">University of Haifa and Meta</o rganization> <organization abbrev="U. Haifa &amp; Meta">University of Haifa and Meta</o rganization>
<address> <address>
<email>shay.gueron@gmail.com</email> <email>shay.gueron@gmail.com</email>
</address> </address>
</author> </author>
<date year="2025" month="September" day="07"/> <date year="2026" month="April"/>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 196?>
<t>Hybrid key exchange refers to using multiple key exchange algorithms simultan <area>SEC</area>
eously and combining the result with the goal of providing security even if a wa <workgroup>tls</workgroup>
y is found to defeat the encryption for all but one of the component algorithms.
It is motivated by transition to post-quantum cryptography. This document pro <!-- [rfced] Please insert any keywords (beyond those that appear in
vides a construction for hybrid key exchange in the Transport Layer Security (TL the title) for use on https://www.rfc-editor.org/search. -->
S) protocol version 1.3.</t>
<keyword>example</keyword>
<abstract>
<t>Hybrid key exchange refers to using multiple key exchange algorithms simultan
eously and combining the result with the goal of providing security even if a wa
y is found to defeat the encryption for all but one of the component algorithms.
It is motivated by the transition to post-quantum cryptography. This document
provides a construction for hybrid key exchange in the Transport Layer Security
(TLS) protocol version 1.3.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 200?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>This document gives a construction for hybrid key exchange in TLS 1.3. <!-- [rfced] How may we clarify "negotiated and transmitted" in this sentence?
The overall design approach is a simple, "concatenation"-based approach: each h Are these part of a series (i.e., viewed, negotiated, and transmitted) as
ybrid key exchange combination should be viewed as a single new key exchange met shown in Perhaps A, or should this phrase be revised as shown in Perhaps B?
hod, negotiated and transmitted using the existing TLS 1.3 mechanisms.</t>
Original:
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.
Perhaps A:
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.
Perhaps B:
Each hybrid key exchange combination should be viewed as a
single new key exchange method that should be negotiated and transmitted usin
g the
existing TLS 1.3 mechanisms.
-->
<t>This document gives a construction for hybrid key exchange in TLS 1.3.
The overall design approach is a simple, "concatenation"-based approach: Each h
ybrid key exchange combination should be viewed as a single new key exchange met
hod, negotiated and transmitted using the existing TLS 1.3 mechanisms.</t>
<t>This document does not propose specific post-quantum mechanisms; see <x ref target="scope"/> for more on the scope of this document.</t> <t>This document does not propose specific post-quantum mechanisms; see <x ref target="scope"/> for more on the scope of this document.</t>
<section anchor="revision-history">
<name>Revision history</name>
<ul empty="true">
<li>
<t><strong>RFC Editor's Note:</strong> Please remove this section pr
ior to publication of a final version of this document.</t>
</li>
</ul>
<t>Earlier versions of this document categorized various design decision
s one could make when implementing hybrid key exchange in TLS 1.3.</t>
<ul spacing="normal">
<li>
<t>draft-ietf-tls-hybrid-design-12:
</t>
<ul spacing="normal">
<li>
<t>Editorial changes</t>
</li>
<li>
<t>Change Kyber references to ML-KEM references</t>
</li>
</ul>
</li>
<li>
<t>draft-ietf-tls-hybrid-design-10:
</t>
<ul spacing="normal">
<li>
<t>Clarifications on shared secret and public key generation</t>
</li>
</ul>
</li>
<li>
<t>draft-ietf-tls-hybrid-design-09:
</t>
<ul spacing="normal">
<li>
<t>Remove IANA registry requests</t>
</li>
<li>
<t>Editorial changes</t>
</li>
</ul>
</li>
<li>
<t>draft-ietf-tls-hybrid-design-09:
</t>
<ul spacing="normal">
<li>
<t>Removal of TBD hybrid combinations using Kyber512 or secp384r
1</t>
</li>
<li>
<t>Editorial changes</t>
</li>
</ul>
</li>
<li>
<t>draft-ietf-tls-hybrid-design-08:
</t>
<ul spacing="normal">
<li>
<t>Add reference to ECP256R1Kyber768 and KyberDraft00 drafts</t>
</li>
</ul>
</li>
<li>
<t>draft-ietf-tls-hybrid-design-07:
</t>
<ul spacing="normal">
<li>
<t>Editorial changes</t>
</li>
<li>
<t>Add reference to X25519Kyber768 draft</t>
</li>
</ul>
</li>
<li>
<t>draft-ietf-tls-hybrid-design-06:
</t>
<ul spacing="normal">
<li>
<t>Bump to version -06 to avoid expiry</t>
</li>
</ul>
</li>
<li>
<t>draft-ietf-tls-hybrid-design-05:
</t>
<ul spacing="normal">
<li>
<t>Define four hybrid key exchange methods</t>
</li>
<li>
<t>Updates to reflect NIST's selection of Kyber</t>
</li>
<li>
<t>Clarifications and rewordings based on working group comments
</t>
</li>
</ul>
</li>
<li>
<t>draft-ietf-tls-hybrid-design-04:
</t>
<ul spacing="normal">
<li>
<t>Some wording changes</t>
</li>
<li>
<t>Remove design considerations appendix</t>
</li>
</ul>
</li>
<li>
<t>draft-ietf-tls-hybrid-design-03:
</t>
<ul spacing="normal">
<li>
<t>Remove specific code point examples and requested codepoint r
ange for hybrid private use</t>
</li>
<li>
<t>Change "Open questions" to "Discussion"</t>
</li>
<li>
<t>Some wording changes</t>
</li>
</ul>
</li>
<li>
<t>draft-ietf-tls-hybrid-design-02:
</t>
<ul spacing="normal">
<li>
<t>Bump to version -02 to avoid expiry</t>
</li>
</ul>
</li>
<li>
<t>draft-ietf-tls-hybrid-design-01:
</t>
<ul spacing="normal">
<li>
<t>Forbid variable-length secret keys</t>
</li>
<li>
<t>Use fixed-length KEM public keys/ciphertexts</t>
</li>
</ul>
</li>
<li>
<t>draft-ietf-tls-hybrid-design-00:
</t>
<ul spacing="normal">
<li>
<t>Allow key_exchange values from the same algorithm to be reuse
d across multiple KeyShareEntry records in the same ClientHello.</t>
</li>
</ul>
</li>
<li>
<t>draft-stebila-tls-hybrid-design-03:
</t>
<ul spacing="normal">
<li>
<t>Add requirement for KEMs to provide protection against key re
use.</t>
</li>
<li>
<t>Clarify FIPS-compliance of shared secret concatenation method
.</t>
</li>
</ul>
</li>
<li>
<t>draft-stebila-tls-hybrid-design-02:
</t>
<ul spacing="normal">
<li>
<t>Design considerations from draft-stebila-tls-hybrid-design-00
and draft-stebila-tls-hybrid-design-01 are moved to the appendix.</t>
</li>
<li>
<t>A single construction is given in the main body.</t>
</li>
</ul>
</li>
<li>
<t>draft-stebila-tls-hybrid-design-01:
</t>
<ul spacing="normal">
<li>
<t>Add (Comb-KDF-1) and (Comb-KDF-2) options.</t>
</li>
<li>
<t>Add two candidate instantiations.</t>
</li>
</ul>
</li>
<li>
<t>draft-stebila-tls-hybrid-design-00: Initial version.</t>
</li>
</ul>
</section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
only when, they <xref target="RFC8174"/> when, and only when, they appear in all capitals,
appear in all capitals, as shown here.</t> as shown here.
<?line -18?> </t>
<t>For the purposes of this document, it is helpful to divide cryptographic alg
<t>For the purposes of this document, it is helpful to be able to divide cryptog orithms into two classes:</t>
raphic algorithms into two classes:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>"Traditional" algorithms: Algorithms that are widely deployed tod ay, but may be deprecated in the future. In the context of TLS 1.3, examples of traditional key exchange algorithms include elliptic curve Diffie-Hellman using secp256r1 or x25519, or finite-field Diffie-Hellman.</t> <t>"Traditional" algorithms: Algorithms that are widely deployed tod ay but may be deprecated in the future. In the context of TLS 1.3, examples of traditional key exchange algorithms include Elliptic Curve Diffie-Hellman (ECDH) using secp256r1 or x25519 or finite field Diffie-Hellman.</t>
</li> </li>
<li> <li>
<t>"Next-generation" (or "next-gen") algorithms: Algorithms that are <!-- [rfced] Please review the verbs in the phrase "may be that the
not yet widely deployed, but may eventually be widely deployed. An additional cryptographic community may have less confidence". Would updating as
facet of these algorithms may be that the cryptographic community has less confi shown below be correct?
dence in their security due to them being relatively new or less studied. This
includes "post-quantum" algorithms.</t> Original:
An additional facet of these algorithms may be that the cryptographic
community has less confidence in their security due to them being
relatively new or less studied.
Perhaps:
An additional facet of these algorithms is that the cryptographic
community may have less confidence in their security due to them being
relatively new or less studied.
-->
<t>"Next-generation" (or "next-gen") algorithms: Algorithms that are
not yet widely deployed but may eventually be widely deployed. An additional f
acet of these algorithms may be that the cryptographic community has less confid
ence in their security due to them being relatively new or less studied. This i
ncludes "post-quantum" algorithms.</t>
</li> </li>
</ul> </ul>
<t>"Hybrid" key exchange, in this context, means the use of two (or more <t>In this context, "hybrid" key exchange means the use of two (or more)
) key exchange algorithms based on different cryptographic assumptions, e.g., on key exchange algorithms based on different cryptographic assumptions, e.g., one
e traditional algorithm and one next-gen algorithm, with the purpose of the fina traditional algorithm and one next-generation algorithm, with the purpose of th
l session key being secure as long as at least one of the component key exchange e final session key being secure as long as at least one of the component key ex
algorithms remains unbroken. change algorithms remains unbroken.
When one of the algorithms is traditional and one of them is post-quantum, this When one of the algorithms is traditional and one is post-quantum, this is a Pos
is a Post-Quantum Traditional Hybrid Scheme <xref target="PQUIP-TERM"/>; while t t-Quantum Traditional Hybrid Scheme <xref target="RFC9794"/>; while this is the
his is the initial use case for this document, the document is not limited to th initial use case for this document, the document is not limited to this case.
is case. This document uses the term "component" algorithms to refer to the algori
This document uses the term "component" algorithms to refer to the algorithms co thms combined in a hybrid key exchange.</t>
mbined in a hybrid key exchange.</t>
<t>Some researchers prefer the phrase "composite" to refer to the use of <t>Some researchers prefer the term "composite" to refer to the use of m
multiple algorithms, to distinguish from "hybrid public key encryption" in whic ultiple algorithms to distinguish from "hybrid public key encryption", in which
h a key encapsulation mechanism and data encapsulation mechanism are combined to a key encapsulation mechanism and data encapsulation mechanism are combined to c
create public key encryption.</t> reate public key encryption.</t>
<t>It is intended that the component algorithms within a hybrid key exch ange are to be performed, that is, negotiated and transmitted, within the TLS 1. 3 handshake. Any out-of-band method of exchanging keying material is considered out-of-scope.</t> <t>It is intended that the component algorithms within a hybrid key exch ange are to be performed, that is, negotiated and transmitted, within the TLS 1. 3 handshake. Any out-of-band method of exchanging keying material is considered out-of-scope.</t>
<t>The primary motivation of this document is preparing for post-quantum <t>The primary motivation of this document is preparing for post-quantum
algorithms. However, it is possible that public key cryptography based on alte algorithms. However, it is possible that public key cryptography based on alte
rnative mathematical constructions will be desired to mitigate risks independent rnative mathematical constructions will be desired to mitigate risks independent
of the advent of a quantum computer, for example because of a cryptanalytic bre of the advent of a quantum computer, for example, because of a cryptanalytic br
akthrough. As such this document opts for the more generic term "next-generatio eakthrough. As such, this document opts for the more generic term "next-generat
n" algorithms rather than exclusively "post-quantum" algorithms.</t> ion" algorithms rather than exclusively "post-quantum" algorithms.</t>
<t>Note that TLS 1.3 uses the phrase "groups" to refer to key exchange a <t>Note that TLS 1.3 uses the term "groups" to refer to key exchange alg
lgorithms -- for example, the <tt>supported_groups</tt> extension -- since all k orithms -- for example, the <tt>supported_groups</tt> extension -- since all key
ey exchange algorithms in TLS 1.3 are Diffie-Hellman-based. As a result, some p exchange algorithms in TLS 1.3 are Diffie-Hellman-based. As a result, some par
arts of this document will refer to data structures or messages with the term "g ts of this document will refer to data structures or messages with the term "gro
roup" in them despite using a key exchange algorithm that is neither Diffie-Hell up" in them despite using a key exchange algorithm that is neither Diffie-Hellma
man-based nor a group.</t> n-based nor a group.</t>
</section> </section>
<section anchor="motivation"> <section anchor="motivation">
<name>Motivation for use of hybrid key exchange</name> <name>Motivation for Use of Hybrid Key Exchange</name>
<t>A hybrid key exchange algorithm allows early adopters eager for post- <t>A hybrid key exchange algorithm allows early adopters eager for post-
quantum security to have the potential of post-quantum security (possibly from a quantum security to have the potential of post-quantum security (possibly from a
less-well-studied algorithm) while still retaining at least the security curren less-well-studied algorithm) while still retaining at least the security curren
tly offered by traditional algorithms. They may even need to retain traditional tly offered by traditional algorithms. They may even need to retain traditional
algorithms due to regulatory constraints, for example US National Institute of algorithms due to regulatory constraints, for example, US National Institute of
Standards and Technology (NIST) FIPS compliance.</t> Standards and Technology (NIST) FIPS compliance.</t>
<t>Ideally, one would not use hybrid key exchange: one would have confid <t>Ideally, one would not use hybrid key exchange: One would have confid
ence in a single algorithm and parameterization that will stand the test of time ence 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 crypta . However, this may not be the case in the face of quantum computers and crypta
nalytic advances more generally.</t> nalytic advances more generally.</t>
<t>Many (though not all) post-quantum algorithms currently under conside <t>Many (though not all) post-quantum algorithms currently under conside
ration are relatively new; they have not been subject to the same depth of study ration are relatively new; they have not been subject to the same depth of study
as RSA and finite-field or elliptic curve Diffie-Hellman, and thus the security as RSA and finite field or elliptic curve Diffie-Hellman; thus, the security co
community does not necessarily have as much confidence in their fundamental sec mmunity does not necessarily have as much confidence in their fundamental securi
urity, or the concrete security level of specific parameterizations.</t> ty or the concrete security level of specific parameterizations.</t>
<t>Moreover, it is possible that after next-generation algorithms are de fined, and for a period of time thereafter, conservative users may not have full confidence in some algorithms.</t> <t>Moreover, it is possible that after next-generation algorithms are de fined, and for a period of time thereafter, conservative users may not have full confidence in some algorithms.</t>
<t>Some users may want to accelerate adoption of post-quantum cryptograp hy due to the threat of retroactive decryption (also known as harvest-now-decryp t-later): if a cryptographic assumption is broken due to the advent of a quantum computer or some other cryptanalytic breakthrough, confidentiality of informati on can be broken retroactively by any adversary who has passively recorded hands hakes and encrypted communications. Hybrid key exchange enables potential secur ity against retroactive decryption while not fully abandoning traditional crypto systems.</t> <t>Some users may want to accelerate adoption of post-quantum cryptograp hy due to the threat of retroactive decryption (also known as "harvest-now-decry pt-later"): If a cryptographic assumption is broken due to the advent of a quant um computer or some other cryptanalytic breakthrough, confidentiality of informa tion can be broken retroactively by any adversary who has passively recorded han dshakes and encrypted communications. Hybrid key exchange enables potential sec urity against retroactive decryption while not fully abandoning traditional cryp tosystems.</t>
<t>As such, there may be users for whom hybrid key exchange is an approp riate step prior to an eventual transition to next-generation algorithms. Users should consider the confidence they have in each hybrid component to assess that the hybrid system meets the desired motivation.</t> <t>As such, there may be users for whom hybrid key exchange is an approp riate step prior to an eventual transition to next-generation algorithms. Users should consider the confidence they have in each hybrid component to assess that the hybrid system meets the desired motivation.</t>
</section> </section>
<section anchor="scope"> <section anchor="scope">
<name>Scope</name> <name>Scope</name>
<t>This document focuses on hybrid ephemeral key exchange in TLS 1.3 <xr ef target="TLS13"/>. It intentionally does not address:</t> <t>This document focuses on hybrid ephemeral key exchange in TLS 1.3 <xr ef target="RFC8446"/>. It intentionally does not address:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Selecting which next-generation algorithms to use in TLS 1.3, or algorithm identifiers or encoding mechanisms for next-generation algorithms.</t> <t>Selecting which next-generation algorithms to use in TLS 1.3 or a lgorithm identifiers or encoding mechanisms for next-generation algorithms.</t>
</li> </li>
<li> <li>
<t>Authentication using next-generation algorithms. While quantum c omputers could retroactively decrypt previous sessions, session authentication c annot be retroactively broken.</t> <t>Authentication using next-generation algorithms. While quantum c omputers could retroactively decrypt previous sessions, session authentication c annot be retroactively broken.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="goals"> <section anchor="goals">
<name>Goals</name> <name>Goals</name>
<t>The primary goal of a hybrid key exchange mechanism is to facilitate the establishment of a shared secret which remains secure as long as one of the component key exchange mechanisms remains unbroken.</t> <t>The primary goal of a hybrid key exchange mechanism is to facilitate the establishment of a shared secret that remains secure as long as one of the c omponent key exchange mechanisms remains unbroken.</t>
<t>In addition to the primary cryptographic goal, there may be several a dditional goals in the context of TLS 1.3:</t> <t>In addition to the primary cryptographic goal, there may be several a dditional goals in the context of TLS 1.3:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t><strong>Backwards compatibility:</strong> Clients and servers who are "hybrid-aware", i.e., compliant with whatever hybrid key exchange standard is developed for TLS, should remain compatible with endpoints and middle-boxes t hat are not hybrid-aware. The three scenarios to consider are: <t><strong>Backwards compatibility</strong>: Clients and servers who are "hybrid-aware", i.e., compliant with whatever hybrid key exchange standard is developed for TLS, should remain compatible with endpoints and middleboxes th at are not hybrid-aware. The three scenarios to consider are:
</t> </t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Hybrid-aware client, hybrid-aware server: These parties shoul d establish a hybrid shared secret.</t> <t>Hybrid-aware client, hybrid-aware server: These parties shoul d establish a hybrid shared secret.</t>
</li> </li>
<li> <li>
<t>Hybrid-aware client, non-hybrid-aware server: These parties should establish a non-hybrid shared secret (assuming the hybrid-aware client is willing to downgrade to non-hybrid-only).</t> <t>Hybrid-aware client, non-hybrid-aware server: These parties should establish a non-hybrid shared secret (assuming the hybrid-aware client is willing to downgrade to non-hybrid-only).</t>
</li> </li>
<li> <li>
<t>Non-hybrid-aware client, hybrid-aware server: These parties should establish a non-hybrid shared secret (assuming the hybrid-aware server is willing to downgrade to non-hybrid-only).</t> <t>Non-hybrid-aware client, hybrid-aware server: These parties should establish a non-hybrid shared secret (assuming the hybrid-aware server is willing to downgrade to non-hybrid-only).</t>
</li> </li>
</ol> </ol>
<t> <t>
Ideally backwards compatibility should be achieved without extra round trips and without sending duplicate information; see below.</t> Ideally, backwards compatibility should be achieved without extra round trips an d without sending duplicate information; see below.</t>
</li> </li>
<li> <li>
<t><strong>High performance:</strong> Use of hybrid key exchange sho uld not be prohibitively expensive in terms of computational performance. In ge neral this will depend on the performance characteristics of the specific crypto graphic algorithms used, and as such is outside the scope of this document. See <xref target="PST"/> for preliminary results about performance characteristics. </t> <t><strong>High performance</strong>: Use of hybrid key exchange sho uld not be prohibitively expensive in terms of computational performance. In ge neral, this will depend on the performance characteristics of the specific crypt ographic algorithms used and, as such, is outside the scope of this document. S ee <xref target="PST"/> for preliminary results about performance characteristic s.</t>
</li> </li>
<li> <li>
<t><strong>Low latency:</strong> Use of hybrid key exchange should n ot substantially increase the latency experienced to establish a connection. Fa ctors affecting this may include the following. <t><strong>Low latency</strong>: Use of hybrid key exchange should n ot substantially increase the latency experienced to establish a connection. Fa ctors affecting this may include the following:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The computational performance characteristics of the specific algorithms used. See above.</t> <t>The computational performance characteristics of the specific algorithms used. See above.</t>
</li> </li>
<li> <li>
<t>The size of messages to be transmitted. Public key and ciphe rtext sizes for post-quantum algorithms range from hundreds of bytes to over one hundred kilobytes, so this impact can be substantial. See <xref target="PST"/> for preliminary results in a laboratory setting, and <xref target="LANGLEY"/> f or preliminary results on more realistic networks.</t> <t>The size of messages to be transmitted. Public key and ciphe rtext sizes for post-quantum algorithms range from hundreds of bytes to over one hundred kilobytes, so this impact can be substantial. See <xref target="PST"/> for preliminary results in a laboratory setting and <xref target="LANGLEY"/> fo r preliminary results on more realistic networks.</t>
</li> </li>
<li> <li>
<t>Additional round trips added to the protocol. See below.</t> <t>Additional round trips added to the protocol. See below.</t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t><strong>No extra round trips:</strong> Attempting to negotiate hy brid key exchange should not lead to extra round trips in any of the three hybri d-aware/non-hybrid-aware scenarios listed above.</t> <t><strong>No extra round trips</strong>: Attempting to negotiate hy brid key exchange should not lead to extra round trips in any of the three hybri d-aware/non-hybrid-aware scenarios listed above.</t>
</li> </li>
<li> <li>
<t><strong>Minimal duplicate information:</strong> Attempting to neg otiate hybrid key exchange should not mean having to send multiple public keys o f the same type.</t> <t><strong>Minimal duplicate information</strong>: Attempting to neg otiate hybrid key exchange should not mean having to send multiple public keys o f the same type.</t>
</li> </li>
</ul> </ul>
<t>The tolerance for lower performance / increased latency due to use of hybrid key exchange will depend on the context and use case of the systems and the network involved.</t> <t>The tolerance for lower performance and increased latency due to use of hybrid key exchange will depend on the context and use case of the systems an d the network involved.</t>
</section> </section>
</section> </section>
<section anchor="kems"> <section anchor="kems">
<name>Key encapsulation mechanisms</name> <name>Key Encapsulation Mechanisms</name>
<t>This document models key agreement as key encapsulation mechanisms (KEM s), which consist of three algorithms:</t> <t>This document models key agreement as key encapsulation mechanisms (KEM s), which consist of three algorithms:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t><tt>KeyGen() -&gt; (pk, sk)</tt>: A probabilistic key generation al gorithm, which generates a public key <tt>pk</tt> and a secret key <tt>sk</tt>.< /t> <t><tt>KeyGen() -&gt; (pk, sk)</tt>: A probabilistic key generation al gorithm, which generates a public key <tt>pk</tt> and a secret key <tt>sk</tt>.< /t>
</li> </li>
<li> <li>
<t><tt>Encaps(pk) -&gt; (ct, ss)</tt>: A probabilistic encapsulation a lgorithm, which takes as input a public key <tt>pk</tt> and outputs a ciphertext <tt>ct</tt> and shared secret <tt>ss</tt>.</t> <t><tt>Encaps(pk) -&gt; (ct, ss)</tt>: A probabilistic encapsulation a lgorithm, which takes as input a public key <tt>pk</tt> and outputs a ciphertext <tt>ct</tt> and shared secret <tt>ss</tt>.</t>
</li> </li>
<li> <li>
<t><tt>Decaps(sk, ct) -&gt; ss</tt>: A decapsulation algorithm, which takes as input a secret key <tt>sk</tt> and ciphertext <tt>ct</tt> and outputs a shared secret <tt>ss</tt>, or in some cases a distinguished error value.</t> <t><tt>Decaps(sk, ct) -&gt; ss</tt>: A decapsulation algorithm, which takes as input a secret key <tt>sk</tt> and ciphertext <tt>ct</tt> and outputs a shared secret <tt>ss</tt> or, in some cases, a distinguished error value.</t>
</li> </li>
</ul> </ul>
<t>The main security property for KEMs is indistinguishability under adapt
ive chosen ciphertext attack (IND-CCA2), which means that shared secret values s <!-- [rfced] Is "for example" needed in these sentences?
hould be indistinguishable from random strings even given the ability to have ot
her arbitrary ciphertexts decapsulated. IND-CCA2 corresponds to security agains Original:
t an active attacker, and the public key / secret key pair can be treated as a l IND-CCA2 corresponds to security against an active attacker, and the
ong-term key or reused (see for example <xref target="KATZ"/> or <xref target="H public key / secret key pair can be treated as a long-term key or
HK"/> for definitions of IND-CCA2 and IND-CPA security). A common design patter reused (see for example [KATZ] or [HHK] for definitions of IND-CCA2
n for obtaining security under key reuse is to apply the Fujisaki-Okamoto (FO) t and IND-CPA security).
ransform <xref target="FO"/> or a variant thereof <xref target="HHK"/>.</t> ...
<t>A weaker security notion is indistinguishability under chosen plaintext Diffie-Hellman key exchange, when viewed
attack (IND-CPA), which means that the shared secret values should be indisting as a KEM, does not formally satisfy IND-CCA2 security, but is still
uishable from random strings given a copy of the public key. IND-CPA roughly co safe to use for ephemeral key exchange in TLS 1.3, see for example
rresponds to security against a passive attacker, and sometimes corresponds to o [DOWLING].
ne-time key exchange.</t> ...
<t>Key exchange in TLS 1.3 is phrased in terms of Diffie-Hellman key excha For additional perspectives on the general transition from traditional to
nge in a group. DH key exchange can be modeled as a KEM, with <tt>KeyGen</tt> c post-quantum cryptography, see for example [ETSI], among others.
orresponding to selecting an exponent <tt>x</tt> as the secret key and computing
the public key <tt>g^x</tt>; encapsulation corresponding to selecting an expone Perhaps:
nt <tt>y</tt>, computing the ciphertext <tt>g^y</tt> and the shared secret <tt>g IND-CCA2 corresponds to security against an active attacker, and the
^(xy)</tt>, and decapsulation as computing the shared secret <tt>g^(xy)</tt>. Se public key and secret key pair can be treated as a long-term key or
e <xref target="HPKE"/> for more details of such Diffie-Hellman-based key encaps reused (see [KATZ] or [HHK] for definitions of IND-CCA2
ulation mechanisms. Diffie-Hellman key exchange, when viewed as a KEM, does not and IND-CPA security).
formally satisfy IND-CCA2 security, but is still safe to use for ephemeral key e ...
xchange in TLS 1.3, see for example <xref target="DOWLING"/>.</t> Diffie-Hellman key exchange, when viewed
<t>TLS 1.3 does not require that ephemeral public keys be used only in a s as a KEM, does not formally satisfy IND-CCA2 security but is still
ingle key exchange session; some implementations may reuse them, at the cost of safe to use for ephemeral key exchange in TLS 1.3, see
limited forward secrecy. As a result, any KEM used in the manner described in t [DOWLING].
his document <bcp14>MUST</bcp14> explicitly be designed to be secure in the even ...
t that the public key is reused. Finite-field and elliptic-curve Diffie-Hellman For additional perspectives on the general transition from traditional to
key exchange methods used in TLS 1.3 satisfy this criteria. For generic KEMs, post-quantum cryptography, see [ETSI].
this means satisfying IND-CCA2 security or having a transform like the Fujisaki- -->
Okamoto transform <xref target="FO"/> <xref target="HHK"/> applied. While it is
recommended that implementations avoid reuse of KEM public keys, implementation <!-- [rfced] Please review the placement of the parenthetical that starts with
s that do reuse KEM public keys <bcp14>MUST</bcp14> ensure that the number of re "see, for example, [KATZ]" in the second sentence below (the surrounding
uses of a KEM public key abides by any bounds in the specification of the KEM or text is provided for context). Note that IND-CPA is not discussed until
subsequent security analyses. Implementations <bcp14>MUST NOT</bcp14> reuse ra the following paragraph. Would it be helpful to make the parenthetical a
ndomness in the generation of KEM ciphertexts.</t> complete sentence and place it in a new paragraph after the paragraph
about IND-CPA?
Original:
The main security property for KEMs is indistinguishability under
adaptive chosen ciphertext attack (IND-CCA2), which means that shared
secret values should be indistinguishable from random strings even
given the ability to have other arbitrary ciphertexts decapsulated.
IND-CCA2 corresponds to security against an active attacker, and the
public key and secret key pair can be treated as a long-term key or
reused (see, for example, [KATZ] or [HHK] for definitions of IND-CCA2
and IND-CPA security). A common design pattern for obtaining
security under key reuse is to apply the Fujisaki-Okamoto (FO)
transform [FO] or a variant thereof [HHK].
A weaker security notion is indistinguishability under chosen
plaintext attack (IND-CPA), which means that the shared secret values
should be indistinguishable from random strings given a copy of the
public key. IND-CPA roughly corresponds to security against a
passive attacker and sometimes corresponds to one-time key exchange.
Perhaps:
The main security property for KEMs is indistinguishability under
adaptive chosen ciphertext attack (IND-CCA2), which means that shared
secret values should be indistinguishable from random strings even
given the ability to have other arbitrary ciphertexts decapsulated.
IND-CCA2 corresponds to security against an active attacker, and the
public key and secret key pair can be treated as a long-term key or
reused. A common design pattern for obtaining
security under key reuse is to apply the Fujisaki-Okamoto (FO)
transform [FO] or a variant thereof [HHK].
A weaker security notion is indistinguishability under chosen
plaintext attack (IND-CPA), which means that the shared secret values
should be indistinguishable from random strings given a copy of the
public key. IND-CPA roughly corresponds to security against a
passive attacker and sometimes corresponds to one-time key exchange.
See [KATZ] or [HHK] for definitions of IND-CCA2
and IND-CPA security.
-->
<t>The main security property for KEMs is indistinguishability under adaptive ch
osen ciphertext attack (IND-CCA2), which means that shared secret values should
be indistinguishable from random strings even given the ability to have other ar
bitrary ciphertexts decapsulated. IND-CCA2 corresponds to security against an a
ctive attacker, and the public key and secret key pair can be treated as a long-
term key or reused (see, for example, <xref target="KATZ"/> or <xref target="HHK
"/> for definitions of IND-CCA2 and IND-CPA security). A common design pattern
for obtaining security under key reuse is to apply the Fujisaki-Okamoto (FO) tra
nsform <xref target="FO"/> or a variant thereof <xref target="HHK"/>.</t>
<t>A weaker security notion is indistinguishability under chosen
plaintext attack (IND-CPA), which means that the shared secret values shou
ld be indistinguishable from random strings given a copy of the public key. IND
-CPA roughly corresponds to security against a passive attacker and sometimes co
rresponds to one-time key exchange.</t>
<!-- [rfced] May we add numbers to this long sentence improve readability?
Original:
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).
Perhaps:
DH key exchange can be modeled as a KEM, with
(1) KeyGen corresponding to selecting an exponent x as the secret key and
computing the public key g^x, (2) encapsulation corresponding to
selecting an exponent y and computing the ciphertext g^y and the shared
secret g^(xy), and (3) decapsulation corresponding to computing the shared se
cret
g^(xy).
-->
<t>Key exchange in TLS 1.3 is phrased in terms of Diffie-Hellman key excha
nge in a group. DH key exchange can be modeled as a KEM, with <tt>KeyGen</tt> c
orresponding to selecting an exponent <tt>x</tt> as the secret key and computing
the public key <tt>g^x</tt>, encapsulation corresponding to selecting an expone
nt <tt>y</tt> and computing the ciphertext <tt>g^y</tt> and the shared secret <t
t>g^(xy)</tt>, and decapsulation as computing the shared secret <tt>g^(xy)</tt>.
See <xref target="RFC9180"/> for more details of such Diffie-Hellman-based key
encapsulation mechanisms. Diffie-Hellman key exchange, when viewed as a KEM, doe
s not formally satisfy IND-CCA2 security but is still safe to use for ephemeral
key exchange in TLS 1.3; see, for example, <xref target="DOWLING"/>.</t>
<t>TLS 1.3 does not require that ephemeral public keys be used only in a s
ingle 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 t
his document <bcp14>MUST</bcp14> explicitly be designed to be secure in the even
t that the public key is reused. Finite field and elliptic curve Diffie-Hellman
key exchange methods used in TLS 1.3 satisfy this criteria. For generic KEMs,
this means satisfying IND-CCA2 security or having a transform like the Fujisaki-
Okamoto transform <xref target="FO"/> <xref target="HHK"/> applied. While it is
recommended that implementations avoid reuse of KEM public keys, implementation
s that do reuse KEM public keys <bcp14>MUST</bcp14> ensure that the number of re
uses of a KEM public key abides by any bounds in the specification of the KEM or
subsequent security analyses. Implementations <bcp14>MUST NOT</bcp14> reuse ra
ndomness in the generation of KEM ciphertexts.</t>
</section> </section>
<section anchor="construction"> <section anchor="construction">
<name>Construction for hybrid key exchange</name> <name>Construction for Hybrid Key Exchange</name>
<section anchor="construction-negotiation"> <section anchor="construction-negotiation">
<name>Negotiation</name> <name>Negotiation</name>
<t>Each particular combination of algorithms in a hybrid key exchange wi ll be represented as a <tt>NamedGroup</tt> and sent in the <tt>supported_groups< /tt> extension. No internal structure or grammar is implied or required in the value of the identifier; they are simply opaque identifiers.</t> <t>Each particular combination of algorithms in a hybrid key exchange wi ll be represented as a <tt>NamedGroup</tt> and sent in the <tt>supported_groups< /tt> extension. No internal structure or grammar is implied or required in the value of the identifier; they are simply opaque identifiers.</t>
<t>Each value representing a hybrid key exchange will correspond to an o rdered pair of two or more algorithms. (Note that this is independent from futu re documents standardizing solely post-quantum key exchange methods, which would have to be assigned their own identifier.)</t> <t>Each value representing a hybrid key exchange will correspond to an o rdered pair of two or more algorithms. (Note that this is independent from futu re documents standardizing solely post-quantum key exchange methods, which would have to be assigned their own identifier.)</t>
</section> </section>
<section anchor="construction-transmitting"> <section anchor="construction-transmitting">
<name>Transmitting public keys and ciphertexts</name> <name>Transmitting Public Keys and Ciphertexts</name>
<t>This document takes the relatively simple "concatenation approach": t <t>This document takes the relatively simple "concatenation approach": T
he messages from the two or more algorithms being hybridized will be concatenate he messages from the two or more algorithms being hybridized will be concatenate
d together and transmitted as a single value, to avoid having to change existing d together and transmitted as a single value to avoid having to change existing
data structures. The values are directly concatenated, without any additional data structures. The values are directly concatenated, without any additional e
encoding or length fields; the representation and length of elements <bcp14>MUST ncoding or length fields; the representation and length of elements <bcp14>MUST<
</bcp14> be fixed once the algorithm is fixed.</t> /bcp14> be fixed once the algorithm is fixed.</t>
<t>Recall that in TLS 1.3 <xref target="TLS13"/> Section 4.2.8, a KEM pu <t>Recall that, in TLS 1.3 (<xref target="RFC8446" sectionFormat="comma"
blic key or KEM ciphertext is represented as a <tt>KeyShareEntry</tt>:</t> section="4.2.8"/>), a KEM public key or KEM ciphertext is represented as a <tt>
<artwork><![CDATA[ KeyShareEntry</tt>:</t>
<sourcecode><![CDATA[
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} KeyShareEntry; } KeyShareEntry;]]></sourcecode>
]]></artwork>
<t>These are transmitted in the <tt>extension_data</tt> fields of <tt>Ke yShareClientHello</tt> and <tt>KeyShareServerHello</tt> extensions:</t> <t>These are transmitted in the <tt>extension_data</tt> fields of <tt>Ke yShareClientHello</tt> and <tt>KeyShareServerHello</tt> extensions:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
struct { struct {
KeyShareEntry client_shares<0..2^16-1>; KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello; } KeyShareClientHello;
struct { struct {
KeyShareEntry server_share; KeyShareEntry server_share;
} KeyShareServerHello; } KeyShareServerHello;]]></sourcecode>
]]></artwork>
<t>The client's shares are listed in descending order of client preferen ce; the server selects one algorithm and sends its corresponding share.</t> <t>The client's shares are listed in descending order of client preferen ce; the server selects one algorithm and sends its corresponding share.</t>
<t>For a hybrid key exchange, the <tt>key_exchange</tt> field of a <tt>K eyShareEntry</tt> is the concatenation of the <tt>key_exchange</tt> field for ea ch of the constituent algorithms. The order of shares in the concatenation <bcp 14>MUST</bcp14> be the same as the order of algorithms indicated in the definiti on of the <tt>NamedGroup</tt>.</t> <t>For a hybrid key exchange, the <tt>key_exchange</tt> field of a <tt>K eyShareEntry</tt> is the concatenation of the <tt>key_exchange</tt> field for ea ch of the constituent algorithms. The order of shares in the concatenation <bcp 14>MUST</bcp14> be the same as the order of algorithms indicated in the definiti on of the <tt>NamedGroup</tt>.</t>
<t>For the client's share, the <tt>key_exchange</tt> value contains the <t>For the client's share, the <tt>key_exchange</tt> value contains the
concatenation of the <tt>pk</tt> outputs of the corresponding KEMs' <tt>KeyGen</ concatenation of the <tt>pk</tt> outputs of the corresponding KEMs' <tt>KeyGen</
tt> algorithms, if that algorithm corresponds to a KEM; or the (EC)DH ephemeral tt> algorithms if that algorithm corresponds to a KEM or the (EC)DH ephemeral ke
key share, if that algorithm corresponds to an (EC)DH group. For the server's s y share if that algorithm corresponds to an (EC)DH group. For the server's shar
hare, the <tt>key_exchange</tt> value contains concatenation of the <tt>ct</tt> e, the <tt>key_exchange</tt> value contains concatenation of the <tt>ct</tt> out
outputs of the corresponding KEMs' <tt>Encaps</tt> algorithms, if that algorithm puts of the corresponding KEMs' <tt>Encaps</tt> algorithms if that algorithm cor
corresponds to a KEM; or the (EC)DH ephemeral key share, if that algorithm corr responds to a KEM or the (EC)DH ephemeral key share if that algorithm correspond
esponds to an (EC)DH group.</t> s to an (EC)DH group.</t>
<t><xref target="TLS13"/> Section 4.2.8 requires that ``The key_exchange
values for each KeyShareEntry <bcp14>MUST</bcp14> be generated independently.'' <t><xref target="RFC8446" section="4.2.8"/> requires that "The key_excha
In the context of this document, since the same algorithm may appear in multip nge values for each KeyShareEntry <bcp14>MUST</bcp14> be generated independently
le named groups, this document relaxes the above requirement to allow the same k ." In the context of this document, the same algorithm may appear in multiple n
ey_exchange value for the same algorithm to be reused in multiple KeyShareEntry amed groups; thus, this document relaxes the above requirement to allow the same
records sent within the same <tt>ClientHello</tt>. However, key_exchange values key_exchange value for the same algorithm to be reused in multiple KeyShareEntr
for different algorithms <bcp14>MUST</bcp14> be generated independently. Explic y records sent within the same <tt>ClientHello</tt>. However, key_exchange valu
itly, if the <tt>NamedGroup</tt> is the hybrid key exchange <tt>MyECDHMyPQKEM</t es for different algorithms <bcp14>MUST</bcp14> be generated independently. Expl
t>, the <tt>KeyShareEntry.key_exchange</tt> values <bcp14>MUST</bcp14> be genera icitly, if the <tt>NamedGroup</tt> is the hybrid key exchange <tt>MyECDHMyPQKEM<
ted in one of the following two ways:</t> /tt>, the <tt>KeyShareEntry.key_exchange</tt> values <bcp14>MUST</bcp14> be gene
rated in one of the following two ways:</t>
<t>Fully independently:</t> <t>Fully independently:</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
MyECDHMyPQKEM.KeyGen() = (MyECDH.KeyGen(), MyPQKEM.KeyGen()) MyECDHMyPQKEM.KeyGen() = (MyECDH.KeyGen(), MyPQKEM.KeyGen())
KeyShareClientHello { KeyShareClientHello {
KeyShareEntry { KeyShareEntry {
NamedGroup: 'MyECDH', NamedGroup: 'MyECDH',
key_exchange: MyECDH.KeyGen() key_exchange: MyECDH.KeyGen()
}, },
KeyShareEntry { KeyShareEntry {
NamedGroup: 'MyPQKEM', NamedGroup: 'MyPQKEM',
key_exchange: MyPQKEM.KeyGen() key_exchange: MyPQKEM.KeyGen()
}, },
KeyShareEntry { KeyShareEntry {
NamedGroup: 'MyECDHMyPQKEM', NamedGroup: 'MyECDHMyPQKEM',
key_exchange: MyECDHMyPQKEM.KeyGen() key_exchange: MyECDHMyPQKEM.KeyGen()
}, },
} }]]></sourcecode>
]]></artwork>
<t>Reusing key_exchange values of the same component algorithm within th e same <tt>ClientHello</tt>:</t> <t>Reusing key_exchange values of the same component algorithm within th e same <tt>ClientHello</tt>:</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
myecdh_key_share = MyECDH.KeyGen() myecdh_key_share = MyECDH.KeyGen()
mypqkem_key_share = MyPQKEM.KeyGen() mypqkem_key_share = MyPQKEM.KeyGen()
myecdh_mypqkem_key_share = (myecdh_key_share, mypqkem_key_share) myecdh_mypqkem_key_share = (myecdh_key_share, mypqkem_key_share)
KeyShareClientHello { KeyShareClientHello {
KeyShareEntry { KeyShareEntry {
NamedGroup: 'MyECDH', NamedGroup: 'MyECDH',
key_exchange: myecdh_key_share key_exchange: myecdh_key_share
}, },
KeyShareEntry { KeyShareEntry {
NamedGroup: 'MyPQKEM', NamedGroup: 'MyPQKEM',
key_exchange: mypqkem_key_share key_exchange: mypqkem_key_share
}, },
KeyShareEntry { KeyShareEntry {
NamedGroup: 'MyECDHMyPQKEM', NamedGroup: 'MyECDHMyPQKEM',
key_exchange: myecdh_mypqkem_key_share key_exchange: myecdh_mypqkem_key_share
}, },
} }]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="construction-shared-secret"> <section anchor="construction-shared-secret">
<name>Shared secret calculation</name> <name>Shared Secret Calculation</name>
<t>Here this document also takes a simple "concatenation approach": the
two shared secrets are concatenated together and used as the shared secret in th <!-- [rfced] May we update this sentence as follows to clarify "Here"? In the
e existing TLS 1.3 key schedule. Again, this document does not add any addition suggested text below, we removed "Here" and added "for the calculation of
al structure (length fields) in the concatenation procedure: for both the tradit shared secrets" after "concatenation approach".
ional groups and post quantum KEMs, the shared secret output length is fixed for
a specific elliptic curve or parameter set.</t> Original:
<t>In other words, if the <tt>NamedGroup</tt> is <tt>MyECDHMyPQKEM</tt>, Here this document also takes a simple "concatenation approach": the
the shared secret is calculated as</t> two shared secrets are concatenated together and used as the shared
secret in the existing TLS 1.3 key schedule.
Perhaps:
This document also takes a simple "concatenation approach" for the
calculation of shared secrets: The
two shared secrets are concatenated together and used as the shared
secret in the existing TLS 1.3 key schedule.
-->
<t>Here, this document also takes a simple "concatenation approach": The
two shared secrets are concatenated together and used as the shared secret in t
he existing TLS 1.3 key schedule. Again, this document does not add any additio
nal structure (length fields) in the concatenation procedure; for both the tradi
tional groups and post quantum KEMs, the shared secret output length is fixed fo
r a specific elliptic curve or parameter set.</t>
<t>In other words, if the <tt>NamedGroup</tt> is <tt>MyECDHMyPQKEM</tt>,
the shared secret is calculated as:</t>
<!-- [rfced] The following line exceeds the 72-character line limit for
artwork. Please let us know how it can be modified.
Original:
concatenated_shared_secret = MyECDH.shared_secret || MyPQKEM.shared_secret
-->
<artwork><![CDATA[ <artwork><![CDATA[
concatenated_shared_secret = MyECDH.shared_secret || MyPQKEM.shared_secret concatenated_shared_secret = MyECDH.shared_secret || MyPQKEM.shared_secret]]></a
]]></artwork> rtwork>
<t>and inserted into the TLS 1.3 key schedule in place of the (EC)DHE sh ared secret, as shown in <xref target="fig-key-schedule"/>.</t> <t>and inserted into the TLS 1.3 key schedule in place of the (EC)DHE sh ared secret, as shown in <xref target="fig-key-schedule"/>.</t>
<figure anchor="fig-key-schedule"> <figure anchor="fig-key-schedule">
<name>Key schedule for hybrid key exchange</name> <name>Key Schedule for Hybrid Key Exchange</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 0
| |
v v
PSK -> HKDF-Extract = Early Secret PSK -> HKDF-Extract = Early Secret
| |
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
| |
skipping to change at line 470 skipping to change at line 452
| |
v v
Derive-Secret(., "derived", "") Derive-Secret(., "derived", "")
| |
v v
0 -> HKDF-Extract = Master Secret 0 -> HKDF-Extract = Master Secret
| |
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
+-----> Derive-Secret(...) +-----> Derive-Secret(...)]]></artwork>
]]></artwork>
</figure> </figure>
<t><strong>FIPS-compliance of shared secret concatenation.</strong>
The US National Institute of Standards and Technology (NIST) documents <xref tar <!--[rfced] May we update "non-approved" to "unapproved" in the sentence
get="NIST-SP-800-56C"/> and <xref target="NIST-SP-800-135"/> give recommendation below?
s for key derivation methods in key exchange protocols. Some hybrid combination
s may combine the shared secret from a NIST-approved algorithm (e.g., ECDH using Original:
the nistp256/secp256r1 curve) with a shared secret from a non-approved algorith Some hybrid
m (e.g., post-quantum). <xref target="NIST-SP-800-56C"/> lists simple concatena combinations may combine the shared secret from a NIST-approved
tion as an approved method for generation of a hybrid shared secret in which one algorithm (e.g., ECDH using the nistp256/secp256r1 curve) with a
of the constituent shared secret is from an approved method.</t> shared secret from a non-approved algorithm (e.g., post-quantum).
Perhaps:
Some hybrid
combinations may combine the shared secret from a NIST-approved
algorithm (e.g., ECDH using the nistp256/secp256r1 curve) with a
shared secret from an unapproved algorithm (e.g., post-quantum).
-->
<t><strong>FIPS compliance of shared secret concatenation.</strong>
The US National Institute of Standards and Technology (NIST) documents <xref tar
get="NIST-SP-800-56C"/> and <xref target="NIST-SP-800-135"/> give recommendation
s for key derivation methods in key exchange protocols. Some hybrid combination
s may combine the shared secret from a NIST-approved algorithm (e.g., ECDH using
the nistp256/secp256r1 curve) with a shared secret from a non-approved algorith
m (e.g., post-quantum). <xref target="NIST-SP-800-56C"/> lists simple concatena
tion as an approved method for generation of a hybrid shared secret in which one
of the constituent shared secrets is from an approved method.</t>
</section> </section>
</section> </section>
<section anchor="discussion"> <section anchor="discussion">
<name>Discussion</name> <name>Discussion</name>
<t><strong>Larger public keys and/or ciphertexts.</strong> <t><strong>Larger public keys and/or ciphertexts.</strong>
The <tt>key_exchange</tt> field in the <tt>KeyShareEntry</tt> struct in <xref ta
rget="construction-transmitting"/> limits public keys and ciphertexts to 2^16-1 <!-- [rfced] Would adding a reference for "Classic McEliece" be helpful here?
bytes. Some post-quantum KEMs have larger public keys and/or ciphertexts; for e If so, please provide the reference entry.
xample, Classic McEliece's smallest parameter set has public key size 261,120 by
tes. However, all defined parameter sets for ML-KEM <xref target="NIST-FIPS-203 Original:
"/> have public keys and ciphertexts that fall within the TLS constraints (altho Some post-quantum KEMs have larger
ugh may result in ClientHello messages larger than a single packet).</t> public keys and/or ciphertexts; for example, Classic McEliece's
smallest parameter set has public key size 261,120 bytes.
-->
The <tt>key_exchange</tt> field in the <tt>KeyShareEntry</tt> struct in <xref ta
rget="construction-transmitting"/> limits public keys and ciphertexts to 2<sup>1
6</sup>-1 bytes. Some post-quantum KEMs have larger public keys and/or cipherte
xts; for example, Classic McEliece's smallest parameter set has a public key siz
e of 261,120 bytes. However, all defined parameter sets for the Module-Lattice-
Based Key
Encapsulation Mechanism (ML-KEM) <xref target="NIST-FIPS-203"/> have public k
eys and ciphertexts that fall within the TLS constraints (although this may resu
lt in ClientHello messages larger than a single packet).</t>
<t><strong>Duplication of key shares.</strong> <t><strong>Duplication of key shares.</strong>
Concatenation of public keys in the <tt>key_exchange</tt> field in the <tt>KeySh Concatenation of public keys in the <tt>key_exchange</tt> field in the <tt>KeySh
areEntry</tt> struct as described in <xref target="construction-transmitting"/> areEntry</tt> struct as described in <xref target="construction-transmitting"/>
can result in sending duplicate key shares. For example, if a client wanted to can result in sending duplicate key shares. For example, if a client wants to o
offer support for two combinations, say "SecP256r1MLKEM768" and "X25519MLKEM768" ffer support for two combinations, say "SecP256r1MLKEM768" and "X25519MLKEM768"
<xref target="ECDHE-MLKEM"/>, it would end up sending two ML-KEM-768 public key <xref target="I-D.kwiatkowski-tls-ecdhe-mlkem"/>, it would end up sending two ML
s, since the <tt>KeyShareEntry</tt> for each combination contains its own copy o -KEM-768 public keys, since the <tt>KeyShareEntry</tt> for each combination cont
f a ML-KEM-768 key. This duplication may be more problematic for post-quantum a ains its own copy of an ML-KEM-768 key. This duplication may be more problemati
lgorithms which have larger public keys. On the other hand, if the client wants c for post-quantum algorithms that have larger public keys. On the other hand,
to offer, for example "SecP256r1MLKEM768" and "secp256r1" (for backwards compat if the client wants to offer, for example, "SecP256r1MLKEM768" and "secp256r1" (
ibility), there is relatively little duplicated data (as the secp256r1 keys are for backwards compatibility), there is relatively little duplicated data (as the
comparatively small).</t> secp256r1 keys are comparatively small).</t>
<t><strong>Failures.</strong>
Some post-quantum key exchange algorithms, including ML-KEM <xref target="NIST-F
IPS-203"/>, have non-zero probability of failure, meaning two honest parties may
derive different shared secrets. This would cause a handshake failure. ML-KEM
has a cryptographically small failure rate; if other algorithms are used, imple
menters should be aware of the potential of handshake failure. Clients <bcp14>MA
Y</bcp14> retry if a failure is encountered.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA will assign identifiers from the TLS Supported Groups registry <xr
ef target="IANATLS"/> for the hybrid combinations defined following this documen <!-- [rfced] IANA Considerations section
t.
These assignments should be made in a range that is distinct from the Finite Fie a) The only mention of this document in the "TLS Supported Groups" registry is
ld Groups range. the Reference at the top of the registry. We have thus added a sentence to the
For these entries in the TLS Supported Groups registry, the "Recommended" column IANA Considerations section to indicate this (see Current below). The rest of
<bcp14>SHOULD</bcp14> be "N" and the "DTLS-OK" column <bcp14>SHOULD</bcp14> be the text in the IANA Considerations section seems to be contain instructions
"Y".</t> for future registrations in the registry. Link to registry:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
b) How may we clarify "range that is distinct from the Finite Field Groups
range"? We see two ranges in the registry that include "Finite Field
Diffie-Hellman groups" in the Notes column. We could note that there are two
ranges from which assignments should not be made (see Perhaps A), or we could
update to specify the ranges from which assignments per this document should
be made (see Perhaps B). Note that for Perhaps B, we used ranges 0-255 and
512-65535 because they both indicate that the Recommended column be set to
"N".
Original:
IANA will assign identifiers from the TLS Supported Groups registry
[IANATLS] for the hybrid combinations defined following this
document. These assignments should be made in a range that is
distinct from the Finite Field Groups range. For these entries in
the TLS Supported Groups registry, the "Recommended" column SHOULD be
"N" and the "DTLS-OK" column SHOULD be "Y".
Current:
IANA has added this document as a reference for the "TLS Supported Groups"
registry" [IANA-TLS].
For hybrid combinations that are defined per this
document, IANA will assign identifiers in a range that is
distinct from the Finite Field Groups range. In addition,
the "Recommended" column SHOULD be "N", and the "DTLS-OK" column SHOULD be "Y
".
Perhaps A:
IANA has added this document as a reference for the "TLS Supported Groups"
registry" [IANA-TLS].
For hybrid combinations that are defined per this
document, IANA will assign identifiers in a range that is
distinct from the ranges for "Finite Field Diffie-Hellman groups". In additio
n,
the "Recommended" column SHOULD be "N", and the "DTLS-OK"
column SHOULD be "Y".
Perhaps B:
IANA has added this document as a reference for the "TLS Supported Groups"
registry" [IANA-TLS].
For hybrid combinations that are defined per this
document, IANA will assign identifiers in the ranges 0-255 and 512-65535
(not in the ranges 256-511 or 256-511, which are for "Finite Field Diffie
Hellman groups"). In addition, the
"Recommended" column SHOULD be "N", and the "DTLS-OK" column SHOULD be "Y".
-->
<t>IANA has added this document as a reference for the "TLS Supported Groups" re
gistry <xref target="IANA-TLS"/>.</t>
<t>For hybrid combinations defined per this document, IANA will
assign identifiers in a range that is distinct from the Finite Field Groups
range. In addition, the "Recommended" column
<bcp14>SHOULD</bcp14> be "N", and the "DTLS-OK" column <bcp14>SHOULD</bcp14>
be "Y".</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The shared secrets computed in the hybrid key exchange should be comput ed 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. S ee <xref target="GIACON"/> and <xref target="BINDEL"/> for an investigation of t hese issues. Under the assumption that shared secrets are fixed length once the combination is fixed, the construction from <xref target="construction-shared-s ecret"/> corresponds to the dual-PRF combiner of <xref target="BINDEL"/> which i s shown to preserve security under the assumption that the hash function is a du al-PRF.</t> <t>The shared secrets computed in the hybrid key exchange should be comput ed 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. S ee <xref target="GIACON"/> and <xref target="BINDEL"/> for an investigation of t hese issues. Under the assumption that shared secrets are fixed length once the combination is fixed, the construction in <xref target="construction-shared-sec ret"/> corresponds to the dual-PRF combiner of <xref target="BINDEL"/>, which is shown to preserve security under the assumption that the hash function is a dua l-PRF.</t>
<t>As noted in <xref target="kems"/>, KEMs used in the manner described in this document <bcp14>MUST</bcp14> explicitly be designed to be secure in the ev ent that the public key is reused, such as achieving IND-CCA2 security or having a transform like the Fujisaki-Okamoto transform applied. ML-KEM has such secur ity properties. However, some other post-quantum KEMs designed to be IND-CPA-se cure (i.e., without countermeasures such as the FO transform) are completely ins ecure under public key reuse; for example, some lattice-based IND-CPA-secure KEM s are vulnerable to attacks that recover the private key after just a few thousa nd samples <xref target="FLUHRER"/>.</t> <t>As noted in <xref target="kems"/>, KEMs used in the manner described in this document <bcp14>MUST</bcp14> explicitly be designed to be secure in the ev ent that the public key is reused, such as achieving IND-CCA2 security or having a transform like the Fujisaki-Okamoto transform applied. ML-KEM has such secur ity properties. However, some other post-quantum KEMs designed to be IND-CPA-se cure (i.e., without countermeasures such as the FO transform) are completely ins ecure under public key reuse; for example, some lattice-based IND-CPA-secure KEM s are vulnerable to attacks that recover the private key after just a few thousa nd samples <xref target="FLUHRER"/>.</t>
<t><strong>Public keys, ciphertexts, and secrets should be constant length .</strong> <t><strong>Public keys, ciphertexts, and secrets should be constant length .</strong>
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 ML-KEM.</t> 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 ML-KEM.</t>
<t>Note that variable-length secrets are, generally speaking, dangerous. In particular, when using key material of variable length and processing it usin g hash functions, a timing side channel may arise. In broad terms, when the sec ret 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 <xref target="LUCKY13"/> and Raccoon <xref target="RACCOON"/> attacks. </t> <t>Note that variable-length secrets are, generally speaking, dangerous. In particular, when using key material of variable length and processing it usin g hash functions, a timing side channel may arise. In broad terms, when the sec ret 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 <xref target="LUCKY13"/> and Raccoon <xref target="RACCOON"/> attacks. </t>
<t>Furthermore, <xref target="AVIRAM"/> identified a risk of using variabl e-length secrets when the hash function used in the key derivation function is n o longer collision-resistant.</t> <t>Furthermore, <xref target="AVIRAM"/> identifies a risk of using variabl e-length secrets when the hash function used in the key derivation function is n o longer collision-resistant.</t>
<t>If concatenation were to be used with values that are not fixed-length, a length prefix or other unambiguous encoding would need to be used to ensure t hat the composition of the two values is injective and requires a mechanism diff erent from that specified in this document.</t> <t>If concatenation were to be used with values that are not fixed-length, a length prefix or other unambiguous encoding would need to be used to ensure t hat the composition of the two values is injective and requires a mechanism diff erent from that specified in this document.</t>
<t>Therefore, this specification <bcp14>MUST</bcp14> only be used with alg <t>Therefore, this specification <bcp14>MUST</bcp14> only be used with alg
orithms which have fixed-length shared secrets (after the variant has been fixed orithms that have fixed-length shared secrets (after the variant has been fixed
by the algorithm identifier in the <tt>NamedGroup</tt> negotiation in <xref tar by the algorithm identifier in the <tt>NamedGroup</tt> negotiation in <xref targ
get="construction-negotiation"/>).</t> et="construction-negotiation"/>).</t>
</section>
<section anchor="acknowledgements">
<name>Acknowledgements</name>
<t>These ideas have grown from discussions with many colleagues, including
Christopher Wood, Matt Campagna, Eric Crockett, Deirdre Connolly, authors of th
e various hybrid Internet-Drafts 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 Post-Quantum Software in Mou
ntain View, California, in January 2019. Daniel J. Bernstein and Tanja Lange co
mmented on the risks of reuse of ephemeral public keys. Matt Campagna and the t
eam at Amazon Web Services provided additional suggestions. Nimrod Aviram propo
sed restricting to fixed-length secrets.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9794" to="PQUIP-TERM"/>
<displayreference target="I-D.campagna-tls-bike-sike-hybrid" to="CAMPAGNA"/>
<displayreference target="RFC8784" to="IKE-PSK"/>
<displayreference target="I-D.schanck-tls-additional-keyshare" to="SCHANCK"/
>
<displayreference target="I-D.whyte-qsh-tls13" to="WHYTE13"/>
<displayreference target="I-D.kwiatkowski-tls-ecdhe-mlkem" to="ECDHE-MLKEM"/
>
<displayreference target="I-D.kiefer-tls-ecdhe-sidh" to="KIEFER"/>
<displayreference target="I-D.whyte-qsh-tls12" to="WHYTE12"/>
<displayreference target="RFC8773" to="EXTERN-PSK"/>
<displayreference target="RFC9180" to="HPKE"/>
<displayreference target="RFC8391" to="XMSS"/>
<displayreference target="I-D.tjhai-ipsecme-hybrid-qske-ikev2" to="IKE-HYBRI
D"/>
<displayreference target="RFC8446" to="TLS13"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="FO"> <reference anchor="FO">
<front> <front>
<title>Secure Integration of Asymmetric and Symmetric Encryption Sch emes</title> <title>Secure Integration of Asymmetric and Symmetric Encryption Sch emes</title>
<author fullname="Eiichiro Fujisaki" initials="E." surname="Fujisaki "> <author fullname="Eiichiro Fujisaki" initials="E." surname="Fujisaki ">
<organization/> <organization/>
</author> </author>
<author fullname="Tatsuaki Okamoto" initials="T." surname="Okamoto"> <author fullname="Tatsuaki Okamoto" initials="T." surname="Okamoto">
<organization/> <organization/>
</author> </author>
<date month="December" year="2011"/> <date month="December" year="2011"/>
</front> </front>
<seriesInfo name="Journal of Cryptology" value="vol. 26, no. 1, pp. 80 -101"/> <refcontent>Journal of Cryptology, vol. 26, no. 1, pp. 80-101</refcont ent>
<seriesInfo name="DOI" value="10.1007/s00145-011-9114-1"/> <seriesInfo name="DOI" value="10.1007/s00145-011-9114-1"/>
<refcontent>Springer Science and Business Media LLC</refcontent>
</reference> </reference>
<reference anchor="HHK"> <reference anchor="HHK">
<front> <front>
<title>A Modular Analysis of the Fujisaki-Okamoto Transformation</ti tle> <title>A Modular Analysis of the Fujisaki-Okamoto Transformation</ti tle>
<author fullname="Dennis Hofheinz" initials="D." surname="Hofheinz"> <author fullname="Dennis Hofheinz" initials="D." surname="Hofheinz">
<organization/> <organization/>
</author> </author>
<author fullname="Kathrin Hövelmanns" initials="K." surname="Hövelma nns"> <author fullname="Kathrin Hövelmanns" initials="K." surname="Hövelma nns">
<organization/> <organization/>
</author> </author>
<author fullname="Eike Kiltz" initials="E." surname="Kiltz"> <author fullname="Eike Kiltz" initials="E." surname="Kiltz">
<organization/> <organization/>
</author> </author>
<date year="2017"/> <date year="2017"/>
</front> </front>
<seriesInfo name="Lecture Notes in Computer Science" value="pp. 341-37 1"/> <refcontent>Theory of Cryptography (TCC 2017), Lecture Notes in Comput er Science, vol. 10677, pp. 341-371</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-319-70500-2_12"/> <seriesInfo name="DOI" value="10.1007/978-3-319-70500-2_12"/>
<seriesInfo name="ISBN" value="[&quot;9783319704999&quot;, &quot;97833
19705002&quot;]"/>
<refcontent>Springer International Publishing</refcontent>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="TLS13">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
</references> </references>
<references anchor="sec-informative-references">
<!-- [rfced] References
a) Note that draft-tjhai-ipsecme-hybrid-qske-ikev2 was replaced by
draft-ietf-ipsecme-ikev2-multiple-ke and published as RFC 9370. May we update
this reference entry to RFC 9370?
Current:
[IKE-HYBRID]
Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
Geest, D., Garcia-Morchon, O., and V. Smyslov, "Framework
to Integrate Post-quantum Key Exchanges into Internet Key
Exchange Protocol Version 2 (IKEv2)", Work in Progress,
Internet-Draft, draft-tjhai-ipsecme-hybrid-qske-ikev2-04,
9 July 2019, <https://datatracker.ietf.org/doc/html/draft-
tjhai-ipsecme-hybrid-qske-ikev2-04>.
Perhaps:
[RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
Key Exchanges in the Internet Key Exchange Protocol
Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May
2023, <https://www.rfc-editor.org/info/rfc9370>.
a.1) Related to the above, if [IKE-HYBRID] is updated to [RFC9370], are any
changes needed to the text that includes the citation?
Current:
Considering other IETF standards, there is work on post-quantum
preshared keys in Internet Key Exchange Protocol Version 2 (IKEv2)
[IKE-PSK] and a framework for hybrid key exchange in IKEv2
[IKE-HYBRID].
Perhaps:
[RFC9370] on the multiple key exchanges in the Internet Key Exchange
Protocol Version 2 (IKEv2) has been published as a Proposed Standard, and
other IETF work includes a framework for hybrid key exchange in IKEv2
[IKE-HYBRID].
b) Note that draft-kwiatkowski-tls-ecdhe-mlkem was replaced by
draft-ietf-tls-ecdhe-mlkem. Should this reference be updated to point
to the newer document?
Current:
[ECDHE-MLKEM]
Kwiatkowski, K., Kampanakis, P., Westerbaan, B., and D.
Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement
for TLSv1.3", Work in Progress, Internet-Draft, draft-
kwiatkowski-tls-ecdhe-mlkem-03, 24 December 2024,
<https://datatracker.ietf.org/doc/html/draft-kwiatkowski-
tls-ecdhe-mlkem-03>.
Perhaps:
[ECDHE-MLKEM]
Kwiatkowski, K., Kampanakis, P., Westerbaan, B., and D.
Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement
for TLSv1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-ecdhe-mlkem-04, 8 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
ecdhe-mlkem-04>.
c) FYI: We updated the following references to match reference
style guidance for referencing web-based public code repositories (e.g., GitHub)
.
See <https://www.rfc-editor.org/styleguide/part2/#ref_repo> for more information
.
Original:
[OQS-102] Open Quantum Safe Project, "OQS-OpenSSL-1-0-2_stable",
November 2018, <https://github.com/open-quantum-
safe/openssl/tree/OQS-OpenSSL_1_0_2-stable>.
[OQS-111] Open Quantum Safe Project, "OQS-OpenSSL-1-1-1_stable",
January 2022, <https://github.com/open-quantum-
safe/openssl/tree/OQS-OpenSSL_1_1_1-stable>.
[OQS-PROV] Open Quantum Safe Project, "OQS Provider for OpenSSL 3",
July 2023,
<https://github.com/open-quantum-safe/oqs-provider/>.
Current:
[OQS-102] "OQS-OpenSSL-1-0-2_stable", commit 537b2f9, 31 January
2020, <https://github.com/open-quantum-safe/openssl/tree/
OQS-OpenSSL_1_0_2-stable>.
[OQS-111] "OQS-OpenSSL-1-1-1_stable", commit 5f49b7a, 8 January
2025, <https://github.com/open-quantum-safe/openssl/tree/
OQS-OpenSSL_1_1_1-stable>.
[OQS-PROV] "OQS Provider for OpenSSL 3", commit 573fb25, 8 January
2026,
<https://github.com/open-quantum-safe/oqs-provider/>.
-->
<references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="AVIRAM" target="https://mailarchive.ietf.org/arch/msg /tls/F4SVeL2xbGPaPB2GW_GkBbD_a5M/"> <reference anchor="AVIRAM" target="https://mailarchive.ietf.org/arch/msg /tls/F4SVeL2xbGPaPB2GW_GkBbD_a5M/">
<front> <front>
<title>[TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3</ti tle> <title>[TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3</ti tle>
<author initials="" surname="Nimrod Aviram"> <author initials="" surname="Nimrod Aviram">
<organization/> <organization/>
</author> </author>
<author initials="" surname="Benjamin Dowling"> <author initials="" surname="Benjamin Dowling">
<organization/> <organization/>
</author> </author>
skipping to change at line 630 skipping to change at line 759
<organization/> <organization/>
</author> </author>
<author fullname="Michael Naehrig" initials="M." surname="Naehrig"> <author fullname="Michael Naehrig" initials="M." surname="Naehrig">
<organization/> <organization/>
</author> </author>
<author fullname="Douglas Stebila" initials="D." surname="Stebila"> <author fullname="Douglas Stebila" initials="D." surname="Stebila">
<organization/> <organization/>
</author> </author>
<date month="May" year="2015"/> <date month="May" year="2015"/>
</front> </front>
<seriesInfo name="2015 IEEE Symposium on Security and Privacy" value=" pp. 553-570"/> <refcontent>2015 IEEE Symposium on Security and Privacy, pp. 553-570</ refcontent>
<seriesInfo name="DOI" value="10.1109/sp.2015.40"/> <seriesInfo name="DOI" value="10.1109/sp.2015.40"/>
<refcontent>IEEE</refcontent>
</reference> </reference>
<reference anchor="BERNSTEIN"> <reference anchor="BERNSTEIN">
<front> <front>
<title>Post-Quantum Cryptography</title> <title>Post-Quantum Cryptography</title>
<author> <author fullname="Daniel J. Bernstein" role="editor"/>
<organization/> <author fullname="Johannes Buchmann" role="editor"/>
</author> <author fullname="Erik Dahmen" role="editor"/>
<date year="2009"/> <date year="2009"/>
</front> </front>
<seriesInfo name="DOI" value="10.1007/978-3-540-88702-7"/> <seriesInfo name="DOI" value="10.1007/978-3-540-88702-7"/>
<seriesInfo name="ISBN" value="[&quot;9783540887010&quot;, &quot;97835 <refcontent>Springer Berlin</refcontent>
40887027&quot;]"/>
<refcontent>Springer Berlin Heidelberg</refcontent>
</reference> </reference>
<reference anchor="BINDEL"> <reference anchor="BINDEL">
<front> <front>
<title>Hybrid Key Encapsulation Mechanisms and Authenticated Key Exc hange</title> <title>Hybrid Key Encapsulation Mechanisms and Authenticated Key Exc hange</title>
<author fullname="Nina Bindel" initials="N." surname="Bindel"> <author fullname="Nina Bindel" initials="N." surname="Bindel">
<organization/> <organization/>
</author> </author>
<author fullname="Jacqueline Brendel" initials="J." surname="Brendel "> <author fullname="Jacqueline Brendel" initials="J." surname="Brendel ">
<organization/> <organization/>
</author> </author>
skipping to change at line 666 skipping to change at line 793
<organization/> <organization/>
</author> </author>
<author fullname="Brian Goncalves" initials="B." surname="Goncalves" > <author fullname="Brian Goncalves" initials="B." surname="Goncalves" >
<organization/> <organization/>
</author> </author>
<author fullname="Douglas Stebila" initials="D." surname="Stebila"> <author fullname="Douglas Stebila" initials="D." surname="Stebila">
<organization/> <organization/>
</author> </author>
<date year="2019"/> <date year="2019"/>
</front> </front>
<seriesInfo name="Lecture Notes in Computer Science" value="pp. 206-22 6"/> <refcontent>Post-Quantum Cryptography (PQCrypto 2019), Lecture Notes i n Computer Science, vol. 11505, pp. 206-226</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-030-25510-7_12"/> <seriesInfo name="DOI" value="10.1007/978-3-030-25510-7_12"/>
<seriesInfo name="ISBN" value="[&quot;9783030255091&quot;, &quot;97830
30255107&quot;]"/>
<refcontent>Springer International Publishing</refcontent>
</reference>
<reference anchor="CAMPAGNA">
<front>
<title>Hybrid Post-Quantum Key Encapsulation Methods (PQ KEM) for Tr
ansport Layer Security 1.2 (TLS)</title>
<author fullname="Matt Campagna" initials="M." surname="Campagna">
<organization>AWS</organization>
</author>
<author fullname="Eric Crockett" initials="E." surname="Crockett">
<organization>AWS</organization>
</author>
<date day="2" month="September" year="2021"/>
<abstract>
<t> 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 Diffie-Hellman (ECDH) with a post-quantum key
encapsulation method (PQ KEM) using the existing TLS PRF.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-campagna-tls-bike-sike-
hybrid-07"/>
</reference> </reference>
<!-- [CAMPAGNA]
draft-campagna-tls-bike-sike-hybrid-07
IESG State: Expired as of 01/12/26
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
campagna-tls-bike-sike-hybrid.xml"/>
<reference anchor="CECPQ1" target="https://security.googleblog.com/2016/ 07/experimenting-with-post-quantum.html"> <reference anchor="CECPQ1" target="https://security.googleblog.com/2016/ 07/experimenting-with-post-quantum.html">
<front> <front>
<title>Experimenting with Post-Quantum Cryptography</title> <title>Experimenting with Post-Quantum Cryptography</title>
<author initials="M." surname="Braithwaite"> <author initials="M." surname="Braithwaite">
<organization/> <organization/>
</author> </author>
<date year="2016" month="July" day="07"/> <date year="2016" month="July" day="07"/>
</front> </front>
<refcontent>Google Security Blog</refcontent>
</reference> </reference>
<reference anchor="CECPQ2" target="https://www.imperialviolet.org/2018/1 2/12/cecpq2.html"> <reference anchor="CECPQ2" target="https://www.imperialviolet.org/2018/1 2/12/cecpq2.html">
<front> <front>
<title>CECPQ2</title> <title>CECPQ2</title>
<author initials="A." surname="Langley"> <author initials="A." surname="Langley">
<organization/> <organization/>
</author> </author>
<date year="2018" month="December" day="12"/> <date year="2018" month="December" day="12"/>
</front> </front>
</reference> </reference>
skipping to change at line 725 skipping to change at line 831
<front> <front>
<title>Chosen-Ciphertext Security of Multiple Encryption</title> <title>Chosen-Ciphertext Security of Multiple Encryption</title>
<author fullname="Yevgeniy Dodis" initials="Y." surname="Dodis"> <author fullname="Yevgeniy Dodis" initials="Y." surname="Dodis">
<organization/> <organization/>
</author> </author>
<author fullname="Jonathan Katz" initials="J." surname="Katz"> <author fullname="Jonathan Katz" initials="J." surname="Katz">
<organization/> <organization/>
</author> </author>
<date year="2005"/> <date year="2005"/>
</front> </front>
<seriesInfo name="Lecture Notes in Computer Science" value="pp. 188-20 9"/> <refcontent>Theory of Cryptography (TCC 2005), Lecture Notes in Comput er Science, vol. 3378, pp. 188-209</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-540-30576-7_11"/> <seriesInfo name="DOI" value="10.1007/978-3-540-30576-7_11"/>
<seriesInfo name="ISBN" value="[&quot;9783540245735&quot;, &quot;97835
40305767&quot;]"/>
<refcontent>Springer Berlin Heidelberg</refcontent>
</reference> </reference>
<reference anchor="DOWLING"> <reference anchor="DOWLING">
<front> <front>
<title>A Cryptographic Analysis of the TLS 1.3 Handshake Protocol</t itle> <title>A Cryptographic Analysis of the TLS 1.3 Handshake Protocol</t itle>
<author fullname="Benjamin Dowling" initials="B." surname="Dowling"> <author fullname="Benjamin Dowling" initials="B." surname="Dowling">
<organization/> <organization/>
</author> </author>
<author fullname="Marc Fischlin" initials="M." surname="Fischlin"> <author fullname="Marc Fischlin" initials="M." surname="Fischlin">
<organization/> <organization/>
</author> </author>
<author fullname="Felix Günther" initials="F." surname="Günther"> <author fullname="Felix Günther" initials="F." surname="Günther">
<organization/> <organization/>
</author> </author>
<author fullname="Douglas Stebila" initials="D." surname="Stebila"> <author fullname="Douglas Stebila" initials="D." surname="Stebila">
<organization/> <organization/>
</author> </author>
<date month="July" year="2021"/> <date month="July" year="2021"/>
</front> </front>
<seriesInfo name="Journal of Cryptology" value="vol. 34, no. 4"/> <refcontent>Journal of Cryptology, vol. 34, article 37</refcontent>
<seriesInfo name="DOI" value="10.1007/s00145-021-09384-1"/> <seriesInfo name="DOI" value="10.1007/s00145-021-09384-1"/>
<refcontent>Springer Science and Business Media LLC</refcontent>
</reference> </reference>
<reference anchor="ETSI" target="https://www.etsi.org/images/files/ETSIW hitePapers/QuantumSafeWhitepaper.pdf"> <reference anchor="ETSI" target="https://www.etsi.org/images/files/ETSIW hitePapers/QuantumSafeWhitepaper.pdf">
<front> <front>
<title>Quantum safe cryptography and security: An introduction, bene <title>Quantum Safe Cryptography and Security: An introduction, bene
fits, enablers and challengers</title> fits, enablers and challengers</title>
<author initials="M." surname="Campagna" role="editor"> <author>
<organization/> <organization>Campagna, M., Ed., et al.</organization>
</author>
<author initials="" surname="others">
<organization/>
</author> </author>
<date year="2015" month="June"/> <date year="2015" month="June"/>
</front> </front>
<seriesInfo name="ETSI White Paper No. 8" value=""/> <refcontent>ETSI White Paper No. 8</refcontent>
</reference> </reference>
<reference anchor="EVEN"> <reference anchor="EVEN">
<front> <front>
<title>On the Power of Cascade Ciphers</title> <title>On the Power of Cascade Ciphers</title>
<author fullname="S. Even" initials="S." surname="Even"> <author fullname="S. Even" initials="S." surname="Even">
<organization/> <organization/>
</author> </author>
<author fullname="O. Goldreich" initials="O." surname="Goldreich"> <author fullname="O. Goldreich" initials="O." surname="Goldreich">
<organization/> <organization/>
</author> </author>
<date year="1984"/> <date year="1984"/>
</front> </front>
<seriesInfo name="Advances in Cryptology" value="pp. 43-50"/> <refcontent>Advances in Cryptology, pp. 43-50</refcontent>
<seriesInfo name="DOI" value="10.1007/978-1-4684-4730-9_4"/> <seriesInfo name="DOI" value="10.1007/978-1-4684-4730-9_4"/>
<seriesInfo name="ISBN" value="[&quot;9781468447323&quot;, &quot;97814
68447309&quot;]"/>
<refcontent>Springer US</refcontent>
</reference>
<reference anchor="EXTERN-PSK">
<front>
<title>TLS 1.3 Extension for Certificate-Based Authentication with a
n External Pre-Shared Key</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="March" year="2020"/>
<abstract>
<t>This document specifies a TLS 1.3 extension that allows a serve
r to authenticate with a combination of a certificate and an external pre-shared
key (PSK).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8773"/>
<seriesInfo name="DOI" value="10.17487/RFC8773"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 773.xml"/>
<reference anchor="FLUHRER" target="https://eprint.iacr.org/2016/085"> <reference anchor="FLUHRER" target="https://eprint.iacr.org/2016/085">
<front> <front>
<title>Cryptanalysis of ring-LWE based key exchange with key share r euse</title> <title>Cryptanalysis of ring-LWE based key exchange with key share r euse</title>
<author initials="S." surname="Fluhrer"> <author initials="S." surname="Fluhrer">
<organization/> <organization/>
</author> </author>
<date year="2016" month="January"/> <date year="2016"/>
</front> </front>
<seriesInfo name="Cryptology ePrint Archive, Report 2016/085" value="" /> <refcontent>Cryptology ePrint Archive, Paper 2016/085</refcontent>
</reference> </reference>
<reference anchor="FRODO"> <reference anchor="FRODO">
<front> <front>
<title>Frodo: Take off the Ring! Practical, Quantum-Secure Key Excha nge from LWE</title> <title>Frodo: Take off the Ring! Practical, Quantum-Secure Key Excha nge from LWE</title>
<author fullname="Joppe Bos" initials="J." surname="Bos"> <author fullname="Joppe Bos" initials="J." surname="Bos">
<organization>NXP Semiconductors, Eindhoven, Netherlands</organiza tion> <organization>NXP Semiconductors, Eindhoven, Netherlands</organiza tion>
</author> </author>
<author fullname="Craig Costello" initials="C." surname="Costello"> <author fullname="Craig Costello" initials="C." surname="Costello">
<organization>Microsoft Research, Redmond, WA, USA</organization> <organization>Microsoft Research, Redmond, WA, USA</organization>
</author> </author>
skipping to change at line 831 skipping to change at line 918
<organization>Stanford University, Stanford, CA, USA</organization > <organization>Stanford University, Stanford, CA, USA</organization >
</author> </author>
<author fullname="Ananth Raghunathan" initials="A." surname="Raghuna than"> <author fullname="Ananth Raghunathan" initials="A." surname="Raghuna than">
<organization>Google, Mountain View, CA, USA</organization> <organization>Google, Mountain View, CA, USA</organization>
</author> </author>
<author fullname="Douglas Stebila" initials="D." surname="Stebila"> <author fullname="Douglas Stebila" initials="D." surname="Stebila">
<organization>McMaster University, Hamilton, ON, Canada</organizat ion> <organization>McMaster University, Hamilton, ON, Canada</organizat ion>
</author> </author>
<date month="October" year="2016"/> <date month="October" year="2016"/>
</front> </front>
<seriesInfo name="Proceedings of the 2016 ACM SIGSAC Conference on Com puter and Communications" value="Security"/> <refcontent>Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 1006-1018</refcontent>
<seriesInfo name="DOI" value="10.1145/2976749.2978425"/> <seriesInfo name="DOI" value="10.1145/2976749.2978425"/>
<refcontent>ACM</refcontent>
</reference> </reference>
<reference anchor="GIACON"> <reference anchor="GIACON">
<front> <front>
<title>KEM Combiners</title> <title>KEM Combiners</title>
<author fullname="Federico Giacon" initials="F." surname="Giacon"> <author fullname="Federico Giacon" initials="F." surname="Giacon">
<organization/> <organization/>
</author> </author>
<author fullname="Felix Heuer" initials="F." surname="Heuer"> <author fullname="Felix Heuer" initials="F." surname="Heuer">
<organization/> <organization/>
</author> </author>
<author fullname="Bertram Poettering" initials="B." surname="Poetter ing"> <author fullname="Bertram Poettering" initials="B." surname="Poetter ing">
<organization/> <organization/>
</author> </author>
<date year="2018"/> <date year="2018"/>
</front> </front>
<seriesInfo name="Lecture Notes in Computer Science" value="pp. 190-21 8"/> <refcontent>Public-Key Cryptography (PKC 2018), Lecture Notes in Compu ter Science, vol. 10769, pp. 190-218</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-319-76578-5_7"/> <seriesInfo name="DOI" value="10.1007/978-3-319-76578-5_7"/>
<seriesInfo name="ISBN" value="[&quot;9783319765778&quot;, &quot;97833
19765785&quot;]"/>
<refcontent>Springer International Publishing</refcontent>
</reference> </reference>
<reference anchor="HARNIK"> <reference anchor="HARNIK">
<front> <front>
<title>On Robust Combiners for Oblivious Transfer and Other Primitiv es</title> <title>On Robust Combiners for Oblivious Transfer and Other Primitiv es</title>
<author fullname="Danny Harnik" initials="D." surname="Harnik"> <author fullname="Danny Harnik" initials="D." surname="Harnik">
<organization/> <organization/>
</author> </author>
<author fullname="Joe Kilian" initials="J." surname="Kilian"> <author fullname="Joe Kilian" initials="J." surname="Kilian">
<organization/> <organization/>
</author> </author>
skipping to change at line 874 skipping to change at line 958
<organization/> <organization/>
</author> </author>
<author fullname="Omer Reingold" initials="O." surname="Reingold"> <author fullname="Omer Reingold" initials="O." surname="Reingold">
<organization/> <organization/>
</author> </author>
<author fullname="Alon Rosen" initials="A." surname="Rosen"> <author fullname="Alon Rosen" initials="A." surname="Rosen">
<organization/> <organization/>
</author> </author>
<date year="2005"/> <date year="2005"/>
</front> </front>
<seriesInfo name="Lecture Notes in Computer Science" value="pp. 96-113 "/> <refcontent>Advances in Cryptology (EUROCRYPT 2005), Lecture Notes in Computer Science, vol. 3494, pp. 96-113</refcontent>
<seriesInfo name="DOI" value="10.1007/11426639_6"/> <seriesInfo name="DOI" value="10.1007/11426639_6"/>
<seriesInfo name="ISBN" value="[&quot;9783540259107&quot;, &quot;97835
40320555&quot;]"/>
<refcontent>Springer Berlin Heidelberg</refcontent>
</reference>
<reference anchor="HPKE">
<front>
<title>Hybrid Public Key Encryption</title>
<author fullname="R. Barnes" initials="R." surname="Barnes"/>
<author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
<author fullname="B. Lipp" initials="B." surname="Lipp"/>
<author fullname="C. Wood" initials="C." surname="Wood"/>
<date month="February" year="2022"/>
<abstract>
<t>This document describes a scheme for hybrid public key encrypti
on (HPKE). This scheme provides a variant of public key encryption of arbitrary-
sized plaintexts for a recipient public key. It also includes three authenticate
d variants, including one that authenticates possession of a pre-shared key and
two optional ones that authenticate possession of a key encapsulation mechanism
(KEM) private key. HPKE works for any combination of an asymmetric KEM, key deri
vation function (KDF), and authenticated encryption with additional data (AEAD)
encryption function. Some authenticated variants may not be supported by all KEM
s. We provide instantiations of the scheme using widely used and efficient primi
tives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based ke
y derivation function (HKDF), and SHA2.</t>
<t>This document is a product of the Crypto Forum Research Group (
CFRG) in the IRTF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9180"/>
<seriesInfo name="DOI" value="10.17487/RFC9180"/>
</reference> </reference>
<reference anchor="IANATLS" target="https://www.iana.org/assignments/tls <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
-parameters/tls-parameters.xhtml#tls-parameters-8"> 180.xml"/>
<reference anchor="IANA-TLS" target="https://www.iana.org/assignments/tl
s-parameters">
<front> <front>
<title>Transport Layer Security (TLS) Parameters - TLS Supported Gro <title>TLS Supported Groups</title>
ups</title> <author>
<author initials="" surname="Internet Assigned Numbers Authority"> <organization>IANA</organization>
<organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="IKE-HYBRID">
<front>
<title>Framework to Integrate Post-quantum Key Exchanges into Intern
et Key Exchange Protocol Version 2 (IKEv2)</title>
<author fullname="C. Tjhai" initials="C." surname="Tjhai">
<organization>Post-Quantum</organization>
</author>
<author fullname="M. Tomlinson" initials="M." surname="Tomlinson">
<organization>Post-Quantum</organization>
</author>
<author fullname="grbartle@cisco.com" initials="" surname="grbartle@
cisco.com">
<organization>Cisco Systems</organization>
</author>
<author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
<organization>Cisco Systems</organization>
</author>
<author fullname="Daniel Van Geest" initials="D." surname="Van Geest
">
<organization>ISARA Corporation</organization>
</author>
<author fullname="Oscar Garcia-Morchon" initials="O." surname="Garci
a-Morchon">
<organization>Philips</organization>
</author>
<author fullname="Valery Smyslov" initials="V." surname="Smyslov">
<organization>ELVIS-PLUS</organization>
</author>
<date day="9" month="July" year="2019"/>
<abstract>
<t> 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 post-quantum key exchange payloads in
conjunction with the existing (Elliptic Curve) Diffie-Hellman
payload.
</t> <reference anchor="I-D.tjhai-ipsecme-hybrid-qske-ikev2" target="https://datatrac
</abstract> ker.ietf.org/doc/html/draft-tjhai-ipsecme-hybrid-qske-ikev2-04">
</front> <front>
<seriesInfo name="Internet-Draft" value="draft-tjhai-ipsecme-hybrid-qs <title>Framework to Integrate Post-quantum Key Exchanges into Internet Key
ke-ikev2-04"/> Exchange Protocol Version 2 (IKEv2)</title>
</reference> <author initials="C." surname="Tjhai" fullname="C. Tjhai">
<reference anchor="IKE-PSK"> <organization>Post-Quantum</organization>
<front> </author>
<title>Mixing Preshared Keys in the Internet Key Exchange Protocol V <author initials="M." surname="Tomlinson" fullname="M. Tomlinson">
ersion 2 (IKEv2) for Post-quantum Security</title> <organization>Post-Quantum</organization>
<author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/> </author>
<author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/ <author initials="G." surname="Bartlett" fullname="G. Bartlett">
> <organization>Cisco Systems</organization>
<author fullname="D. McGrew" initials="D." surname="McGrew"/> </author>
<author fullname="V. Smyslov" initials="V." surname="Smyslov"/> <author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
<date month="June" year="2020"/> <organization>Cisco Systems</organization>
<abstract> </author>
<t>The possibility of quantum computers poses a serious challenge <author initials="D." surname="Van Geest" fullname="Daniel Van Geest">
to cryptographic algorithms deployed widely today. The Internet Key Exchange Pro <organization>ISARA Corporation</organization>
tocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; s </author>
omeone storing VPN communications today could decrypt them at a later time when <author initials="O." surname="Garcia-Morchon" fullname="Oscar Garcia-Morc
a quantum computer is available. It is anticipated that IKEv2 will be extended t hon">
o support quantum-secure key exchange algorithms; however, that is not likely to <organization>Philips</organization>
happen in the near term. To address this problem before then, this document des </author>
cribes an extension of IKEv2 to allow it to be resistant to a quantum computer b <author initials="V." surname="Smyslov" fullname="Valery Smyslov">
y using preshared keys.</t> <organization>ELVIS-PLUS</organization>
</abstract> </author>
</front> <date month="July" day="9" year="2019" />
<seriesInfo name="RFC" value="8784"/> </front>
<seriesInfo name="DOI" value="10.17487/RFC8784"/> <seriesInfo name="Internet-Draft" value="draft-tjhai-ipsecme-hybrid-qske-ikev
</reference> 2-04" />
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
784.xml"/>
<reference anchor="KATZ"> <reference anchor="KATZ">
<front> <front>
<title>Introduction to Modern Cryptography, Third Edition</title> <title>Introduction to Modern Cryptography</title>
<author initials="J." surname="Katz"> <author initials="J." surname="Katz">
<organization/> <organization/>
</author> </author>
<author initials="Y." surname="Lindell"> <author initials="Y." surname="Lindell">
<organization/> <organization/>
</author> </author>
<date year="2021"/> <date year="2021"/>
</front> </front>
<seriesInfo name="CRC Press" value=""/> <refcontent>Third Edition</refcontent>
</reference> <refcontent>CRC Press</refcontent>
<reference anchor="KIEFER">
<front>
<title>Hybrid ECDHE-SIDH Key Exchange for TLS</title>
<author fullname="Franziskus Kiefer" initials="F." surname="Kiefer">
<organization>Mozilla</organization>
</author>
<author fullname="Kris Kwiatkowski" initials="K." surname="Kwiatkows
ki">
<organization>Cloudflare</organization>
</author>
<date day="5" month="November" year="2018"/>
<abstract>
<t> This draft specifies a TLS key exchange that combines the po
st-
quantum key exchange, Supersingular elliptic curve isogenie diffie-
hellman (SIDH), with elliptic curve Diffie-Hellman (ECDHE) key
exchange.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-kiefer-tls-ecdhe-sidh-0
0"/>
</reference> </reference>
<!-- [KIEFER]
draft-kiefer-tls-ecdhe-sidh-00
IESG State: Expired as of 01/12/26
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
kiefer-tls-ecdhe-sidh.xml"/>
<reference anchor="LANGLEY" target="https://www.imperialviolet.org/2018/ 04/11/pqconftls.html"> <reference anchor="LANGLEY" target="https://www.imperialviolet.org/2018/ 04/11/pqconftls.html">
<front> <front>
<title>Post-quantum confidentiality for TLS</title> <title>Post-quantum confidentiality for TLS</title>
<author initials="A." surname="Langley"> <author initials="A." surname="Langley">
<organization/> <organization/>
</author> </author>
<date year="2018" month="April" day="11"/> <date year="2018" month="April" day="11"/>
</front> </front>
</reference> </reference>
<reference anchor="LUCKY13"> <reference anchor="LUCKY13">
<front> <front>
<title>Lucky Thirteen: Breaking the TLS and DTLS Record Protocols</t itle> <title>Lucky Thirteen: Breaking the TLS and DTLS Record Protocols</t itle>
<author fullname="N. J. Al Fardan" initials="N." surname="Al Fardan" > <author fullname="N. J. Al Fardan" initials="N." surname="Al Fardan" >
<organization/> <organization/>
</author> </author>
<author fullname="K. G. Paterson" initials="K." surname="Paterson"> <author fullname="K. G. Paterson" initials="K." surname="Paterson">
<organization/> <organization/>
</author> </author>
<date month="May" year="2013"/> <date month="May" year="2013"/>
</front> </front>
<seriesInfo name="2013 IEEE Symposium on Security and Privacy" value=" pp. 526-540"/> <refcontent>2013 IEEE Symposium on Security and Privacy, pp. 526-540</ refcontent>
<seriesInfo name="DOI" value="10.1109/sp.2013.42"/> <seriesInfo name="DOI" value="10.1109/sp.2013.42"/>
<refcontent>IEEE</refcontent>
</reference> </reference>
<reference anchor="NIELSEN"> <reference anchor="NIELSEN">
<front> <front>
<title>Quantum Computation and Quantum Information</title> <title>Quantum Computation and Quantum Information</title>
<author initials="M. A." surname="Nielsen"> <author initials="M. A." surname="Nielsen">
<organization/> <organization/>
</author> </author>
<author initials="I. L." surname="Chuang"> <author initials="I. L." surname="Chuang">
<organization/> <organization/>
</author> </author>
<date year="2000"/> <date year="2000"/>
</front> </front>
<seriesInfo name="Cambridge University Press" value=""/> <refcontent>Cambridge University Press</refcontent>
</reference> </reference>
<reference anchor="NIST" target="https://www.nist.gov/pqcrypto"> <reference anchor="NIST" target="https://www.nist.gov/pqcrypto">
<front> <front>
<title>Post-Quantum Cryptography</title> <title>Post-Quantum Cryptography</title>
<author> <author>
<organization>National Institute of Standards and Technology (NIST )</organization> <organization>NIST</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="NIST-FIPS-203">
<reference anchor="NIST-FIPS-203" target="https://nvlpubs.nist.gov/nistp
ubs/FIPS/NIST.FIPS.203.pdf">
<front> <front>
<title>Module-lattice-based key-encapsulation mechanism standard</ti tle> <title>Module-Lattice-Based Key-Encapsulation Mechanism Standard</ti tle>
<author> <author>
<organization/> <organization abbrev="NIST">National Institute of Standards and Te chnology</organization>
</author> </author>
<date month="August" year="2024"/> <date month="August" year="2024"/>
</front> </front>
<seriesInfo name="DOI" value="10.6028/nist.fips.203"/> <seriesInfo name="NIST FIPS" value="203"/>
<refcontent>National Institute of Standards and Technology (U.S.)</ref <seriesInfo name="DOI" value="10.6028/NIST.FIPS.203"/>
content>
</reference> </reference>
<reference anchor="NIST-SP-800-56C"> <reference anchor="NIST-SP-800-56C">
<front> <front>
<title>Recommendation for Key-Derivation Methods in Key-Establishmen t Schemes</title> <title>Recommendation for Key-Derivation Methods in Key-Establishmen t Schemes</title>
<author fullname="Elaine Barker" initials="E." surname="Barker"> <author fullname="Elaine Barker" initials="E." surname="Barker">
<organization/> <organization/>
</author> </author>
<author fullname="Lily Chen" initials="L." surname="Chen"> <author fullname="Lily Chen" initials="L." surname="Chen">
<organization/> <organization/>
</author> </author>
<author fullname="Richard Davis" initials="R." surname="Davis"> <author fullname="Richard Davis" initials="R." surname="Davis">
<organization/> <organization/>
</author> </author>
<date month="August" year="2020"/> <date month="August" year="2020"/>
</front> </front>
<seriesInfo name="NIST SP" value="800-56Cr2"/>
<seriesInfo name="DOI" value="10.6028/nist.sp.800-56cr2"/> <seriesInfo name="DOI" value="10.6028/nist.sp.800-56cr2"/>
<refcontent>National Institute of Standards and Technology</refcontent >
</reference> </reference>
<reference anchor="NIST-SP-800-135"> <reference anchor="NIST-SP-800-135">
<front> <front>
<title>Recommendation for existing application-specific key derivati <title>Recommendation for Existing Application-Specific Key Derivati
on functions</title> on Functions</title>
<author fullname="Q H Dang" initials="Q." surname="Dang"> <author fullname="Quynh Dang" initials="Q." surname="Dang">
<organization/> <organization/>
</author> </author>
<date year="2011"/> <date month="December" year="2011"/>
</front> </front>
<seriesInfo name="NIST SP" value="800-135r1"/>
<seriesInfo name="DOI" value="10.6028/nist.sp.800-135r1"/> <seriesInfo name="DOI" value="10.6028/nist.sp.800-135r1"/>
<refcontent>National Institute of Standards and Technology</refcontent >
</reference> </reference>
<reference anchor="OQS-102" target="https://github.com/open-quantum-safe /openssl/tree/OQS-OpenSSL_1_0_2-stable"> <reference anchor="OQS-102" target="https://github.com/open-quantum-safe /openssl/tree/OQS-OpenSSL_1_0_2-stable">
<front> <front>
<title>OQS-OpenSSL-1-0-2_stable</title> <title>OQS-OpenSSL-1-0-2_stable</title>
<author> <author/>
<organization>Open Quantum Safe Project</organization> <date day="31" year="2020" month="January"/>
</author>
<date year="2018" month="November"/>
</front> </front>
<refcontent>commit 537b2f9</refcontent>
</reference> </reference>
<reference anchor="OQS-111" target="https://github.com/open-quantum-safe /openssl/tree/OQS-OpenSSL_1_1_1-stable"> <reference anchor="OQS-111" target="https://github.com/open-quantum-safe /openssl/tree/OQS-OpenSSL_1_1_1-stable">
<front> <front>
<title>OQS-OpenSSL-1-1-1_stable</title> <title>OQS-OpenSSL-1-1-1_stable</title>
<author> <author/>
<organization>Open Quantum Safe Project</organization> <date day="8" year="2025" month="January"/>
</author>
<date year="2022" month="January"/>
</front> </front>
<refcontent>commit 5f49b7a</refcontent>
</reference> </reference>
<reference anchor="OQS-PROV" target="https://github.com/open-quantum-saf e/oqs-provider/"> <reference anchor="OQS-PROV" target="https://github.com/open-quantum-saf e/oqs-provider/">
<front> <front>
<title>OQS Provider for OpenSSL 3</title> <title>OQS Provider for OpenSSL 3</title>
<author> <author/>
<organization>Open Quantum Safe Project</organization> <date day="8" year="2026" month="January"/>
</author>
<date year="2023" month="July"/>
</front>
</reference>
<reference anchor="PQUIP-TERM">
<front>
<title>Terminology for Post-Quantum Traditional Hybrid Schemes</titl
e>
<author fullname="F. Driscoll" initials="F." surname="Driscoll"/>
<author fullname="M. Parsons" initials="M." surname="Parsons"/>
<author fullname="B. Hale" initials="B." surname="Hale"/>
<date month="June" year="2025"/>
<abstract>
<t>One aspect of the transition to post-quantum algorithms in cryp
tographic protocols is the development of hybrid schemes that incorporate both p
ost-quantum and traditional asymmetric algorithms. This document defines termino
logy for such schemes. It is intended to be used as a reference and, hopefully,
to ensure consistency and clarity across different protocols, standards, and org
anisations.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9794"/> <refcontent>commit 573fb25</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC9794"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 794.xml"/>
<reference anchor="PST"> <reference anchor="PST">
<front> <front>
<title>Benchmarking Post-quantum Cryptography in TLS</title> <title>Benchmarking Post-quantum Cryptography in TLS</title>
<author fullname="Christian Paquin" initials="C." surname="Paquin"> <author fullname="Christian Paquin" initials="C." surname="Paquin">
<organization/> <organization/>
</author> </author>
<author fullname="Douglas Stebila" initials="D." surname="Stebila"> <author fullname="Douglas Stebila" initials="D." surname="Stebila">
<organization/> <organization/>
</author> </author>
<author fullname="Goutam Tamvada" initials="G." surname="Tamvada"> <author fullname="Goutam Tamvada" initials="G." surname="Tamvada">
<organization/> <organization/>
</author> </author>
<date year="2020"/> <date year="2020"/>
</front> </front>
<seriesInfo name="Lecture Notes in Computer Science" value="pp. 72-91" /> <refcontent>Post-Quantum Cryptography (PQCrypto 2020), Lecture Notes i n Computer Science, vol. 12100, pp. 72-91</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-030-44223-1_5"/> <seriesInfo name="DOI" value="10.1007/978-3-030-44223-1_5"/>
<seriesInfo name="ISBN" value="[&quot;9783030442224&quot;, &quot;97830
30442231&quot;]"/>
<refcontent>Springer International Publishing</refcontent>
</reference> </reference>
<reference anchor="RACCOON" target="https://raccoon-attack.com/"> <reference anchor="RACCOON" target="https://raccoon-attack.com/">
<front> <front>
<title>Raccoon Attack: Finding and Exploiting Most-Significant-Bit-O racles in TLS-DH(E)</title> <title>Raccoon Attack: Finding and Exploiting Most-Significant-Bit-O racles in TLS-DH(E)</title>
<author initials="R." surname="Merget"> <author initials="R." surname="Merget">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Brinkmann"> <author initials="M." surname="Brinkmann">
<organization/> <organization/>
</author> </author>
skipping to change at line 1163 skipping to change at line 1176
</author> </author>
<author initials="J." surname="Schwenk"> <author initials="J." surname="Schwenk">
<organization/> <organization/>
</author> </author>
<date year="2020" month="September"/> <date year="2020" month="September"/>
</front> </front>
</reference> </reference>
<reference anchor="S2N" target="https://aws.amazon.com/blogs/security/po st-quantum-tls-now-supported-in-aws-kms/"> <reference anchor="S2N" target="https://aws.amazon.com/blogs/security/po st-quantum-tls-now-supported-in-aws-kms/">
<front> <front>
<title>Post-quantum TLS now supported in AWS KMS</title> <title>Post-quantum TLS now supported in AWS KMS</title>
<author> <author fullname="Andrew Hopkins"/>
<organization>Amazon Web Services</organization> <author fullname="Matthew Campagna"/>
</author>
<date year="2019" month="November" day="04"/> <date year="2019" month="November" day="04"/>
</front> </front>
<refcontent>AWS Security Blog</refcontent>
</reference> </reference>
<reference anchor="SCHANCK"> <!-- [SCHANCK]
<front> draft-schanck-tls-additional-keyshare-00
<title>A Transport Layer Security (TLS) Extension For Establishing A IESG State: Expired as of 01/12/26
n Additional Shared Secret</title> -->
<author fullname="John M. Schanck" initials="J. M." surname="Schanck <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
"> schanck-tls-additional-keyshare.xml"/>
<organization>University of Waterloo</organization> <!-- [WHYTE12]
</author> draft-whyte-qsh-tls12-02
<author fullname="Douglas Stebila" initials="D." surname="Stebila"> IESG State: Expired as of 01/12/26
<organization>McMaster University</organization> -->
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<date day="17" month="April" year="2017"/> whyte-qsh-tls12.xml"/>
<abstract> <!-- [WHYTE13]
<t> This document defines a Transport Layer Security (TLS) exten draft-whyte-qsh-tls13-06
sion that IESG State: Expired as of 01/12/26
allows parties to establish an additional shared secret using a -->
second key exchange algorithm and incorporates this shared secret <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
into the TLS key schedule. whyte-qsh-tls13.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</t> 391.xml"/>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-schanck-tls-additional-
keyshare-00"/>
</reference>
<reference anchor="WHYTE12">
<front>
<title>Quantum-Safe Hybrid (QSH) Ciphersuite for Transport Layer Sec
urity (TLS) version 1.2</title>
<author fullname="John M. Schanck" initials="J. M." surname="Schanck
">
</author>
<author fullname="William Whyte" initials="W." surname="Whyte">
<organization>Security Innovation</organization>
</author>
<author fullname="Zhenfei Zhang" initials="Z." surname="Zhang">
<organization>Security Innovation</organization>
</author>
<date day="22" month="July" year="2016"/>
<abstract>
<t> This document describes the Quantum-Safe Hybrid ciphersuite,
a new
cipher suite providing modular design for quantum-safe 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.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-whyte-qsh-tls12-02"/>
</reference>
<reference anchor="WHYTE13">
<front>
<title>Quantum-Safe Hybrid (QSH) Key Exchange for Transport Layer Se
curity (TLS) version 1.3</title>
<author fullname="William Whyte" initials="W." surname="Whyte">
<organization>Onboard Security</organization>
</author>
<author fullname="Zhenfei Zhang" initials="Z." surname="Zhang">
<organization>Onboard Security</organization>
</author>
<author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
<organization>Cisco Systems</organization>
</author>
<author fullname="Oscar Garcia-Morchon" initials="O." surname="Garci
a-Morchon">
<organization>Philips</organization>
</author>
<date day="3" month="October" year="2017"/>
<abstract>
<t> This document describes the Quantum-Safe Hybrid Key Exchange
, a
mechanism for providing modular design for quantum-safe cryptography
to be adopted in the handshake for the Transport Layer Security (TLS)
protocol version 1.3.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-whyte-qsh-tls13-06"/>
</reference>
<reference anchor="XMSS">
<front>
<title>XMSS: eXtended Merkle Signature Scheme</title>
<author fullname="A. Huelsing" initials="A." surname="Huelsing"/>
<author fullname="D. Butin" initials="D." surname="Butin"/>
<author fullname="S. Gazdag" initials="S." surname="Gazdag"/>
<author fullname="J. Rijneveld" initials="J." surname="Rijneveld"/>
<author fullname="A. Mohaisen" initials="A." surname="Mohaisen"/>
<date month="May" year="2018"/>
<abstract>
<t>This note describes the eXtended Merkle Signature Scheme (XMSS)
, a hash-based digital signature system that is based on existing descriptions i
n scientific literature. This note specifies Winternitz One-Time Signature Plus
(WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a
multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building
block. XMSS provides cryptographic digital signatures without relying on the con
jectured hardness of mathematical problems. Instead, it is proven that it only r
elies on the properties of cryptographic hash functions. XMSS provides strong se
curity guarantees and is even secure when the collision resistance of the underl
ying hash function is broken. It is suitable for compact implementations, is rel
atively simple to implement, and naturally resists side-channel attacks. Unlike
most other signature systems, hash-based signatures can so far withstand known a
ttacks using quantum computers.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8391"/>
<seriesInfo name="DOI" value="10.17487/RFC8391"/>
</reference>
<reference anchor="ZHANG"> <reference anchor="ZHANG">
<front> <front>
<title>On the Security of Multiple Encryption or CCA-security+CCA-se curity=CCA-security?</title> <title>On the Security of Multiple Encryption or CCA-security+CCA-se curity=CCA-security?</title>
<author fullname="Rui Zhang" initials="R." surname="Zhang"> <author fullname="Rui Zhang" initials="R." surname="Zhang">
<organization/> <organization/>
</author> </author>
<author fullname="Goichiro Hanaoka" initials="G." surname="Hanaoka"> <author fullname="Goichiro Hanaoka" initials="G." surname="Hanaoka">
<organization/> <organization/>
</author> </author>
<author fullname="Junji Shikata" initials="J." surname="Shikata"> <author fullname="Junji Shikata" initials="J." surname="Shikata">
<organization/> <organization/>
</author> </author>
<author fullname="Hideki Imai" initials="H." surname="Imai"> <author fullname="Hideki Imai" initials="H." surname="Imai">
<organization/> <organization/>
</author> </author>
<date year="2004"/> <date year="2004"/>
</front> </front>
<seriesInfo name="Lecture Notes in Computer Science" value="pp. 360-37 4"/> <refcontent>Public Key Cryptography (PKC 2004), Lecture Notes in Compu ter Science, vol. 2947, pp. 360-374</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-540-24632-9_26"/> <seriesInfo name="DOI" value="10.1007/978-3-540-24632-9_26"/>
<seriesInfo name="ISBN" value="[&quot;9783540210184&quot;, &quot;97835
40246329&quot;]"/>
<refcontent>Springer Berlin Heidelberg</refcontent>
</reference> </reference>
<reference anchor="ECDHE-MLKEM">
<front>
<title>Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3</ti
tle>
<author fullname="Kris Kwiatkowski" initials="K." surname="Kwiatkows
ki">
<organization>PQShield</organization>
</author>
<author fullname="Panos Kampanakis" initials="P." surname="Kampanaki
s">
<organization>AWS</organization>
</author>
<author fullname="Bas Westerbaan" initials="B." surname="Westerbaan"
>
<organization>Cloudflare</organization>
</author>
<author fullname="Douglas Stebila" initials="D." surname="Stebila">
<organization>University of Waterloo</organization>
</author>
<date day="24" month="December" year="2024"/>
<abstract>
<t> This draft defines three hybrid key agreements for TLS 1.3:
X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which
combine a post-quantum KEM with an elliptic curve Diffie-Hellman
(ECDHE).
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</abstract> kwiatkowski-tls-ecdhe-mlkem.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-kwiatkowski-tls-ecdhe-m
lkem-03"/>
</reference>
</references> </references>
</references> </references>
<?line 533?> <?line 533?>
<section anchor="related-work"> <section anchor="related-work">
<name>Related work</name> <name>Related Work</name>
<t>Quantum computing and post-quantum cryptography in general are outside the scope of this document. For a general introduction to quantum computing, se e a standard textbook such as <xref target="NIELSEN"/>. For an overview of post -quantum cryptography as of 2009, see <xref target="BERNSTEIN"/>; while not cont aining more recent advances, it still provides a helpful introduction. For the current status of the NIST Post-Quantum Cryptography Standardization Project, se e <xref target="NIST"/>. For additional perspectives on the general transition from traditional to post-quantum cryptography, see for example <xref target="ETS I"/>, among others.</t> <t>Quantum computing and post-quantum cryptography in general are outside the scope of this document. For a general introduction to quantum computing, se e a standard textbook such as <xref target="NIELSEN"/>. For an overview of post -quantum cryptography as of 2009, see <xref target="BERNSTEIN"/>; while not cont aining more recent advances, it still provides a helpful introduction. For the current status of the NIST Post-Quantum Cryptography Standardization Project, se e <xref target="NIST"/>. For additional perspectives on the general transition from traditional to post-quantum cryptography, see for example <xref target="ETS I"/>, among others.</t>
<t>There have been several Internet-Drafts describing mechanisms for embed ding post-quantum and/or hybrid key exchange in TLS:</t> <t>There have been several Internet-Drafts describing mechanisms for embed ding post-quantum and/or hybrid key exchange in TLS:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Internet-Drafts for TLS 1.2: <xref target="WHYTE12"/>, <xref target ="CAMPAGNA"/></t> <t>TLS 1.2: <xref target="I-D.whyte-qsh-tls12"/>, <xref target="I-D.ca mpagna-tls-bike-sike-hybrid"/></t>
</li> </li>
<li> <li>
<t>Internet-Drafts for TLS 1.3: <xref target="KIEFER"/>, <xref target= "SCHANCK"/>, <xref target="WHYTE13"/></t> <t>TLS 1.3: <xref target="I-D.kiefer-tls-ecdhe-sidh"/>, <xref target=" I-D.schanck-tls-additional-keyshare"/>, <xref target="I-D.whyte-qsh-tls13"/></t>
</li> </li>
</ul> </ul>
<t>There have been several prototype implementations for post-quantum and/ or hybrid key exchange in TLS:</t> <t>There have been several prototype implementations for post-quantum and/ or hybrid key exchange in TLS:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Experimental implementations in TLS 1.2: <xref target="BCNS15"/>, < xref target="CECPQ1"/>, <xref target="FRODO"/>, <xref target="OQS-102"/>, <xref target="S2N"/></t> <t>TLS 1.2: <xref target="BCNS15"/>, <xref target="CECPQ1"/>, <xref ta rget="FRODO"/>, <xref target="OQS-102"/>, <xref target="S2N"/></t>
</li> </li>
<li> <li>
<t>Experimental implementations in TLS 1.3: <xref target="CECPQ2"/>, < xref target="OQS-111"/>, <xref target="OQS-PROV"/>, <xref target="PST"/></t> <t>TLS 1.3: <xref target="CECPQ2"/>, <xref target="OQS-111"/>, <xref t arget="OQS-PROV"/>, <xref target="PST"/></t>
</li> </li>
</ul> </ul>
<t>These experimental implementations have taken an ad hoc approach and no <t>These experimental implementations have taken an ad hoc approach and no
t attempted to implement one of the drafts listed above.</t> t attempted to implement one of the Internet-Drafts listed above.</t>
<t>Unrelated to post-quantum but still related to the issue of combining m <t>Unrelated to post-quantum but still related to the issue of combining m
ultiple types of keying material in TLS is the use of pre-shared keys, especiall ultiple types of keying material in TLS is the use of pre-shared keys, especiall
y the recent TLS working group document on including an external pre-shared key y the recent TLS Working Group document on including an external pre-shared key
<xref target="EXTERN-PSK"/>.</t> <xref target="RFC8773"/>.</t>
<t>Considering other IETF standards, there is work on post-quantum preshar <t>Considering other IETF standards, there is work on post-quantum pre-sha
ed keys in IKEv2 <xref target="IKE-PSK"/> and a framework for hybrid key exchang red keys in the Internet Key Exchange Protocol Version 2 (IKEv2) <xref target="R
e in IKEv2 <xref target="IKE-HYBRID"/>. The XMSS hash-based signature scheme ha FC8784"/> and a framework for hybrid key exchange in IKEv2 <xref target="I-D.tjh
s been published as an informational RFC by the IRTF <xref target="XMSS"/>.</t> ai-ipsecme-hybrid-qske-ikev2"/>. The eXtended Merkle Signature Scheme (XMSS) ha
<t>In the academic literature, <xref target="EVEN"/> initiated the study o sh-based signature scheme has been published as an Informational RFC by the IRTF
f combining multiple symmetric encryption schemes; <xref target="ZHANG"/>, <xref <xref target="RFC8391"/>.</t>
target="DODIS"/>, and <xref target="HARNIK"/> examined combining multiple publi <t>In the academic literature, <xref target="EVEN"/> initiated the study o
c key encryption schemes, and <xref target="HARNIK"/> coined the term "robust co f combining multiple symmetric encryption schemes; <xref target="ZHANG"/>, <xref
mbiner" to refer to a compiler that constructs a hybrid scheme from individual s target="DODIS"/>, and <xref target="HARNIK"/> examined combining multiple publi
chemes while preserving security properties. <xref target="GIACON"/> and <xref c key encryption schemes; and <xref target="HARNIK"/> coined the term "robust co
target="BINDEL"/> examined combining multiple key encapsulation mechanisms.</t> mbiner" to refer to a compiler that constructs a hybrid scheme from individual s
chemes while preserving security properties. <xref target="GIACON"/> and <xref
target="BINDEL"/> examined combining multiple key encapsulation mechanisms.</t>
</section> </section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+196XbbSLLmfz0FRj5nSvIQFEnJtix3121ai6XWWqJc7rp9
ui0QTJIogQALACWz1Opnuc8yTzbxRWQCCRCk7OrqMzPnXNdiCUtmZGTsS8J1
3bUsyEK15xzP+0kwcO7U3FFf/LEXjZQTRM7NWc9pN7fXvH4/Ufd7TqCyoZuF
qTvm592BSoNRtDaI/cib0DCDxBtmbv1Tbvv12sDL6KlOq/PKbb11W2/WfLow
ipM5DR0N47W1YJrsOVkyS7NOq/W21VkjiB7iZLDnnESZSiKVuQeYY20tzbxo
8NkL44hGnKt0bRrsOX/NYr/hpHGSJWqY0k/zCX74Gz0+60+CNA3i6GY+pTdO
Dm+O1ta8WTaOk701x3HpP4eASPecg6bTy1Q/CD2+Jis7iGej0EtLd+Jk5EXB
r15Go+45H6PgXiVpkM2deOh8ooUlYRzzg2riBSFhJ5WX/zR70Hebvleeu9d0
jsLZOFGJNXfPj7OsdL08836Q+rHTm9Pwk9SeMB3KO3/y8UTTjycLs32YqSSO
7MnG3ty+umqRx14w9BzaB+dcZYITQykfm/ru/yzuGahohuaIZ/jTCJcYsLUo
TiY0y73CdhxdEsovT5rtFv3berOVtlrtHSKadtt9227vuG165vj4tPzQ2ze7
7ra73X7rvmm9arXczud2h567Ptrfbb/Z2TM/0CWi6/a2XNjZeU1kR8Rnzd79
8eS6e77HQGdeMlLZnjPOsmm6t7UFgL3EH9OjTRB6kxC0hQtbk3S0RVS/dbTT
+1Gddb70P1x5V+87Hz59/nD3vn/w2Xt1viVDCs+t/5XA+JuzH0/6QRREI6en
/ERlKRhP8+Mp8ePhIj+u8zA5M7WZmdqC/5yi8cfVf+v9vggmSTxwuvdB4k3q
H3mvop+9CU11ED+EBFT9UyehFzmn8YRwEw/Su6D+qVMVRXPnCrSeampaeOZw
7oXONTHx0vvE4c5P8Ujd0433+xe99qti19utt1u9q2an1X7V3GnhgcPri97N
4clFHWW82mm5u7tvWh33DR49uTg4PKt7rrVNtPPqVbvlvhEK2u+eX3U/XHRp
4e4B8exk6o0ij0VcP7hTbor/ibDD04f7Vz+066knVf4sIe5pjuJ4FKp+GI9A
/Vu0gtdbBID6MlVJMFFRRrh3H4Js7E7jNHN/mXlRNps0x9kktGno0H7ewfPO
FZ7/QZ539pP5NItHiTcdz5+nj/Om8z7xaJAH+p8qEVn7NYlrSGy9vk79+h4e
HprBBDB54X0Qhypj/qD3d7faHfzrK3/6S2dhITLo8yB2m84ZcUOo5mXwdt12
x+XNOrg8OOkt2/7t1qs3r7GtbX7y09nJxYd6ScNctb0roubwpneyfMHEswEv
M5h4I5VuDYOQ/o93Po0Jj1ce4SPd0lvS84aKL09xuTkdDEsywWxcSo85vrV7
LGYN+RAeIsJHRtw88yGZG05fRWoYZKT0VOT1Q5qR3yDZEYaKxEeSrq/EbhJj
fjUIsjhZoIp9TfL1exJnYxqer6W086TtSZzuMdIcXqrDKHAu4qazW942QvRr
4PfHwxqObbs7r2kDdt4QP779DLl9+JcbYnD3qncqwvvNm20oi7OPx9eH1/Ub
pKYJIaoZeH5iSJE4bfdVCevMJl7khfM0SKHZErDf2adDp++lqmIXMZfhCimy
RDmJmqVqNW7rVLuNKeFSkgU0yxXAdbqiYRrOtZqSNeOUoLZ5EtR5dH15YOlL
It+tzts3r9/svG3S37s7Hbz24aS7f1krFllhvn5FP7/6DP4+7l5fnFRUKw3a
ef16++1n7Nbx1ekh4/9texdC96R70SXNtEIiEGpFT6awBCGuUqhKd+qRIlLQ
D5Vfm18gIF6UL7q7pU27SbwoZeyceXMir55mDmeDgNkkmjPvOS4rzt5siqdp
Oz8k8Wz6DD+IntNGp9NlwOnVi9mkjyG7/BrNhvWfHrrHP72/PjkQBZH9PPYC
N5gSt06MXnB/SUlHkJ647+g3CiLeBWmfdm/+c89e34nF3k4WO+fxgGApSfSG
czMOkoFzSFwbaA27cj1/bjqnXvZr/c2fSLQG0UCF4SKBXu87V4lK04rhAbhP
Do+I93jhd4EaqoT1ovIHYyjGwZieOetefDg7/OnbVUZrhyhva/qLH0dDGnVB
a1xZutHBQ8EAqtALQQZk0mHf/xWd0iLxj0Wefdw//QkW46Lhsd3cwY5enBye
9UiI2dDlSjieTGcZW9Ask831E2N1fs3WkRQmOC8CFabLbKUTWgfJ6jENP1rc
Qm8COiT5Zdnwi3vaavFiejfLNysK0ozsl3vsCxPjwo58pfVB20w2Ka+fjMCT
KKUxZqQtSP724N15yUCU2I3yx5HIxw3AtqlhdI9Ornpup1VszOtWZ3cLt5q4
RfuzbR7tXbm75BO8er1f8zBtpb6ZdCovtLdfLX+Bbiagj8sfem67tcQmGpG+
mPXZzIunKjL06kLF85U0DbfIYVVbGOaSLvR6Z5/bn1ufOy55uaTLbQRbz5CC
hJNjPVODXzybUxyMD9r0+GflZwv2U76Q9hLj9bcuhP55diH0z++ykE5HdCJG
v7q+/PG3rOQXUjpJfE+yJNmqQIw5+QZLFw2+s/0vwrwthvXVDx9PrlyycM5F
u755C8VwRby4xEnZ2enQu+3P0O/X3f39y8uL+vUmnu/HceR6Web5d7zukiq9
lvtOl+/vOUekB+BQgPnIxQjjgP2LczB3jxRhMAx8WpT7PsjcSxqc7F3tnroH
xxuHm4uq1YgqFlTXTedcAcLFW+yCBNHdxIuixbsXTdt5Ld0i1daLJzFtT3o3
r719HmRZ/bB41x8/qOiuvC8tcgHoSq+zBK3eQ9r0Jt6vccQohTeX5i7elu24
sU6M4gc3NUaIG9B2PKTu3SQt7UVJpcFsobec/C1gufup55ye1+k1prkuA+R8
Un2yiJL7wFdlCU/WXpsEB0irt3/cvdg/FeWdwrz17xhSbyAWhRe6ZOiynUuP
fzr+6eaw3ZHHH8bzTJFVM8YL7HjJ7e2622CQv5z3emLwbL8Fh/4nzf1hmZ/W
2Xm93SGjv8Pewf7B8aF7fnZ6eK7tjIfAy+7ih/QusIyNSXinJmtrrus6Xj/N
iCyztbW6wGYCKyWFTTVLQdaTWZgF01CVn/LCEQy88SR10gCPeJGKZ2konpif
R23I+aERU3pAPAP8PopJoZEaEzGCpwxVOOqeREIwdDznwZs75G0M4xmNR8AM
CCwv4/dVxJoVBgPkDLlwTn+WOXHEyhFP0PxTRE0yC84mGZYZhpzEWXDvgVz6
cyeDmRwYK3Jaspgs/UwvkzGZOoPYn8FA17ATY3uwrAif2hQFQOP6cDEAe8Yq
p1Gz2I9Dh00QGq7d3G7Kpk2CwYDE/9qLsun7+MJ2dJ/W1spgjsiY+RYYdQiN
l0vYJDCAXQlRO96U4PP8MZDoYduJKhrOOo2NQHXEpsq6Kz6heZacZrxRN50Q
iRh+6TiehbQhyrkP1APelylgdzqReii/SY7LOB406MaI9pK3ElTHezkhOUa/
C+0ytXwhiwy/6LXR2xgmSIkkqugaxIStKObtJVpQTjpVPsR5mTKKEd4R6Srn
8TH1SVM+PTFqScwS6mS/+bpQpTUPzfviBTmv9wFvMt3K4mS+tva98/IliQD2
WOLku9S5iEkqvXzpXIWKsEqMNKEtkbGIZRhz5MDTnKDdWT8kvcMXY3DQMIDh
aCipBoZDLwkDIkL9SLrwjKMTEMGvhNF7j2aapYYYBoQY/VaEvcT2Tbw75TyM
wcKgDRN4e4bWiL6fSY1o09HViCEPxpFhUn19XwY9nZP3KQKMZIRiIXZ+5pJk
tC4+O1vLzLYf0pKHGqdYp8Q0ONCUkNsLmhOs89pGKiJ2YX/lmSlab80U17Kj
iBEQiCMihGROP/wyU2mWLl30tw0vwvbm/YHZCIvxUs0ojLlX7Q4pSaxuur27
k7R/8/y7Zv7uYFBgHrtxuH/VefX6us3zvXm9yzjkXzhx1WrJyM9P8eY5kliY
+i8IWr/NJ+bhn53mtZnm/WwyxSiGnegWfvXuY0Ko+jINiH+fG+yVGexAEW8q
6LZ6QSzyzazk4xTGCRMzLSgkvmcX7DvIgFBLAdpgXlk95QLJiUKmkPY61VE7
eouu3GH3R4j4gCw49vTsOnbMOsikVI4etoJ+TdhaWED9wC8w8EzJ8h8EX56d
abvCJ7k49uOBIpmMYKD64kHYmFUy66gBPyEPJIxTS+mRyIT+J9JXZfmxzh4J
jwA414Hy9YMg9WecG11fteznltJZTkmdb6akthnsKE76gchmeIcugtlkZWkB
BevUEBGpj2HwhSxr/QiEYiG80i0/mI4VGdFfvoIAcgnZDcOYdfPnnHZJ3BD+
nGEST0QDehPLWsRK+zoqTErbT+I0LSzMUzXvQcIeRiIG/RgxDm068UD7pLCi
7FjRvM0cTJ04XklAIg5+mQUJqyUmB0IBc5W25dj60vzkjTzyfRiDAmyzxFlz
h2MrMDPDwIOAIQYsK4eSVaQ5+qtA7hRSoo53GLHPDtJibnj2sbaDGD1Yi21s
oNnwpllw11hhJROSjASYlpHZnAmhy+nHg/lXLbFt78oGUrzu6cGR295kqIsL
nU0nZjs/bVovZA8xGSYEI8QiXFTyPWAFynNfMX0L4eMAgVDDhGKQ3ahkEuhI
2uOLrPiNzWpxgB6YJNfPP/Zu1hvyt3NxyT9fH/7w8eT68AA/9467Z2f5D2v6
id7x5cezg+Kn4s39y/Pzw4sDeZmuOqVLa+vn3Z/oDrCzfnl1c3J50T1bF9zb
5ho2UxgsQGh+SnTIpvQardxPgr54yO/3r/73f7V3yGr9H2Rsdtrtt2S4yi8o
AKBfYMLJbHFEHp38Sts8XwN1eAlGgV/ge9Mg88K0AXOdTPgHsmVJ4RI2X/4V
mPnbnvOHvj9t73yvL2DBpYsGZ6WLjLPFKwsvCxJrLtVMk2OzdL2C6TK83Z9K
vxu8Wxf/8B8h9Ljb3v2P79fW1o5giBOdTGcJnIdFe7rhBOyBjlU4Hc5CvVcQ
3OzhBiyFLLeTZLPlZ9OexkL8oZfS8HswnJHnMdGIdevpPZLN+ZvZ2BPieKAJ
aENJM4bxnHl+4M0b7D1PyN/uQ2ET1fieDqZgNcNZNqM9Je850r51BC3BNqVY
8I1CB2PFBUBLQwZB5IczWivJ8YAYnPT5LCH1fhAMh4FyId4nXqRNU5ijZDMm
bdimX9iIa+BHMqGCTLn0Anke5TchBdYvCEi3sMnXnQ16aT3SV9c3n0UW/MC5
yqpIK9CFYEU2I0ZgzFUeI4R1iUvyUJEz9HyV6QBFWsKGRj1PzBguUQDMslmE
GMGYuIyQnOa5HN/EFYKkCKEMZkrL8gmNCgwmKuTiHYIOrjShgUdJs9kgYEDZ
CdZ7QsLN9nVtmiK+XpeI0XppZxu5JNK00SB9R644L4Z0Jy+a6HZDO8ebS+ki
t0wHtJ8w3bMqO6QpmU8s6onqmqNmg91Pm+YKW0MEGOIHsufFrUYRjNLMaiJH
4jQTd7FtBjgFh4xeBTkXxgj9krmZOfDKl8Sdlq0wQZkX3K6on8R3ikj1E/xl
awybTdLyyvR65MEJbttb1ZA94OBMKdFkiQhTOtXzaQAELoqo+tPTO5L0Qajy
YQBNoBUlttFHDGLIQq4k1PBcroMCCaCEwSTIjFUByvBgQ5WjLTPISLwMVYs4
kkaeTXPa61FJbp8Ut8SPFUnl1TlSRLBsqyfEcChCQ1xzqkfD1o8TrEgmTgnc
9YXZNPXmFmoxe0NENoeWZkE6FsNs3bgYRVigiFayxiYU+2MCV9/ypuksNDai
jiqJ7eZl3vIHElWsnuAgixO2UO2shASJe8ImiAZ4IRc0NWFS5oxlCLUsjKlK
kJ+FPOTxgnRVPK5hhuUgqA7E0ZADMprvFMvKuRPPMjceun28KwYzcK/nBhMS
KByRRs0ciFIkDlvHEBvyOofcmmKxkac38ciV0CHfujgYc1Giph6KWpi6S6G+
Uvz4OH4gmZ8YNU4PpgErbyDAQn6pMimXaV6IcgmWxFgCMSD97CNwYVnWwD/i
2eI6J7K9hMNghA1OgvQOG0lKBlsZZbnQGNzr3zynyPgjsQ5wsSqtomlk39NU
7QmgXNkDJdwnKrrLxkk8G42xJaQiZv64gi4yyFMtBJSEOlnH0uvCxVFV7drC
D6vGm6TcaVtDUvCslVZpHIRABcGGbHKxYfh3JAUrJeZdJn9d18aGyK7bPIH0
WYa6pfvEK+Keu3CAfMUG73J7JocOHFK2RiQiLgj1dDIEZdgkmIjqspqwK5NA
vhSWBEIgpIJS6O8J6ScU0xVqTJDP4GvHgBQEkdA04EAHpyuXgG/4l9g34P2p
A5+EekIj8ATiLZ0XPAWMapqqExqPLwr+I1eqWy9ZCrWNoELqkMRGNmlABAe5
rWi9ySJ/5mYPIWrscXAcgaFMCl04y1T7+IZm3rnIbY9NIveBluxqu6iAaFPr
RZL1vC+ZJ7mt3ALg8IQZmf6C4RKiBnzIgknSTIsGSipplnluTNIOCMPLHEve
MhZeokbQDDHJN5Eg9AoqHG1u/9j7bSUkHN9wivgGlMhAwdQVg+uB4/1Q9Nj3
mv3csx7jfSnbrHlup2yt5dVsuqReSJPZgTsaNKmnIveCibKFMvMQUAmw+kIJ
bLIYR8aTOE1VPupS0JIoJHnqcQahkHBYPKHh3CNNtUHKiYQkz0TXN5fpDIsY
ZhHqIkrBHEcKJG3j/B272YIxWQZRRTrroyrC2CQcCCMNQJyPqBNR6xz26HWv
ywsp+UUghVU+lnj52XiWVog4dzrylFikfEidJAg1fB4id6Qf6ryRIS3Xgyxj
Y1oGZa9Ne5AIkVnThbSDzKxFvq1CCVAF57QX8VL96w3paaeifuy9ALYHHHkf
yLI5eQxDJhBLAwQFAEkNDllvYrdUci8qmwg9KeiLMUA+fFhZPov1kgJjC7R4
+YFohOO9vq9CQKlExmnbZGkG2vLr6D/Ye1yJqzKkWRnAgcrT4htemJIOjBCR
oW0ae7TzNC5KLPRTbggjanNPku3LnCxgWfwUe/pVxgYnkLBiLnteYWA0FioS
abygqPlDiA9crKe3Fgp3G2UGcwYkSWHgPYxjdo+nqKHlRyR6rAaFlSl8rg1j
zhAwjeskCSRJjVqScvHUUik50ZoY8ZI9EJ0BWgGZ0OOwa2MpirDkuqA+lfYk
IhdtdTWEEE1sQOgHBEsrndRnVLE+ybuT2Qu6oiGnRX4YNpcOWFSqHpbzTBN5
gyQ16XkjvQwXG7ovZBZxgJ3vLxwMAICgVVp4H/oZWTqZNGjuYVdSG76F0SAG
R49z6Y8vJNdeTd0P6QeOuUVmYDWFj5tUw1CWrfb4yK1OT0+6NiTiPca2hJbg
8wYDFIJyuK0nGTd0k7Aft0LccAGNPR3Lv0LfCemTLE7YpCNExpxQKooLeL9X
bA7Bg0JrDKPz/mLordpPtBwQWS7qQMngl9lMUzP8o3vO/eu4CHoHdYTEKwNA
TKu1b4VhdbAD+/ghJulE+4gyoPSp7KiZ0qB677NwgAPGL2n0gESHl4myV1wi
Sb74JBdP5ZyM7JkJwSyGdJ6P5FibsxjJWTspAn5GVpqFlSUsllnh8FRxsY0d
MWQEGetlMezKBPny5XvPv3tgSw4w0zb0gZM5ykYkW5bq5pgEwpIlJTShjlS4
Hr2r1kmlNlWzkVt8ulrrgXgVcNXuRqpNSGzGAAqc2HJg6sobRmYImnLYQt0h
Qu4rZ2cFOClucvvxF1UJwNpQ6qokaD9U1pBoJtnGhJALJnpKckvtphbn8qrj
MyoapfE0TvYwairOWKByYZdTU0GMJWqSlFRnyTxRHLm1cz0/WfFqhXw3WDGb
uqbx4rTYCRjL/Ag5jqT+ieIGrLgtgJDU2RTwt5vORRXSlaj694Avo38b+Ay/
dkqcfj0TWHVlpJUChTwnyC+eoW6AtKCTSH1hEkyFEs3dVEmN72A25aoqZdsm
UvXVJ4p/aAoTHgfkDeiQGBwHcN/H5R6xBkuLStLYYwJYi0o0OUYwYpjzya3n
AIFfdEmQZLBmksSM9lDEB2J/SUJEpg7NegEVC6j+JLOX/EE/NRKvqK1YloBC
zl4sZ0+HhtAONsvAequq3RxSmxxr7t3oEjlSKAgQRx6n+REQIez3gfcVgGpU
n8UPDozXyJ9/PZbJhdJpYlBLAP8DniGA1mM50lwKe4ZdcJukSbxEUhhAazki
kGI4jeTdiymQO54mrcXeZowwBt02qesbrVVqd/HZTalsg8Yp4exe2ROkwa8S
sDYBIgnWWpFYevOqiFSy55tXfvDr6aogqCmmQcxkTJxD7M2w9ue6Qgn+GetR
fde5C8KY7yLkpVMLxKF+Zgx8a2u+klI4fhDS2hOJfqQqwz4IaT4+6n6qFQMg
lh6z702eB/BNJlOGYii7zsBo4ZKEGAyKSglTrKuhtsXBRbwoXkCsXdoBeFYi
4PJw+XPUGypPaHJBZAEV0dxQi2hGW7JuLeqhXG9i6QhzCQ0x3OdBROZKWC/1
/oUFIB0IB0G/B+Fa5FSsKqSc7BHiyOZ5HD+L4SqDT7ClhGciMpt7tnKWHuT8
rB3WFXHJGjlprCxQUp7yMkCJj+aYOJSmGZr6Pg5Js8C65TMJlmRtYPPe0QAL
rsskHigy9JgfR7SDUsuRrkoRpc4Gqpc2G9qmZQNIh8WYCKzkNrb2luD6oKKN
Tcf93tmY3hEz3m3e7jldUHHfg7ZkPijXsZYSpjyPvsc15VbC43Z6dyuKwSo9
c27Tu1s4KbeHvAiaVqb3Ef5O66Yvr3Zh9ky8eJA9idElIJAWoZtc9F4Itls/
k7tlk+Q2TQXCA8UQpoQYP2Mo6Q7gG6hvg6iy/KqAzeEooFyEiB1FE0sCBeIx
K9VIT6skoWe41k6zCFvZeWwCQQCacl7UuXEC0BrE0xaSxCW9gTflAIY/jok7
bZClK8rZOLk4cPf3u52c5kyOn6z18hp0CWBhe1UmDrUCSRAQmSC1wWWpHAGX
qjKOMmkATWBfAkpeQoZSwh5VUbBo7RIrOAMqsUVCMp8cuUEqcqcSukHARAI3
skoE/Qx7W7S1ZW/r1AsSo7syzrvqbgV4kS7nYfBYnJgqxw0Yi3ZQ/vER7cyk
n+ja4+Px8alWVRycDDJTip+vAhDxL1fdfAmbyCdxCAvVElIpSHYvMow8Vtw3
WYp80bLTeUWj9qG96ZQsIiz4aPZzkHp3gXt5501ItTkbR5ebYjpA0BKoR5cC
tCcFp1EmLizBqpeB+JXzoIgprIIUUgA6lLiCADXdTUMkMRbI7qpbR3UslH8P
yhOig503zXVpsf2GoAj7HLkM58/TlQlEVugKHI0oc1odgSwml8PPlfKF0yWR
K0S/Ofs5KHkJlQKqatzL5O8c5+C40osj9MyayNAziQ1dJ6O1x60Fda7JTTyM
U7o6ZHL75RZD6IyCYRzdGEZiz/iAtvge/f3L7buKAvja6ea3jcrItsgd/X1+
m3N1RdqO/r7xZb55K7tTkfVpZcz6V5vaZMWxD3YD0AApvJB3hV2l2qTqKg3f
XLWbDWmzsZuleLvyoCWbRvB1Uho3Hc4LaVKkY1DHhk4iTmvykSraXmJh9Vz0
tOEsyjV9ZgwLAkOqOUi6/Fp4txjeNv8k0q3LTu00YdmwlNjjO1GQeauRLpCG
IyYCDjnwhpPXuoh5ZAqTCHAEDGQ7/Xk1PQ+rGiXyM8NirGLJDYSYtoppy4l7
rnEluqQFBVk4N2UcI12m01cm6KhH5IB8IcwsfghSrT7gcdoZPc5h6JSeW1s2
WddKkq/D7IohCynOInpARQ3mov00BR2wG0xalaWufgkMsUBO0AvawvcspREG
d6peuywoFqMKoZGkLlFi1ZLsQz4H/Sl5AVN136WBQnYe7TDl/obGwvM8yCDW
b1Qe1zsZpTNDsGzx8/Emkneb6QJfr/Iq7BZUUeoUVR/OWtHDoN15qxRJpkbW
jPxgdK9EmaVP+NAdxb2rFfBNObWGXzRahASLnssy4zU6LIuJfZX9r2kKfXxh
lyc9cQT/Qvt90oBq33ej4tYTOgxJ8nGs0CcBl5RaPoG7UgVNfczflEMlKEwm
EyE3t24vyEkc8GE12rTnCGj0bEkPIZP8c66Q51pPU1mDTRgl3mTicSQS9IIy
EDbkWHLlgoDNDLN9RR5HJ+/Zy8bbxBNTj3bUTvU0NVJkiHxRwjZL118oQp3J
Q2oTALExqstrjeYppXs2ivopU9Zpl4+xNSQV3rkUS/PIfvArG5DkfNNaShGh
OhljLDSr6EMXuJvjgaQ2AEnpAiPNTem9MBEqzGgzYtmBSqv0llnvLTjW4p1J
C3peZSF9y5W25bxfeX1PRL2Jn+V9TPUY1tXBsnHcJmvotRieZf9IiftSaVO2
25yZJBpFL1gRLzG5aNPJXKkI03kRbfxymQNRq5+xoVpA0ciD25I7zyNceeqR
K8O5O4x1TfpO404TaXFGj34K1ZkilLQ86usmM1Lgkha2852p3CMOuCZDKwy1
GK9Jx6ItnufaaXaau41FGStOrW3lsYaoSohSP9nt3traP//5Tzn6h3HnPOYn
BBWyREzkd/kdzcJ2j9sf2s1m5+/t1277e3nuqdy59o7nWZNMCVfMWjtuBFQu
jj5jN281xoHSHGyr2U0kXH6nx/kSfScfKV21wnJvneR4PrNJm/6htXQ9Fgjv
1r5mYMnkyMDVwSyoCxRpUNDNysAwwnRoMmDX1tepGJZ5nAuRZNc0b+99p10N
TiKJjyDJ3HJ1GcKOJP6ytOJY8MRN6d+pFcK6TNSmAb1hYgFUCM3UzpcljFYX
taOwFQ21kGefpVZv4QQLICzHg0ZYkSC2ZjPsmEdTtT+Wv1zSvYOg1PJTBCJy
qC1l2yw6ncp7V4smUXSIq3K2fDleEL8zUbEcDfY2wRz9rvBF7VL8YKizxvl+
V/xrliDvTAHaxuH+JnnAZRdHL+H5oSLzvnGmDTaEAL8FG/WYQIzwazAhYdX/
dzCxtrZEghsDShvdt7c347JEzbuGDR+UhYohZhN9Htg2TDhvfvddXXdapUtF
qrgLfshXBYex6GvM0xI48HkgKzNeUG5YwJz4ok0Lzp+UeouBGm6MzidbXGte
Qr+qP9oGp743OlW6VMNukr61FYddIbsM5UW3lSUVnkM6H30lfq6mlbKYMFKw
zqi9PZ/j2KLz+dUPRI23mlVKS2zWME49UHbZTp51ZXvtwZtDJx7NJOlrQa81
ZQmMZp4j+aOzIXfySw2n+tAmB+eqSlLrxfJm1ZkZe853MsV3jfyuveI9pwKB
6NLGtwzPAK8Yv7yg3zCBhbxnlrFssiexA66VVK7VEaidEqxpWFpN/XqfJ3Mc
gvUZw8uxtH9cQO9kPv3lTk0qz1Sg1uPUPbtRnaPhLDz2b6eZKgy/O9EsLOnf
RDXLEF2hG1SFlk9d8ELfhFIrnqKEb115kFzFY5Woiljnqmmd0vs6PxFSphQX
TnVv3jLnT869SGsCyiYkWD2uijWyP1aDWciNckgxVPWRXata9e6K+MZGybnb
rDccaXk+zZXQJkA19GPTYGTVLItSlI4NhFVNVMAEDKtLE2PGeI3GEdT193mJ
S6VRAbUbpgkAJR5SXylZQD6FYanWqdUuFWSnOanICQlMT/a2Cb3RX/JCLjDK
l//xj1xIlG4IeQJBAVoIRFHpupG6jcVeTEPdoFIYZodlsK1zFuj5x8dhMMIJ
hK4ZhePu/zQu4HN/Wl/11D++6qn7JU9d9U6RTHeOcZzH4Rc+dpBweci9XfJF
h98Riv/l4s/3zoFKgnvlyvgbzWZz8/+D1/81RJs/lckbzvqArwxwsMj67wvJ
CnYhNFS2/Ni0YZht//vSP98KyX/v2+8ESatm3869NJODKv+bV7/mdRa/j3vO
i6pwliNs/7h+aov9JVmXdbJPXr78tjOmmi9fcjztN7d8FvH/x8fKoeDIynFt
ZeXsb7qO2okiOWcOqYql0IRp2D4Bi6NVJVfQVFEiusWtcnWHFMJF1+cd1Chz
3cHLsLF9dm937zobck4ItLd1LCjOace5MlvF+TJsd2xKyUO1LkvPgXLK5VPY
KRIU6NThEaHN1BiXFduy6ODC8PoIhKHJyFpHe9bW1+eHS5TaWIpA4oIFJGta
mJFzg8Wpd2RHD/JfmC7PcNBzUs3SbBGcdoZRk2NtvNMEwStxUx1bZttmeZbn
SXL46co0EdlaEtKW0mRDXKUkFtfFcZ4q/JoVvSufHLCPU5jo6XP/kHw5XyHu
h5ILdCeXDFdpTCySF1yj3XndbrQ7rRy6PEYj5+1yl2p5GOEqfZyppixzwj/h
hNexEiMIvQ0xfOUoDqt5HI2jurVZyij44GZ61nZX89yYxhof55BnsaYod8rQ
n/Hy5YEuI9Z0m8cWmTj2q7FPG3hDIN9OPF5aLtBYTUmoeypWudj0YYEscd58
+6VvVjIR6OmVCg9u+TcHkkuMDwd2WbKs4aSE2XVSGVcsdfjg7jevd9fldDc5
pbS4+Phone/99MStz5JgRdXybJrDjHmEOFwcb1oqfShCn1Wk5QFXOzOfh6fB
ZHA2TF2cZ88glXGScLX2WbezcZ4Uxb2hHHOysqlAxNYSTqRJLmXHxfdDP2/u
+lkbkOb4Lx+BsBTVueBfdzbY1a3vIdo0jXqcYszTyHSL1HlBKvrEno2i7k1r
FWFGObAHDG3S0JAVwiZHXhDONFcsSqmStiyF+rnbhL88sEQoNMxBApH7q0ri
othauq2HMq+c1mVoaEzaQyQYN3hhO8UStaLE5YiHoQIhSzldxivars009JiG
c8zZ2VKbkZSqASXmcRwWo95hn3Xhb7mRX3qR8poeq0kZBQfc6WAKOe3DQGqg
Mk2S592fuGl1LqxtwKCFIT8+wxy6xp9Pa94vHcu5tsYXOfkv5Q6l/t68iqDu
S0vFwc+Pj/pjUbqQ0Aqfl8whox+saHf5aG+dei6+J2UhZ4KOOi63kV4ec/qL
FMr6WQGs1J3RX5C6BlYpTNUprxQN8hk+o+NYCmXpAiUSs35dlHKt08LC2SRy
9MGNBN/6xXperbl+gI9mXJ7WPfbTOm9GfoJ+eUPQJ67vuOUTVHXHcSVqpxuh
c+2yoqGlr0pPy6cKJFMmPYYiAXSD7Xpei7+nqymgbXRhtjbEfq/D5QKrG9m0
UsmXzXIDXr7rqOnLQxwJJ0PgdKkiA8m14emMdd7HyPT7W6dCLNb8C1NKWM8U
hxidY6sWE/trFNZpXoAGsqto63LM9qmagORc9cwL3avrI+MfcHLbWqfolsDE
zfi4X8WZ2mplfN0imRQ8nO42i/KTb718UjmvIYozY2twfw/JXTYt/6/Xjjak
9Bj0xJT5exduFpWalmTnKauNKEHZyLVOCFm0yCur1rX3rl79hjSqm1ImLZlJ
g6V8OJZZMEN+WcC6mavgkAxqTgfqAWXzLfQx7irGPgNMup8sGaVrtytwMeiY
434WwlnTh7pK/b+2vuEm35vDB/Uh5FwyykfX/DzjzoGhQuI4nqVcsqLPVX18
1J9x5BDvy5dXtnlnWfkN8yFM5klbYMkxyZo5xTkrpT5A+MpqrLBKvLiIM5/Q
nq9R01OVh/dX1YCZM0d1QYg5WFLIqHTqW/3R5ozqRnEwE7II3h03gQ4gFUnv
pNIZXVSf6pr5PNNYnCNIizTTmHVzbgOpkJQfDzL9XkkYAN04NYilOZ/dOwab
h1JSkASp7s4mkYwGTnRpaCCs1ohApL6cYFWVNnzckD4UTIMjpnU/jP27NK9i
DecyE9PpDD2b2QxxWdqrhHYYe+8rU8Yg58hKH6sAr6nUHKkKOM5m/t2cv6CY
4Qyqx0f9lT+tScw3sR4f9ae1cF1GQX3QLAFzA9IGPSJfjKYncpsInYI4zBCo
F8Qu2+ccXWXE2LK1EmmyRXUUa+TCgAj5gyUuiYmAmQEZpWElBvOg8hMueQoO
BulMdOlgCvsw/QafH8dgoygt+AKZKuKNdoHU0miG01PyOkt9eprKZRxPhQbf
SsG5OZnUqg6Cja7h4VpenAzGjUbRoCiz8ayjUgqzXRt20N2Sc6tRQ9JNSIuI
pYIJirNUtM5qivszSiiq9+ZKXxyoGAwbIvWknlq6yUCYfOKZCJD+vCo+cpM6
DwLYqT+r9rzG87cr05822Xbs+jgii1hhJEWspmaT5vF0ZGiUwGqQQ/fzKJg+
d3GCTCvoSnmjmSp5ZPtjNPLHkJPOpxjfKjon7si/FNxwDtFgsU8cfacyEqMH
KkgGtPNkxEYxn7In3y7Lyx/M13e0XWo+veryZ1Mk2FNtcPCDrGaDRWRPlHyo
VY8Oq730MRBdahiQmT7gBm98gzSbmZM/y98ImqglCEI/ImlXlZomnE/osR/H
U7Rbl44o7sXDjJ02AvccKh3drD8G6qFBOAsDmjUKPD5n+s9eNEP7Jz7VhkY2
InISuH9uOu8JIWmmAqlQvvGinz3+cKkyHzZReZe3HKNq2jhYx9W1I8GusXct
d0sy5U2wpJqPyZmPSQxKKfjZaKS/KYLmA/s78+ZLU2BetCP6pre+zDra05ZP
gSFQAfK9VpK+5i70xxeJ/OriV3Jyfigd8WS+V7j8fLmgOEWEveevOddDKmbN
a0Hlm7y/VCGQljGvODkINkQ/ju9ysw0hDP5ULJ/JdSQ+CmwmdLqtPh/P4x3t
tFpvG/qjXPnn7oujrSG5dXiLz9qSUyB8toD0kY8cYpOeOOsjb+bIfnuNVumn
PucRKwOXaLZCOGb5N1/zhIw57FJ//dKAj7cLNBTUhO+lT0Xqp4ai8/NfioPd
RNpbVRurvm9X18yHL5TDlyGrH9XXUGepUQ8iHOV0Sn1wVVUkaVen5kgzyJ4B
i8lyQFAi7su/FsYnGVSn0edNOe1mZ4+A1l9hBNyPj/vd86vuh4vu09PKF7fx
onypWd7TX36UX/SHG5+eli+dc1g4rmJBBi9GPb9qkYd8Fo0+P7M6Zt4xwQt+
v3/Ra7/S6z3cv/qhLT/zZ8/lR/39Xb22zgWj4+umYNTwsB1rrHa7+AWfkZXf
+NAWo0LVquGlN8jDuY5IHQyccewXXxeEmOJaJjlrRCyjfAg7IiLfCqseZPIx
0pJwgeLR8GoO8c2fwEAc7tDHLOkPV+aFt9jXVKcvyqePC5KC0ncOyP7TUQvt
nCk2n9hHkfAPC5sFhWsdsB1ZdgS3OetGtfLQYNC/3JCEw6fS2Ss0AbDAcKtz
cnhzlAvb1Ipjs8ZAsZeNHcRFCsixvJPTw/sOopLyQXZt+pOLirQUj7HiU5L2
y/L9dxZmMCvwsVO257UrDX/f4xK1VL5LkBuCrI35xAtJjlrH0RBG8K1EbSSe
XNNSHx8xMiNDl4N7vjdQE9LnITpceQ6Q6uGP0DD64waZ0q3hfJJuPRGkczIh
oJ7tj48KsOk7GpA/1ypscHB5cNJjuckBt+Pu9cUJUAfBylHbmuFrD+434y+M
5MeB7qbTx34ncR+xAxMBK5+E7rH+JeWXiO2fG8WplUgWtLPKQDcIaT0cE6oB
0LpTx81KZ0qUwjvLg42r1r6yB37t/wBwUsnAhosAAA==
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>The ideas in this document have grown from discussions with many collea
gues, including <contact fullname="Christopher Wood"/>, <contact fullname="Matt
Campagna"/>, <contact fullname="Eric Crockett"/>, <contact fullname="Deirdre Con
nolly"/>, authors of the various hybrid documents and implementations cited in t
his document, and members of the TLS Working Group. The immediate impetus for t
his document came from discussions with attendees at the Workshop on Post-Quantu
m Software in Mountain View, California in January 2019. <contact fullname="Dan
iel J. Bernstein"/> and <contact fullname="Tanja Lange"/> commented on the risks
of reuse of ephemeral public keys. <contact fullname="Matt Campagna"/> and the
team at Amazon Web Services provided additional suggestions. <contact fullname
="Nimrod Aviram"/> proposed restricting to fixed-length secrets.</t>
</section>
<!--[rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Internet Key Exchange Protocol Version 2 (IKEv2)
Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM)
eXtended Merkle Signature Scheme (XMSS)
b) Both the expansion and the acronym for the following terms are used
throughout the document. Would you like to update to using the expansion upon
first usage and the acronym for the rest of the document?
Diffie-Hellman (DH)
elliptic curve (EC)
Fujisaki-Okamoto (FO)
key encapsulation mechanism (KEM)
-->
<!-- [rfced] We updated <artwork> to <sourcecode> in Section 3.2.
Please review and let us know how/if the "type" attribute should be set for
these. Perhaps as type="tls-presentation" or type="pseudocode"?
The current list of preferred values for "type" is available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, feel free to
suggest additions for consideration. Note that it is also acceptable
to leave the "type" attribute not set.
-->
<!--[rfced] The questions below relate to the use of <em> in the document.
Note that <em> produces bold in the HTML/PDF outputs and encloses text
with asterisks in the TXT output. For more information about <em>, see
https://authors.ietf.org/en/rfcxml-vocabulary#em.
a) Section 1.4 ("Goals"): Is <em> needed in the unordered list? In particular,
please review the appearance in the TXT output (i.e., asterisks are used for
bullets and also used around the items enclosed in <em>).
b) Section 3.3: The text enclosed in <em> is not a complete sentence. Is the
intent to combine with the following sentence (Perhaps A), create a
sub-section (Perhaps B), or something else?
Original:
*FIPS-compliance of shared secret concatenation.* The US National
Institute of Standards and Technology (NIST) documents
[NIST-SP-800-56C] and [NIST-SP-800-135] give recommendations for key
derivation methods in key exchange protocols. ...
Perhaps A:
In regard to FIPS compliance, the US National
Institute of Standards and Technology (NIST) documents
[NIST-SP-800-56C] and [NIST-SP-800-135] give recommendations for key
derivation methods in key exchange protocols. ...
Perhaps B:
3.3.1. FIPS Compliance
The US National
Institute of Standards and Technology (NIST) documents
[NIST-SP-800-56C] and [NIST-SP-800-135] give recommendations for key
derivation methods in key exchange protocols. ...
c) Section 4: May we remove the <em> and update to use either <dl>
(Perhaps A) or separate subsections (Perhaps B)?
Original
*Larger public keys and/or ciphertexts.* The key_exchange field in
the KeyShareEntry struct in Section 3.2 limits public keys and
ciphertexts to 2^16-1 bytes.
...
*Duplication of key shares.* Concatenation of public keys in the
key_exchange field in the KeyShareEntry struct as described in
Section 3.2 can result in sending duplicate key shares.
Perhaps A:
Larger public keys and/or ciphertexts:
The key_exchange field in
the KeyShareEntry struct in Section 3.2 limits public keys and
ciphertexts to 2^16-1 bytes. ...
...
Duplication of key shares:
Concatenation of public keys in the
key_exchange field in the KeyShareEntry struct as described in
Section 3.2 can result in sending duplicate key shares. ...
Perhaps B:
4.1. Larger Public Keys and/or Ciphertexts
The key_exchange field in
the KeyShareEntry struct in Section 3.2 limits public keys and
ciphertexts to 2^16-1 bytes. ...
...
4.2. Duplication of Key Shares
Concatenation of public keys in the
key_exchange field in the KeyShareEntry struct as described in
Section 3.2 can result in sending duplicate key shares.
d) Section 6: Please confirm that <em> is intended for the entire sentence
here.
Original:
*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 ML-KEM.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether "master" should be updated.
In addition, please consider whether "traditional" should be updated for
clarity. While the NIST website indicates that this term is potentially
biased, it is also ambiguous. "Traditional" is a subjective term, as it is
not the same for everyone.
Link to NIST website:
https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-li
brary/nist-technical-series-publications-author-instructions#table1
--> -->
</back>
</rfc> </rfc>
 End of changes. 133 change blocks. 
1217 lines changed or deleted 919 lines changed or added

This html diff was produced by rfcdiff 1.48.