<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" submissionType="IETF" docName="draft-ietf-mls-architecture-15" number="9750" category="info" tocInclude="true" sortRefs="true" symRefs="true" consensus="true" updates="" obsoletes="" xml:lang="en" prepTime="2025-04-22T13:44:17" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-mls-architecture-15" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9750" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="MLS Architecture">The Messaging Layer Security (MLS) Architecture</title>
    <seriesInfo name="RFC" value="9750" stream="IETF"/>
    <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche">
      <organization showOnFrontPage="true">Inria &amp; Mozilla</organization>
      <address>
        <email>ietf@beurdouche.com</email>
      </address>
    </author>
    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
      <address>
        <email>ekr@rtfm.com</email>
      </address>
    </author>
    <author initials="E." surname="Omara" fullname="Emad Omara">
      <organization showOnFrontPage="true"/>
      <address>
        <email>emad.omara@gmail.com</email>
      </address>
    </author>
    <author initials="S." surname="Inguva" fullname="Srinivas Inguva">
      <organization showOnFrontPage="true"/>
      <address>
        <email>singuva@yahoo.com</email>
      </address>
    </author>
    <author initials="A." surname="Duric" fullname="Alan Duric">
      <address>
        <email>alan@duric.net</email>
      </address>
    </author>
    <date month="04" year="2025"/>
    <area>SEC</area>
    <workgroup>mls</workgroup>
    <keyword>security</keyword>
    <keyword>authenticated key exchange</keyword>
    <keyword>end-to-end encryption</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">The Messaging Layer Security (MLS) protocol (RFC 9420)
provides a group key agreement protocol for messaging applications.
MLS is designed to protect against eavesdropping, tampering, and message
forgery, and to provide forward secrecy (FS) and post-compromise security
(PCS).

</t>
      <t indent="0" pn="section-abstract-2">This document describes the architecture for using MLS in a general
secure group messaging infrastructure and defines the security goals
for MLS.  It provides guidance on building a group messaging system
and discusses security and privacy trade-offs offered by multiple
security mechanisms that are part of the MLS protocol (e.g., frequency
of public encryption key rotation). The document also provides
guidance for parts of the infrastructure that are not standardized by
MLS and are instead left to the application.</t>
      <t indent="0" pn="section-abstract-3">While the recommendations of this document are not mandatory to follow in order
to interoperate at the protocol level, they affect the overall security
guarantees that are achieved by a messaging application. This is especially true
in the case of active adversaries that are able to compromise clients, the
Delivery Service (DS), or the Authentication Service (AS).</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9750" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-setting">General Setting</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-overview">Protocol Overview</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-abstract-services">Abstract Services</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview-of-operation">Overview of Operation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-step-1-account-creation">Step 1: Account Creation</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-step-2-initial-keying-mater">Step 2: Initial Keying Material</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-step-3-adding-bob-to-the-gr">Step 3: Adding Bob to the Group</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-step-4-adding-charlie-to-th">Step 4: Adding Charlie to the Group</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-other-group-operations">Other Group Operations</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.6">
                <t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-proposals-and-commits">Proposals and Commits</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.7">
                <t indent="0" pn="section-toc.1-1.3.2.7.1"><xref derivedContent="3.7" format="counter" sectionFormat="of" target="section-3.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-users-clients-and-groups">Users, Clients, and Groups</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authentication-service">Authentication Service</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-delivery-service">Delivery Service</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-storage-and-retrieval">Key Storage and Retrieval</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-delivery-of-messages">Delivery of Messages</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.2.2">
                  <li pn="section-toc.1-1.5.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-strongly-consistent">Strongly Consistent</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-eventually-consistent">Eventually Consistent</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.3.1"><xref derivedContent="5.2.3" format="counter" sectionFormat="of" target="section-5.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-welcome-messages">Welcome Messages</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-invalid-commits">Invalid Commits</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-functional-requirements">Functional Requirements</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-membership-changes">Membership Changes</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-parallel-groups">Parallel Groups</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-asynchronous-usage">Asynchronous Usage</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-access-control">Access Control</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-handling-authentication-fai">Handling Authentication Failures</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.6">
                <t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent="6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recovery-after-state-loss">Recovery After State Loss</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.7">
                <t indent="0" pn="section-toc.1-1.6.2.7.1"><xref derivedContent="6.7" format="counter" sectionFormat="of" target="section-6.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-support-for-multiple-device">Support for Multiple Devices</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.8">
                <t indent="0" pn="section-toc.1-1.6.2.8.1"><xref derivedContent="6.8" format="counter" sectionFormat="of" target="section-6.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extensibility">Extensibility</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.9">
                <t indent="0" pn="section-toc.1-1.6.2.9.1"><xref derivedContent="6.9" format="counter" sectionFormat="of" target="section-6.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-data-framing-an">Application Data Framing and Type Advertisements</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.10">
                <t indent="0" pn="section-toc.1-1.6.2.10.1"><xref derivedContent="6.10" format="counter" sectionFormat="of" target="section-6.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-federation">Federation</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.11">
                <t indent="0" pn="section-toc.1-1.6.2.11.1"><xref derivedContent="6.11" format="counter" sectionFormat="of" target="section-6.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-compatibility-with-future-v">Compatibility with Future Versions of MLS</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-requirements">Operational Requirements</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-and-privacy-consid">Security and Privacy Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-assumptions-on-transport-se">Assumptions on Transport Security Links</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2.1.2">
                  <li pn="section-toc.1-1.8.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.8.2.1.2.1.1"><xref derivedContent="8.1.1" format="counter" sectionFormat="of" target="section-8.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-integrity-and-authenticatio">Integrity and Authentication of Custom Metadata</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.8.2.1.2.2.1"><xref derivedContent="8.1.2" format="counter" sectionFormat="of" target="section-8.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-metadata-protection-for-une">Metadata Protection for Unencrypted Group Operations</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.8.2.1.2.3.1"><xref derivedContent="8.1.3" format="counter" sectionFormat="of" target="section-8.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dos-protection">DoS Protection</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.8.2.1.2.4.1"><xref derivedContent="8.1.4" format="counter" sectionFormat="of" target="section-8.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-message-suppression-and-err">Message Suppression and Error Correction</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-intended-security-guarantee">Intended Security Guarantees</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2.2.2">
                  <li pn="section-toc.1-1.8.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.8.2.2.2.1.1"><xref derivedContent="8.2.1" format="counter" sectionFormat="of" target="section-8.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-message-secrecy-and-authent">Message Secrecy and Authentication</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.8.2.2.2.2.1"><xref derivedContent="8.2.2" format="counter" sectionFormat="of" target="section-8.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-forward-secrecy-and-post-co">Forward Secrecy and Post-Compromise Security</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.8.2.2.2.3.1"><xref derivedContent="8.2.3" format="counter" sectionFormat="of" target="section-8.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-non-repudiation-vs-deniabil">Non-Repudiation vs. Deniability</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.8.2.2.2.4.1"><xref derivedContent="8.2.4" format="counter" sectionFormat="of" target="section-8.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-associating-a-users-clients">Associating a User's Clients</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-endpoint-compromise">Endpoint Compromise</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2.3.2">
                  <li pn="section-toc.1-1.8.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.8.2.3.2.1.1"><xref derivedContent="8.3.1" format="counter" sectionFormat="of" target="section-8.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-compromise-of-symmetric-key">Compromise of Symmetric Keying Material</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.8.2.3.2.2.1"><xref derivedContent="8.3.2" format="counter" sectionFormat="of" target="section-8.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-compromise-by-an-active-adv">Compromise by an Active Adversary with the Ability to Sign Messages</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.8.2.3.2.3.1"><xref derivedContent="8.3.3" format="counter" sectionFormat="of" target="section-8.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-compromise-of-authenticatio">Compromise of Authentication with Access to a Signature Key</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.8.2.3.2.4.1"><xref derivedContent="8.3.4" format="counter" sectionFormat="of" target="section-8.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations-in-">Security Considerations in the Context of a Full State Compromise</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.8.2.4">
                <t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-service-node-compromise">Service Node Compromise</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2.4.2">
                  <li pn="section-toc.1-1.8.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.8.2.4.2.1.1"><xref derivedContent="8.4.1" format="counter" sectionFormat="of" target="section-8.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-considerations">General Considerations</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.8.2.4.2.2.1"><xref derivedContent="8.4.2" format="counter" sectionFormat="of" target="section-8.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-delivery-service-compromise">Delivery Service Compromise</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.4.2.3">
                    <t indent="0" pn="section-toc.1-1.8.2.4.2.3.1"><xref derivedContent="8.4.3" format="counter" sectionFormat="of" target="section-8.4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authentication-service-comp">Authentication Service Compromise</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.8.2.5">
                <t indent="0" pn="section-toc.1-1.8.2.5.1"><xref derivedContent="8.5" format="counter" sectionFormat="of" target="section-8.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-considerations-for-attacks-">Considerations for Attacks Outside of the Threat Model</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.6">
                <t indent="0" pn="section-toc.1-1.8.2.6.1"><xref derivedContent="8.6" format="counter" sectionFormat="of" target="section-8.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-no-protection-against-repla">No Protection Against Replay by Insiders</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.7">
                <t indent="0" pn="section-toc.1-1.8.2.7.1"><xref derivedContent="8.7" format="counter" sectionFormat="of" target="section-8.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cryptographic-analysis-of-t">Cryptographic Analysis of the MLS Protocol</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">End-to-end security is used in the vast majority of instant messaging systems
and is also deployed in systems for other purposes such as calling and conferencing.
In this context, "end-to-end" captures
the notion that users of the system enjoy some level of security -- with the
precise level depending on the system design -- even in the face of malicious
actions by the operator of the messaging system.</t>
      <t indent="0" pn="section-1-2">Messaging Layer Security (MLS) specifies an architecture (this document) and a
protocol <xref target="RFC9420" format="default" sectionFormat="of" derivedContent="RFC9420"/> for providing end-to-end security in this
setting. MLS is not intended as a full instant messaging protocol but rather is
intended to be embedded in concrete protocols, such as the Extensible Messaging and Presence Protocol (XMPP) <xref target="RFC6120" format="default" sectionFormat="of" derivedContent="RFC6120"/>.
Implementations of the MLS protocol will interoperate at the cryptographic
level, though they may have incompatibilities in terms of how protected messages
are delivered, contents of protected messages, and identity/authentication
infrastructures.
The MLS protocol has been designed to provide the same security guarantees to
all users, for all group sizes, including groups of only two clients.</t>
    </section>
    <section anchor="general-setting" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-general-setting">General Setting</name>
      <section anchor="protocol-overview" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-protocol-overview">Protocol Overview</name>
        <t indent="0" pn="section-2.1-1">MLS provides a way for <em>clients</em> to form <em>groups</em> within which they can
communicate securely.  For example, a set of users might use clients on their
phones or laptops to join a group and communicate with each other. A group may
be as small as two clients (e.g., for simple person-to-person messaging) or as
large as hundreds of thousands.  A client that is part of a group is a <em>member</em>
of that group. As groups change membership and group or member properties, they
advance from one <em>epoch</em> to another and the cryptographic state of the group
evolves.</t>
        <t indent="0" pn="section-2.1-2">The group is represented as a tree, which represents the members as the leaves
of a tree. It is used to efficiently encrypt to subsets of the members. Each
member has a state called a <em>LeafNode</em> object holding the client's identity,
credentials, and capabilities.</t>
        <t indent="0" pn="section-2.1-3">Various messages are used in the evolution from epoch to epoch.
