<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!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.3) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-tls-hybrid-design-16" number="9954" updates="" obsoletes="" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3"> version="3" xml:lang="en" consensus="true">

  <front>

<!-- xml2rfc v2v3 conversion 3.25.0 [rfced] Note that we have updated the short title, which appears
in the running header in the PDF output, as follows.

Original:
 ietf-tls-hybrid-design

Current:
 Hybrid Key Exchange in TLS 1.3
-->
  <front>

    <title abbrev="ietf-tls-hybrid-design">Hybrid key exchange abbrev="Hybrid Key Exchange in TLS 1.3">Hybrid Key Exchange in TLS 1.3</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-tls-hybrid-design-16"/> name="RFC" value="9954"/>
    <author initials="D." surname="Stebila" fullname="Douglas Stebila">
      <organization>University of Waterloo</organization>
      <address>
        <email>dstebila@uwaterloo.ca</email>
      </address>
    </author>
    <author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
      <organization>Cisco Systems</organization>
      <address>
        <email>sfluhrer@cisco.com</email>
      </address>
    </author>
    <author initials="S." surname="Gueron" fullname="Shay Gueron">
      <organization abbrev="U. Haifa &amp; Meta">University of Haifa and Meta</organization>
      <address>
        <email>shay.gueron@gmail.com</email>
      </address>
    </author>
    <date year="2025" month="September" day="07"/>
    <keyword>Internet-Draft</keyword> year="2026" month="April"/>

    <area>SEC</area>
    <workgroup>tls</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <?line 196?>
<t>Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way 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>
  </front>
  <middle>
    <?line 200?>

    <section anchor="introduction">
      <name>Introduction</name>
<!-- [rfced] How may we clarify "negotiated and transmitted" in this sentence?
Are these part of a series (i.e., viewed, negotiated, and transmitted) as
shown in Perhaps A, or should this phrase be revised as shown in Perhaps B?

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 using 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 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.</t>
      <t>This document does not propose specific post-quantum mechanisms; see <xref 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 prior to publication of a final version of this document.</t>
          </li>
        </ul>
        <t>Earlier versions of this document categorized various design decisions 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 secp384r1</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 range 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 reused 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 reuse.</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">
        <name>Terminology</name>
        <t>The
	<t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t>
        <?line -18?> here.
</t>
 <t>For the purposes of this document, it is helpful to be able to divide cryptographic algorithms into two classes:</t>
        <ul spacing="normal">
          <li>
            <t>"Traditional" algorithms: Algorithms that are widely deployed today, today but may be deprecated in the future.  In the context of TLS 1.3, examples of traditional key exchange algorithms include elliptic curve Elliptic Curve Diffie-Hellman (ECDH) using secp256r1 or x25519, x25519 or finite-field finite field Diffie-Hellman.</t>
          </li>
          <li>
<!-- [rfced] Please review the verbs in the phrase "may be that the
cryptographic community may have less confidence". Would updating as
shown below be correct?

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, deployed but may eventually be widely deployed.  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.  This includes "post-quantum" algorithms.</t>
          </li>
        </ul>
        <t>"Hybrid" key exchange, in
        <t>In this context, "hybrid" key exchange means the use of two (or more) key exchange algorithms based on different cryptographic assumptions, e.g., one traditional algorithm and one next-gen next-generation algorithm, with the purpose of the final session key being secure as long as at least one of the component key exchange algorithms remains unbroken.
When one of the algorithms is traditional and one of them is post-quantum, this is a Post-Quantum Traditional Hybrid Scheme <xref target="PQUIP-TERM"/>; target="RFC9794"/>; while this is the initial use case for this document, the document is not limited to this case.
	This document uses the term "component" algorithms to refer to the algorithms combined in a hybrid key exchange.</t>

        <t>Some researchers prefer the phrase term "composite" to refer to the use of multiple algorithms, algorithms to distinguish from "hybrid public key encryption" encryption", in which a key encapsulation mechanism and data encapsulation mechanism are combined to create public key encryption.</t>
        <t>It is intended that the component algorithms within a hybrid key exchange 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 algorithms.  However, it is possible that public key cryptography based on alternative mathematical constructions will be desired to mitigate risks independent of the advent of a quantum computer, for example example, because of a cryptanalytic breakthrough.  As such such, this document opts for the more generic term "next-generation" algorithms rather than exclusively "post-quantum" algorithms.</t>
        <t>Note that TLS 1.3 uses the phrase term "groups" to refer to key exchange algorithms -- for example, the <tt>supported_groups</tt> extension -- since all key exchange algorithms in TLS 1.3 are Diffie-Hellman-based.  As a result, some parts of this document will refer to data structures or messages with the term "group" in them despite using a key exchange algorithm that is neither Diffie-Hellman-based nor a group.</t>
      </section>
      <section anchor="motivation">
        <name>Motivation for use Use of hybrid key exchange</name> Hybrid Key Exchange</name>
        <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 less-well-studied algorithm) while still retaining at least the security currently offered by traditional algorithms.  They may even need to retain traditional algorithms due to regulatory constraints, for example example, US National Institute of Standards and Technology (NIST) FIPS compliance.</t>
        <t>Ideally, one would not use hybrid key exchange: one One would have confidence in a single algorithm and parameterization that will stand the test of time.  However, this may not be the case in the face of quantum computers and cryptanalytic advances more generally.</t>
        <t>Many (though not all) post-quantum algorithms currently under consideration are relatively new; they have not been subject to the same depth of study as RSA and finite-field finite field or elliptic curve Diffie-Hellman, and thus Diffie-Hellman; thus, the security community does not necessarily have as much confidence in their fundamental security, security or the concrete security level of specific parameterizations.</t>
        <t>Moreover, it is possible that after next-generation algorithms are defined, 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 cryptography due to the threat of retroactive decryption (also known as harvest-now-decrypt-later): if "harvest-now-decrypt-later"): If a cryptographic assumption is broken due to the advent of a quantum computer or some other cryptanalytic breakthrough, confidentiality of information can be broken retroactively by any adversary who has passively recorded handshakes and encrypted communications.  Hybrid key exchange enables potential security against retroactive decryption while not fully abandoning traditional cryptosystems.</t>
        <t>As such, there may be users for whom hybrid key exchange is an appropriate 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 anchor="scope">
        <name>Scope</name>
        <t>This document focuses on hybrid ephemeral key exchange in TLS 1.3 <xref target="TLS13"/>. target="RFC8446"/>.  It intentionally does not address:</t>
        <ul spacing="normal">
          <li>
            <t>Selecting which next-generation algorithms to use in TLS 1.3, 1.3 or algorithm identifiers or encoding mechanisms for next-generation algorithms.</t>
          </li>
          <li>
            <t>Authentication using next-generation algorithms.  While quantum computers could retroactively decrypt previous sessions, session authentication cannot be retroactively broken.</t>
          </li>
        </ul>
      </section>
      <section anchor="goals">
        <name>Goals</name>
        <t>The primary goal of a hybrid key exchange mechanism is to facilitate the establishment of a shared secret which that remains secure as long as one of the component key exchange mechanisms remains unbroken.</t>
        <t>In addition to the primary cryptographic goal, there may be several additional goals in the context of TLS 1.3:</t>
        <ul spacing="normal">
          <li>
            <t><strong>Backwards compatibility:</strong> 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 middleboxes that are not hybrid-aware.  The three scenarios to consider are:
            </t>
            <ol spacing="normal" type="1"><li>
                <t>Hybrid-aware client, hybrid-aware server: These parties should establish a hybrid shared secret.</t>
              </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>
              </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>
              </li>
            </ol>
            <t>
