<?xml version='1.0' 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.7 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-mahy-mls-xwing-00" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.20.0 -->
  <front>
    <title abbrev="XWing ciphersuite for MLS">Messaging Layer Security Ciphersuite using XWing Key Exchange Mechanism</title>
    <seriesInfo name="Internet-Draft" value="draft-mahy-mls-xwing-00"/>
    <author initials="R." surname="Mahy" fullname="Rohan Mahy">
      <organization>Unaffiliated</organization>
      <address>
        <email>rohan.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2024" month="March" day="04"/>
    <area>sec</area>
    <workgroup>MLS</workgroup>
    <keyword>ML-KEM</keyword>
    <keyword>Kyber</keyword>
    <keyword>post-quantum</keyword>
    <keyword>post quantum KEM</keyword>
    <keyword>KEM</keyword>
    <keyword>PQ/T</keyword>
    <keyword>hybrid</keyword>
    <keyword>hybrid KEM</keyword>
    <keyword>Key Exchange Mechanism</keyword>
    <abstract>
      <?line 48?>

<t>This document registers a new Messaging Layer Security (MLS) ciphersuite using
the X-Wing hybrid post-quantum resistant / traditional (PQ/T) Key Exchange
Mechanism (KEM).</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-mahy-mls-xwing/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        MLS Working Group mailing list (<eref target="mailto:mls@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/mls/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/mls/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/rohanmahy/mahy-mls-xwing/"/>.</t>
    </note>
  </front>
  <middle>
    <?line 54?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The potential availability of a cryptographically-relevant quantum
computer has caused concern that well-funded adversaries could overturn
long-held assumptions about the security assurances of classical
Key Exchange Mechanisms (KEMs) and classical cryptographic signatures,
which are fundamental to modern security protocols, including the MLS
protocol <xref target="RFC9420"/>.</t>
      <t>The MLS Working Group has expressed strong desire to have a handful of
complimentary post-quantum security extensions for use with the MLS
protocol to address the related threats:</t>
      <ol spacing="normal" type="1"><li>
          <t>A straightforward MLS cipher suite that replaces a classical KEM with a
hybrid post-quantum/traditional KEM. Such a cipher suite could be
implemented as a drop-in replacement in many MLS libraries without changes
to any other part of the MLS stack. The aim is for implementations to have a
single KEM which would be performant and work for the vast majority of
implementations. It addresses the the harvest-now / decrypt-later threat model using the simplest, and most practicable solution available.</t>
        </li>
        <li>
          <t>Versions of existing cipher suites that use post-quantum signatures; and
specific guidelines on the construction, use, and validation of hybrid
signatures.</t>
        </li>
        <li>
          <t>One or more mechanisms which reduce the bandwidth or storage requirements,
or improve performance when using post-quantum algorithms (for example by updating post-quantum keys less frequently than classical keys, or by sharing portions of post-quantum keys across a large number of clients or groups.)</t>
        </li>
      </ol>
      <t>This document addresses the first of these work items. It reserves an MLS
cipher suite value based on the MLS default cipher suite, but replacing the KEM
with the X-Wing <xref target="I-D.connolly-cfrg-xwing-kem"/> hybrid post-quantum /
traditional KEM. The IANA Hybrid Public Key Encryption (HPKE) <xref target="RFC9180"/>
Key Exchange Mechanism (KEM) Identifier value for X-Wing is pending at the
time of this writing.</t>
      <t>X-Wing is a "concrete, simple choice for [a] post-quantum hybrid KEM, that
should be suitable for the vast majority of use cases". X-Wing combines the
ML-KEM <xref target="MLKEM"/> post-quantum KEM and the X25519 <xref target="RFC7748"/> traditional
KEM. The MLS cipher suite uses the other components of the default MLS cipher
suite <tt>MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519</tt>.</t>
      <t>This document replaces a previous, similar proposal based on the KEM in
<xref target="I-D.draft-westerbaan-cfrg-hpke-xyber768d00"/>.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This ciphersuite uses a hybrid post-quantum/traditional KEM and a traditional
signature algorithm. As such, it is designed to provide confidentiality against
quantum and classical attacks, but provides authenticity against classical
attacks only. This is actually very useful, because an attacker could store
MLS-encrypted traffic that uses any classical KEM today. If years or decades in
the future a quantum attack on classical KEMs becomes feasible, the traffic sent
today (some of which could still be sensitive in the future) will then be readable.
By contrast, an attack on a signature algorithm in MLS would require an active
attack which can extract the private key during the signature key's lifetime.</t>
      <t>The security properties of <xref target="I-D.connolly-cfrg-xwing-kem"/> apply.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document registers a new MLS Ciphersuite value.</t>
      <artwork><![CDATA[
Value:        new assignment
Name:         MLS_128_XWING_AES128GCM_SHA256_Ed25519
Recommended:  N
Reference:    This document
]]></artwork>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC9420">
          <front>
            <title>The Messaging Layer Security (MLS) Protocol</title>
            <author fullname="R. Barnes" initials="R." surname="Barnes"/>
            <author fullname="B. Beurdouche" initials="B." surname="Beurdouche"/>
            <author fullname="R. Robert" initials="R." surname="Robert"/>
            <author fullname="J. Millican" initials="J." surname="Millican"/>
            <author fullname="E. Omara" initials="E." surname="Omara"/>
            <author fullname="K. Cohn-Gordon" initials="K." surname="Cohn-Gordon"/>
            <date month="July" year="2023"/>
            <abstract>
              <t>Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9420"/>
          <seriesInfo name="DOI" value="10.17487/RFC9420"/>
        </reference>
        <reference anchor="I-D.connolly-cfrg-xwing-kem">
          <front>
            <title>X-Wing: general-purpose hybrid post-quantum KEM</title>
            <author fullname="Deirdre Connolly" initials="D." surname="Connolly">
              <organization>SandboxAQ</organization>
            </author>
            <author fullname="Peter Schwabe" initials="P." surname="Schwabe">
              <organization>MPI-SP &amp; Radboud University</organization>
            </author>
            <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
              <organization>Cloudflare</organization>
            </author>
            <date day="23" month="January" year="2024"/>
            <abstract>
              <t>   This memo defines X-Wing, a general-purpose post-quantum/traditional
   hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML-
   KEM-768.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-connolly-cfrg-xwing-kem-01"/>
        </reference>
        <reference anchor="RFC9180">
          <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="I-D.draft-westerbaan-cfrg-hpke-xyber768d00">
          <front>
            <title>X25519Kyber768Draft00 hybrid post-quantum KEM for HPKE</title>
            <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
              <organization>Cloudflare</organization>
            </author>
            <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
              <organization>Cloudflare</organization>
            </author>
            <date day="4" month="May" year="2023"/>
            <abstract>
              <t>   This memo defines X25519Kyber768Draft00, a hybrid post-quantum KEM,
   for HPKE (RFC9180).  This KEM does not support the authenticated
   modes of HPKE.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-westerbaan-cfrg-hpke-xyber768d00-02"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="MLKEM" target="https://csrc.nist.gov/pubs/fips/203/ipd">
          <front>
            <title>FIPS 203 (Initial Draft): Module-Lattice-Based Key-Encapsulation Mechanism Standard</title>
            <author initials="" surname="National Institute of Standards and Technology">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="RFC7748">
          <front>
            <title>Elliptic Curves for Security</title>
            <author fullname="A. Langley" initials="A." surname="Langley"/>
            <author fullname="M. Hamburg" initials="M." surname="Hamburg"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="January" year="2016"/>
            <abstract>
              <t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7748"/>
          <seriesInfo name="DOI" value="10.17487/RFC7748"/>
        </reference>
      </references>
    </references>
    <?line 126?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Thanks to Joël Alwen, Marta Mularczyk, Britta Hale, and Richard Barnes.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAHgt5mUAA41Y7W7cNhb9z6fgOj9iA9aM4zZNMovF1kmcZDZxmrWzTYCi
cCmJkrimRJWkZqwGzgv1MfbF9lxSmhnFNnYN2KMRyft57r2HTpKEeeW1XPAz
6ZwoVVPyd6KXll/IrLPK9/yFaitpXae85J2jDZ8/0d+3suen11klmlLiND0o
VzORplauFsOmbOdwYSw/e3fBcpM1oobK3IrCJ7Wo+qTWLrle40RydMRUaxfc
287546OjZ0fHzHVprZxTpvF9i4PL04+vOH/AhXZmwfdUk8tW4k/j9w753vLk
OT6gbG95/vHVnrBSLLiwnq2NvSqt6dpFsCMuOJmxTHhZGtsvuGoKw65kj635
gvEEG5O3p2f09LZPpaWH1jif/N6Jxnf1+J0P3/m4OX58+Of8I31WfWpVvn3a
bLs7hsx50eSXQpsG3vbSsVYt+C/eZIfcGeutLBye+poefmVsJZtOwly+4x3n
MVaf4DRl4jUt4W0tlF5wxPtHJX0xM7bES2GzasEr71u3mM9pC71RKzkbN83p
xTy1Zu3kHKfnpE35qksX3BrYTWmcT3M5Zw8414it81vh8dAsM/X83nPxDGOi
85WxIQ/IjFvw8xk/w1bo5jxi6JxkbF/CUoTwD+GBlQX/VyOKQmkFcXlYltH7
oDi49mNJb8gaxhpjaxxcIZKMcLD5xhFQJGwRRHhhS7njT+ZsNkPW/Kw0q3nb
pW5eqNbNj4++m6s2qh1K7OGr5YcLjgW+v2yUV0Lzl1QCB8iYyTstk3fCe5XJ
5LlwMid0JKdNJlrX6eDRFiL8ghAibP4wKNgEKvwkw+cQtPfhLJQtGwdLOpSi
KTYCHMcn/wjBjdGm7BlLkoSL1HkrMuTgY6UcR8l2NcqLW1nCVVQ0F7yR6/u7
xj4weDAp/9A7mK8k/5yE3jCUwm45Qb5TBH7P5+gAIleD6ftUSQeTemHbYOwj
OwezaHmt8lxLBugtG28R1oxEkB8SqjycoLiLFWE8BTZgK6IheGb71pvSirZS
mdC6T6zUckWmjLUOlLSInuWVcDwTHeUoM00mbcN9JTxfS62TokMnyrnIV/Bc
WCWx13Q65wYvfGcbhrIuk0rilXCuq1syEAFNTec5xceNQaRlK6DAkY2Zxney
jd3dNlyIgzsICd1snjrGnSobASukO2RrvKhQ+2jNsFlQgrHfG16bnHza2NFa
g95jNJqOajLd5ZQ+spQazbjIv3z5y/mrF8++Pz66uZnFgGN92oBC6OR1C/0U
PYAMseA5sg4roLkSK4lkwKG86DS8DkHXKthm+ylYNvbJa+TVhSjSkEFi+Bpt
5raJ0CDynJSHNWSYWgOeMQq8Q90/mvETskqosvKQtUaFBC8iknmEcki2la0W
lBqxE2wkIKoW7A54z3chja0zftFRBqbSI1pSyRQ8l+Q5wYn05Na0iWpG1aEi
8bUWTR+M1Cq1EXFkA8EpYsQxchybjCc1LYYhAWoID/wV2dWMU8KEqrmKUdxo
FxGfm+wwKmQto68BQuvBYt5KG/om7CIQ0sANskjTSmBM1uLfxsaaY98omPGl
H7MjY37otxJ2hWGQNGaNnpDLAOeE8maHvAW46oGbhPoJkp0/DEbUNJ5bambI
UAq7ndFd6KZDE9Byxo5n/GeUa3AUkZHX6EJb/hIT42LeCV1TGG5K6q+kkLlW
ZqpArZWdgmGqofJtgmXoFgBXbEmHJCmauBJa5bHDQ/lAFrZiZ+y7Gf+pkcRp
aoNCqbclHxNgJfpcjFcKgWuVA4LY7byxoiSg/96hwijYqPuYXIt+tE0YTq8r
2QxRnPgndEk5q6jBUDLltaD48rTnXUtmf3sA/MlxTUVWkGIo1T3FrtkpFNoT
SBqkOOQ4CrF+zMBtgSKzxlEVaJrAvOlq8LHYFxX5RcIC/3Gzg2/H1hRWhbJu
LABqFYRS5LeOEMRGSZDjxCvQPCa1iUx1FGNqXkNOqYJyWYhO+wlcDnnajV1i
RCbRvk1nGsYg2uYyeQkK0mAAY+xkhS0HLnwl65ubO+fknN1qJVS+y5P3J/xN
3P+hSzVAGGZFE6qG8LX/5sPb04OxVz96il59zziJU5UviVYDznArOk8QGExH
iIl306MIowuXiVrGyGJtDdRgDbOAse0JwfdoaFpJIYqlijZlQHuC6F/Er1NX
t4z5MBQgc9XYbijOoaTv6zGhWDNky+3NRqMxUNJQk2RvpPcIR2B4CPZENS1R
fYZsHT9+/OgZdv4dgXvy5Pun2LyTA7bJwa1p0Y24i92XBhp4fUBs7MEjerYn
WTz5G95cPjp+evnyDcRHCy5PTi/w6vWLs8uLNyfHj3+4PM3Dwm+z22RtM6Ew
cFfKdC5EnNg9zXT4CvBMwEweq4YNmIwXtLUkxpcK0URsVu2VTK7pNvTkh6f5
UZz2D3YujChhND4b2/pg1JQJBpv+jwEZoi8mcd60xW1fwsx2iHVWgZ54ghjx
ibKhwW7IzxWsodZbqDzSv8CtSgF27Nmmy01IE3g4ZqKLNTyIcIFmk4RsR8AO
LRsOIZa6JyzAEsJ75jvikxz0ryffQWwgVwYCSU0mHgvIIFxTzyZgXiQyli35
Yekik20GkAvTfEo7vMkF1C4LXBiFDe0Q01KQ3cho6HtdjNvmsho1U+4nohxZ
Z2ocLKRwCgV2GMfxYIVDDFhQx/ediQUf59DogdI61CexMrpDEUvZWnAAeoIN
FEvahRmexyn8vKc0QU2c3Tv2CX5H3kkq1UykH8OMC+cyUjrkYzQN78ETiQcE
U1qrViARNFt43tktdxjVYOEhxpgqJDW1gdDuUmLMTq8iNf+fPVy0LTARbiXU
ou8skfsvWfBx978woQ9D2NevX9nP9LwY73u0mxJZNiSIvQ9X5PFnbCafPy3f
v763jbBzyn1N/07JcfY9vhfSAopR0sTSYAGL964UoSb/TrIrUDUt8zKwDfZl
ESe1zP+2Vwjt5N4N+Suaq0Ap/2H+86fmJ3otQYjOQEwFP+vovw9/9FeH/Dli
jTdvhB6Y0jlSSZT8ubANEaP/Au/BJ7DBEgAA

-->

</rfc>