A <em>Proposal</em> message proposes
a change to be made in the next epoch, such as adding or removing a member.
A <em>Commit</em> message initiates a new epoch by instructing members of the group to
implement a collection of proposals. Proposals and Commits are collectively
called <em>handshake messages</em>.
A <em>KeyPackage</em> provides keys that can be used to add the client to a group,
including a public encryption key and a signature key (both stored in
the KeyPackage's <tt>LeafNode</tt> object).
A <em>Welcome</em> message provides a new member to the group with the information to
initialize their state for the epoch in which they were added.</t>
        <t indent="0" pn="section-2.1-4">Of course most (but not all) applications use MLS to send encrypted group messages.
An <em>application message</em> is an MLS message with an arbitrary application payload.</t>
        <t indent="0" pn="section-2.1-5">Finally, a <em>PublicMessage</em> contains an integrity-protected MLS handshake message,
while a <em>PrivateMessage</em> contains a confidential, integrity-protected handshake
or application message.</t>
        <t indent="0" pn="section-2.1-6">For a more detailed explanation of these terms, please consult the MLS protocol
specification <xref target="RFC9420" format="default" sectionFormat="of" derivedContent="RFC9420"/>.</t>
      </section>
      <section anchor="abstract-services" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-abstract-services">Abstract Services</name>
        <t indent="0" pn="section-2.2-1">MLS is designed to operate within the context of a messaging service, which
may be a single service provider, a federated system, or some kind of
peer-to-peer system. The service needs to provide two services that
facilitate client communication using MLS:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-2">
          <li pn="section-2.2-2.1">
            <t indent="0" pn="section-2.2-2.1.1">An Authentication Service (AS), which is responsible for
attesting to bindings between application-meaningful identifiers and the
public key material used for authentication in the MLS protocol. The
AS must also be able to generate credentials that encode these
bindings and validate credentials provided by MLS clients.
</t>
          </li>
          <li pn="section-2.2-2.2">
            <t indent="0" pn="section-2.2-2.2.1">A Delivery Service (DS), which can receive and distribute
messages between group members. In the case of group messaging, the DS
may also be responsible for acting as a "broadcaster" where the sender
sends a single message which is then forwarded to each recipient in the group
by the DS. The DS is also responsible for storing and delivering initial
public key material required by MLS clients in order to proceed with the group
secret key establishment that is part of the MLS protocol.</t>
          </li>
        </ul>
        <t indent="0" pn="section-2.2-3">For presentation purposes, this document treats the AS and DS as conventional
network services. However, MLS does not require a specific implementation
for the AS or DS. These services may reside on the same server or different
servers, they may be distributed between server and client components, and they
may even involve some action by users.  For example:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-4">
          <li pn="section-2.2-4.1">
            <t indent="0" pn="section-2.2-4.1.1">Several secure messaging services today provide a centralized DS and rely on
manual comparison of clients' public keys as the AS.</t>
          </li>
          <li pn="section-2.2-4.2">
            <t indent="0" pn="section-2.2-4.2.1">MLS clients connected to a peer-to-peer network could instantiate a
decentralized DS by transmitting MLS messages over that network.</t>
          </li>
          <li pn="section-2.2-4.3">
            <t indent="0" pn="section-2.2-4.3.1">In an MLS group using a Public Key Infrastructure (PKI) for authentication,
the AS would comprise the certificate issuance and validation processes,
both of which involve logic inside MLS clients as well as various
existing PKI roles (e.g., Certification Authorities).</t>
          </li>
        </ul>
        <t indent="0" pn="section-2.2-5">It is important to note that the AS can be
completely abstract in the case of a service provider which allows MLS
clients to generate, distribute, and validate credentials themselves.
As with the AS, the DS can be completely abstract if
users are able to distribute credentials and messages without relying
on a central DS (as in a peer-to-peer system).  Note,
though, that in such scenarios, clients will need to implement logic
that assures the delivery properties required of the DS (see
<xref target="delivery-guarantees" format="default" sectionFormat="of" derivedContent="Section 5.2"/>).</t>
        <t indent="0" pn="section-2.2-6"><xref target="fig-mls-overview" format="default" sectionFormat="of" derivedContent="Figure 1"/> shows the relationship of these concepts,
with three clients and one group, and clients 2 and 3 being
part of the group and client 1 not being part of any group.</t>
        <figure anchor="fig-mls-overview" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-a-simplified-messaging-syst">A Simplified Messaging System</name>
          <artset pn="section-2.2-7.1">
            <artwork type="svg" align="left" pn="section-2.2-7.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="256" width="456" viewBox="0 0 456 256" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,80" fill="none" stroke="black"/>
                <path d="M 80,144 L 80,176" fill="none" stroke="black"/>
                <path d="M 144,32 L 144,80" fill="none" stroke="black"/>
                <path d="M 168,144 L 168,176" fill="none" stroke="black"/>
                <path d="M 184,32 L 184,80" fill="none" stroke="black"/>
                <path d="M 208,144 L 208,176" fill="none" stroke="black"/>
                <path d="M 248,80 L 248,144" fill="none" stroke="black"/>
                <path d="M 296,144 L 296,176" fill="none" stroke="black"/>
                <path d="M 304,32 L 304,80" fill="none" stroke="black"/>
                <path d="M 336,144 L 336,176" fill="none" stroke="black"/>
                <path d="M 424,144 L 424,176" fill="none" stroke="black"/>
                <path d="M 8,32 L 144,32" fill="none" stroke="black"/>
                <path d="M 184,32 L 304,32" fill="none" stroke="black"/>
                <path d="M 8,80 L 144,80" fill="none" stroke="black"/>
                <path d="M 184,80 L 304,80" fill="none" stroke="black"/>
                <path d="M 80,144 L 168,144" fill="none" stroke="black"/>
                <path d="M 208,144 L 296,144" fill="none" stroke="black"/>
                <path d="M 336,144 L 424,144" fill="none" stroke="black"/>
                <path d="M 80,176 L 168,176" fill="none" stroke="black"/>
                <path d="M 208,176 L 296,176" fill="none" stroke="black"/>
                <path d="M 336,176 L 424,176" fill="none" stroke="black"/>
                <path d="M 304,80 L 336,144" fill="none" stroke="black"/>
                <path d="M 152,144 L 184,80" fill="none" stroke="black"/>
                <g class="text">
                  <text x="76" y="52">Authentication</text>
                  <text x="244" y="52">Delivery</text>
                  <text x="56" y="68">Service</text>
                  <text x="108" y="68">(AS)</text>
                  <text x="224" y="68">Service</text>
                  <text x="276" y="68">(DS)</text>
                  <text x="432" y="100">Group</text>
                  <text x="212" y="116">........</text>
                  <text x="284" y="116">........</text>
                  <text x="388" y="116">................</text>
                  <text x="184" y="132">.</text>
                  <text x="448" y="132">.</text>
                  <text x="184" y="148">.</text>
                  <text x="448" y="148">.</text>
                  <text x="116" y="164">Client</text>
                  <text x="152" y="164">1</text>
                  <text x="184" y="164">.</text>
                  <text x="244" y="164">Client</text>
                  <text x="280" y="164">2</text>
                  <text x="372" y="164">Client</text>
                  <text x="408" y="164">3</text>
                  <text x="448" y="164">.</text>
                  <text x="184" y="180">.</text>
                  <text x="448" y="180">.</text>
                  <text x="184" y="196">.</text>
                  <text x="236" y="196">Member</text>
                  <text x="272" y="196">1</text>
                  <text x="364" y="196">Member</text>
                  <text x="400" y="196">2</text>
                  <text x="448" y="196">.</text>
                  <text x="184" y="212">.</text>
                  <text x="448" y="212">.</text>
                  <text x="316" y="228">..................................</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="left" pn="section-2.2-7.1.2">
     +----------------+    +--------------+
     | Authentication |    |   Delivery   |
     |  Service (AS)  |    | Service (DS) |
     +----------------+    +-------+------+
                          /        |       \            Group
                         / ........|........\................
                        /  .       |         \              .
              +--------+-+ .  +----+-----+    +----------+  .
              | Client 1 | .  | Client 2 |    | Client 3 |  .
              +----------+ .  +----------+    +----------+  .
                           .   Member 1        Member 2     .
                           .                                .
                           ..................................
</artwork>
          </artset>
        </figure>
      </section>
    </section>
    <section anchor="overview-of-operation" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-overview-of-operation">Overview of Operation</name>
      <t indent="0" pn="section-3-1"><xref target="fig-group-formation-example" format="default" sectionFormat="of" derivedContent="Figure 2"/> shows the formation of an example
group consisting of Alice, Bob, and Charlie, with Alice
      driving the creation of the group.</t>
      <figure anchor="fig-group-formation-example" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-group-formation-example">Group Formation Example</name>
        <artset pn="section-3-2.1">
          <artwork type="svg" align="left" pn="section-3-2.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="464" width="592" viewBox="0 0 592 464" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 528,64 L 528,144" fill="none" stroke="black"/>
              <path d="M 528,176 L 528,208" fill="none" stroke="black"/>
              <path d="M 528,240 L 528,320" fill="none" stroke="black"/>
              <path d="M 528,352 L 528,448" fill="none" stroke="black"/>
              <path d="M 128,64 L 392,64" fill="none" stroke="black"/>
              <path d="M 8,80 L 304,80" fill="none" stroke="black"/>
              <path d="M 208,96 L 392,96" fill="none" stroke="black"/>
              <path d="M 88,112 L 304,112" fill="none" stroke="black"/>
              <path d="M 288,128 L 392,128" fill="none" stroke="black"/>
              <path d="M 168,144 L 304,144" fill="none" stroke="black"/>
              <path d="M 200,176 L 480,176" fill="none" stroke="black"/>
              <path d="M 280,192 L 480,192" fill="none" stroke="black"/>
              <path d="M 360,208 L 480,208" fill="none" stroke="black"/>
              <path d="M 264,240 L 480,240" fill="none" stroke="black"/>
              <path d="M 8,256 L 256,256" fill="none" stroke="black"/>
              <path d="M 144,272 L 480,272" fill="none" stroke="black"/>
              <path d="M 112,288 L 480,288" fill="none" stroke="black"/>
              <path d="M 88,304 L 344,304" fill="none" stroke="black"/>
              <path d="M 88,320 L 376,320" fill="none" stroke="black"/>
              <path d="M 296,352 L 480,352" fill="none" stroke="black"/>
              <path d="M 8,368 L 224,368" fill="none" stroke="black"/>
              <path d="M 176,384 L 480,384" fill="none" stroke="black"/>
              <path d="M 144,400 L 480,400" fill="none" stroke="black"/>
              <path d="M 88,416 L 312,416" fill="none" stroke="black"/>
              <path d="M 176,432 L 312,432" fill="none" stroke="black"/>
              <path d="M 176,448 L 344,448" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="488,400 476,394.4 476,405.6" fill="black" transform="rotate(0,480,400)"/>
              <polygon class="arrowhead" points="488,384 476,378.4 476,389.6" fill="black" transform="rotate(0,480,384)"/>
              <polygon class="arrowhead" points="488,352 476,346.4 476,357.6" fill="black" transform="rotate(0,480,352)"/>
              <polygon class="arrowhead" points="488,288 476,282.4 476,293.6" fill="black" transform="rotate(0,480,288)"/>
              <polygon class="arrowhead" points="488,272 476,266.4 476,277.6" fill="black" transform="rotate(0,480,272)"/>
              <polygon class="arrowhead" points="488,240 476,234.4 476,245.6" fill="black" transform="rotate(0,480,240)"/>
              <polygon class="arrowhead" points="488,208 476,202.4 476,213.6" fill="black" transform="rotate(0,480,208)"/>
              <polygon class="arrowhead" points="488,192 476,186.4 476,197.6" fill="black" transform="rotate(0,480,192)"/>
              <polygon class="arrowhead" points="488,176 476,170.4 476,181.6" fill="black" transform="rotate(0,480,176)"/>
              <polygon class="arrowhead" points="400,128 388,122.4 388,133.6" fill="black" transform="rotate(0,392,128)"/>
              <polygon class="arrowhead" points="400,96 388,90.4 388,101.6" fill="black" transform="rotate(0,392,96)"/>
              <polygon class="arrowhead" points="400,64 388,58.4 388,69.6" fill="black" transform="rotate(0,392,64)"/>
              <polygon class="arrowhead" points="184,448 172,442.4 172,453.6" fill="black" transform="rotate(180,176,448)"/>
              <polygon class="arrowhead" points="184,432 172,426.4 172,437.6" fill="black" transform="rotate(180,176,432)"/>
              <polygon class="arrowhead" points="176,144 164,138.4 164,149.6" fill="black" transform="rotate(180,168,144)"/>
              <polygon class="arrowhead" points="96,416 84,410.4 84,421.6" fill="black" transform="rotate(180,88,416)"/>
              <polygon class="arrowhead" points="96,320 84,314.4 84,325.6" fill="black" transform="rotate(180,88,320)"/>
              <polygon class="arrowhead" points="96,304 84,298.4 84,309.6" fill="black" transform="rotate(180,88,304)"/>
              <polygon class="arrowhead" points="96,112 84,106.4 84,117.6" fill="black" transform="rotate(180,88,112)"/>
              <polygon class="arrowhead" points="16,368 4,362.4 4,373.6" fill="black" transform="rotate(180,8,368)"/>
              <polygon class="arrowhead" points="16,256 4,250.4 4,261.6" fill="black" transform="rotate(180,8,256)"/>
              <polygon class="arrowhead" points="16,80 4,74.4 4,85.6" fill="black" transform="rotate(180,8,80)"/>
              <g class="text">
                <text x="24" y="36">Alice</text>
                <text x="96" y="36">Bob</text>
                <text x="192" y="36">Charlie</text>
                <text x="396" y="36">AS</text>
                <text x="476" y="36">DS</text>
                <text x="28" y="68">Create</text>
                <text x="88" y="68">account</text>
                <text x="356" y="84">Credential</text>
                <text x="108" y="100">Create</text>
                <text x="168" y="100">account</text>
                <text x="556" y="100">Step</text>
                <text x="584" y="100">1</text>
                <text x="356" y="116">Credential</text>
                <text x="188" y="132">Create</text>
                <text x="248" y="132">account</text>
                <text x="356" y="148">Credential</text>
                <text x="32" y="180">Initial</text>
                <text x="92" y="180">Keying</text>
                <text x="156" y="180">Material</text>
                <text x="112" y="196">Initial</text>
                <text x="172" y="196">Keying</text>
                <text x="236" y="196">Material</text>
                <text x="556" y="196">Step</text>
                <text x="584" y="196">2</text>
                <text x="192" y="212">Initial</text>
                <text x="252" y="212">Keying</text>
                <text x="316" y="212">Material</text>
                <text x="16" y="244">Get</text>
                <text x="48" y="244">Bob</text>
                <text x="96" y="244">Initial</text>
                <text x="156" y="244">Keying</text>
                <text x="220" y="244">Material</text>
                <text x="280" y="260">Bob</text>
                <text x="328" y="260">Initial</text>
                <text x="388" y="260">Keying</text>
                <text x="452" y="260">Material</text>
                <text x="16" y="276">Add</text>
                <text x="48" y="276">Bob</text>
                <text x="76" y="276">to</text>
                <text x="112" y="276">group</text>
                <text x="556" y="276">Step</text>
                <text x="584" y="276">3</text>
                <text x="52" y="292">Welcome(Bob)</text>
                <text x="368" y="308">Add</text>
                <text x="400" y="308">Bob</text>
                <text x="428" y="308">to</text>
                <text x="464" y="308">group</text>
                <text x="436" y="324">Welcome(Bob)</text>
                <text x="16" y="356">Get</text>
                <text x="64" y="356">Charlie</text>
                <text x="128" y="356">Initial</text>
                <text x="188" y="356">Keying</text>
                <text x="252" y="356">Material</text>
                <text x="264" y="372">Charlie</text>
                <text x="328" y="372">Initial</text>
                <text x="388" y="372">Keying</text>
                <text x="452" y="372">Material</text>
                <text x="16" y="388">Add</text>
                <text x="64" y="388">Charlie</text>
                <text x="108" y="388">to</text>
                <text x="144" y="388">group</text>
                <text x="68" y="404">Welcome(Charlie)</text>
                <text x="556" y="404">Step</text>
                <text x="584" y="404">4</text>
                <text x="336" y="420">Add</text>
                <text x="384" y="420">Charlie</text>
                <text x="428" y="420">to</text>
                <text x="464" y="420">group</text>
                <text x="336" y="436">Add</text>
                <text x="384" y="436">Charlie</text>
                <text x="428" y="436">to</text>
                <text x="464" y="436">group</text>
                <text x="420" y="452">Welcome(Charlie)</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="left" pn="section-3-2.1.2">
Alice     Bob       Charlie                     AS        DS

Create account ---------------------------------&gt;               |
&lt;------------------------------------- Credential               |
          Create account -----------------------&gt;               | Step 1
          &lt;--------------------------- Credential               |
                    Create account -------------&gt;               |
                    &lt;----------------- Credential               |

Initial Keying Material -----------------------------------&gt;    |
          Initial Keying Material -------------------------&gt;    | Step 2
                    Initial Keying Material ---------------&gt;    |

Get Bob Initial Keying Material ---------------------------&gt;    |
&lt;------------------------------- Bob Initial Keying Material    |
Add Bob to group ------------------------------------------&gt;    | Step 3
Welcome(Bob) ----------------------------------------------&gt;    |
          &lt;-------------------------------- Add Bob to group    |
          &lt;------------------------------------ Welcome(Bob)    |

Get Charlie Initial Keying Material -----------------------&gt;    |
&lt;--------------------------- Charlie Initial Keying Material    |
Add Charlie to group --------------------------------------&gt;    |
Welcome(Charlie) ------------------------------------------&gt;    | Step 4
          &lt;---------------------------- Add Charlie to group    |
                     &lt;----------------- Add Charlie to group    |
                     &lt;--------------------- Welcome(Charlie)    |
</artwork>
        </artset>
      </figure>
      <t indent="0" pn="section-3-3">This process proceeds as follows.</t>
      <section anchor="step-1-account-creation" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-step-1-account-creation">Step 1: Account Creation</name>
        <t indent="0" pn="section-3.1-1">Alice, Bob, and Charlie create accounts with a service provider and obtain
credentials from the AS. This is a one-time setup phase.</t>
      </section>
      <section anchor="step-2-initial-keying-material" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-step-2-initial-keying-mater">Step 2: Initial Keying Material</name>
        <t indent="0" pn="section-3.2-1">Alice, Bob, and Charlie authenticate to the DS and store some initial
keying material which is used to send encrypted messages to them
for the first time. This keying material is authenticated with their
long-term credentials. Although in principle this keying material
can be reused for multiple senders, in order to provide forward secrecy
it is better for this material to be regularly refreshed so that each
sender can use a new key and delete older keys.</t>
      </section>
      <section anchor="step-3-adding-bob-to-the-group" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-step-3-adding-bob-to-the-gr">Step 3: Adding Bob to the Group</name>
        <t indent="0" pn="section-3.3-1">When Alice wants to create a group including Bob, she first uses the DS to look
up his initial keying material. She then generates two messages:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3-2">
          <li pn="section-3.3-2.1">
            <t indent="0" pn="section-3.3-2.1.1">A message to the entire group (which at this point is just her and Bob)
that adds Bob to the group.</t>
          </li>
          <li pn="section-3.3-2.2">
            <t indent="0" pn="section-3.3-2.2.1">A Welcome message just to Bob encrypted with his initial keying material that
includes the secret keying information necessary to join the group.</t>
          </li>
        </ul>
        <t indent="0" pn="section-3.3-3">She sends both of these messages to the DS, which is responsible
for sending them to the appropriate people. Note that the security of MLS
does not depend on the DS forwarding the Welcome message only to Bob, as it
is encrypted for him; it is simply not necessary for other group members
to receive it.</t>
      </section>
      <section anchor="step-4-adding-charlie-to-the-group" numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-step-4-adding-charlie-to-th">Step 4: Adding Charlie to the Group</name>
        <t indent="0" pn="section-3.4-1">If Alice then wants to add Charlie to the group, she follows a similar procedure
as with Bob.  She first uses the DS to look
up his initial keying material and then generates two messages:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.4-2">
          <li pn="section-3.4-2.1">
            <t indent="0" pn="section-3.4-2.1.1">A message to the entire group (consisting of her, Bob, and Charlie) adding
Charlie to the group.</t>
          </li>
          <li pn="section-3.4-2.2">
            <t indent="0" pn="section-3.4-2.2.1">A Welcome message just to Charlie encrypted with his initial keying material that
includes the secret keying information necessary to join the group.</t>
          </li>
        </ul>
        <t indent="0" pn="section-3.4-3">At the completion of this process, we have a group with Alice, Bob, and Charlie,
which means that they share a single encryption key which can be used to
send messages or to key other protocols.

</t>
      </section>
      <section anchor="other-group-operations" numbered="true" removeInRFC="false" toc="include" pn="section-3.5">
        <name slugifiedName="name-other-group-operations">Other Group Operations</name>
        <t indent="0" pn="section-3.5-1">Once the group has been created, clients can perform other actions,
such as:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5-2">
          <li pn="section-3.5-2.1">
            <t indent="0" pn="section-3.5-2.1.1">sending a message to everyone in the group</t>
          </li>
          <li pn="section-3.5-2.2">
            <t indent="0" pn="section-3.5-2.2.1">receiving a message from someone in the group</t>
          </li>
          <li pn="section-3.5-2.3">
            <t indent="0" pn="section-3.5-2.3.1">adding one or more clients to an existing group</t>
          </li>
          <li pn="section-3.5-2.4">
            <t indent="0" pn="section-3.5-2.4.1">removing one or more members from an existing group</t>
          </li>
          <li pn="section-3.5-2.5">
            <t indent="0" pn="section-3.5-2.5.1">updating their own key material</t>
          </li>
          <li pn="section-3.5-2.6">
            <t indent="0" pn="section-3.5-2.6.1">leaving a group (by asking to be removed)</t>
          </li>
        </ul>
        <t indent="0" pn="section-3.5-3">Importantly, MLS does not itself enforce any access control on group
operations. For instance, any member of the group can send a message
to add a new member or to evict an existing member.
This is in contrast to some designs in which there is a single group
controller who can modify the group. MLS-using applications are
responsible for setting their own access control policies. For instance,
if only the group administrator is allowed to change group members,
then it is the responsibility of the application to inform members
of this policy and who the administrator is.</t>
      </section>
      <section anchor="proposals-and-commits" numbered="true" removeInRFC="false" toc="include" pn="section-3.6">
        <name slugifiedName="name-proposals-and-commits">Proposals and Commits</name>
        <t indent="0" pn="section-3.6-1">The general pattern for any change in the group state (e.g., to add or remove
a user) is that it consists of two messages:</t>
        <dl indent="3" newline="false" spacing="normal" pn="section-3.6-2">
          <dt pn="section-3.6-2.1">Proposal:</dt>
          <dd pn="section-3.6-2.2">
            <t indent="0" pn="section-3.6-2.2.1">This message describes the change to be made (e.g., add Bob to the group)
but does not effect a change.</t>
          </dd>
          <dt pn="section-3.6-2.3">Commit:</dt>
          <dd pn="section-3.6-2.4">
            <t indent="0" pn="section-3.6-2.4.1">This message changes the group state to include the changes described in
a set of proposals.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-3.6-3">The simplest pattern is for a client to just send a Commit which contains one or
more Proposals. For instance, Alice could send a Commit with the Proposal
Add(Bob) embedded to add Bob to the group. However, there are situations in
which one client might send a Proposal and another might send the corresponding Commit. For
instance, Bob might wish to remove himself from the group and send a Remove
proposal to do so (see <xref section="12.1.3" sectionFormat="of" target="RFC9420" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9420#section-12.1.3" derivedContent="RFC9420"/>). Because Bob cannot send
the Commit, an existing member must do so.  Commits can apply to multiple valid
Proposals, in which case all the listed changes are applied.</t>
        <t indent="0" pn="section-3.6-4">It is also possible for a Commit to apply to an empty set of Proposals,
in which case it just updates the cryptographic state of the group
without changing its membership.</t>
      </section>
      <section anchor="group-members" numbered="true" removeInRFC="false" toc="include" pn="section-3.7">
        <name slugifiedName="name-users-clients-and-groups">Users, Clients, and Groups</name>
        <t indent="0" pn="section-3.7-1">While it's natural to think of a messaging system as consisting of groups of
users, possibly using different devices, in MLS the basic unit of operation is
not the user but rather the "client".  Formally, a client is a set of
cryptographic objects composed of public values such as a name (an identity), a
public encryption key, and a public signature key. As usual, a user demonstrates
ownership of the client by demonstrating knowledge of the associated secret
values.</t>
        <t indent="0" pn="section-3.7-2">In some messaging systems, clients belonging to the same user must all share the
same signature key pair, but MLS does not assume this; instead, a user may have
multiple clients with the same identity and different keys. In this case, each
client will have its own cryptographic state, and it is up to the application to
determine how to present this situation to users. For instance, it may render
messages to and from a given user identically regardless of which client they
are associated with, or it may choose to distinguish them.
It is also possible to have multiple clients associated with
the same user share state, as described in <xref target="associating-a-users-clients" format="default" sectionFormat="of" derivedContent="Section 8.2.4"/>.</t>
        <t indent="0" pn="section-3.7-3">When a client is part of a group, it is called a member.  A group in MLS is
defined as the set of clients that have knowledge of the shared group secret
established in the group key establishment phase.  Note that until a client has
been added to the group and contributed to the group secret in a manner
verifiable by other members of the group, other members cannot assume that the
client is a member of the group; for instance, the newly added member might not
have received the Welcome message or been unable to decrypt it for some reason.</t>
      </section>
    </section>
    <section anchor="authentication-service" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-authentication-service">Authentication Service</name>
      <t indent="0" pn="section-4-1">The Authentication Service (AS) has to provide three services:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4-2"><li pn="section-4-2.1" derivedCounter="1.">
          <t indent="0" pn="section-4-2.1.1">Issue credentials to clients that attest to bindings between identities and
signature key pairs.</t>
        </li>
        <li pn="section-4-2.2" derivedCounter="2.">
          <t indent="0" pn="section-4-2.2.1">Enable a client to verify that a credential presented by another client is
valid with respect to a reference identifier.</t>
        </li>
        <li pn="section-4-2.3" derivedCounter="3.">
          <t indent="0" pn="section-4-2.3.1">Enable a group member to verify that a credential represents the same client
as another credential.</t>
        </li>
      </ol>
      <t indent="0" pn="section-4-3">A member with a valid credential authenticates its MLS messages by signing them
with the private key corresponding to the public key bound by its credential.</t>
      <t indent="0" pn="section-4-4">The AS is considered an abstract layer by the MLS specification; part of this
service could be, for instance, running on the members' devices, while another
part is a separate entity entirely.  The following examples illustrate the
breadth of this concept:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-5">
        <li pn="section-4-5.1">
          <t indent="0" pn="section-4-5.1.1">A PKI could be used as an AS <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.  The issuance function would be
provided by the certificate authorities in the PKI, and the verification
function would correspond to certificate verification by clients.</t>
        </li>
        <li pn="section-4-5.2">
          <t indent="0" pn="section-4-5.2.1">Several current messaging applications rely on users verifying each other's
key fingerprints for authentication.  In this scenario, the issuance function
is simply the generation of a key pair (i.e., a credential is just an
identifier and public key, with no information to assist in verification).
The verification function is the application function that enables users
to verify keys.</t>
        </li>
        <li pn="section-4-5.3">
          <t indent="0" pn="section-4-5.3.1">In a system based on end-user Key Transparency (KT) <xref target="I-D.ietf-keytrans-architecture" format="default" sectionFormat="of" derivedContent="KT"/>, the
issuance function would correspond to the insertion of a key in a KT log under
a user's identity. The verification function would correspond to verifying a
key's inclusion in the log for a claimed identity, together with the KT log's
mechanisms for a user to monitor and control which keys are associated with
their identity.</t>
        </li>
      </ul>
      <t indent="0" pn="section-4-6">By the nature of its role in MLS authentication, the AS is invested with a
large amount of trust and the compromise of the AS could
allow an adversary to, among other things, impersonate group members. We discuss
security considerations regarding the compromise of the different AS
functions in detail in <xref target="as-compromise" format="default" sectionFormat="of" derivedContent="Section 8.4.3"/>.</t>
      <t indent="0" pn="section-4-7">The association between members' identities and their signature keys is fairly
flexible in MLS.  As noted above, there is no requirement that all clients
belonging to a given user have the same signature key (in fact, having duplicate
signature keys in a group is forbidden). A member can
also rotate the signature key they use within a group.  These mechanisms allow
clients to use different signature keys in different contexts and at different
points in time, providing unlinkability and post-compromise security benefits.
Some security trade-offs related to this flexibility are discussed in
<xref target="security-and-privacy-considerations" format="default" sectionFormat="of" derivedContent="Section 8"/>.

</t>
      <t indent="0" pn="section-4-8">In many applications, there are multiple MLS clients that represent a single
entity, such as a human user with a mobile and desktop version of an
application. Often, the same set of clients is represented in exactly the same
list of groups. In applications where this is the intended situation, other
clients can check that a user is consistently represented by the same set of
clients.  This would make it more difficult for a malicious AS to issue fake
credentials for a particular user because clients would expect the credential to
appear in all groups of which the user is a member. If a client credential does
not appear in all groups after some relatively short period of time, clients
have an indication that the credential might have been created without the
user's knowledge. Due to the asynchronous nature of MLS, however, there may be
transient inconsistencies in a user's client set, so correlating users' clients
across groups is more of a detection mechanism than a prevention mechanism.</t>
    </section>
    <section anchor="delivery-service" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-delivery-service">Delivery Service</name>
      <t indent="0" pn="section-5-1">The Delivery Service (DS) plays two major roles in MLS:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-2">
        <li pn="section-5-2.1">
          <t indent="0" pn="section-5-2.1.1">As a directory service, providing the initial keying material for
clients to use. This allows a client to establish a shared key and send
encrypted messages to other clients even if they're offline.</t>
        </li>
        <li pn="section-5-2.2">
          <t indent="0" pn="section-5-2.2.1">Routing MLS messages among clients.</t>
        </li>
      </ul>
      <t indent="0" pn="section-5-3">While MLS depends on correct behavior by the AS in
order to provide endpoint authentication and hence confidentiality of
the group key, these properties do not depend on correct behavior by
the DS; even a malicious DS cannot add itself to groups or recover
the group key. However, depending precisely on how MLS is used, the DS may
be able to determine group membership or prevent changes to the
group from taking place (e.g., by blocking group change messages).</t>
      <section anchor="key-storage-and-retrieval" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-key-storage-and-retrieval">Key Storage and Retrieval</name>
        <t indent="0" pn="section-5.1-1">Upon joining the system, each client stores its initial cryptographic key
material with the DS. This key material, called a KeyPackage,
advertises the functional abilities of the client (e.g., supported protocol
versions, supported extensions, etc.) and the following cryptographic information:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-2">
          <li pn="section-5.1-2.1">
            <t indent="0" pn="section-5.1-2.1.1">A credential from the AS attesting to the binding between
the identity and the client's signature key.</t>
          </li>
          <li pn="section-5.1-2.2">
            <t indent="0" pn="section-5.1-2.2.1">The client's asymmetric encryption public key.</t>
          </li>
        </ul>
        <t indent="0" pn="section-5.1-3">All the parameters in the KeyPackage are signed with the signature
private key corresponding to the credential.
As noted in <xref target="group-members" format="default" sectionFormat="of" derivedContent="Section 3.7"/>, users may own multiple clients, each
with their own keying material. Each KeyPackage is specific to an MLS version
and cipher suite, but a client may want to offer support for multiple protocol
versions and cipher suites. As such, there may be multiple KeyPackages stored by
each user for a mix of protocol versions, cipher suites, and end-user devices.</t>
        <t indent="0" pn="section-5.1-4">When a client wishes to establish a group or add clients to a group, it first
contacts the DS to request KeyPackages for each of the other clients,
authenticates the KeyPackages using the signature keys, includes the KeyPackages
in Add proposals, and encrypts the information needed to join the group
(the <em>GroupInfo</em> object) with an ephemeral key; it then separately encrypts the
ephemeral key with the public encryption key (<tt>init_key</tt>) from each KeyPackage.
When a client requests a KeyPackage in order to add a user to a group, the
DS should provide the minimum number of KeyPackages necessary to
satisfy the request.  For example, if the request specifies the MLS version, the
DS might provide one KeyPackage per supported cipher suite, even if it has
multiple such KeyPackages to enable the corresponding client to be added to
multiple groups before needing to upload more fresh KeyPackages.
</t>
        <t indent="0" pn="section-5.1-5">In order to avoid replay attacks and provide forward secrecy for messages sent
using the initial keying material, KeyPackages are intended to be used only
once, and <tt>init_key</tt> is intended to be deleted by the client after decryption
of the Welcome message. The DS is responsible for ensuring that
each KeyPackage is only used to add its client to a single group, with the
possible exception of a "last resort" KeyPackage that is specially designated
by the client to be used multiple times. Clients are responsible for providing
new KeyPackages as necessary in order to minimize the chance that the "last
resort" KeyPackage will be used.</t>
        <t indent="3" pn="section-5.1-6"><strong>Recommendation:</strong> Ensure that "last resort" KeyPackages don't get used by
provisioning enough standard KeyPackages.</t>
        <t indent="3" pn="section-5.1-7"><strong>Recommendation:</strong> Rotate "last resort" KeyPackages as soon as possible
after being used or if they have been stored for a prolonged period of time.
Overall, avoid reusing "last resort" KeyPackages as much as possible.</t>
        <t indent="3" pn="section-5.1-8"><strong>Recommendation:</strong> Ensure that the client for which a "last resort" KeyPackage
has been used is updating leaf keys as early as possible.</t>
        <t indent="3" pn="section-5.1-9"><strong>Recommendation:</strong> Ensure that clients delete the private component
of their <tt>init_key</tt> after processing a Welcome message, or after the
rotation of the "last resort" KeyPackage.</t>
        <t indent="0" pn="section-5.1-10">Overall, it needs to be noted that key packages need to be updated when
signature keys are changed.</t>
      </section>
      <section anchor="delivery-guarantees" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-delivery-of-messages">Delivery of Messages</name>
        <t indent="0" pn="section-5.2-1">The main responsibility of the DS is to ensure delivery of
messages. Some MLS messages need only be delivered to specific clients (e.g., a
Welcome message initializing a new member's state), while others need to be
delivered to all the members of a group.  The DS may enable the
latter delivery pattern via unicast channels (sometimes known as "client
fanout"), broadcast channels ("server fanout"), or a mix of both.</t>
        <t indent="0" pn="section-5.2-2">For the most part, MLS does not require the DS to deliver messages
in any particular order. Applications can set policies that control their
tolerance for out-of-order messages (see <xref target="operational-requirements" format="default" sectionFormat="of" derivedContent="Section 7"/>), and
messages that arrive significantly out of order can be dropped without otherwise
affecting the protocol. There are two exceptions to this. First, Proposal
messages should all arrive before the Commit that references them.  Second,
because an MLS group has a linear history of epochs, the members of the group
must agree on the order in which changes are applied.  Concretely, the group
must agree on a single MLS Commit message that ends each epoch and begins the
next one.</t>
        <t indent="0" pn="section-5.2-3">In practice, there's a realistic risk of two members generating Commit messages
at the same time, based on the same epoch, and both attempting to send them to
the group at the same time. The extent to which this is a problem, and the
appropriate solution, depend on the design of the DS. Per the CAP
theorem <xref target="CAPBR" format="default" sectionFormat="of" derivedContent="CAPBR"/>, there are two general classes of distributed systems that the
DS might fall into:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.2-4">
          <li pn="section-5.2-4.1">
            <t indent="0" pn="section-5.2-4.1.1">Consistent and Partition-tolerant, or Strongly Consistent, systems, which can provide
a globally consistent view of data but have the inconvenience of clients needing
to handle rejected messages.</t>
          </li>
          <li pn="section-5.2-4.2">
            <t indent="0" pn="section-5.2-4.2.1">Available and Partition-tolerant, or Eventually Consistent, systems, which continue
working despite network issues but may return different views of data to
different users.</t>
          </li>
        </ul>
        <t indent="0" pn="section-5.2-5">Strategies for sequencing messages in strongly and eventually consistent systems
are described in the next two subsections. Most DSs will use the
strongly consistent paradigm, but this remains a choice that can be handled in
coordination with the client and advertised in the KeyPackages.</t>
        <t indent="0" pn="section-5.2-6">However, note that a malicious DS could also reorder messages or
provide an inconsistent view to different users.  The "generation" counter in
MLS messages provides per-sender loss detection and ordering that cannot be
manipulated by the DS, but this does not provide complete protection against
partitioning.  A DS can cause a partition in the group by partitioning key
exchange messages; this can be detected only by out-of-band comparison (e.g.,
confirming that all clients have the same <tt>epoch_authenticator</tt> value). A
mechanism for more robust protections is discussed in
<xref target="I-D.ietf-mls-extensions" format="default" sectionFormat="of" derivedContent="EXTENSIONS"/>.</t>
        <t indent="0" pn="section-5.2-7">Other forms of DS misbehavior are still possible that are not easy
to detect. For instance, a DS can simply refuse to relay messages
to and from a given client. Without some sort of side information, other clients
cannot generally detect this form of Denial-of-Service (DoS) attack.</t>
        <section anchor="strongly-consistent" numbered="true" removeInRFC="false" toc="include" pn="section-5.2.1">
          <name slugifiedName="name-strongly-consistent">Strongly Consistent</name>
          <t indent="0" pn="section-5.2.1-1">With this approach, the DS ensures that some types of incoming
messages have a linear order and all members agree on that order.  The Delivery
Service is trusted to break ties when two members send a Commit message at the
same time.</t>
          <t indent="0" pn="section-5.2.1-2">As an example, there could be an "ordering server" DS that
broadcasts all messages received to all users and ensures that all clients see
messages in the same order. This would allow clients to only apply the first
valid Commit for an epoch and ignore subsequent Commits. Clients that send a Commit
would then wait to apply it until it is broadcast back to them by the Delivery
Service, assuming that they do not receive another Commit first.
</t>
          <t indent="0" pn="section-5.2.1-3">Alternatively, the DS can rely on the <tt>epoch</tt> and <tt>content_type</tt>
fields of an MLSMessage to provide an order only to handshake messages, and
possibly even filter or reject redundant Commit messages proactively to prevent
them from being broadcast. There is some risk associated with filtering; this
is discussed further in <xref target="invalid-commits" format="default" sectionFormat="of" derivedContent="Section 5.3"/>.</t>
        </section>
        <section anchor="eventually-consistent" numbered="true" removeInRFC="false" toc="include" pn="section-5.2.2">
          <name slugifiedName="name-eventually-consistent">Eventually Consistent</name>
          <t indent="0" pn="section-5.2.2-1">With this approach, the DS is built in a way that may be
significantly more available or performant than a strongly consistent system,
but where it offers weaker consistency guarantees. Messages may arrive to different
clients in different orders and with varying amounts of latency, which means
clients are responsible for reconciliation.
</t>
          <t indent="0" pn="section-5.2.2-2">This type of DS might arise, for example, when group members are
sending each message to each other member individually or when a distributed
peer-to-peer network is used to broadcast messages.</t>
          <t indent="0" pn="section-5.2.2-3">Upon receiving a Commit from the DS, clients can either:</t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.2.2-4"><li pn="section-5.2.2-4.1" derivedCounter="1.">
              <t indent="0" pn="section-5.2.2-4.1.1">Pause sending new messages for a short amount of time to account for a
reasonable degree of network latency and see if any other Commits are
received for the same epoch. If multiple Commits are received, the clients
can use a deterministic tie-breaking policy to decide which to accept, and
then resume sending messages as normal.</t>
            </li>
            <li pn="section-5.2.2-4.2" derivedCounter="2.">
              <t indent="0" pn="section-5.2.2-4.2.1">Accept the Commit immediately but keep a copy of the previous group state for
a short period of time. If another Commit for a past epoch is received,
clients use a deterministic tie-breaking policy to decide if they should
continue using the Commit they originally accepted or revert and use the
later one. Note that any copies of previous or forked group states must be
deleted within a reasonable amount of time to ensure that the protocol provides
forward secrecy.</t>
            </li>
          </ol>
          <t indent="0" pn="section-5.2.2-5">If the Commit references an unknown proposal, group members may need to solicit
the DS or other group members individually for the contents of the
proposal.</t>
        </section>
        <section anchor="welcome-messages" numbered="true" removeInRFC="false" toc="include" pn="section-5.2.3">
          <name slugifiedName="name-welcome-messages">Welcome Messages</name>
          <t indent="0" pn="section-5.2.3-1">Whenever a commit adds new members to a group, MLS requires the committer to
send a Welcome message to the new members. Applications should ensure that
Welcome messages are coupled with the tie-breaking logic for commits (see
Sections <xref target="strongly-consistent" format="counter" sectionFormat="of" derivedContent="5.2.1"/> and <xref target="eventually-consistent" format="counter" sectionFormat="of" derivedContent="5.2.2"/>). That is, when multiple
commits are sent for the same epoch, applications need to ensure that only
Welcome messages corresponding to the commit that "succeeded" are processed by
new members.</t>
          <t indent="0" pn="section-5.2.3-2">This is particularly important when groups are being reinitialized. When a group
is reinitialized, it is restarted with a different protocol version and/or
cipher suite but identical membership. Whenever an authorized member sends and
commits a ReInit proposal, this immediately freezes the existing group and
triggers the creation of a new group with a new <tt>group_id</tt>.</t>
          <t indent="0" pn="section-5.2.3-3">Ideally, the new group would be created by the same member that committed the
<tt>ReInit</tt> proposal (including sending Welcome messages for the new group to all
of the previous group's members). However, this operation is not always atomic,
so it's possible for a member to go offline after committing a ReInit proposal
but before creating the new group. If this happens, it's necessary for another
member to continue the reinitialization by creating the new group and sending
out Welcome messages.</t>
          <t indent="0" pn="section-5.2.3-4">This has the potential to create a race condition, where multiple members try to
continue the reinitialization at the same time, and members receive multiple
Welcome messages for each attempt at reinitializing the same group. Ensuring
that all members agree on which reinitialization attempt is "correct" is key to
prevent this from causing forks.</t>
        </section>
      </section>
      <section anchor="invalid-commits" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-invalid-commits">Invalid Commits</name>
        <t indent="0" pn="section-5.3-1">Situations can arise where a malicious or buggy client sends a Commit that is
not accepted by all members of the group, and the DS is not able to detect this
and reject the Commit.  For example, a buggy client might send an encrypted
Commit with an invalid set of proposals, or a malicious client might send a
malformed Commit of the form described in <xref section="16.12" sectionFormat="of" target="RFC9420" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9420#section-16.12" derivedContent="RFC9420"/>.</t>
        <t indent="0" pn="section-5.3-2">In situations where the DS is attempting to filter redundant Commits, the DS
might update its internal state under the assumption that a Commit has succeeded
and thus end up in a state inconsistent with the members of the group.  For
example, the DS might think that the current epoch is now <tt>n+1</tt> and reject any
commits from other epochs, while the members think the epoch is <tt>n</tt>, and as a
result, the group is stuck -- no member can send a Commit that the DS will
accept.</t>
        <t indent="0" pn="section-5.3-3">Such "desynchronization" problems can arise even when the DS takes
no stance on which Commit is "correct" for an epoch. The DS can enable clients
to choose between Commits, for example by providing Commits in the order
received and allowing clients to reject any Commits that
violate their view of the group's policies. As such, all honest and
correctly implemented clients will arrive at the same "first valid Commit" and
choose to process it. Malicious or buggy clients that process a different Commit
will end up in a forked view of the group.
</t>
        <t indent="0" pn="section-5.3-4">When these desynchronizations happen, the application may choose to take action
to restore the functionality of the group.  These actions themselves can have
security implications.  For example, a client developer might have a client
automatically rejoin a group, using an external join, when it processes an
invalid Commit.  In this operation, however, the client trusts that the
GroupInfo provided by the DS faithfully represents the state of the group, and
not, say, an earlier state containing a compromised leaf node. In addition, the
DS may be able to trigger this condition by deliberately sending the victim an
invalid Commit. In certain scenarios, this trust can enable the DS or a
malicious insider to undermine the post-compromise security guarantees provided
by MLS.</t>
        <t indent="0" pn="section-5.3-5">Actions to recover from desynchronization can also have availability and DoS
implications.  For example, if a recovery mechanism relies on external joins, a
malicious member that deliberately posts an invalid Commit could also post a
corrupted GroupInfo object in order to prevent victims from rejoining the group.
Thus, careful analysis of security implications should be made for any system
for recovering from desynchronization.</t>
      </section>
    </section>
    <section anchor="functional-requirements" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-functional-requirements">Functional Requirements</name>
      <t indent="0" pn="section-6-1">MLS is designed as a large-scale group messaging protocol and hence aims to
provide both performance and security (e.g., integrity and confidentiality)
to its users. Messaging systems that implement MLS provide support for
conversations involving two or more members, and aim to scale to groups with
tens of thousands of members, typically including many users using multiple devices.</t>
      <section anchor="membership-changes" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-membership-changes">Membership Changes</name>
        <t indent="0" pn="section-6.1-1">MLS aims to provide agreement on group membership, meaning that all group
members have agreed on the list of current group members.</t>
        <t indent="0" pn="section-6.1-2">Some applications may wish to enforce Access Control Lists (ACLs) to limit addition or removal of group
members to privileged clients or users. Others may wish to require
authorization from the current group members or a subset thereof.  Such policies
can be implemented at the application layer, on top of MLS. Regardless, MLS does
not allow for or support addition or removal of group members without informing
all other members.
</t>
        <t indent="0" pn="section-6.1-3">Membership of an MLS group is managed at the level of individual clients.  In
most cases, a client corresponds to a specific device used by a user. If a user
has multiple devices, the user will generally be represented in a group by
multiple clients (although applications could choose to have devices share
keying material).  If an application wishes to implement operations at the level
of users, it is up to the application to track which clients belong to a given
user and ensure that they are added/removed consistently.</t>
        <t indent="0" pn="section-6.1-4">MLS provides two mechanisms for changing the membership of a group.  The primary
mechanism is for an authorized member of the group to send a Commit that adds or
removes other members.  A secondary mechanism is an "external join": A member of
the group publishes certain information about the group, which a new member can
use to construct an "external" Commit message that adds the new member to the
group.  (There is no similarly unilateral way for a member to leave the group;
they must be removed by a remaining member.)
</t>
        <t indent="0" pn="section-6.1-5">With both mechanisms, changes to the membership are initiated from inside the
group.  When members perform changes directly, this is clearly the case.
External joins are authorized indirectly, in the sense that a member publishing
a GroupInfo object authorizes anyone to join who has access to the GroupInfo
object, subject to whatever access control policies the application applies
for external joins.</t>
        <t indent="0" pn="section-6.1-6">Both types of joins are done via a Commit message, which could be
blocked by the DS or rejected by clients if the join is not authorized.  The
former approach requires that Commits be visible to the DS; the latter approach
requires that clients all share a consistent policy. In the unfortunate event
that an unauthorized member is able to join, MLS enables any member to remove
them.</t>
        <t indent="0" pn="section-6.1-7">Application setup may also determine other criteria for membership validity. For
example, per-device signature keys can be signed by an identity key recognized
by other participants. If a certificate chain is used to authenticate device
signature keys, then revocation by the owner adds an alternative mechanism to prompt
membership removal.</t>
        <t indent="0" pn="section-6.1-8">An MLS group's secrets change on every change of membership, so each client only
has access to the secrets used by the group while they are a member.  Messages
sent before a client joins or after they are removed are protected with keys
that are not accessible to the client.  Compromise of a member removed from a
group does not affect the security of messages sent after their removal.
Messages sent during the client's membership are also secure as long as the
client has properly implemented the MLS deletion schedule, which calls for the
secrets used to encrypt or decrypt a message to be deleted after use, along with
any secrets that could be used to derive them.</t>
      </section>
      <section anchor="parallel-groups" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-parallel-groups">Parallel Groups</name>
        <t indent="0" pn="section-6.2-1">Any user or client may have membership in several groups simultaneously.  The
set of members of any group may or may not overlap with the members of
another group. MLS guarantees that the FS and PCS goals within a given group are
maintained and not weakened by user membership in multiple groups. However,
actions in other groups likewise do not strengthen the FS and PCS guarantees
within a given group, e.g., key updates within a given group following a device
compromise do not provide PCS healing in other groups; each group must be
updated separately to achieve these security objectives.  This also applies to
future groups that a member has yet to join, which are likewise unaffected by
updates performed in current groups.</t>
        <t indent="0" pn="section-6.2-2">Applications can strengthen connectivity among parallel groups by requiring
periodic key updates from a user across all groups in which they have
membership.
</t>
        <t indent="0" pn="section-6.2-3">MLS provides a pre-shared key (PSK) mechanism that can be used to link healing properties
among parallel groups.  For example, suppose a common member M of two groups A
and B has performed a key update in group A but not in group B.  The key update
provides PCS with regard to M in group A.  If a PSK is exported from group A and
injected into group B, then some of these PCS properties carry over to group B,
since the PSK and secrets derived from it are only known to the new, updated
version of M, not to the old, possibly compromised version of M.</t>
      </section>
      <section anchor="asynchronous-usage" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-asynchronous-usage">Asynchronous Usage</name>
        <t indent="0" pn="section-6.3-1">No operation in MLS requires two distinct clients or members to be online
simultaneously. In particular, members participating in conversations protected
using MLS can update the group's keys, add or remove new members, and send
messages without waiting for another user's reply.</t>
        <t indent="0" pn="section-6.3-2">Messaging systems that implement MLS have to provide a transport layer for
delivering messages asynchronously and reliably.</t>
      </section>
      <section anchor="access-control" numbered="true" removeInRFC="false" toc="include" pn="section-6.4">
        <name slugifiedName="name-access-control">Access Control</name>
        <t indent="0" pn="section-6.4-1">Because all clients within a group (members) have access to the shared
cryptographic material, the MLS protocol allows each member of the messaging group
to perform operations. However, every service/infrastructure has control over
policies applied to its own clients. Applications managing MLS clients can be
configured to allow for specific group operations. On the one hand, an
application could decide that a group administrator will be the only member to
perform Add and Remove operations. On the other hand, in many settings such as
open discussion forums, joining can be allowed for anyone.
</t>
        <t indent="0" pn="section-6.4-2">While MLS application messages are always encrypted,
MLS handshake messages can be sent either encrypted (in an MLS
PrivateMessage) or unencrypted (in an MLS PublicMessage). Applications
may be designed such that intermediaries need to see handshake
messages, for example to enforce policy on which commits are allowed,
or to provide MLS ratchet tree data in a central location. If
handshake messages are unencrypted, it is especially important that
they be sent over a channel with strong transport encryption
(see <xref target="security-and-privacy-considerations" format="default" sectionFormat="of" derivedContent="Section 8"/>) in order to prevent external
attackers from monitoring the status of the group. Applications that
use unencrypted handshake messages may take additional steps to reduce
the amount of metadata that is exposed to the intermediary. Everything
else being equal, using encrypted handshake messages provides stronger
privacy properties than using unencrypted handshake messages,
as it prevents intermediaries from learning about the structure
of the group.
</t>
        <t indent="0" pn="section-6.4-3">If handshake messages are encrypted, any access
control policies must be applied at the client, so the application must ensure
that the access control policies are consistent across all clients to make sure
that they remain in sync.  If two different policies were applied, the clients
might not accept or reject a group operation and end up in different
cryptographic states, breaking their ability to communicate.</t>
        <t indent="3" pn="section-6.4-4"><strong>Recommendation:</strong> Avoid using inconsistent access control policies,
especially when using encrypted group operations.</t>
        <t indent="0" pn="section-6.4-5">MLS allows actors outside the group to influence the group in two ways: External
signers can submit proposals for changes to the group, and new joiners can use
an external join to add themselves to the group.  The <tt>external_senders</tt>
extension ensures that all members agree on which signers are allowed to send
proposals, but any other policies must be assured to be consistent, as noted above.</t>
        <t indent="3" pn="section-6.4-6"><strong>Recommendation:</strong> Have an explicit group policy setting the conditions under
which external joins are allowed.</t>
      </section>
      <section anchor="handling-authentication-failures" numbered="true" removeInRFC="false" toc="include" pn="section-6.5">
        <name slugifiedName="name-handling-authentication-fai">Handling Authentication Failures</name>
        <t indent="0" pn="section-6.5-1">Within an MLS group, every member is authenticated to every other member by
means of credentials issued and verified by the AS.  MLS
does not prescribe what actions, if any, an application should take in the event
that a group member presents an invalid credential.  For example, an application
may require such a member to be immediately evicted or may allow some grace
period for the problem to be remediated. To avoid operational problems, it is
important for all clients in a group to have a consistent view of which
credentials in a group are valid, and how to respond to invalid credentials.</t>
        <t indent="3" pn="section-6.5-2"><strong>Recommendation:</strong> Have a uniform credential validation process to ensure
that all group members evaluate other members' credentials in the same way.</t>
        <t indent="3" pn="section-6.5-3"><strong>Recommendation:</strong> Have a uniform policy for how invalid credentials are
handled.</t>
        <t indent="0" pn="section-6.5-4">In some authentication systems, it is possible for a previously valid credential
to become invalid over time.  For example, in a system based on X.509
certificates, credentials can expire or be revoked.  The MLS update mechanisms
allow a client to replace an old credential with a new one. This is best done
before the old credential becomes invalid.</t>
        <t indent="3" pn="section-6.5-5"><strong>Recommendation:</strong> Proactively rotate credentials, especially if a credential
is about to become invalid.</t>
      </section>
      <section anchor="state-loss" numbered="true" removeInRFC="false" toc="include" pn="section-6.6">
        <name slugifiedName="name-recovery-after-state-loss">Recovery After State Loss</name>
        <t indent="0" pn="section-6.6-1">Group members whose local MLS state is lost or corrupted can reinitialize their
state by rejoining the group as a new member and removing the member
representing their earlier state.  An application can require that a client
performing such a reinitialization prove its prior membership with a PSK that
was exported from the previous state.</t>
        <t indent="0" pn="section-6.6-2">There are a few practical challenges to this approach.  For example, the
application will need to ensure that all members have the required PSK,
including any new members that have joined the group since the epoch in which
the PSK was issued.  And of course, if the PSK is lost or corrupted along with
the member's other state, then it cannot be used to recover.</t>
        <t indent="0" pn="section-6.6-3">Reinitializing in this way does not provide the member with access to group
messages exchanged during the state loss window, but enables proof of prior
membership in the group. Applications may choose various configurations for
providing lost messages to valid group members that are able to prove prior
membership.</t>
      </section>
      <section anchor="support-for-multiple-devices" numbered="true" removeInRFC="false" toc="include" pn="section-6.7">
        <name slugifiedName="name-support-for-multiple-device">Support for Multiple Devices</name>
        <t indent="0" pn="section-6.7-1">It is common for users within a group to own multiple devices. A new
device can be added to a group and be considered as a new client by the
protocol. This client will not gain access to the history even if it is owned by
someone who owns another member of the group.  MLS does not provide direct
support for restoring history in this case, but applications can elect to
provide such a mechanism outside of MLS.  Such mechanisms, if used, may reduce
the FS and PCS guarantees provided by MLS.</t>
      </section>
      <section anchor="extensibility" numbered="true" removeInRFC="false" toc="include" pn="section-6.8">
        <name slugifiedName="name-extensibility">Extensibility</name>
        <t indent="0" pn="section-6.8-1">The MLS protocol provides several extension points where additional information
can be provided.  Extensions to KeyPackages allow clients to disclose additional
information about their capabilities.  Groups can also have extension data
associated with them, and the group agreement properties of MLS will confirm
that all members of the group agree on the content of these extensions.</t>
      </section>
      <section anchor="application-data-framing-and-type-advertisements" numbered="true" removeInRFC="false" toc="include" pn="section-6.9">
        <name slugifiedName="name-application-data-framing-an">Application Data Framing and Type Advertisements</name>
        <t indent="0" pn="section-6.9-1">Application messages carried by MLS are opaque to the protocol and can contain
arbitrary data. Each application that uses MLS needs to define the format of
its <tt>application_data</tt> and any mechanism necessary to determine the format of
that content over the lifetime of an MLS group. In many applications, this means
managing format migrations for groups with multiple members who may each be
offline at unpredictable times.</t>
        <t indent="3" pn="section-6.9-2"><strong>Recommendation:</strong> Use the content mechanism defined in
<xref target="I-D.ietf-mls-extensions" format="default" sectionFormat="of" derivedContent="EXTENSIONS"/>, unless the specific application defines another
mechanism that more appropriately addresses the same requirements for that
application of MLS.
</t>
        <t indent="0" pn="section-6.9-3">The MLS framing for application messages also provides a field where clients can
send information that is authenticated but not encrypted.  Such information can
be used by servers that handle the message, but group members are assured that
it has not been tampered with.</t>
      </section>
      <section anchor="federation" numbered="true" removeInRFC="false" toc="include" pn="section-6.10">
        <name slugifiedName="name-federation">Federation</name>
        <t indent="0" pn="section-6.10-1">The protocol aims to be compatible with federated environments. While this
document does not specify all necessary mechanisms required for federation,
multiple MLS implementations can interoperate to form federated systems if they
use compatible authentication mechanisms, cipher suites, application content, and
infrastructure functionalities. Federation is described in more detail in
<xref target="I-D.ietf-mls-federation" format="default" sectionFormat="of" derivedContent="FEDERATION"/>.</t>
      </section>
      <section anchor="compatibility-with-future-versions-of-mls" numbered="true" removeInRFC="false" toc="include" pn="section-6.11">
        <name slugifiedName="name-compatibility-with-future-v">Compatibility with Future Versions of MLS</name>
        <t indent="0" pn="section-6.11-1">It is important that multiple versions of MLS be able to coexist in the
future. Thus, MLS offers a version negotiation mechanism; this mechanism
prevents version downgrade attacks where an attacker would actively rewrite
messages with a lower protocol version than the messages originally offered by the
endpoints. When multiple versions of MLS are available, the negotiation protocol
guarantees that the creator is able to select the best version out of those
supported in common by the group.</t>
        <t indent="0" pn="section-6.11-2">In MLS 1.0, the creator of the group is responsible for selecting the best
cipher suite supported across clients. Each client is able to verify availability
of protocol version, cipher suites, and extensions at all times once it has at
least received the first group operation message.</t>
        <t indent="0" pn="section-6.11-3">Each member of an MLS group advertises the protocol functionality they support.
These capability advertisements can be updated over time, e.g., if client
software is updated while the client is a member of a group. Thus, in addition
to preventing downgrade attacks, the members of a group can also observe when it
is safe to upgrade to a new cipher suite or protocol version.</t>
      </section>
    </section>
    <section anchor="operational-requirements" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-operational-requirements">Operational Requirements</name>
      <t indent="0" pn="section-7-1">MLS is a security layer that needs to be integrated with an application. A
fully functional deployment of MLS will have to make a number of decisions about
how MLS is configured and operated.  Deployments that wish to interoperate will
need to make compatible decisions. This section lists all of the dependencies of
an MLS deployment that are external to the protocol specification, but would
still need to be aligned within a given MLS deployment, or for two deployments
to potentially interoperate.
</t>
      <t indent="0" pn="section-7-2">The protocol has a built-in ability to negotiate protocol versions,
cipher suites, extensions, credential types, and additional proposal types. For
two deployments to interoperate, they must have overlapping support in each of
these categories. The <tt>required_capabilities</tt> extension (<xref section="7.2" sectionFormat="of" target="RFC9420" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9420#section-7.2" derivedContent="RFC9420"/>) can promote interoperability with a wider set of clients by
ensuring that certain functionality continues to be supported by a group, even
if the clients in the group aren't currently relying on it.</t>
      <t indent="0" pn="section-7-3">MLS relies on the following network services, which need to be compatible in
order for two different deployments based on them to interoperate.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-4">
        <li pn="section-7-4.1">
          <t indent="0" pn="section-7-4.1.1">An <strong>Authentication Service</strong>, described fully in <xref target="authentication-service" format="default" sectionFormat="of" derivedContent="Section 4"/>,
defines the types of credentials which may be used in a deployment and
provides methods for:
          </t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7-4.1.2"><li pn="section-7-4.1.2.1" derivedCounter="1.">
              <t indent="0" pn="section-7-4.1.2.1.1">Issuing new credentials with a relevant credential lifetime,</t>
            </li>
            <li pn="section-7-4.1.2.2" derivedCounter="2.">
              <t indent="0" pn="section-7-4.1.2.2.1">Validating a credential against a reference identifier,</t>
            </li>
            <li pn="section-7-4.1.2.3" derivedCounter="3.">
              <t indent="0" pn="section-7-4.1.2.3.1">Validating whether or not two credentials represent the same client, and</t>
            </li>
            <li pn="section-7-4.1.2.4" derivedCounter="4.">
              <t indent="0" pn="section-7-4.1.2.4.1">Optionally revoking credentials which are no longer authorized.</t>
            </li>
          </ol>
        </li>
        <li pn="section-7-4.2">
          <t indent="0" pn="section-7-4.2.1">A <strong>Delivery Service</strong>, described fully in <xref target="delivery-service" format="default" sectionFormat="of" derivedContent="Section 5"/>, provides
methods for:
          </t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7-4.2.2"><li pn="section-7-4.2.2.1" derivedCounter="1.">
              <t indent="0" pn="section-7-4.2.2.1.1">Delivering messages for a group to all members in the group.</t>
            </li>
            <li pn="section-7-4.2.2.2" derivedCounter="2.">
              <t indent="0" pn="section-7-4.2.2.2.1">Delivering Welcome messages to new members of a group.</t>
            </li>
            <li pn="section-7-4.2.2.3" derivedCounter="3.">
              <t indent="0" pn="section-7-4.2.2.3.1">Uploading new KeyPackages for a user's own clients.</t>
            </li>
            <li pn="section-7-4.2.2.4" derivedCounter="4.">
              <t indent="0" pn="section-7-4.2.2.4.1">Downloading KeyPackages for specific clients. Typically, KeyPackages are
used once and consumed.</t>
            </li>
          </ol>
        </li>
        <li pn="section-7-4.3">
          <t indent="0" pn="section-7-4.3.1">Additional services may or may not be required, depending on the application
design:  </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-4.3.2">
            <li pn="section-7-4.3.2.1">
              <t indent="0" pn="section-7-4.3.2.1.1">In cases where group operations are not encrypted, the DS has the ability to
observe and maintain a copy of the public group state. In particular, this
is useful for either (1) clients that do not have the ability to send the full public
state in a Welcome message when inviting a user or (2) clients that need to
recover from losing their state. Such public state can contain privacy-sensitive information such as group members' credentials and related public
keys; hence, services need to carefully evaluate the privacy impact of
storing this data on the DS.</t>
            </li>
            <li pn="section-7-4.3.2.2">
              <t indent="0" pn="section-7-4.3.2.2.1">If external joiners are allowed, there must be a method for publishing a
serialized <tt>GroupInfo</tt> object (with an <tt>external_pub</tt> extension) that
corresponds to a specific group and epoch, and for keeping that object in sync with
the state of the group.</t>
            </li>
            <li pn="section-7-4.3.2.3">
              <t indent="0" pn="section-7-4.3.2.3.1">If an application chooses not to allow external joining, it may
instead provide a method for external users to solicit group members (or a
designated service) to add them to a group.</t>
            </li>
            <li pn="section-7-4.3.2.4">
              <t indent="0" pn="section-7-4.3.2.4.1">If the application uses PSKs that members of a group may not have access to
(e.g., to control entry into the group or to prove membership in the group
in the past, as discussed in <xref target="state-loss" format="default" sectionFormat="of" derivedContent="Section 6.6"/>), there must be a method for distributing
these PSKs to group members who might not have them -- for instance, if they
joined the group after the PSK was generated.</t>
            </li>
            <li pn="section-7-4.3.2.5">
              <t indent="0" pn="section-7-4.3.2.5.1">If an application wishes to detect and possibly discipline members that send
malformed commits with the intention of corrupting a group's state, there
must be a method for reporting and validating malformed commits.</t>
            </li>
          </ul>
        </li>
      </ul>
      <t indent="0" pn="section-7-5">MLS requires the following parameters to be defined, which must be the same for
two implementations to interoperate:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-6">
        <li pn="section-7-6.1">
          <t indent="0" pn="section-7-6.1.1">The maximum total lifetime that is acceptable for a KeyPackage.</t>
        </li>
        <li pn="section-7-6.2">
          <t indent="0" pn="section-7-6.2.1">How long to store the resumption PSK for past epochs of a group.</t>
        </li>
        <li pn="section-7-6.3">
          <t indent="0" pn="section-7-6.3.1">The degree of tolerance that's allowed for out-of-order message delivery:  </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-6.3.2">
            <li pn="section-7-6.3.2.1">
              <t indent="0" pn="section-7-6.3.2.1.1">How long to keep unused nonce and key pairs for a sender.</t>
            </li>
            <li pn="section-7-6.3.2.2">
              <t indent="0" pn="section-7-6.3.2.2.1">A maximum number of unused key pairs to keep.</t>
            </li>
            <li pn="section-7-6.3.2.3">
              <t indent="0" pn="section-7-6.3.2.3.1">A maximum number of steps that clients will move a secret tree ratchet
forward in response to a single message before rejecting it.</t>
            </li>
            <li pn="section-7-6.3.2.4">
              <t indent="0" pn="section-7-6.3.2.4.1">Whether to buffer messages that aren't yet able to be understood due to
other messages not arriving first, and, if so, how many and for how long -- for
example, Commit messages that arrive before a proposal they reference or
application messages that arrive before the Commit starting an epoch.</t>
            </li>
          </ul>
        </li>
      </ul>
      <t indent="0" pn="section-7-7">If implementations differ in these parameters, they will interoperate to some
extent but may experience unexpected failures in certain situations, such as
extensive message reordering.</t>
      <t indent="0" pn="section-7-8">MLS provides the following locations where an application may store arbitrary
data. The format and intention of any data in these locations must align for two
deployments to interoperate:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-9">
        <li pn="section-7-9.1">
          <t indent="0" pn="section-7-9.1.1">Application data, sent as the payload of an encrypted message.</t>
        </li>
        <li pn="section-7-9.2">
          <t indent="0" pn="section-7-9.2.1">Additional authenticated data, sent unencrypted in an otherwise encrypted
message.</t>
        </li>
        <li pn="section-7-9.3">
          <t indent="0" pn="section-7-9.3.1">Group IDs, as decided by group creators and used to uniquely identify a group.</t>
        </li>
        <li pn="section-7-9.4">
          <t indent="0" pn="section-7-9.4.1">Application-level identifiers of public key material (specifically,
the <tt>application_id</tt> extension as defined in <xref section="5.3.3" sectionFormat="of" target="RFC9420" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9420#section-5.3.3" derivedContent="RFC9420"/>).</t>
        </li>
      </ul>
      <t indent="0" pn="section-7-10">MLS requires the following policies to be defined, which restrict the set of
acceptable behaviors in a group. These policies must be consistent between
deployments for them to interoperate:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-11">
        <li pn="section-7-11.1">
          <t indent="0" pn="section-7-11.1.1">A policy on which cipher suites are acceptable.</t>
        </li>
        <li pn="section-7-11.2">
          <t indent="0" pn="section-7-11.2.1">A policy on any mandatory or forbidden MLS extensions.</t>
        </li>
        <li pn="section-7-11.3">
          <t indent="0" pn="section-7-11.3.1">A policy on when to send proposals and commits in plaintext instead of
encrypted.</t>
        </li>
        <li pn="section-7-11.4">
          <t indent="0" pn="section-7-11.4.1">A policy for which proposals are valid to have in a commit, including but not
limited to:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-11.4.2">
            <li pn="section-7-11.4.2.1">
              <t indent="0" pn="section-7-11.4.2.1.1">When a member is allowed to add or remove other members of the group.</t>
            </li>
            <li pn="section-7-11.4.2.2">
              <t indent="0" pn="section-7-11.4.2.2.1">When, and under what circumstances, a reinitialization proposal is allowed.</t>
            </li>
            <li pn="section-7-11.4.2.3">
              <t indent="0" pn="section-7-11.4.2.3.1">When proposals from external senders are allowed and how to authorize
those proposals.</t>
            </li>
            <li pn="section-7-11.4.2.4">
              <t indent="0" pn="section-7-11.4.2.4.1">When external joiners are allowed and how to authorize those external
commits.</t>
            </li>
            <li pn="section-7-11.4.2.5">
              <t indent="0" pn="section-7-11.4.2.5.1">Which other proposal types are allowed.</t>
            </li>
          </ul>
        </li>
        <li pn="section-7-11.5">
          <t indent="0" pn="section-7-11.5.1">A policy of when members should commit pending proposals in a group.</t>
        </li>
        <li pn="section-7-11.6">
          <t indent="0" pn="section-7-11.6.1">A policy of how to protect and share the GroupInfo objects needed for
external joins.</t>
        </li>
        <li pn="section-7-11.7">
          <t indent="0" pn="section-7-11.7.1">A policy for when two credentials represent the same client, distinguishing
          the following two cases:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7-11.7.2">
            <li pn="section-7-11.7.2.1">
              <t indent="0" pn="section-7-11.7.2.1.1">When there are multiple devices for a given user.</t>
            </li>
            <li pn="section-7-11.7.2.2">
              <t indent="0" pn="section-7-11.7.2.2.1">When a single device has multiple signature keys -- for instance,
              if the device has keys corresponding to multiple overlapping time periods.</t>
            </li>
          </ul>
        </li>
        <li pn="section-7-11.8">
          <t indent="0" pn="section-7-11.8.1">A policy on how long to allow a member to stay in a group without updating its
leaf keys before removing them.</t>
        </li>
      </ul>
      <t indent="0" pn="section-7-12">Finally, there are some additional application-defined behaviors that are
partially an individual application's decision but may overlap with
interoperability:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-13">
        <li pn="section-7-13.1">
          <t indent="0" pn="section-7-13.1.1">When and how to pad messages.</t>
        </li>
        <li pn="section-7-13.2">
          <t indent="0" pn="section-7-13.2.1">When to send a reinitialization proposal.</t>
        </li>
        <li pn="section-7-13.3">
          <t indent="0" pn="section-7-13.3.1">How often clients should update their leaf keys.</t>
        </li>
        <li pn="section-7-13.4">
          <t indent="0" pn="section-7-13.4.1">Whether to prefer sending full commits or partial/empty commits.</t>
        </li>
        <li pn="section-7-13.5">
          <t indent="0" pn="section-7-13.5.1">Whether there should be a <tt>required_capabilities</tt> extension in groups.</t>
        </li>
      </ul>
    </section>
    <section anchor="security-and-privacy-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-security-and-privacy-consid">Security and Privacy Considerations</name>
      <t indent="0" pn="section-8-1">MLS adopts the Internet threat model <xref target="RFC3552" format="default" sectionFormat="of" derivedContent="RFC3552"/> and therefore assumes that the
attacker has complete control of the network. It is intended to provide the
security services described in <xref target="intended-security-guarantees" format="default" sectionFormat="of" derivedContent="Section 8.2"/> in the face of
attackers who can:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-2">
        <li pn="section-8-2.1">
          <t indent="0" pn="section-8-2.1.1">Monitor the entire network.</t>
        </li>
        <li pn="section-8-2.2">
          <t indent="0" pn="section-8-2.2.1">Read unprotected messages.</t>
        </li>
        <li pn="section-8-2.3">
          <t indent="0" pn="section-8-2.3.1">Generate, inject, and delete any message in the unprotected
transport layer.</t>
        </li>
      </ul>
      <t indent="0" pn="section-8-3">While MLS should be run over a secure transport such as QUIC <xref target="RFC9000" format="default" sectionFormat="of" derivedContent="RFC9000"/> or TLS
<xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>, the security guarantees of MLS do not depend on the
transport. This departs from the usual design practice of trusting the transport
because MLS is designed to provide security even in the face of compromised
network elements, especially the DS.</t>
      <t indent="0" pn="section-8-4">Generally, MLS is designed under the assumption that the transport layer is
present to keep metadata private from network observers, while the MLS protocol
provides confidentiality, integrity, and authentication guarantees for the
application data (which could pass through multiple systems). Additional
properties such as partial anonymity or deniability could also be achieved in
specific architecture designs.</t>
      <t indent="0" pn="section-8-5">In addition, these guarantees are intended to degrade gracefully in the presence
of compromise of the transport security links as well as of both clients and
elements of the messaging system, as described in the remainder of this section.</t>
      <section anchor="assumptions-on-transport-security-links" numbered="true" removeInRFC="false" toc="include" pn="section-8.1">
        <name slugifiedName="name-assumptions-on-transport-se">Assumptions on Transport Security Links</name>
        <t indent="0" pn="section-8.1-1">As discussed above, MLS provides the highest level of security when its messages
are delivered over an encrypted transport, thus preventing attackers from
selectively interfering with MLS communications as well as
protecting the already limited amount of metadata. Very little
information is contained in the unencrypted header of the MLS protocol message
format for group operation messages, and application messages are always
encrypted in MLS.</t>
        <t indent="3" pn="section-8.1-2"><strong>Recommendation:</strong> Use transports that provide reliability and metadata
confidentiality whenever possible, e.g., by transmitting MLS messages over
a protocol such as TLS <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> or QUIC <xref target="RFC9000" format="default" sectionFormat="of" derivedContent="RFC9000"/>.</t>
        <t indent="0" pn="section-8.1-3">MLS avoids the need to send the full list of recipients to the server for
dispatching messages because that list could potentially contain tens of
thousands of recipients. Header metadata in MLS messages typically consists of
an opaque <tt>group_id</tt>, a numerical value to determine the epoch of the group (the
number of changes that have been made to the group), and whether the message is
an application message, a proposal, or a commit.</t>
        <t indent="0" pn="section-8.1-4">Even though some of this metadata information does not consist of sensitive
information, when correlated with other data a network observer might be able to
reconstruct sensitive information. Using a secure channel to transfer this
information will prevent a network attacker from accessing this MLS protocol
metadata if it cannot compromise the secure channel.</t>
        <section anchor="integrity-and-authentication-of-custom-metadata" numbered="true" removeInRFC="false" toc="include" pn="section-8.1.1">
          <name slugifiedName="name-integrity-and-authenticatio">Integrity and Authentication of Custom Metadata</name>
          <t indent="0" pn="section-8.1.1-1">MLS provides an authenticated "Additional Authenticated Data" (AAD) field for
applications to make data available outside a PrivateMessage, while
cryptographically binding it to the message.</t>
          <t indent="3" pn="section-8.1.1-2"><strong>Recommendation:</strong> Use the "Additional Authenticated Data" field of the
PrivateMessage instead of using other unauthenticated means of sending
metadata throughout the infrastructure. If the data should be kept private, the
infrastructure should use encrypted application messages instead.</t>
        </section>
        <section anchor="metadata-protection-for-unencrypted-group-operations" numbered="true" removeInRFC="false" toc="include" pn="section-8.1.2">
          <name slugifiedName="name-metadata-protection-for-une">Metadata Protection for Unencrypted Group Operations</name>
          <t indent="0" pn="section-8.1.2-1">Having no secure channel to exchange MLS messages can have a serious impact on
privacy when transmitting unencrypted group operation messages. Observing the
contents and signatures of the group operation messages may lead an adversary to
extract information about the group membership.</t>
          <t indent="3" pn="section-8.1.2-2"><strong>Recommendation:</strong> Never use the unencrypted mode for group operations
without using a secure channel for the transport layer.</t>
        </section>
        <section anchor="dos-protection" numbered="true" removeInRFC="false" toc="include" pn="section-8.1.3">
          <name slugifiedName="name-dos-protection">DoS Protection</name>
          <t indent="0" pn="section-8.1.3-1">In general, we do not consider DoS resistance to be the
responsibility of the protocol. However, it should not be possible for anyone
aside from the DS to perform a trivial DoS attack from which it is
hard to recover. This can be achieved through the secure transport layer,
which prevents selective attack on MLS communications by network
attackers.</t>
          <t indent="0" pn="section-8.1.3-2">In the centralized setting, DoS protection can typically be performed by using
tickets or cookies which identify users to a service for a certain number of
connections. Such a system helps in preventing anonymous clients from sending
arbitrary numbers of group operation messages to the DS or the MLS
clients.</t>
          <t indent="3" pn="section-8.1.3-3"><strong>Recommendation:</strong> Use credentials uncorrelated with specific users to help
prevent DoS attacks, in a privacy-preserving manner. Note that the privacy of
these mechanisms has to be adjusted in accordance with the privacy expected
from secure transport links. (See more discussion in the next section.)</t>
        </section>
        <section anchor="message-suppression-and-error-correction" numbered="true" removeInRFC="false" toc="include" pn="section-8.1.4">
          <name slugifiedName="name-message-suppression-and-err">Message Suppression and Error Correction</name>
          <t indent="0" pn="section-8.1.4-1">As noted above, MLS is designed to provide some robustness in the face of
tampering within the secure transport, e.g., tampering by the DS.
The confidentiality and authenticity properties of MLS prevent the DS from
reading or writing messages.  MLS also provides a few tools for detecting
message suppression, with the caveat that message suppression cannot always be
distinguished from transport failure.
</t>
          <t indent="0" pn="section-8.1.4-2">Each encrypted MLS message carries a per-sender incrementing "generation" number.
If a group member observes a gap in the generation
sequence for a sender, then they know that they have missed a message from that
sender.  MLS also provides a facility for group members to send authenticated
acknowledgments of application messages received within a group.</t>
          <t indent="0" pn="section-8.1.4-3">As discussed in <xref target="delivery-service" format="default" sectionFormat="of" derivedContent="Section 5"/>, the DS is trusted to select
the single Commit message that is applied in each epoch from among the Commits sent
by group members.  Since only one Commit per epoch is meaningful, it's not
useful for the DS to transmit multiple Commits to clients.  The risk remains
that the DS will use the ability maliciously.</t>
        </section>
      </section>
      <section anchor="intended-security-guarantees" numbered="true" removeInRFC="false" toc="include" pn="section-8.2">
        <name slugifiedName="name-intended-security-guarantee">Intended Security Guarantees</name>
        <t indent="0" pn="section-8.2-1">MLS aims to provide a number of security guarantees, covering authentication, as
well as confidentiality guarantees to different degrees in different scenarios.</t>
        <section anchor="message-secrecy-authentication" numbered="true" removeInRFC="false" toc="include" pn="section-8.2.1">
          <name slugifiedName="name-message-secrecy-and-authent">Message Secrecy and Authentication</name>
          <t indent="0" pn="section-8.2.1-1">MLS enforces the encryption of application messages and thus generally
guarantees authentication and confidentiality of application messages sent in a
group.</t>
          <t indent="0" pn="section-8.2.1-2">In particular, this means that only other members of a given group can decrypt
the payload of a given application message, which includes information about the
sender of the message.</t>
          <t indent="0" pn="section-8.2.1-3">Similarly, group members receiving a message from another group member can
authenticate that group member as the sender of the message and verify the
message's integrity.</t>
          <t indent="0" pn="section-8.2.1-4">Message content can be deniable if the signature keys are exchanged over a
deniable channel prior to signing messages.</t>
          <t indent="0" pn="section-8.2.1-5">Depending on the group settings, handshake messages can be encrypted as well. If
that is the case, the same security guarantees apply.</t>
          <t indent="0" pn="section-8.2.1-6">MLS optionally allows the addition of padding to messages, mitigating the amount
of information leaked about the length of the plaintext to an observer on the
network.</t>
        </section>
        <section anchor="fs-and-pcs" numbered="true" removeInRFC="false" toc="include" pn="section-8.2.2">
          <name slugifiedName="name-forward-secrecy-and-post-co">Forward Secrecy and Post-Compromise Security</name>
          <t indent="0" pn="section-8.2.2-1">MLS provides additional protection regarding secrecy of past messages and future
messages. These cryptographic security properties are forward secrecy (FS) and post-compromise security (PCS).</t>
          <t indent="0" pn="section-8.2.2-2">FS means that access to all encrypted traffic history combined with
access to all current keying material on clients will not defeat the
secrecy properties of messages older than the oldest key of the
compromised client.  Note that this means that clients have to delete the appropriate
keys as soon as they have been used with the expected message;
otherwise, the secrecy of the messages and the security of MLS are
considerably weakened.</t>
          <t indent="0" pn="section-8.2.2-3">PCS means that if a group member's state is compromised at some time t1 but the
group member subsequently performs an update at some time t2, then all MLS
guarantees apply to messages sent by the member after time t2 and to messages sent by other
members after they have processed the update. For example, if an attacker learns
all secrets known to Alice at time t1, including both Alice's long-term secret
keys and all shared group keys, but Alice performs a key update at time t2, then
the attacker is unable to violate any of the MLS security properties after the
updates have been processed.</t>
          <t indent="0" pn="section-8.2.2-4">Both of these properties are satisfied even against compromised DSs and ASes in
the case where some other mechanism for verifying keys is in use, such as Key
Transparency <xref target="I-D.ietf-keytrans-architecture" format="default" sectionFormat="of" derivedContent="KT"/>.</t>
          <t indent="0" pn="section-8.2.2-5">Confidentiality is mainly ensured on the client side.  Because FS and PCS rely on the active deletion and
replacement of keying material, any client which is persistently offline may
still be holding old keying material and thus be a threat to both FS and PCS if
it is later compromised.</t>
          <t indent="0" pn="section-8.2.2-6">MLS partially defends against this problem by active members including
new keying material. However, not much can be done on the inactive side especially in the
case where the client has not processed messages.
</t>
          <t indent="3" pn="section-8.2.2-7"><strong>Recommendation:</strong> Mandate key updates from clients that are not otherwise
sending messages and evict clients that are idle for too long.</t>
          <t indent="0" pn="section-8.2.2-8">These recommendations will reduce the ability of idle compromised clients to
decrypt a potentially long set of messages that might have been sent after the point of compromise.
</t>
          <t indent="0" pn="section-8.2.2-9">The precise details of such mechanisms are a matter of local policy and beyond
the scope of this document.</t>
        </section>
        <section anchor="Non-Repudiation-vs-Deniability" numbered="true" removeInRFC="false" toc="include" pn="section-8.2.3">
          <name slugifiedName="name-non-repudiation-vs-deniabil">Non-Repudiation vs. Deniability</name>
          <t indent="0" pn="section-8.2.3-1">MLS provides strong authentication within a group, such that a group member
cannot send a message that appears to be from another group member.
Additionally, some services require that a recipient be able to prove to the
service provider that a message was sent by a given client, in order to report
abuse. MLS supports both of these use cases. In some deployments, these services
are provided by mechanisms which allow the receiver to prove a message's origin
to a third party. This is often called "non-repudiation".</t>
          <t indent="0" pn="section-8.2.3-2">Roughly speaking, "deniability" is the opposite of "non-repudiation", i.e., the
property that it is impossible to prove to a third party that a message was sent
by a given sender.  MLS does not make any claims with regard to deniability.  It
may be possible to operate MLS in ways that provide certain deniability
properties, but defining the specific requirements and resulting notions of
deniability requires further analysis.</t>
        </section>
        <section anchor="associating-a-users-clients" numbered="true" removeInRFC="false" toc="include" pn="section-8.2.4">
          <name slugifiedName="name-associating-a-users-clients">Associating a User's Clients</name>
          <t indent="0" pn="section-8.2.4-1">When a user has multiple devices, the base MLS protocol only describes how to
operate each device as a distinct client in the MLS groups that the user is a
member of. As a result, the other members of the group will be able to identify
which of a user's devices sent each message and, therefore, which device the user
was using at the time. Group members would also be able to detect when the user
adds or removes authorized devices from their account. For some applications,
this may be an unacceptable breach of the user's privacy.</t>
          <t indent="0" pn="section-8.2.4-2">This risk only arises when the leaf nodes for the clients in question provide
data that can be used to correlate the clients.  One way to mitigate this
risk is by only doing client-level authentication within MLS. If user-level
authentication is still desirable, the application would have to provide it
through some other mechanism.</t>
          <t indent="0" pn="section-8.2.4-3">It is also possible to maintain user-level authentication while hiding
information about the clients that a user owns.  This can be done by having the
clients share cryptographic state, so that they appear as a single client within
the MLS group. Appearing as a single client has the privacy benefits of no
longer leaking which device was used to send a particular message and no longer
leaking the user's authorized devices. However, the application would need to
provide a synchronization mechanism so that the state of each client remains consistent
across changes to the MLS group. Flaws in this synchronization mechanism may
impair the ability of the user to recover from a compromise of one of their
devices. In particular, state synchronization may make it easier for an attacker
to use one compromised device to establish exclusive control of a user's
account, locking them out entirely and preventing them from recovering.
</t>
        </section>
      </section>
      <section anchor="endpoint-compromise" numbered="true" removeInRFC="false" toc="include" pn="section-8.3">
        <name slugifiedName="name-endpoint-compromise">Endpoint Compromise</name>
        <t indent="0" pn="section-8.3-1">The MLS protocol adopts a threat model which includes multiple forms of
endpoint/client compromise. While adversaries are in a strong position if
they have compromised an MLS client, there are still situations where security
guarantees can be recovered thanks to the PCS properties achieved by the MLS
protocol.</t>
        <t indent="0" pn="section-8.3-2">In this section we will explore the consequences and recommendations regarding
the following compromise scenarios:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8.3-3">
          <li pn="section-8.3-3.1">
            <t indent="0" pn="section-8.3-3.1.1">The attacker has access to a symmetric encryption key.</t>
          </li>
          <li pn="section-8.3-3.2">
            <t indent="0" pn="section-8.3-3.2.1">The attacker has access to an application ratchet secret.</t>
          </li>
          <li pn="section-8.3-3.3">
            <t indent="0" pn="section-8.3-3.3.1">The attacker has access to the group secrets for one group.</t>
          </li>
          <li pn="section-8.3-3.4">
            <t indent="0" pn="section-8.3-3.4.1">The attacker has access to a signature oracle for any group.</t>
          </li>
          <li pn="section-8.3-3.5">
            <t indent="0" pn="section-8.3-3.5.1">The attacker has access to the signature key for one group.</t>
          </li>
          <li pn="section-8.3-3.6">
            <t indent="0" pn="section-8.3-3.6.1">The attacker has access to all secrets of a user for all groups (full state
compromise).</t>
          </li>
        </ul>
        <section anchor="symmetric-key-compromise" numbered="true" removeInRFC="false" toc="include" pn="section-8.3.1">
          <name slugifiedName="name-compromise-of-symmetric-key">Compromise of Symmetric Keying Material</name>
          <t indent="0" pn="section-8.3.1-1">As described above, each MLS epoch creates a new group secret.</t>
          <t indent="0" pn="section-8.3.1-2">These group secrets are then used to create a per-sender ratchet secret, which
in turn is used to create a per-sender Authenticated Encryption with
   Associated Data (AEAD) <xref target="RFC5116" format="default" sectionFormat="of" derivedContent="RFC5116"/> key
that is then used to encrypt MLS plaintext messages.  Each time a message is
sent, the ratchet secret is used to create a new ratchet secret and a new
corresponding AEAD key.  Because of the properties of the key derivation
function, it is not possible to compute a ratchet secret from its corresponding
AEAD key or compute ratchet secret n-1 from ratchet secret n.
</t>
          <t indent="0" pn="section-8.3.1-3">Below, we consider the compromise of each of these pieces of keying material in
turn, in ascending order of severity.  While this is a limited kind of
compromise, it can be realistic in cases of implementation vulnerabilities where
only part of the memory leaks to the adversary.</t>
          <section anchor="compromise-of-aead-keys" numbered="true" removeInRFC="false" toc="exclude" pn="section-8.3.1.1">
            <name slugifiedName="name-compromise-of-aead-keys">Compromise of AEAD Keys</name>
            <t indent="0" pn="section-8.3.1.1-1">In some circumstances, adversaries may have access to specific AEAD keys and
nonces which protect an application message or a group operation message. Compromise of
these keys allows the attacker to decrypt the specific message encrypted with
that key but no other; because the AEAD keys are derived from the ratchet
secret, it cannot generate the next ratchet secret and hence not the next AEAD
key.</t>
            <t indent="0" pn="section-8.3.1.1-2">In the case of an application message, an AEAD key compromise means that the
encrypted application message will be leaked as well as the signature over that
message. This means that the compromise has both confidentiality and privacy
implications on the future AEAD encryptions of that chain.  In the case of a
group operation message, only the privacy is affected, as the signature is
revealed, because the secrets themselves are protected by Hybrid Public Key Encryption (HPKE).  Note
that under that compromise scenario, authentication is not affected in either of
these cases.  As every member of the group can compute the AEAD keys for all the
chains (they have access to the group secrets) in order to send and receive
messages, the authentication provided by the AEAD encryption layer of the common
framing mechanism is weak. Successful decryption of an AEAD encrypted message
only guarantees that some member of the group -- or in this case an attacker
who has compromised the AEAD keys -- sent the message.</t>
            <t indent="0" pn="section-8.3.1.1-3">Compromise of the AEAD keys allows the attacker to send an encrypted message
using that key, but the attacker cannot send a message to a group that appears to be from
any valid client because the attacker cannot forge the signature. This applies to all the
forms of symmetric key compromise described in <xref target="symmetric-key-compromise" format="default" sectionFormat="of" derivedContent="Section 8.3.1"/>.
</t>
          </section>
          <section anchor="compromise-of-ratchet-secret-material" numbered="true" removeInRFC="false" toc="exclude" pn="section-8.3.1.2">
            <name slugifiedName="name-compromise-of-ratchet-secre">Compromise of Ratchet Secret Material</name>
            <t indent="0" pn="section-8.3.1.2-1">When a ratchet secret is compromised, the adversary can compute both the current
AEAD keys for a given sender and any future keys for that sender in this
epoch. Thus, it can decrypt current and future messages by the corresponding
sender. However, because it does not have previous ratchet secrets, it cannot
decrypt past messages as long as those secrets and keys have been deleted.
</t>
            <t indent="0" pn="section-8.3.1.2-2">Because of its forward secrecy guarantees, MLS will also retain secrecy of all
other AEAD keys generated for <em>other</em> MLS clients, outside this dedicated chain
of AEAD keys and nonces, even within the epoch of the compromise.  MLS provides
post-compromise security against an active adaptive attacker across epochs for
AEAD encryption, which means that as soon as the epoch is changed, if the
attacker does not have access to more secret material they won't be able to
access any protected messages from future epochs.</t>
          </section>
          <section anchor="compromise-of-the-group-secrets-of-a-single-group-for-one-or-more-group-epochs" numbered="true" removeInRFC="false" toc="exclude" pn="section-8.3.1.3">
            <name slugifiedName="name-compromise-of-the-group-sec">Compromise of the Group Secrets of a Single Group for One or More Group Epochs</name>
            <t indent="0" pn="section-8.3.1.3-1">An adversary who gains access to a set of group secrets -- as when a member of the
group is compromised -- is significantly more powerful. In this section, we
consider the case where the signature keys are not compromised. This can occur
if the attacker has access to part of the memory containing the group secrets
but not to the signature keys which might be stored in a secure enclave.</t>
            <t indent="0" pn="section-8.3.1.3-2">In this scenario, the adversary gains the ability to compute any number of
ratchet secrets for the epoch and their corresponding AEAD encryption keys and
thus can encrypt and decrypt all messages for the compromised epochs.</t>
            <t indent="0" pn="section-8.3.1.3-3">If the adversary is passive, it is expected from the PCS properties of the MLS
protocol that as soon as the compromised party remediates the compromise and
sends an honest Commit message, the next epochs will provide message secrecy.</t>
            <t indent="0" pn="section-8.3.1.3-4">If the adversary is active, the adversary can engage in the protocol itself and
perform updates on behalf of the compromised party with no ability for an honest
group to recover message secrecy. However, MLS provides PCS against active
adaptive attackers through its Remove group operation. This means that as long
as other members of the group are honest, the protocol will guarantee message
secrecy for all messages exchanged in the epochs after the compromised party has
been removed.</t>
          </section>
        </section>
        <section anchor="compromise-by-an-active-adversary-with-the-ability-to-sign-messages" numbered="true" removeInRFC="false" toc="include" pn="section-8.3.2">
          <name slugifiedName="name-compromise-by-an-active-adv">Compromise by an Active Adversary with the Ability to Sign Messages</name>
          <t indent="0" pn="section-8.3.2-1">If an active adversary has compromised an MLS client and can sign messages, two
different scenarios emerge. In the strongest compromise scenario, the attacker
has access to the signing key and can forge authenticated messages. In a weaker,
yet realistic scenario, the attacker has compromised a client but the client
signature keys are protected with dedicated hardware features which do not allow
direct access to the value of the private key and instead provide a signature
API.</t>
          <t indent="0" pn="section-8.3.2-2">When considering an active adaptive attacker with access to a signature oracle,
the compromise scenario implies a significant impact on both the secrecy and
authentication guarantees of the protocol, especially if the attacker also has
access to the group secrets. In that case, both secrecy and authentication are
broken.  The attacker can generate any message, for the current and future
epochs, until the compromise is remediated and the formerly compromised client
sends an honest update.</t>
          <t indent="0" pn="section-8.3.2-3">Note that under this compromise scenario, the attacker can perform all
operations which are available to a legitimate client even without access to the
actual value of the signature key.</t>
        </section>
        <section anchor="compromise-of-the-authentication-with-access-to-a-signature-key" numbered="true" removeInRFC="false" toc="include" pn="section-8.3.3">
          <name slugifiedName="name-compromise-of-authenticatio">Compromise of Authentication with Access to a Signature Key</name>
          <t indent="0" pn="section-8.3.3-1">The difference between having access to the value of the signature key and only
having access to a signing oracle is not about the ability of an active adaptive
network attacker to perform different operations during the time of the
compromise; the attacker can perform every operation available to a legitimate
client in both cases.</t>
          <t indent="0" pn="section-8.3.3-2">There is a significant difference, however, in terms of recovery after a
compromise.</t>
          <t indent="0" pn="section-8.3.3-3">Because of the PCS guarantees provided by the MLS protocol, when a previously
compromised client recovers from compromise and performs an honest Commit, both
secrecy and authentication of future messages can be recovered as long as the
attacker doesn't otherwise get access to the key. Because the adversary doesn't
have the signing key, they cannot authenticate messages on behalf of the
compromised party, even if they still have control over some group keys by
colluding with other members of the group.</t>
          <t indent="0" pn="section-8.3.3-4">This is in contrast with the case where the signature key is leaked. In that
case, the compromised endpoint needs to refresh its credentials and invalidate
the old credentials before the attacker will be unable to authenticate messages.</t>
          <t indent="0" pn="section-8.3.3-5">Beware that in both oracle and private key access, an active adaptive attacker
can follow the protocol and request to update its own credential. This in turn
induces a signature key rotation, which could provide the attacker with part or
the full value of the private key, depending on the architecture of the service
provider.</t>
          <t indent="3" pn="section-8.3.3-6"><strong>Recommendation:</strong> Signature private keys should be compartmentalized from
other secrets and preferably protected by a Hardware Security Module (HSM) or dedicated hardware
features to allow recovery of the authentication for future messages after a
compromise.
</t>
          <t indent="3" pn="section-8.3.3-7"><strong>Recommendation:</strong> When the credential type supports revocation, the users of
a group should check for revoked keys.</t>
        </section>
        <section anchor="security-considerations-in-the-context-of-a-full-state-compromise" numbered="true" removeInRFC="false" toc="include" pn="section-8.3.4">
          <name slugifiedName="name-security-considerations-in-">Security Considerations in the Context of a Full State Compromise</name>
          <t indent="0" pn="section-8.3.4-1">In real-world compromise scenarios, it is often the case that adversaries target
specific devices to obtain parts of the memory or even the ability to execute
arbitrary code in the targeted device.</t>
          <t indent="0" pn="section-8.3.4-2">Also, recall that in this setting, the application will often retain the
unencrypted messages. If so, the adversary does not have to break encryption at
all to access sent and received messages. Messages may also be sent by using the
application to instruct the protocol implementation.</t>
          <t indent="3" pn="section-8.3.4-3"><strong>Recommendation:</strong> If messages are stored on the device, they should be
protected using encryption at rest, and the keys used should be stored
securely using dedicated mechanisms on the device.</t>
          <t indent="3" pn="section-8.3.4-4"><strong>Recommendation:</strong> If the threat model of the system includes an adversary
that can access the messages on the device without even needing to attack
MLS, the application should delete plaintext and ciphertext messages as soon
as practical after encryption or decryption.</t>
          <t indent="0" pn="section-8.3.4-5">Note that this document makes a clear distinction between the way signature keys
and other group shared secrets must be handled.  In particular, a large set of
group secrets cannot necessarily be assumed to be protected by an HSM or secure
enclave features. This is especially true because these keys are frequently used
and changed with each message received by a client.</t>
          <t indent="0" pn="section-8.3.4-6">However, the signature private keys are mostly used by clients to send a
message. They also provide strong authentication guarantees to other clients;
hence, we consider that their protection by additional security mechanisms should
be a priority.</t>
          <t indent="0" pn="section-8.3.4-7">Overall, there is no way to detect or prevent these compromises, as discussed in
the previous sections: Performing separation of the application secret states
can help recovery after compromise; this is the case for signature keys, but
similar concerns exist for a client's encryption private keys.</t>
          <t indent="3" pn="section-8.3.4-8"><strong>Recommendation:</strong> The secret keys used for public key encryption should be
stored similarly to the way the signature keys are stored, as keys can be used
to decrypt the group operation messages and contain the secret material used
to compute all the group secrets.</t>
          <t indent="0" pn="section-8.3.4-9">Even if secure enclaves are not perfectly secure or are even completely broken,
adopting additional protections for these keys can ease recovery of the secrecy
and authentication guarantees after a compromise where, for instance, an
attacker can sign messages without having access to the key. In certain
contexts, the rotation of credentials might only be triggered by the AS through
ACLs and hence be beyond the capabilities of the attacker.</t>
        </section>
      </section>
      <section anchor="service-node-compromise" numbered="true" removeInRFC="false" toc="include" pn="section-8.4">
        <name slugifiedName="name-service-node-compromise">Service Node Compromise</name>
        <section anchor="general-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-8.4.1">
          <name slugifiedName="name-general-considerations">General Considerations</name>
          <section anchor="privacy-of-the-network-connections" numbered="true" removeInRFC="false" toc="exclude" pn="section-8.4.1.1">
            <name slugifiedName="name-privacy-of-the-network-conn">Privacy of the Network Connections</name>
            <t indent="0" pn="section-8.4.1.1-1">There are many scenarios leading to communication between the application on a
device and the DS or the AS. In particular,
when:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8.4.1.1-2">
              <li pn="section-8.4.1.1-2.1">
                <t indent="0" pn="section-8.4.1.1-2.1.1">The application connects to the AS to generate or validate
a new credential before distributing it.</t>
              </li>
              <li pn="section-8.4.1.1-2.2">
                <t indent="0" pn="section-8.4.1.1-2.2.1">The application fetches credentials at the DS prior to creating
a messaging group (one-to-one or more than two clients).</t>
              </li>
              <li pn="section-8.4.1.1-2.3">
                <t indent="0" pn="section-8.4.1.1-2.3.1">The application fetches service provider information or messages on the
DS.</t>
              </li>
              <li pn="section-8.4.1.1-2.4">
                <t indent="0" pn="section-8.4.1.1-2.4.1">The application sends service provider information or messages to the Delivery
Service.</t>
              </li>
            </ul>
            <t indent="0" pn="section-8.4.1.1-3">In all these cases, the application will often connect to the device via a
secure transport which leaks information about the origin of the request, such as
the IP address and -- depending on the protocol -- the MAC address of the device.</t>
            <t indent="0" pn="section-8.4.1.1-4">Similar concerns exist in the peer-to-peer use cases for MLS.</t>
            <t indent="3" pn="section-8.4.1.1-5"><strong>Recommendation:</strong> In the case where privacy or anonymity is
important, using adequate protection such as Multiplexed Application Substrate over QUIC Encryption (MASQUE)
<xref target="I-D.schinazi-masque-proxy" format="default" sectionFormat="of" derivedContent="MASQUE-PROXY"/>, Tor <xref target="Tor" format="default" sectionFormat="of" derivedContent="Tor"/>, or a VPN can improve metadata
protection.
</t>
            <t indent="0" pn="section-8.4.1.1-6">More generally, using anonymous credentials in an MLS-based architecture might
not be enough to provide strong privacy or anonymity properties.</t>
          </section>
          <section anchor="storage-of-metadata-and-encryption-at-rest-on-the-servers" numbered="true" removeInRFC="false" toc="exclude" pn="section-8.4.1.2">
            <name slugifiedName="name-storage-of-metadata-and-enc">Storage of Metadata and Encryption at Rest on the Servers</name>
            <t indent="0" pn="section-8.4.1.2-1">In the case where private data or metadata has to be persisted on the servers
for functionality (mappings between identities and push tokens, group
metadata, etc.), it should be stored encrypted at rest and only decrypted upon need
during the execution. Honest service providers can rely on such "encryption at
rest" mechanisms to be able to prevent access to the data when not using it.</t>
            <t indent="3" pn="section-8.4.1.2-2"><strong>Recommendation:</strong> Store cryptographic material used for server-side
decryption of sensitive metadata on the clients and only send it when needed.
The server can use the secret to open and update encrypted data containers
after which they can delete these keys until the next time they need it, in
which case those can be provided by the client.</t>
            <t indent="3" pn="section-8.4.1.2-3"><strong>Recommendation:</strong> Rely on group secrets exported from the MLS session for
server-side encryption at rest and update the key after each removal from the
group. Otherwise, rotate those keys on a regular basis.</t>
          </section>
        </section>
        <section anchor="delivery-service-compromise" numbered="true" removeInRFC="false" toc="include" pn="section-8.4.2">
          <name slugifiedName="name-delivery-service-compromise">Delivery Service Compromise</name>
          <t indent="0" pn="section-8.4.2-1">MLS is intended to provide strong guarantees in the face of compromise of the
DS. Even a totally compromised DS should not be able to read messages or inject
    messages that will be acceptable to legitimate clients. It should also not be
able to undetectably remove, reorder, or replay messages.</t>
          <t indent="0" pn="section-8.4.2-2">However, a malicious DS can mount a variety of DoS attacks on the system,
including total DoS attacks (where it simply refuses to forward any messages)
and partial DoS attacks (where it refuses to forward messages to and from
specific clients).  As noted in <xref target="delivery-guarantees" format="default" sectionFormat="of" derivedContent="Section 5.2"/>, these attacks are only
partially detectable by clients without an out-of-band channel. Ultimately,
failure of the DS to provide reasonable service must be dealt with as a customer
service matter, not via technology.</t>
          <t indent="0" pn="section-8.4.2-3">Because the DS is responsible for providing the initial keying material to
clients, it can provide stale keys. This does not inherently lead to compromise
of the message stream, but does allow the DS to attack post-compromise security to a limited
extent. This threat can be mitigated by having initial keys expire.</t>
          <t indent="0" pn="section-8.4.2-4">Initial keying material (KeyPackages) using the <tt>basic</tt> credential type is more
vulnerable to replacement by a malicious or compromised DS, as there is no
built-in cryptographic binding between the identity and the public key of the
client.</t>
          <t indent="3" pn="section-8.4.2-5"><strong>Recommendation:</strong> Prefer a credential type in KeyPackages which includes a
strong cryptographic binding between the identity and its key (for example, the
<tt>x509</tt> credential type). When using the <tt>basic</tt> credential type, take extra
care to verify the identity (typically out of band).</t>
          <section anchor="privacy-of-delivery-and-push-notifications" numbered="true" removeInRFC="false" toc="exclude" pn="section-8.4.2.1">
            <name slugifiedName="name-privacy-of-delivery-and-pus">Privacy of Delivery and Push Notifications</name>
            <t indent="0" pn="section-8.4.2.1-1">Push tokens provide an important mechanism that is often ignored from the standpoint of privacy considerations. In many modern messaging architectures, applications are using
push notification mechanisms typically provided by OS vendors. This is to make
sure that when messages are available at the DS (or via other
mechanisms if the DS is not a central server), the recipient application on a
device knows about it. Sometimes the push notification can contain the
application message itself, which saves a round trip with the DS.</t>
            <t indent="0" pn="section-8.4.2.1-2">To "push" this information to the device, the service provider and the OS
infrastructures use unique per-device, per-application identifiers called
push tokens. This means that the push notification provider and the service
provider have information on which devices receive information and at which
point in time. Alternatively, non-mobile applications could use a WebSocket or
persistent connection for notifications directly from the DS.</t>
            <t indent="0" pn="section-8.4.2.1-3">Even though the service provider and the push notification provider
can't necessarily access the content (typically encrypted MLS
messages), no technical mechanism in MLS prevents them from determining
which devices are recipients of the same message.</t>
            <t indent="0" pn="section-8.4.2.1-4">For secure messaging systems, push notifications are often sent in real time, as it
is not acceptable to create artificial delays for message retrieval.</t>
            <t indent="3" pn="section-8.4.2.1-5"><strong>Recommendation:</strong> If real-time notifications are not necessary, one can
delay notifications randomly across recipient devices using a mixnet or other
techniques.</t>
            <t indent="0" pn="section-8.4.2.1-6">Note that with a legal request to ask the service provider for the push token
associated with an identifier, it is easy to correlate the token with a second
request to the company operating the push notification system to get information
about the device, which is often linked with a real identity via a cloud
account, a credit card, or other information.</t>
            <t indent="3" pn="section-8.4.2.1-7"><strong>Recommendation:</strong> If stronger privacy guarantees are needed with regard to
the push notification provider, the client can choose to periodically connect
to the DS without the need of a dedicated push notification
infrastructure.</t>
            <t indent="0" pn="section-8.4.2.1-8">Applications can also consider anonymous systems for server fanout (for
example, <xref target="Loopix" format="default" sectionFormat="of" derivedContent="Loopix"/>).</t>
          </section>
        </section>
        <section anchor="as-compromise" numbered="true" removeInRFC="false" toc="include" pn="section-8.4.3">
          <name slugifiedName="name-authentication-service-comp">Authentication Service Compromise</name>
          <t indent="0" pn="section-8.4.3-1">The Authentication Service design is left to the infrastructure designers. In
most designs, a compromised AS is a serious matter, as the AS can serve
incorrect or attacker-provided identities to clients.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8.4.3-2">
            <li pn="section-8.4.3-2.1">
              <t indent="0" pn="section-8.4.3-2.1.1">The attacker can link an identity to a credential.</t>
            </li>
            <li pn="section-8.4.3-2.2">
              <t indent="0" pn="section-8.4.3-2.2.1">The attacker can generate new credentials.</t>
            </li>
            <li pn="section-8.4.3-2.3">
              <t indent="0" pn="section-8.4.3-2.3.1">The attacker can sign new credentials.</t>
            </li>
            <li pn="section-8.4.3-2.4">
              <t indent="0" pn="section-8.4.3-2.4.1">The attacker can publish or distribute credentials.</t>
            </li>
          </ul>
          <t indent="0" pn="section-8.4.3-3">An attacker that can generate or sign new credentials may or may not have access
to the underlying cryptographic material necessary to perform such
operations. In that last case, it results in windows of time for which all
emitted credentials might be compromised.</t>
          <t indent="3" pn="section-8.4.3-4"><strong>Recommendation:</strong> Use HSMs to store the root signature keys to limit the
ability of an adversary with no physical access to extract the top-level
signature private key.</t>
          <t indent="0" pn="section-8.4.3-5">Note that historically some systems generate signature keys on the
AS and distribute the private keys to clients along with
their credential. This is a dangerous practice because it allows the AS or an
attacker who has compromised the AS to silently impersonate the client.</t>
          <section anchor="authentication-compromise-ghost-users-and-impersonations" numbered="true" removeInRFC="false" toc="exclude" pn="section-8.4.3.1">
            <name slugifiedName="name-authentication-compromise-g">Authentication Compromise: Ghost Users and Impersonation</name>
            <t indent="0" pn="section-8.4.3.1-1">One important property of MLS is that all members know which other members are
in the group at all times. If all members of the group and the AS
are honest, no parties other than the members of the current group can
read and write messages protected by the protocol for that group.</t>
            <t indent="0" pn="section-8.4.3.1-2">This guarantee applies to the cryptographic identities of the members.
Details about how to verify the identity of a client depend on the MLS
credential type used. For example, cryptographic verification of credentials can
be largely performed autonomously (e.g., without user interaction) by the
clients themselves for the <tt>x509</tt> credential type.</t>
            <t indent="0" pn="section-8.4.3.1-3">In contrast, when MLS clients use the <tt>basic</tt> credential type, some other
mechanism must be used to verify identities. For instance, the Authentication
Service could operate some sort of directory server to provide keys, or users
could verify keys via an out-of-band mechanism.</t>
            <t indent="3" pn="section-8.4.3.1-4"><strong>Recommendation:</strong> Select the MLS credential type with the strongest security
which is supported by all target members of an MLS group.</t>
            <t indent="3" pn="section-8.4.3.1-5"><strong>Recommendation:</strong> Do not use the same signature key pair across
groups. Update all keys for all groups on a regular basis. Do not preserve
keys in different groups when suspecting a compromise.</t>
            <t indent="0" pn="section-8.4.3.1-6">If the AS is compromised, it could validate a signature
key pair (or generate a new one) for an attacker. The attacker could then use this key pair to join a
group as if it were another of the user's clients.  Because a user can have many
MLS clients running the MLS protocol, it possibly has many signature key pairs
for multiple devices. These attacks could be very difficult to detect,
especially in large groups where the UI might not reflect all the changes back
to the users. If the application participates in a key transparency mechanism in
which it is possible to determine every key for a given user, then this
would allow for detection of surreptitiously created false credentials.</t>
            <t indent="3" pn="section-8.4.3.1-7"><strong>Recommendation:</strong> Make sure that MLS clients reflect all the membership
changes to the users as they happen. If a choice has to be made because the
number of notifications is too high, the client should provide a log of state
of the device so that the user can examine it.</t>
            <t indent="3" pn="section-8.4.3.1-8"><strong>Recommendation:</strong> Provide a key transparency mechanism for the
AS to allow public verification of the credentials
authenticated by this service.</t>
            <t indent="0" pn="section-8.4.3.1-9">While the ways to handle MLS credentials are not defined by the protocol or the
architecture documents, the MLS protocol has been designed with a mechanism that
can be used to provide out-of-band authentication to users. The
<tt>authentication_secret</tt> generated for each user at each epoch of the group is a
one-time, per-client authentication secret which can be exchanged between users
to prove their identities to each other. This can be done, for instance, using a QR
code that can be scanned by the other parties.
</t>
            <t indent="3" pn="section-8.4.3.1-10"><strong>Recommendation:</strong> Provide one or more out-of-band authentication mechanisms
to limit the impact of an AS compromise.</t>
            <t indent="0" pn="section-8.4.3.1-11">We note, again, that the AS may not be a centralized
system and could be realized by many mechanisms such as establishing prior
one-to-one deniable channels, gossiping, or using trust on first use (TOFU) for
credentials used by the MLS protocol.</t>
            <t indent="0" pn="section-8.4.3.1-12">Another important consideration is the ease of redistributing new keys on client
compromise, which helps recovering security faster in various cases.</t>
          </section>
          <section anchor="privacy-of-the-group-membership" numbered="true" removeInRFC="false" toc="exclude" pn="section-8.4.3.2">
            <name slugifiedName="name-privacy-of-the-group-member">Privacy of the Group Membership</name>
            <t indent="0" pn="section-8.4.3.2-1">Group membership is itself sensitive information, and MLS is designed to limit
the amount of persistent metadata. However, large groups often require an
infrastructure that provides server fanout.  In the case of client fanout, the
destination of a message is known by all clients; hence, the server usually does
not need this information.  However, servers may learn this information through
traffic analysis.  Unfortunately, in a server-side fanout model, the Delivery
Service can learn that a given client is sending the same message to a set of
other clients. In addition, there may be applications of MLS in which the group
membership list is stored on some server associated with the DS.
</t>
            <t indent="0" pn="section-8.4.3.2-2">While this knowledge is not a breach of the protocol's authentication or
confidentiality guarantees, it is a serious issue for privacy.</t>
            <t indent="0" pn="section-8.4.3.2-3">Some infrastructures keep a mapping between keys used in the MLS protocol and
user identities. An attacker with access to this information due to compromise
or regulation can associate unencrypted group messages (e.g., Commits and
Proposals) with the corresponding user identity.</t>
            <t indent="3" pn="section-8.4.3.2-4"><strong>Recommendation:</strong> Use encrypted group operation messages to limit privacy
risks whenever possible.</t>
            <t indent="0" pn="section-8.4.3.2-5">In certain cases, the adversary can access specific bindings between public keys
and identities. If the signature keys are reused across groups, the adversary
can get more information about the targeted user.</t>
            <t indent="3" pn="section-8.4.3.2-6"><strong>Recommendation:</strong> Ensure that linking between public keys and identities
only happens in expected scenarios.</t>
          </section>
        </section>
      </section>
      <section anchor="considerations-for-attacks-outside-of-the-threat-model" numbered="true" removeInRFC="false" toc="include" pn="section-8.5">
        <name slugifiedName="name-considerations-for-attacks-">Considerations for Attacks Outside of the Threat Model</name>
        <t indent="0" pn="section-8.5-1">Physical attacks on devices storing and executing MLS principals are not
considered in depth in the threat model of the MLS protocol.  While
non-permanent, non-invasive attacks can sometimes be equivalent to software
attacks, physical attacks are considered outside of the MLS threat model.</t>
        <t indent="0" pn="section-8.5-2">Compromise scenarios typically consist of a software adversary, which can
maintain active adaptive compromise and arbitrarily change the behavior of the
client or service.</t>
        <t indent="0" pn="section-8.5-3">On the other hand, security goals consider that honest clients will always run
the protocol according to its specification. This relies on implementations of
the protocol to securely implement the specification, which remains non-trivial.</t>
        <t indent="3" pn="section-8.5-4"><strong>Recommendation:</strong> Additional steps should be taken to protect the device and
the MLS clients from physical compromise. In such settings, HSMs and secure
enclaves can be used to protect signature keys.</t>
      </section>
      <section anchor="no-protection-against-replay-by-insiders" numbered="true" removeInRFC="false" toc="include" pn="section-8.6">
        <name slugifiedName="name-no-protection-against-repla">No Protection Against Replay by Insiders</name>
        <t indent="0" pn="section-8.6-1">MLS does not protect against one group member replaying a PrivateMessage sent by another
group member within the same epoch that the message was originally sent. Similarly, MLS
does not protect against the replay (by a group member or otherwise) of a PublicMessage
within the same epoch that the message was originally sent. Applications for
whom replay is an important risk should apply mitigations at the application layer, as
discussed below.</t>
        <t indent="0" pn="section-8.6-2">In addition to the risks discussed in <xref target="symmetric-key-compromise" format="default" sectionFormat="of" derivedContent="Section 8.3.1"/>, an attacker
with access to the ratchet secrets for an endpoint can replay PrivateMessage
objects sent by other members of the group by taking the signed content of the
message and re-encrypting it with a new generation of the original sender's
ratchet.  If the other members of the group interpret a message with a new
generation as a fresh message, then this message will appear fresh.  (This is
possible because the message signature does not cover the <tt>generation</tt> field
of the message.)  Messages sent as PublicMessage objects similarly lack replay
protections.  There is no message counter comparable to the <tt>generation</tt> field
in PrivateMessage.</t>
        <t indent="0" pn="section-8.6-3">Applications can detect replay by including a unique identifier for the message
(e.g., a counter) in either the message payload or the <tt>authenticated_data</tt>
field, both of which are included in the signatures for
PublicMessage and PrivateMessage.</t>
      </section>
      <section anchor="cryptographic-analysis-of-the-mls-protocol" numbered="true" removeInRFC="false" toc="include" pn="section-8.7">
        <name slugifiedName="name-cryptographic-analysis-of-t">Cryptographic Analysis of the MLS Protocol</name>
        <t indent="0" pn="section-8.7-1">Various academic works have analyzed MLS and the different security guarantees
it aims to provide. The security of large parts of the protocol has been
        analyzed by <xref target="BBN19" format="default" sectionFormat="of" derivedContent="BBN19"/> (for MLS Draft 7), <xref target="ACDT21" format="default" sectionFormat="of" derivedContent="ACDT21"/> (for MLS Draft 11), and <xref target="AJM20" format="default" sectionFormat="of" derivedContent="AJM20"/> (for MLS Draft 12).</t>
        <t indent="0" pn="section-8.7-2">Individual components of various drafts of the MLS protocol have been
analyzed in isolation and with differing adversarial models. For
example, <xref target="BBR18" format="default" sectionFormat="of" derivedContent="BBR18"/>, <xref target="ACDT19" format="default" sectionFormat="of" derivedContent="ACDT19"/>, <xref target="ACCKKMPPWY19" format="default" sectionFormat="of" derivedContent="ACCKKMPPWY19"/>, <xref target="AJM20" format="default" sectionFormat="of" derivedContent="AJM20"/>,
<xref target="ACJM20" format="default" sectionFormat="of" derivedContent="ACJM20"/>, <xref target="AHKM21" format="default" sectionFormat="of" derivedContent="AHKM21"/>, <xref target="CGWZ25" format="default" sectionFormat="of" derivedContent="CGWZ25"/>, and <xref target="WPB25" format="default" sectionFormat="of" derivedContent="WPB25"/> analyze the
ratcheting tree sub-protocol of MLS that facilitates key agreement;
<xref target="WPBB22" format="default" sectionFormat="of" derivedContent="WPBB22"/> analyzes the sub-protocol of MLS for group state agreement
and authentication; and <xref target="BCK21" format="default" sectionFormat="of" derivedContent="BCK21"/> analyzes the key derivation paths in
the ratchet tree and key schedule. Finally, <xref target="CHK21" format="default" sectionFormat="of" derivedContent="CHK21"/> analyzes the
authentication and cross-group healing guarantees provided by MLS.</t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-keytrans-architecture" to="KT"/>
    <displayreference target="I-D.ietf-mls-extensions" to="EXTENSIONS"/>
    <displayreference target="I-D.ietf-mls-federation" to="FEDERATION"/>
    <displayreference target="I-D.schinazi-masque-proxy" to="MASQUE-PROXY"/>
    <references anchor="sec-combined-references" pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC5116" target="https://www.rfc-editor.org/info/rfc5116" quoteTitle="true" derivedAnchor="RFC5116">
          <front>
            <title>An Interface and Algorithms for Authenticated Encryption</title>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <date month="January" year="2008"/>
            <abstract>
              <t indent="0">This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5116"/>
          <seriesInfo name="DOI" value="10.17487/RFC5116"/>
        </reference>
        <reference anchor="RFC9420" target="https://www.rfc-editor.org/info/rfc9420" quoteTitle="true" derivedAnchor="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 indent="0">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>
      </references>
      <references anchor="sec-informative-references" pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="ACCKKMPPWY19" target="https://eprint.iacr.org/2019/1489" quoteTitle="true" derivedAnchor="ACCKKMPPWY19">
          <front>
            <title>Keep the Dirt: Tainted TreeKEM, Adaptively and Actively Secure Continuous Group Key Agreement</title>
            <author initials="J." surname="Alwen" fullname="Joel Alwen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Capretto" fullname="Margarita Capretto">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Cueto" fullname="Miguel Cueto">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Kamath" fullname="Chethan Kamath">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Klein" fullname="Karen Klein">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I." surname="Markov" fullname="Ilia Markov">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Pascual-Perez" fullname="Guillermo Pascual-Perez">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Pietrzak" fullname="Krzysztof Pietrzak">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Walter" fullname="Michael Walter">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Yeo" fullname="Michelle Yeo">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>
        <reference anchor="ACDT19" target="https://eprint.iacr.org/2019/1189.pdf" quoteTitle="true" derivedAnchor="ACDT19">
          <front>
            <title>Security Analysis and Improvements for the IETF MLS Standard for Group Messaging</title>
            <author initials="J." surname="Alwen" fullname="Joel Alwen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Coretti" fullname="Sandro Coretti">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Dodis" fullname="Yevgeniy Dodis">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Tselekounis" fullname="Yiannis Tselekounis">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>
        <reference anchor="ACDT21" target="https://eprint.iacr.org/2021/1083.pdf" quoteTitle="true" derivedAnchor="ACDT21">
          <front>
            <title>Modular Design of Secure Group Messaging Protocols and the Security of MLS</title>
            <author initials="J." surname="Alwen" fullname="Joel Alwen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Coretti" fullname="Sandro Coretti">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Dodis" fullname="Yevgeniy Dodis">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Tselekounis" fullname="Yiannis Tselekounis">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>
        <reference anchor="ACJM20" target="https://eprint.iacr.org/2020/752.pdf" quoteTitle="true" derivedAnchor="ACJM20">
          <front>
            <title>Continuous Group Key Agreement with Active Security</title>
            <author initials="J." surname="Alwen" fullname="Joel Alwen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Coretti" fullname="Sandro Coretti">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Jost" fullname="Daniel Jost">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Mularczyk" fullname="Marta Mularczyk">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>
        <reference anchor="AHKM21" target="https://eprint.iacr.org/2021/1456.pdf" quoteTitle="true" derivedAnchor="AHKM21">
          <front>
            <title>Server-Aided Continuous Group Key Agreement</title>
            <author initials="J." surname="Alwen" fullname="Joel Alwen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Hartmann" fullname="Dominik Hartmann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Kiltz" fullname="Eike Kiltz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Mularczyk" fullname="Marta Mularczyk">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>
        <reference anchor="AJM20" target="https://eprint.iacr.org/2020/1327.pdf" quoteTitle="true" derivedAnchor="AJM20">
          <front>
            <title>On The Insider Security of MLS</title>
            <author initials="J." surname="Alwen" fullname="Joel Alwen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Jost" fullname="Daniel Jost">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Mularczyk" fullname="Marta Mularczyk">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>
        <reference anchor="BBN19" target="https://inria.hal.science/hal-02425229/document" quoteTitle="true" derivedAnchor="BBN19">
          <front>
            <title>Formal Models and Verified Protocols for Group Messaging: Attacks and Proofs for IETF MLS</title>
            <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Naldurg" fullname="Prasad Naldurg">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019"/>
          </front>
          <seriesInfo name="HAL ID" value="hal-02425229"/>
        </reference>
        <reference anchor="BBR18" target="https://hal.inria.fr/hal-02425247/file/treekem+%281%29.pdf" quoteTitle="true" derivedAnchor="BBR18">
          <front>
            <title>TreeKEM: Asynchronous Decentralized Key Management for Large Dynamic Groups - A protocol proposal for Messaging Layer Security (MLS)</title>
            <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Barnes" fullname="Richard Barnes">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018"/>
          </front>
          <seriesInfo name="HAL ID" value="hal-02425247"/>
        </reference>
        <reference anchor="BCK21" target="https://eprint.iacr.org/2021/137.pdf" quoteTitle="true" derivedAnchor="BCK21">
          <front>
            <title>Security Analysis of the MLS Key Distribution</title>
            <author initials="C." surname="Brzuska" fullname="Chris Brzuska">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Cornelissen" fullname="Eric Cornelissen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Kohbrok" fullname="Konrad Kohbrok">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>
        <reference anchor="CAPBR" target="https://dl.acm.org/doi/10.1145/343477.343502" quoteTitle="true" derivedAnchor="CAPBR">
          <front>
            <title>Towards robust distributed systems (abstract)</title>
            <author fullname="Eric A. Brewer" initials="E. A." surname="Brewer">
              <organization showOnFrontPage="true">UC Berkeley and Inktomi</organization>
            </author>
            <date month="July" year="2000"/>
          </front>
          <refcontent>Proceedings of the nineteenth annual ACM symposium on Principles of distributed computing, p. 7</refcontent>
          <seriesInfo name="DOI" value="10.1145/343477.343502"/>
        </reference>
        <reference anchor="CGWZ25" target="https://eprint.iacr.org/2025/229.pdf" quoteTitle="true" derivedAnchor="CGWZ25">
          <front>
            <title>ETK: External-Operations TreeKEM and the Security of MLS in RFC 9420</title>
            <author initials="C." surname="Cremers" fullname="Cas Cremers">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Günsay" fullname="Esra Günsay">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Wesselkamp" fullname="Vera Wesselkamp">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Zhao" fullname="Mang Zhao">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2025"/>
          </front>
        </reference>
        <reference anchor="CHK21" target="https://www.usenix.org/system/files/sec21-cremers.pdf" quoteTitle="true" derivedAnchor="CHK21">
          <front>
            <title>The Complexities of Healing in Secure Group Messaging: Why Cross-Group Effects Matter</title>
            <author initials="C." surname="Cremers" fullname="Cas Cremers">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Hale" fullname="Britta Hale">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Kohbrok" fullname="Konrad Kohbrok">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="August" year="2021"/>
          </front>
          <refcontent>Proceedings of the 30th USENIX Security Symposium</refcontent>
        </reference>
        <reference anchor="I-D.ietf-mls-extensions" target="https://datatracker.ietf.org/doc/html/draft-ietf-mls-extensions-06" quoteTitle="true" derivedAnchor="EXTENSIONS">
          <front>
            <title>The Messaging Layer Security (MLS) Extensions</title>
            <author initials="R." surname="Robert" fullname="Raphael Robert">
              <organization showOnFrontPage="true">Phoenix R&amp;D</organization>
            </author>
            <date month="February" day="19" year="2025"/>
            <abstract>
              <t indent="0">   The Messaging Layer Security (MLS) protocol is an asynchronous group
   authenticated key exchange protocol.  MLS provides a number of
   capabilities to applications, as well as several extension points
   internal to the protocol.  This document provides a consolidated
   application API, guidance for how the protocol's extension points
   should be used, and a few concrete examples of both core protocol
   extensions and uses of the application API.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mls-extensions-06"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-mls-federation" target="https://datatracker.ietf.org/doc/html/draft-ietf-mls-federation-03" quoteTitle="true" derivedAnchor="FEDERATION">
          <front>
            <title>The Messaging Layer Security (MLS) Federation</title>
            <author initials="E." surname="Omara" fullname="Emad Omara">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <author initials="R." surname="Robert" fullname="Raphael Robert">
              <organization showOnFrontPage="true">Phoenix R&amp;D</organization>
            </author>
            <date month="September" day="9" year="2023"/>
            <abstract>
              <t indent="0">   This document describes how the Messaging Layer Security (MLS)
   protocol can be used in a federated environment.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/mlswg/mls-federation.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mls-federation-03"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-keytrans-architecture" target="https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-architecture-03" quoteTitle="true" derivedAnchor="KT">
          <front>
            <title>Key Transparency Architecture</title>
            <author initials="B." surname="McMillion" fullname="Brendan McMillion">
         </author>
            <date month="February" day="25" year="2025"/>
            <abstract>
              <t indent="0">   This document defines the terminology and interaction patterns
   involved in the deployment of Key Transparency (KT) in a general
   secure group messaging infrastructure, and specifies the security
   properties that the protocol provides.  It also gives more general,
   non-prescriptive guidance on how to securely apply KT to a number of
   common applications.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-keytrans-architecture-03"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="Loopix" target="" quoteTitle="true" derivedAnchor="Loopix">
          <front>
            <title>The Loopix Anonymity System</title>
            <author initials="A. M." surname="Piotrowska" fullname="Ania M. Piotrowska">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Hayes" fullname="Jamie Hayes">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Elahi" fullname="Tariq Elahi">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Meiser" fullname="Sebastian Meiser">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Danezis" fullname="George Danezis">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="August" year="2017"/>
          </front>
          <refcontent>Proceedings of the 26th USENIX Security Symposium</refcontent>
        </reference>
        <reference anchor="I-D.schinazi-masque-proxy" target="https://datatracker.ietf.org/doc/html/draft-schinazi-masque-proxy-05" quoteTitle="true" derivedAnchor="MASQUE-PROXY">
          <front>
            <title>The MASQUE Proxy</title>
            <author initials="D." surname="Schinazi" fullname="David Schinazi">
              <organization showOnFrontPage="true">Google LLC</organization>
            </author>
            <date month="February" day="18" year="2025"/>
            <abstract>
              <t indent="0">   MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a
   set of protocols and extensions to HTTP that allow proxying all kinds
   of Internet traffic over HTTP.  This document defines the concept of
   a "MASQUE Proxy", an Internet-accessible node that can relay client
   traffic in order to provide privacy guarantees.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-schinazi-masque-proxy-05"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC3552" target="https://www.rfc-editor.org/info/rfc3552" quoteTitle="true" derivedAnchor="RFC3552">
          <front>
            <title>Guidelines for Writing RFC Text on Security Considerations</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="B. Korver" initials="B." surname="Korver"/>
            <date month="July" year="2003"/>
            <abstract>
              <t indent="0">All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="72"/>
          <seriesInfo name="RFC" value="3552"/>
          <seriesInfo name="DOI" value="10.17487/RFC3552"/>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t indent="0">This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC6120" target="https://www.rfc-editor.org/info/rfc6120" quoteTitle="true" derivedAnchor="RFC6120">
          <front>
            <title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <date month="March" year="2011"/>
            <abstract>
              <t indent="0">The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6120"/>
          <seriesInfo name="DOI" value="10.17487/RFC6120"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9000" quoteTitle="true" derivedAnchor="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="Tor" target="https://torproject.org/" quoteTitle="true" derivedAnchor="Tor">
          <front>
            <title>The Tor Project</title>
            <author>
              <organization showOnFrontPage="true"/>
            </author>
          </front>
        </reference>
        <reference anchor="WPB25" target="https://eprint.iacr.org/2025/410.pdf" quoteTitle="true" derivedAnchor="WPB25">
          <front>
            <title>TreeKEM: A Modular Machine-Checked Symbolic Security Analysis of Group Key Agreement in Messaging Layer Security</title>
            <author initials="T." surname="Wallez" fullname="Théophile Wallez">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Protzenko" fullname="Jonathan Protzenko">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2025"/>
          </front>
        </reference>
        <reference anchor="WPBB22" target="https://eprint.iacr.org/2022/1732.pdf" quoteTitle="true" derivedAnchor="WPBB22">
          <front>
            <title>TreeSync: Authenticated Group Management for Messaging Layer Security</title>
            <author initials="T." surname="Wallez" fullname="Théophile Wallez">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Protzenko" fullname="Jonathan Protzenko">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2022"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact initials="R." surname="Barnes" fullname="Richard Barnes">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <email>rlb@ipv.sx</email>
        </address>
      </contact>
      <contact initials="K." surname="Cohn-Gordon" fullname="Katriel Cohn-Gordon">
        <organization showOnFrontPage="true">Meta Platforms</organization>
        <address>
          <email>me@katriel.co.uk</email>
        </address>
      </contact>
      <contact initials="C." surname="Cremers" fullname="Cas Cremers">
        <organization showOnFrontPage="true">CISPA Helmholtz Center for Information Security</organization>
        <address>
          <email>cremers@cispa.de</email>
        </address>
      </contact>
      <contact initials="B." surname="Hale" fullname="Britta Hale">
        <organization showOnFrontPage="true">Naval Postgraduate School</organization>
        <address>
          <email>britta.hale@nps.edu</email>
        </address>
      </contact>
      <contact initials="A." surname="Kwon" fullname="Albert Kwon">
        <organization showOnFrontPage="true">Badge Inc.</organization>
        <address>
          <email>kwonalbert@badgeinc.com</email>
        </address>
      </contact>
      <contact initials="K." surname="Kohbrok" fullname="Konrad Kohbrok">
        <organization showOnFrontPage="true">Phoenix R&amp;D</organization>
        <address>
          <email>konrad.kohbrok@datashrine.de</email>
        </address>
      </contact>
      <contact initials="R." surname="Mahy" fullname="Rohan Mahy">
        <organization showOnFrontPage="true">Wire</organization>
        <address>
          <email>rohan.mahy@wire.com</email>
        </address>
      </contact>
      <contact initials="B." surname="McMillion" fullname="Brendan McMillion">
        <organization showOnFrontPage="true"/>
        <address>
          <email>brendanmcmillion@gmail.com</email>
        </address>
      </contact>
      <contact initials="T. van der" surname="Merwe" fullname="Thyla van der Merwe">
        <organization showOnFrontPage="true"/>
        <address>
          <email>tjvdmerwe@gmail.com</email>
        </address>
      </contact>
      <contact initials="J." surname="Millican" fullname="Jon Millican">
        <organization showOnFrontPage="true">Meta Platforms</organization>
        <address>
          <email>jmillican@meta.com</email>
        </address>
      </contact>
      <contact initials="R." surname="Robert" fullname="Raphael Robert">
        <organization showOnFrontPage="true">Phoenix R&amp;D</organization>
        <address>
          <email>ietf@raphaelrobert.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche">
        <organization showOnFrontPage="true">Inria &amp; Mozilla</organization>
        <address>
          <email>ietf@beurdouche.com</email>
        </address>
      </author>
      <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
        <address>
          <email>ekr@rtfm.com</email>
        </address>
      </author>
      <author initials="E." surname="Omara" fullname="Emad Omara">
        <organization showOnFrontPage="true"/>
        <address>
          <email>emad.omara@gmail.com</email>
        </address>
      </author>
      <author initials="S." surname="Inguva" fullname="Srinivas Inguva">
        <organization showOnFrontPage="true"/>
        <address>
          <email>singuva@yahoo.com</email>
        </address>
      </author>
      <author initials="A." surname="Duric" fullname="Alan Duric">
        <address>
          <email>alan@duric.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