Ideally
Ideally, backwards compatibility should be achieved without extra round trips and without sending duplicate information; see below.</t>
          </li>
          <li>
            <t><strong>High performance:</strong> performance</strong>: Use of hybrid key exchange should not be prohibitively expensive in terms of computational performance.  In general general, this will depend on the performance characteristics of the specific cryptographic algorithms used, and used and, as such such, is outside the scope of this document.  See <xref target="PST"/> for preliminary results about performance characteristics.</t>
          </li>
          <li>
            <t><strong>Low latency:</strong> latency</strong>: Use of hybrid key exchange should not substantially increase the latency experienced to establish a connection.  Factors affecting this may include the following. following:
            </t>
            <ul spacing="normal">
              <li>
                <t>The computational performance characteristics of the specific algorithms used.  See above.</t>
              </li>
              <li>
                <t>The size of messages to be transmitted.  Public key and ciphertext 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, setting and <xref target="LANGLEY"/> for preliminary results on more realistic networks.</t>
              </li>
              <li>
                <t>Additional round trips added to the protocol.  See below.</t>
              </li>
            </ul>
          </li>
          <li>
            <t><strong>No extra round trips:</strong> trips</strong>: Attempting to negotiate hybrid key exchange should not lead to extra round trips in any of the three hybrid-aware/non-hybrid-aware scenarios listed above.</t>
          </li>
          <li>
            <t><strong>Minimal duplicate information:</strong> information</strong>: Attempting to negotiate hybrid key exchange should not mean having to send multiple public keys of the same type.</t>
          </li>
        </ul>
        <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 and the network involved.</t>
      </section>
    </section>
    <section anchor="kems">
      <name>Key encapsulation mechanisms</name> Encapsulation Mechanisms</name>
      <t>This document models key agreement as key encapsulation mechanisms (KEMs), which consist of three algorithms:</t>
      <ul spacing="normal">
        <li>
          <t><tt>KeyGen() -&gt; (pk, sk)</tt>: A probabilistic key generation algorithm, which generates a public key <tt>pk</tt> and a secret key <tt>sk</tt>.</t>
        </li>
        <li>
          <t><tt>Encaps(pk) -&gt; (ct, ss)</tt>: A probabilistic encapsulation algorithm, 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>
          <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 <tt>ss</tt> or, in some cases cases, a distinguished error value.</t>
        </li>
      </ul>

<!-- [rfced] Is "for example" needed in these sentences?

Original:
   IND-CCA2 corresponds to security against an active attacker, and the
   public key / 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).
   ...
   Diffie-Hellman key exchange, when viewed
   as a KEM, does not formally satisfy IND-CCA2 security, but is still
   safe to use for ephemeral key exchange in TLS 1.3, see for example
   [DOWLING].
   ...
   For additional perspectives on the general transition from traditional to
   post-quantum cryptography, see for example [ETSI], among others.

Perhaps:
   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 [KATZ] or [HHK] for definitions of IND-CCA2
   and IND-CPA security).
   ...
   Diffie-Hellman key exchange, when viewed
   as a KEM, does not formally satisfy IND-CCA2 security but is still
   safe to use for ephemeral key exchange in TLS 1.3, see
   [DOWLING].
   ...
   For additional perspectives on the general transition from traditional to
   post-quantum cryptography, see [ETSI].
-->

<!-- [rfced] Please review the placement of the parenthetical that starts with
"see, for example, [KATZ]" in the second sentence below (the surrounding
text is provided for context).  Note that IND-CPA is not discussed until
the following paragraph. Would it be helpful to make the parenthetical a
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 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 (see, for example 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) transform <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 should be indistinguishable from random strings given a copy of the public key.  IND-CPA roughly corresponds to security against a passive attacker, attacker and sometimes corresponds 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 secret
   g^(xy).
-->

      <t>Key exchange in TLS 1.3 is phrased in terms of Diffie-Hellman key exchange in a group.  DH key exchange can be modeled as a KEM, with <tt>KeyGen</tt> corresponding to selecting an exponent <tt>x</tt> as the secret key and computing the public key <tt>g^x</tt>; <tt>g^x</tt>, encapsulation corresponding to selecting an exponent <tt>y</tt>, <tt>y</tt> and computing the ciphertext <tt>g^y</tt> and the shared secret <tt>g^(xy)</tt>, and decapsulation as computing the shared secret <tt>g^(xy)</tt>. See <xref target="HPKE"/> target="RFC9180"/> for more details of such Diffie-Hellman-based key encapsulation mechanisms. Diffie-Hellman key exchange, when viewed as a KEM, does not formally satisfy IND-CCA2 security, security but is still safe to use for ephemeral key exchange in TLS 1.3, see 1.3; see, for example example, <xref target="DOWLING"/>.</t>
      <t>TLS 1.3 does not require that ephemeral public keys be used only in a single key exchange session; some implementations may reuse them, at the cost of limited forward secrecy.  As a result, any KEM used in the manner described in this document <bcp14>MUST</bcp14> explicitly be designed to be secure in the event that the public key is reused.  Finite-field  Finite field and elliptic-curve 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, implementations that do reuse KEM public keys <bcp14>MUST</bcp14> ensure that the number of reuses of a KEM public key abides by any bounds in the specification of the KEM or subsequent security analyses.  Implementations <bcp14>MUST NOT</bcp14> reuse randomness in the generation of KEM ciphertexts.</t>
    </section>
    <section anchor="construction">
      <name>Construction for hybrid key exchange</name> Hybrid Key Exchange</name>
      <section anchor="construction-negotiation">
        <name>Negotiation</name>
        <t>Each particular combination of algorithms in a hybrid key exchange will 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 ordered pair of two or more algorithms.  (Note that this is independent from future documents standardizing solely post-quantum key exchange methods, which would have to be assigned their own identifier.)</t>
      </section>
      <section anchor="construction-transmitting">
        <name>Transmitting public keys Public Keys and ciphertexts</name> Ciphertexts</name>
        <t>This document takes the relatively simple "concatenation approach": the The messages from the two or more algorithms being hybridized will be concatenated together and transmitted as a single value, value to avoid having to change existing data structures.  The values are directly concatenated, without any additional encoding or length fields; the representation and length of elements <bcp14>MUST</bcp14> be fixed once the algorithm is fixed.</t>
        <t>Recall that that, in TLS 1.3 <xref target="TLS13"/> Section 4.2.8, (<xref target="RFC8446" sectionFormat="comma" section="4.2.8"/>), a KEM public key or KEM ciphertext is represented as a <tt>KeyShareEntry</tt>:</t>
        <artwork><![CDATA[
        <sourcecode><![CDATA[
    struct {
        NamedGroup group;
        opaque key_exchange<1..2^16-1>;
    } KeyShareEntry;
]]></artwork> KeyShareEntry;]]></sourcecode>

        <t>These are transmitted in the <tt>extension_data</tt> fields of <tt>KeyShareClientHello</tt> and <tt>KeyShareServerHello</tt> extensions:</t>
        <artwork><![CDATA[
        <sourcecode><![CDATA[
    struct {
        KeyShareEntry client_shares<0..2^16-1>;
    } KeyShareClientHello;

    struct {
        KeyShareEntry server_share;
    } KeyShareServerHello;
]]></artwork> KeyShareServerHello;]]></sourcecode>

        <t>The client's shares are listed in descending order of client preference; 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>KeyShareEntry</tt> is the concatenation of the <tt>key_exchange</tt> field for each of the constituent algorithms.  The order of shares in the concatenation <bcp14>MUST</bcp14> be the same as the order of algorithms indicated in the definition of the <tt>NamedGroup</tt>.</t>
        <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</tt> algorithms, algorithms if that algorithm corresponds to a KEM; KEM or the (EC)DH ephemeral key share, share if that algorithm corresponds to an (EC)DH group.  For the server's share, the <tt>key_exchange</tt> value contains concatenation of the <tt>ct</tt> outputs of the corresponding KEMs' <tt>Encaps</tt> algorithms, algorithms if that algorithm corresponds to a KEM; KEM or the (EC)DH ephemeral key share, share if that algorithm corresponds to an (EC)DH group.</t>

        <t><xref target="TLS13"/> Section 4.2.8 target="RFC8446" section="4.2.8"/> requires that ``The "The key_exchange values for each KeyShareEntry <bcp14>MUST</bcp14> be generated independently.'' independently."  In the context of this document, since the same algorithm may appear in multiple named groups, groups; thus, this document relaxes the above requirement to allow the same key_exchange value for the same algorithm to be reused in multiple KeyShareEntry records sent within the same <tt>ClientHello</tt>.  However, key_exchange values for different algorithms <bcp14>MUST</bcp14> be generated independently. Explicitly, if the <tt>NamedGroup</tt> is the hybrid key exchange <tt>MyECDHMyPQKEM</tt>, the <tt>KeyShareEntry.key_exchange</tt> values <bcp14>MUST</bcp14> be generated in one of the following two ways:</t>
        <t>Fully independently:</t>
        <artwork><![CDATA[
        <sourcecode type=""><![CDATA[
MyECDHMyPQKEM.KeyGen() = (MyECDH.KeyGen(), MyPQKEM.KeyGen())

KeyShareClientHello {
    KeyShareEntry {
        NamedGroup: 'MyECDH',
        key_exchange: MyECDH.KeyGen()
    },
    KeyShareEntry {
        NamedGroup: 'MyPQKEM',
        key_exchange: MyPQKEM.KeyGen()
    },
    KeyShareEntry {
        NamedGroup: 'MyECDHMyPQKEM',
        key_exchange: MyECDHMyPQKEM.KeyGen()
    },
}
]]></artwork>
}]]></sourcecode>

        <t>Reusing key_exchange values of the same component algorithm within the same <tt>ClientHello</tt>:</t>
        <artwork><![CDATA[
        <sourcecode type=""><![CDATA[
myecdh_key_share = MyECDH.KeyGen()
mypqkem_key_share = MyPQKEM.KeyGen()
myecdh_mypqkem_key_share = (myecdh_key_share, mypqkem_key_share)

KeyShareClientHello {
    KeyShareEntry {
        NamedGroup: 'MyECDH',
        key_exchange: myecdh_key_share
    },
    KeyShareEntry {
        NamedGroup: 'MyPQKEM',
        key_exchange: mypqkem_key_share
    },
    KeyShareEntry {
        NamedGroup: 'MyECDHMyPQKEM',
        key_exchange: myecdh_mypqkem_key_share
    },
}
]]></artwork>
}]]></sourcecode>
      </section>
      <section anchor="construction-shared-secret">
        <name>Shared secret calculation</name>
        <t>Here Secret Calculation</name>

<!-- [rfced] May we update this sentence as follows to clarify "Here"? In the
suggested text below, we removed "Here" and added "for the calculation of
shared secrets" after "concatenation approach".

Original:
   Here this document also takes a simple "concatenation approach": the
   two shared secrets are concatenated together and used as the shared
   secret in the existing TLS 1.3 key schedule.

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 the existing TLS 1.3 key schedule.  Again, this document does not add any additional structure (length fields) in the concatenation procedure: procedure; for both the traditional groups and post quantum KEMs, the shared secret output length is fixed for 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>
        <artwork><![CDATA[ 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>
-->

        <artwork><![CDATA[
concatenated_shared_secret = MyECDH.shared_secret || MyPQKEM.shared_secret]]></artwork>

        <t>and inserted into the TLS 1.3 key schedule in place of the (EC)DHE shared secret, as shown in <xref target="fig-key-schedule"/>.</t>
        <figure anchor="fig-key-schedule">
          <name>Key schedule Schedule for hybrid key exchange</name> Hybrid Key Exchange</name>
          <artwork><![CDATA[
                                    0
                                    |
                                    v
                      PSK ->  HKDF-Extract = Early Secret
                                    |
                                    +-----> Derive-Secret(...)
                                    +-----> Derive-Secret(...)
                                    +-----> Derive-Secret(...)
                                    |
                                    v
                              Derive-Secret(., "derived", "")
                                    |
                                    v
concatenated_shared_secret -> HKDF-Extract = Handshake Secret
^^^^^^^^^^^^^^^^^^^^^^^^^^          |
                                    +-----> Derive-Secret(...)
                                    +-----> Derive-Secret(...)
                                    |
                                    v
                              Derive-Secret(., "derived", "")
                                    |
                                    v
                         0 -> HKDF-Extract = Master Secret
                                    |
                                    +-----> Derive-Secret(...)
                                    +-----> Derive-Secret(...)
                                    +-----> Derive-Secret(...)
                                    +-----> Derive-Secret(...)
]]></artwork> Derive-Secret(...)]]></artwork>
        </figure>
        <t><strong>FIPS-compliance

<!--[rfced] May we update "non-approved" to "unapproved" in the sentence
below?

Original:
   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 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 target="NIST-SP-800-56C"/> and <xref target="NIST-SP-800-135"/> give recommendations for key derivation methods in key exchange protocols.  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 a non-approved algorithm (e.g., post-quantum).  <xref target="NIST-SP-800-56C"/> lists simple concatenation as an approved method for generation of a hybrid shared secret in which one of the constituent shared secret secrets is from an approved method.</t>
      </section>
    </section>
    <section anchor="discussion">
      <name>Discussion</name>
      <t><strong>Larger public keys and/or ciphertexts.</strong>

<!-- [rfced] Would adding a reference for "Classic McEliece" be helpful here?
If so, please provide the reference entry.

Original:
   Some post-quantum KEMs have larger
   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 target="construction-transmitting"/> limits public keys and ciphertexts to 2^16-1 2<sup>16</sup>-1 bytes.  Some post-quantum KEMs have larger public keys and/or ciphertexts; for example, Classic McEliece's smallest parameter set has a public key size of 261,120 bytes.  However, all defined parameter sets for ML-KEM the Module-Lattice-Based Key
   Encapsulation Mechanism (ML-KEM) <xref target="NIST-FIPS-203"/> have public keys and ciphertexts that fall within the TLS constraints (although this may result in ClientHello messages larger than a single packet).</t>
      <t><strong>Duplication of key shares.</strong>
Concatenation of public keys in the <tt>key_exchange</tt> field in the <tt>KeyShareEntry</tt> struct as described in <xref target="construction-transmitting"/> can result in sending duplicate key shares.  For example, if a client wanted wants to offer support for two combinations, say "SecP256r1MLKEM768" and "X25519MLKEM768" <xref target="ECDHE-MLKEM"/>, target="I-D.kwiatkowski-tls-ecdhe-mlkem"/>, it would end up sending two ML-KEM-768 public keys, since the <tt>KeyShareEntry</tt> for each combination contains its own copy of a an ML-KEM-768 key.  This duplication may be more problematic for post-quantum algorithms which that have larger public keys.  On the other hand, if the client wants to offer, for example example, "SecP256r1MLKEM768" and "secp256r1" (for backwards compatibility), there is relatively little duplicated data (as the secp256r1 keys are comparatively small).</t>
      <t><strong>Failures.</strong>
Some post-quantum key exchange algorithms, including ML-KEM <xref target="NIST-FIPS-203"/>,
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>

<!-- [rfced] IANA Considerations section

a) The only mention of this document in the "TLS Supported Groups" registry is
the Reference at the top of the registry. We have non-zero probability thus added a sentence to the
IANA Considerations section to indicate this (see Current below). The rest of failure, meaning two honest parties
the text in the IANA Considerations section seems to be contain instructions
for future registrations in the registry. Link to registry:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

b) How may derive different shared secrets.  This would cause a handshake failure.  ML-KEM has a cryptographically small failure rate; if other algorithms 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 used, implementers two
ranges from which assignments should not be aware of made (see Perhaps A), or we could
update to specify the potential of handshake failure. Clients <bcp14>MAY</bcp14> retry if a failure is encountered.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA 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 <xref target="IANATLS"/>
   [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 <bcp14>SHOULD</bcp14> 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 addition,
   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" registry <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 anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The shared secrets computed in the hybrid key exchange should be computed in a way that achieves the "hybrid" property: the The resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken.  See <xref target="GIACON"/> and <xref target="BINDEL"/> for an investigation of these issues.  Under the assumption that shared secrets are fixed length once the combination is fixed, the construction from in <xref target="construction-shared-secret"/> corresponds to the dual-PRF combiner of <xref target="BINDEL"/> target="BINDEL"/>, which is shown to preserve security under the assumption that the hash function is a dual-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 event 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 security properties.  However, some other post-quantum KEMs designed to be IND-CPA-secure (i.e., without countermeasures such as the FO transform) are completely insecure under public key reuse; for example, some lattice-based IND-CPA-secure KEMs are vulnerable to attacks that recover the private key after just a few thousand samples <xref target="FLUHRER"/>.</t>
      <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>
      <t>Note that variable-length secrets are, generally speaking, dangerous.  In particular, when using key material of variable length and processing it using hash functions, a timing side channel may arise.  In broad terms, when the secret is longer, the hash function may need to process more blocks internally.  In some unfortunate circumstances, this has led to timing attacks, e.g., the Lucky Thirteen <xref target="LUCKY13"/> and Raccoon <xref target="RACCOON"/> attacks.</t>
      <t>Furthermore, <xref target="AVIRAM"/> identified identifies a risk of using variable-length secrets when the hash function used in the key derivation function is no 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 that the composition of the two values is injective and requires a mechanism different from that specified in this document.</t>
      <t>Therefore, this specification <bcp14>MUST</bcp14> only be used with algorithms which that have fixed-length shared secrets (after the variant has been fixed by the algorithm identifier in the <tt>NamedGroup</tt> negotiation in <xref target="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 the 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 Mountain View, California, in January 2019.  Daniel J. Bernstein and Tanja Lange commented on the risks of reuse of ephemeral public keys.  Matt Campagna and the team at Amazon Web Services provided additional suggestions.  Nimrod Aviram proposed restricting to fixed-length secrets.</t>
    </section>
  </middle>
  <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-HYBRID"/>
    <displayreference target="RFC8446" to="TLS13"/>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="FO">
          <front>
            <title>Secure Integration of Asymmetric and Symmetric Encryption Schemes</title>
            <author fullname="Eiichiro Fujisaki" initials="E." surname="Fujisaki">
              <organization/>
            </author>
            <author fullname="Tatsuaki Okamoto" initials="T." surname="Okamoto">
              <organization/>
            </author>
            <date month="December" year="2011"/>
          </front>
          <seriesInfo name="Journal
          <refcontent>Journal of Cryptology" value="vol. Cryptology, vol. 26, no. 1, pp. 80-101"/> 80-101</refcontent>
          <seriesInfo name="DOI" value="10.1007/s00145-011-9114-1"/>
          <refcontent>Springer Science and Business Media LLC</refcontent>
        </reference>
        <reference anchor="HHK">
          <front>
            <title>A Modular Analysis of the Fujisaki-Okamoto Transformation</title>
            <author fullname="Dennis Hofheinz" initials="D." surname="Hofheinz">
              <organization/>
            </author>
            <author fullname="Kathrin Hövelmanns" initials="K." surname="Hövelmanns">
              <organization/>
            </author>
            <author fullname="Eike Kiltz" initials="E." surname="Kiltz">
              <organization/>
            </author>
            <date year="2017"/>
          </front>
          <seriesInfo name="Lecture
          <refcontent>Theory of Cryptography (TCC 2017), Lecture Notes in Computer Science" value="pp. 341-371"/> Science, vol. 10677, pp. 341-371</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-319-70500-2_12"/>
          <seriesInfo name="ISBN" value="[&quot;9783319704999&quot;, &quot;9783319705002&quot;]"/>
          <refcontent>Springer International Publishing</refcontent>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      </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 2119 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 Words</title>
            <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 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 protocol 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) Internet Key Exchange Protocol
              Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May
              2023, <https://www.rfc-editor.org/info/rfc9370>.

a.1) Related to the Transport Layer Security (TLS) protocol. TLS allows client/server applications above, if [IKE-HYBRID] is updated to [RFC9370], are any
changes needed to communicate over the Internet in a way text that includes the citation?

Current:
   Considering other IETF standards, there is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, work on post-quantum
   preshared keys in Internet Key Exchange Protocol Version 2 (IKEv2)
   [IKE-PSK] and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words a framework for use hybrid key exchange in RFCs to Indicate Requirement Levels</title>
            <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 signify IKEv2
   [IKE-HYBRID].

Perhaps:
   [RFC9370] on the requirements multiple key exchanges in the specification. These words are often capitalized. This document defines these words Internet Key Exchange
   Protocol Version 2 (IKEv2) has been published as they should 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 interpreted 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 IETF documents. This document specifies an Internet Best Current Practices 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 Internet Community, and requests discussion and suggestions following references to match reference
style guidance for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
      </references> 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>
        <reference anchor="AVIRAM" target="https://mailarchive.ietf.org/arch/msg/tls/F4SVeL2xbGPaPB2GW_GkBbD_a5M/">
          <front>
            <title>[TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3</title>
            <author initials="" surname="Nimrod Aviram">
              <organization/>
            </author>
            <author initials="" surname="Benjamin Dowling">
              <organization/>
            </author>
            <author initials="" surname="Ilan Komargodski">
              <organization/>
            </author>
            <author initials="" surname="Kenny Paterson">
              <organization/>
            </author>
            <author initials="" surname="Eyal Ronen">
              <organization/>
            </author>
            <author initials="" surname="Eylon Yogev">
              <organization/>
            </author>
            <date year="2021" month="September" day="01"/>
          </front>
        </reference>
        <reference anchor="BCNS15">
          <front>
            <title>Post-Quantum Key Exchange for the TLS Protocol from the Ring Learning with Errors Problem</title>
            <author fullname="Joppe W. Bos" initials="J." surname="Bos">
              <organization/>
            </author>
            <author fullname="Craig Costello" initials="C." surname="Costello">
              <organization/>
            </author>
            <author fullname="Michael Naehrig" initials="M." surname="Naehrig">
              <organization/>
            </author>
            <author fullname="Douglas Stebila" initials="D." surname="Stebila">
              <organization/>
            </author>
            <date month="May" year="2015"/>
          </front>
          <seriesInfo name="2015
          <refcontent>2015 IEEE Symposium on Security and Privacy" value="pp. 553-570"/> Privacy, pp. 553-570</refcontent>
          <seriesInfo name="DOI" value="10.1109/sp.2015.40"/>
          <refcontent>IEEE</refcontent>
        </reference>
        <reference anchor="BERNSTEIN">
          <front>
            <title>Post-Quantum Cryptography</title>
            <author>
              <organization/>
            </author>
            <author fullname="Daniel J. Bernstein" role="editor"/>
            <author fullname="Johannes Buchmann" role="editor"/>
            <author fullname="Erik Dahmen" role="editor"/>
            <date year="2009"/>
          </front>
          <seriesInfo name="DOI" value="10.1007/978-3-540-88702-7"/>
          <seriesInfo name="ISBN" value="[&quot;9783540887010&quot;, &quot;9783540887027&quot;]"/>
          <refcontent>Springer Berlin Heidelberg</refcontent> Berlin</refcontent>
        </reference>
        <reference anchor="BINDEL">
          <front>
            <title>Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange</title>
            <author fullname="Nina Bindel" initials="N." surname="Bindel">
              <organization/>
            </author>
            <author fullname="Jacqueline Brendel" initials="J." surname="Brendel">
              <organization/>
            </author>
            <author fullname="Marc Fischlin" initials="M." surname="Fischlin">
              <organization/>
            </author>
            <author fullname="Brian Goncalves" initials="B." surname="Goncalves">
              <organization/>
            </author>
            <author fullname="Douglas Stebila" initials="D." surname="Stebila">
              <organization/>
            </author>
            <date year="2019"/>
          </front>
          <seriesInfo name="Lecture
          <refcontent>Post-Quantum Cryptography (PQCrypto 2019), Lecture Notes in Computer Science" value="pp. 206-226"/> Science, vol. 11505, pp. 206-226</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-030-25510-7_12"/>
          <seriesInfo name="ISBN" value="[&quot;9783030255091&quot;, &quot;9783030255107&quot;]"/>
          <refcontent>Springer International Publishing</refcontent>
        </reference>
        <reference anchor="CAMPAGNA">
          <front>
            <title>Hybrid Post-Quantum Key Encapsulation Methods (PQ KEM) for Transport 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
<!-- [CAMPAGNA]
draft-campagna-tls-bike-sike-hybrid-07
IESG State: Expired 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> 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">
          <front>
            <title>Experimenting with Post-Quantum Cryptography</title>
            <author initials="M." surname="Braithwaite">
              <organization/>
            </author>
            <date year="2016" month="July" day="07"/>
          </front>
          <refcontent>Google Security Blog</refcontent>
        </reference>
        <reference anchor="CECPQ2" target="https://www.imperialviolet.org/2018/12/12/cecpq2.html">
          <front>
            <title>CECPQ2</title>
            <author initials="A." surname="Langley">
              <organization/>
            </author>
            <date year="2018" month="December" day="12"/>
          </front>
        </reference>
        <reference anchor="DODIS">
          <front>
            <title>Chosen-Ciphertext Security of Multiple Encryption</title>
            <author fullname="Yevgeniy Dodis" initials="Y." surname="Dodis">
              <organization/>
            </author>
            <author fullname="Jonathan Katz" initials="J." surname="Katz">
              <organization/>
            </author>
            <date year="2005"/>
          </front>
          <seriesInfo name="Lecture
          <refcontent>Theory of Cryptography (TCC 2005), Lecture Notes in Computer Science" value="pp. 188-209"/> Science, vol. 3378, pp. 188-209</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-540-30576-7_11"/>
          <seriesInfo name="ISBN" value="[&quot;9783540245735&quot;, &quot;9783540305767&quot;]"/>
          <refcontent>Springer Berlin Heidelberg</refcontent>
        </reference>
        <reference anchor="DOWLING">
          <front>
            <title>A Cryptographic Analysis of the TLS 1.3 Handshake Protocol</title>
            <author fullname="Benjamin Dowling" initials="B." surname="Dowling">
              <organization/>
            </author>
            <author fullname="Marc Fischlin" initials="M." surname="Fischlin">
              <organization/>
            </author>
            <author fullname="Felix Günther" initials="F." surname="Günther">
              <organization/>
            </author>
            <author fullname="Douglas Stebila" initials="D." surname="Stebila">
              <organization/>
            </author>
            <date month="July" year="2021"/>
          </front>
          <seriesInfo name="Journal
          <refcontent>Journal of Cryptology" value="vol. Cryptology, vol. 34, no. 4"/> article 37</refcontent>
          <seriesInfo name="DOI" value="10.1007/s00145-021-09384-1"/>
          <refcontent>Springer Science and Business Media LLC</refcontent>
        </reference>
        <reference anchor="ETSI" target="https://www.etsi.org/images/files/ETSIWhitePapers/QuantumSafeWhitepaper.pdf">
          <front>
            <title>Quantum safe cryptography Safe Cryptography and security: Security: An introduction, benefits, enablers and challengers</title>
            <author initials="M." surname="Campagna" role="editor">
              <organization/>
            </author>
            <author initials="" surname="others">
              <organization/>
            <author>
              <organization>Campagna, M., Ed., et al.</organization>
            </author>
            <date year="2015" month="June"/>
          </front>
          <seriesInfo name="ETSI
          <refcontent>ETSI White Paper No. 8" value=""/> 8</refcontent>
        </reference>
        <reference anchor="EVEN">
          <front>
            <title>On the Power of Cascade Ciphers</title>
            <author fullname="S. Even" initials="S." surname="Even">
              <organization/>
            </author>
            <author fullname="O. Goldreich" initials="O." surname="Goldreich">
              <organization/>
            </author>
            <date year="1984"/>
          </front>
          <seriesInfo name="Advances
          <refcontent>Advances in Cryptology" value="pp. 43-50"/> Cryptology, pp. 43-50</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-1-4684-4730-9_4"/>
          <seriesInfo name="ISBN" value="[&quot;9781468447323&quot;, &quot;9781468447309&quot;]"/>
          <refcontent>Springer US</refcontent>
        </reference>
        <reference anchor="EXTERN-PSK">
          <front>
            <title>TLS 1.3 Extension for Certificate-Based Authentication with an 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 server 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>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8773.xml"/>
        <reference anchor="FLUHRER" target="https://eprint.iacr.org/2016/085">
          <front>
            <title>Cryptanalysis of ring-LWE based key exchange with key share reuse</title>
            <author initials="S." surname="Fluhrer">
              <organization/>
            </author>
            <date year="2016" month="January"/> year="2016"/>
          </front>
          <seriesInfo name="Cryptology
          <refcontent>Cryptology ePrint Archive, Report 2016/085" value=""/> Paper 2016/085</refcontent>
        </reference>
        <reference anchor="FRODO">
          <front>
            <title>Frodo: Take off the Ring! Practical, Quantum-Secure Key Exchange from LWE</title>
            <author fullname="Joppe Bos" initials="J." surname="Bos">
              <organization>NXP Semiconductors, Eindhoven, Netherlands</organization>
            </author>
            <author fullname="Craig Costello" initials="C." surname="Costello">
              <organization>Microsoft Research, Redmond, WA, USA</organization>
            </author>
            <author fullname="Leo Ducas" initials="L." surname="Ducas">
              <organization>CWI, Amsterdam, Netherlands</organization>
            </author>
            <author fullname="Ilya Mironov" initials="I." surname="Mironov">
              <organization>Google, Mountain View, CA, USA</organization>
            </author>
            <author fullname="Michael Naehrig" initials="M." surname="Naehrig">
              <organization>Microsoft Research, Redmond, WA, USA</organization>
            </author>
            <author fullname="Valeria Nikolaenko" initials="V." surname="Nikolaenko">
              <organization>Stanford University, Stanford, CA, USA</organization>
            </author>
            <author fullname="Ananth Raghunathan" initials="A." surname="Raghunathan">
              <organization>Google, Mountain View, CA, USA</organization>
            </author>
            <author fullname="Douglas Stebila" initials="D." surname="Stebila">
              <organization>McMaster University, Hamilton, ON, Canada</organization>
            </author>
            <date month="October" year="2016"/>
          </front>
          <seriesInfo name="Proceedings
          <refcontent>Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications" value="Security"/> Communications Security, pp. 1006-1018</refcontent>
          <seriesInfo name="DOI" value="10.1145/2976749.2978425"/>
          <refcontent>ACM</refcontent>
        </reference>
        <reference anchor="GIACON">
          <front>
            <title>KEM Combiners</title>
            <author fullname="Federico Giacon" initials="F." surname="Giacon">
              <organization/>
            </author>
            <author fullname="Felix Heuer" initials="F." surname="Heuer">
              <organization/>
            </author>
            <author fullname="Bertram Poettering" initials="B." surname="Poettering">
              <organization/>
            </author>
            <date year="2018"/>
          </front>
          <seriesInfo name="Lecture
          <refcontent>Public-Key Cryptography (PKC 2018), Lecture Notes in Computer Science" value="pp. 190-218"/> Science, vol. 10769, pp. 190-218</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-319-76578-5_7"/>
          <seriesInfo name="ISBN" value="[&quot;9783319765778&quot;, &quot;9783319765785&quot;]"/>
          <refcontent>Springer International Publishing</refcontent>
        </reference>
        <reference anchor="HARNIK">
          <front>
            <title>On Robust Combiners for Oblivious Transfer and Other Primitives</title>
            <author fullname="Danny Harnik" initials="D." surname="Harnik">
              <organization/>
            </author>
            <author fullname="Joe Kilian" initials="J." surname="Kilian">
              <organization/>
            </author>
            <author fullname="Moni Naor" initials="M." surname="Naor">
              <organization/>
            </author>
            <author fullname="Omer Reingold" initials="O." surname="Reingold">
              <organization/>
            </author>
            <author fullname="Alon Rosen" initials="A." surname="Rosen">
              <organization/>
            </author>
            <date year="2005"/>
          </front>
          <seriesInfo name="Lecture
          <refcontent>Advances in Cryptology (EUROCRYPT 2005), Lecture Notes in Computer Science" value="pp. 96-113"/> Science, vol. 3494, pp. 96-113</refcontent>
          <seriesInfo name="DOI" value="10.1007/11426639_6"/>
          <seriesInfo name="ISBN" value="[&quot;9783540259107&quot;, &quot;9783540320555&quot;]"/>
          <refcontent>Springer Berlin Heidelberg</refcontent>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9180.xml"/>
        <reference anchor="HPKE"> anchor="IANA-TLS" target="https://www.iana.org/assignments/tls-parameters">
          <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 encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated 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 derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key 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 anchor="IANATLS" target="https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8">
          <front>
            <title>Transport Layer Security (TLS) Parameters - TLS
            <title>TLS Supported Groups</title>
            <author initials="" surname="Internet Assigned Numbers Authority">
              <organization/>
            <author>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

<reference anchor="IKE-HYBRID"> anchor="I-D.tjhai-ipsecme-hybrid-qske-ikev2" target="https://datatracker.ietf.org/doc/html/draft-tjhai-ipsecme-hybrid-qske-ikev2-04">
   <front>
      <title>Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2)</title>
      <author fullname="C. Tjhai" initials="C." surname="Tjhai"> surname="Tjhai" fullname="C. Tjhai">
         <organization>Post-Quantum</organization>
      </author>
      <author fullname="M. Tomlinson" initials="M." surname="Tomlinson"> surname="Tomlinson" fullname="M. Tomlinson">
         <organization>Post-Quantum</organization>
      </author>
      <author fullname="grbartle@cisco.com" initials="" surname="grbartle@cisco.com"> initials="G." surname="Bartlett" fullname="G. Bartlett">
         <organization>Cisco Systems</organization>
      </author>
      <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer"> surname="Fluhrer" fullname="Scott Fluhrer">
         <organization>Cisco Systems</organization>
      </author>
      <author fullname="Daniel Van Geest" initials="D." surname="Van Geest" fullname="Daniel Van Geest">
         <organization>ISARA Corporation</organization>
      </author>
      <author fullname="Oscar Garcia-Morchon" initials="O." surname="Garcia-Morchon"> surname="Garcia-Morchon" fullname="Oscar Garcia-Morchon">
         <organization>Philips</organization>
      </author>
      <author fullname="Valery Smyslov" initials="V." surname="Smyslov"> surname="Smyslov" fullname="Valery 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>
            </abstract> day="9" year="2019" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-tjhai-ipsecme-hybrid-qske-ikev2-04"/>
        </reference>
        <reference anchor="IKE-PSK">
          <front>
            <title>Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security</title>
            <author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
            <author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
            <date month="June" year="2020"/>
            <abstract>
              <t>The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8784"/>
          <seriesInfo name="DOI" value="10.17487/RFC8784"/> value="draft-tjhai-ipsecme-hybrid-qske-ikev2-04" />

</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8784.xml"/>
        <reference anchor="KATZ">
          <front>
            <title>Introduction to Modern Cryptography, Third Edition</title> Cryptography</title>
            <author initials="J." surname="Katz">
              <organization/>
            </author>
            <author initials="Y." surname="Lindell">
              <organization/>
            </author>
            <date year="2021"/>
          </front>
          <seriesInfo name="CRC Press" value=""/>
        </reference>
        <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="Kwiatkowski">
              <organization>Cloudflare</organization>
            </author>
            <date day="5" month="November" year="2018"/>
            <abstract>
              <t>   This draft specifies a TLS key exchange that combines the post-
   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-00"/>
          <refcontent>Third Edition</refcontent>
          <refcontent>CRC Press</refcontent>
        </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">
          <front>
            <title>Post-quantum confidentiality for TLS</title>
            <author initials="A." surname="Langley">
              <organization/>
            </author>
            <date year="2018" month="April" day="11"/>
          </front>
        </reference>
        <reference anchor="LUCKY13">
          <front>
            <title>Lucky Thirteen: Breaking the TLS and DTLS Record Protocols</title>
            <author fullname="N. J. Al Fardan" initials="N." surname="Al Fardan">
              <organization/>
            </author>
            <author fullname="K. G. Paterson" initials="K." surname="Paterson">
              <organization/>
            </author>
            <date month="May" year="2013"/>
          </front>
          <seriesInfo name="2013
          <refcontent>2013 IEEE Symposium on Security and Privacy" value="pp. 526-540"/> Privacy, pp. 526-540</refcontent>
          <seriesInfo name="DOI" value="10.1109/sp.2013.42"/>
          <refcontent>IEEE</refcontent>
        </reference>
        <reference anchor="NIELSEN">
          <front>
            <title>Quantum Computation and Quantum Information</title>
            <author initials="M. A." surname="Nielsen">
              <organization/>
            </author>
            <author initials="I. L." surname="Chuang">
              <organization/>
            </author>
            <date year="2000"/>
          </front>
          <seriesInfo name="Cambridge
          <refcontent>Cambridge University Press" value=""/> Press</refcontent>
        </reference>
        <reference anchor="NIST" target="https://www.nist.gov/pqcrypto">
          <front>
            <title>Post-Quantum Cryptography</title>
            <author>
              <organization>National Institute of Standards and Technology (NIST)</organization>
              <organization>NIST</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

        <reference anchor="NIST-FIPS-203"> anchor="NIST-FIPS-203" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf">
          <front>
            <title>Module-lattice-based key-encapsulation mechanism standard</title>
            <title>Module-Lattice-Based Key-Encapsulation Mechanism Standard</title>
            <author>
              <organization/>
              <organization abbrev="NIST">National Institute of Standards and Technology</organization>
            </author>
            <date month="August" year="2024"/>
          </front>
          <seriesInfo name="NIST FIPS" value="203"/>
          <seriesInfo name="DOI" value="10.6028/nist.fips.203"/>
          <refcontent>National Institute of Standards and Technology (U.S.)</refcontent> value="10.6028/NIST.FIPS.203"/>
        </reference>

        <reference anchor="NIST-SP-800-56C">
          <front>
            <title>Recommendation for Key-Derivation Methods in Key-Establishment Schemes</title>
            <author fullname="Elaine Barker" initials="E." surname="Barker">
              <organization/>
            </author>
            <author fullname="Lily Chen" initials="L." surname="Chen">
              <organization/>
            </author>
            <author fullname="Richard Davis" initials="R." surname="Davis">
              <organization/>
            </author>
            <date month="August" year="2020"/>
          </front>
          <seriesInfo name="NIST SP" value="800-56Cr2"/>
          <seriesInfo name="DOI" value="10.6028/nist.sp.800-56cr2"/>
          <refcontent>National Institute of Standards and Technology</refcontent>
        </reference>
        <reference anchor="NIST-SP-800-135">
          <front>
            <title>Recommendation for existing application-specific key derivation functions</title> Existing Application-Specific Key Derivation Functions</title>
            <author fullname="Q H fullname="Quynh Dang" initials="Q." surname="Dang">
              <organization/>
            </author>
            <date month="December" year="2011"/>
          </front>
          <seriesInfo name="NIST SP" value="800-135r1"/>
          <seriesInfo name="DOI" value="10.6028/nist.sp.800-135r1"/>
          <refcontent>National Institute of Standards and Technology</refcontent>
        </reference>

        <reference anchor="OQS-102" target="https://github.com/open-quantum-safe/openssl/tree/OQS-OpenSSL_1_0_2-stable">
          <front>
            <title>OQS-OpenSSL-1-0-2_stable</title>
            <author>
              <organization>Open Quantum Safe Project</organization>
            </author>
            <author/>
            <date year="2018" month="November"/> day="31" year="2020" month="January"/>
          </front>
          <refcontent>commit 537b2f9</refcontent>
        </reference>
        <reference anchor="OQS-111" target="https://github.com/open-quantum-safe/openssl/tree/OQS-OpenSSL_1_1_1-stable">
          <front>
            <title>OQS-OpenSSL-1-1-1_stable</title>
            <author>
              <organization>Open Quantum Safe Project</organization>
            </author>
            <author/>
            <date year="2022" day="8" year="2025" month="January"/>
          </front>
          <refcontent>commit 5f49b7a</refcontent>
        </reference>
        <reference anchor="OQS-PROV" target="https://github.com/open-quantum-safe/oqs-provider/">
          <front>
            <title>OQS Provider for OpenSSL 3</title>
            <author>
              <organization>Open Quantum Safe Project</organization>
            </author>
            <date year="2023" month="July"/>
          </front>
        </reference>
        <reference anchor="PQUIP-TERM">
          <front>
            <title>Terminology for Post-Quantum Traditional Hybrid Schemes</title>
            <author fullname="F. Driscoll" initials="F." surname="Driscoll"/>
            <author fullname="M. Parsons" initials="M." surname="Parsons"/>
            <author fullname="B. Hale" initials="B." surname="Hale"/>
            <author/>
            <date month="June" year="2025"/>
            <abstract>
              <t>One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations.</t>
            </abstract> day="8" year="2026" month="January"/>
          </front>
          <seriesInfo name="RFC" value="9794"/>
          <seriesInfo name="DOI" value="10.17487/RFC9794"/>
          <refcontent>commit 573fb25</refcontent>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9794.xml"/>
        <reference anchor="PST">
          <front>
            <title>Benchmarking Post-quantum Cryptography in TLS</title>
            <author fullname="Christian Paquin" initials="C." surname="Paquin">
              <organization/>
            </author>
            <author fullname="Douglas Stebila" initials="D." surname="Stebila">
              <organization/>
            </author>
            <author fullname="Goutam Tamvada" initials="G." surname="Tamvada">
              <organization/>
            </author>
            <date year="2020"/>
          </front>
          <seriesInfo name="Lecture
          <refcontent>Post-Quantum Cryptography (PQCrypto 2020), Lecture Notes in Computer Science" value="pp. 72-91"/> Science, vol. 12100, pp. 72-91</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-030-44223-1_5"/>
          <seriesInfo name="ISBN" value="[&quot;9783030442224&quot;, &quot;9783030442231&quot;]"/>
          <refcontent>Springer International Publishing</refcontent>
        </reference>
        <reference anchor="RACCOON" target="https://raccoon-attack.com/">
          <front>
            <title>Raccoon Attack: Finding and Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)</title>
            <author initials="R." surname="Merget">
              <organization/>
            </author>
            <author initials="M." surname="Brinkmann">
              <organization/>
            </author>
            <author initials="N." surname="Aviram">
              <organization/>
            </author>
            <author initials="J." surname="Somorovsky">
              <organization/>
            </author>
            <author initials="J." surname="Mittmann">
              <organization/>
            </author>
            <author initials="J." surname="Schwenk">
              <organization/>
            </author>
            <date year="2020" month="September"/>
          </front>
        </reference>
        <reference anchor="S2N" target="https://aws.amazon.com/blogs/security/post-quantum-tls-now-supported-in-aws-kms/">
          <front>
            <title>Post-quantum TLS now supported in AWS KMS</title>
            <author>
              <organization>Amazon Web Services</organization>
            </author>
            <author fullname="Andrew Hopkins"/>
            <author fullname="Matthew Campagna"/>
            <date year="2019" month="November" day="04"/>
          </front>
        </reference>
        <reference anchor="SCHANCK">
          <front>
            <title>A Transport Layer Security (TLS) Extension For Establishing An Additional Shared Secret</title>
            <author fullname="John M. Schanck" initials="J. M." surname="Schanck">
              <organization>University of Waterloo</organization>
            </author>
            <author fullname="Douglas Stebila" initials="D." surname="Stebila">
              <organization>McMaster University</organization>
            </author>
            <date day="17" month="April" year="2017"/>
            <abstract>
              <t>   This document defines a Transport Layer Security (TLS) extension that
   allows parties to establish an additional shared secret using a
   second key exchange algorithm and incorporates this shared secret
   into the TLS key schedule.

              </t>
            </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 Security (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
          <refcontent>AWS 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"/> Blog</refcontent>
        </reference>
        <reference anchor="WHYTE13">
          <front>
            <title>Quantum-Safe Hybrid (QSH) Key Exchange for Transport Layer Security (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="Garcia-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 in 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+
<!-- [SCHANCK]
draft-schanck-tls-additional-keyshare-00
IESG State: Expired as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties 01/12/26
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.schanck-tls-additional-keyshare.xml"/>
<!-- [WHYTE12]
draft-whyte-qsh-tls12-02
IESG State: Expired as of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance 01/12/26
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.whyte-qsh-tls12.xml"/>
<!-- [WHYTE13]
draft-whyte-qsh-tls13-06
IESG State: Expired as of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8391"/>
          <seriesInfo name="DOI" value="10.17487/RFC8391"/>
        </reference> 01/12/26
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.whyte-qsh-tls13.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8391.xml"/>
        <reference anchor="ZHANG">
          <front>
            <title>On the Security of Multiple Encryption or CCA-security+CCA-security=CCA-security?</title>
            <author fullname="Rui Zhang" initials="R." surname="Zhang">
              <organization/>
            </author>
            <author fullname="Goichiro Hanaoka" initials="G." surname="Hanaoka">
              <organization/>
            </author>
            <author fullname="Junji Shikata" initials="J." surname="Shikata">
              <organization/>
            </author>
            <author fullname="Hideki Imai" initials="H." surname="Imai">
              <organization/>
            </author>
            <date year="2004"/>
          </front>
          <seriesInfo name="Lecture
          <refcontent>Public Key Cryptography (PKC 2004), Lecture Notes in Computer Science" value="pp. 360-374"/> Science, vol. 2947, pp. 360-374</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-540-24632-9_26"/>
          <seriesInfo name="ISBN" value="[&quot;9783540210184&quot;, &quot;9783540246329&quot;]"/>
          <refcontent>Springer Berlin Heidelberg</refcontent>
        </reference>
        <reference anchor="ECDHE-MLKEM">
          <front>
            <title>Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3</title>
            <author fullname="Kris Kwiatkowski" initials="K." surname="Kwiatkowski">
              <organization>PQShield</organization>
            </author>
            <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
              <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>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-kwiatkowski-tls-ecdhe-mlkem-03"/>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.kwiatkowski-tls-ecdhe-mlkem.xml"/>
      </references>
    </references>
    <?line 533?>

<section anchor="related-work">
  <name>Related work</name> 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, see a standard textbook such as <xref target="NIELSEN"/>.  For an overview of post-quantum cryptography as of 2009, see <xref target="BERNSTEIN"/>; while not containing more recent advances, it still provides a helpful introduction.  For the current status of the NIST Post-Quantum Cryptography Standardization Project, see <xref target="NIST"/>.  For additional perspectives on the general transition from traditional to post-quantum cryptography, see for example <xref target="ETSI"/>, among others.</t>
      <t>There have been several Internet-Drafts describing mechanisms for embedding post-quantum and/or hybrid key exchange in TLS:</t>
      <ul spacing="normal">
        <li>
          <t>Internet-Drafts for TLS
          <t>TLS 1.2: <xref target="WHYTE12"/>, target="I-D.whyte-qsh-tls12"/>, <xref target="CAMPAGNA"/></t> target="I-D.campagna-tls-bike-sike-hybrid"/></t>
        </li>
        <li>
          <t>Internet-Drafts for TLS
          <t>TLS 1.3: <xref target="KIEFER"/>, target="I-D.kiefer-tls-ecdhe-sidh"/>, <xref target="SCHANCK"/>, target="I-D.schanck-tls-additional-keyshare"/>, <xref target="WHYTE13"/></t> target="I-D.whyte-qsh-tls13"/></t>
        </li>
      </ul>
      <t>There have been several prototype implementations for post-quantum and/or hybrid key exchange in TLS:</t>
      <ul spacing="normal">
        <li>
          <t>Experimental implementations in TLS
          <t>TLS 1.2: <xref target="BCNS15"/>, <xref target="CECPQ1"/>, <xref target="FRODO"/>, <xref target="OQS-102"/>, <xref target="S2N"/></t>
        </li>
        <li>
          <t>Experimental implementations in TLS
          <t>TLS 1.3: <xref target="CECPQ2"/>, <xref target="OQS-111"/>, <xref target="OQS-PROV"/>, <xref target="PST"/></t>
        </li>
      </ul>
      <t>These experimental implementations have taken an ad hoc approach and not attempted to implement one of the drafts Internet-Drafts listed above.</t>
      <t>Unrelated to post-quantum but still related to the issue of combining multiple types of keying material in TLS is the use of pre-shared keys, especially the recent TLS working group Working Group document on including an external pre-shared key <xref target="EXTERN-PSK"/>.</t> target="RFC8773"/>.</t>
      <t>Considering other IETF standards, there is work on post-quantum preshared pre-shared keys in IKEv2 the Internet Key Exchange Protocol Version 2 (IKEv2) <xref target="IKE-PSK"/> target="RFC8784"/> and a framework for hybrid key exchange in IKEv2 <xref target="IKE-HYBRID"/>. target="I-D.tjhai-ipsecme-hybrid-qske-ikev2"/>.  The XMSS eXtended Merkle Signature Scheme (XMSS) hash-based signature scheme has been published as an informational Informational RFC by the IRTF <xref target="XMSS"/>.</t> target="RFC8391"/>.</t>
      <t>In the academic literature, <xref target="EVEN"/> initiated the study of combining multiple symmetric encryption schemes; <xref target="ZHANG"/>, <xref target="DODIS"/>, and <xref target="HARNIK"/> examined combining multiple public key encryption schemes, schemes; and <xref target="HARNIK"/> coined the term "robust combiner" to refer to a compiler that constructs a hybrid scheme from individual schemes while preserving security properties.  <xref target="GIACON"/> and <xref target="BINDEL"/> examined combining multiple key encapsulation mechanisms.</t>
    </section>
  </back>

    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>The ideas in this document have grown from discussions with many colleagues, including <contact fullname="Christopher Wood"/>, <contact fullname="Matt Campagna"/>, <contact fullname="Eric Crockett"/>, <contact fullname="Deirdre Connolly"/>, authors of the various hybrid documents 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 Mountain View, California in January 2019.  <contact fullname="Daniel 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)
-->

<!-- ##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== [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-library/nist-technical-series-publications-author-instructions#table1
-->

  </back>

</rfc>