rfc9750-draft.xml

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

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

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

  <front>
    <title abbrev="MLS Architecture">The Messaging Layer Security (MLS) Architecture</title>
    <seriesInfo name="RFC" value="9750"/>
    <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche">
      <organization>Inria &amp; Mozilla</organization>
      <address>
        <email>ietf@beurdouche.com</email>
      </address>
    </author>
    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
      <organization>Windy Hill Systems, LLC</organization>
      <address>
        <email>ekr@rtfm.com</email>
      </address>
    </author>
    <author initials="E." surname="Omara" fullname="Emad Omara">
      <organization/>
      <address>
        <email>emad.omara@gmail.com</email>
      </address>
    </author>
    <author initials="S." surname="Inguva" fullname="Srinivas Inguva">
      <organization/>
      <address>
        <email>singuva@yahoo.com</email>
      </address>
    </author>
    <author initials="A." surname="Duric" fullname="Alan Duric">
      <organization>Wire</organization>
      <address>
        <email>alan@wire.com</email>
      </address>
    </author>
    <date year="2025" month="February"/>

    <area>SEC</area>
    <workgroup>mls</workgroup>

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

    <abstract>

<t>The Messaging Layer Security (MLS) protocol (RFC 9420)
provides a Group Key Agreement protocol for messaging applications.
MLS is meant to protect against eavesdropping, tampering, and message
forgery and to provide Forward Secrecy (FS) and Post-Compromise Security
(PCS).

<!-- [rfced] Abstract:  We do not see "Group Key Agreement protocol"
in the text of any published RFC.  Should this term be lowercased or perhaps explained in the body of the document?  

Original:
 The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol)
 provides a Group Key Agreement protocol for messaging applications. -->

</t>
      <t>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>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, or the authentication service.</t>
    </abstract>
  </front>
  <middle>

<section anchor="introduction">
      <name>Introduction</name>
      <t>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>Messaging Layer Security (MLS) specifies an architecture (this document) and a
protocol <xref target="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"/>.
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">
      <name>General Setting</name>
      <section anchor="protocol-overview">
        <name>Protocol Overview</name>
        <t>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>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>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>.&nbsp;
A <em>KeyPackage</em> provides keys that can be used to add the client to a group,
including its LeafNode, and <em>Signature Key</em>.&nbsp;
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>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>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>For a more detailed explanation of these terms, please consult the MLS protocol
specification <xref target="RFC9420"/>.</t>
      </section>
      <section anchor="abstract-services">
        <name>Abstract Services</name>
        <t>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">
          <li>
            <t>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.

<!-- [rfced] Sections 2.2 and subsequent:  After the initial
definition of "AS" in Section 2.2, we see alternating use of
"AS" and "Authentication Service".  Would you like to use the
abbreviation in running text after the initial definition?

We have the same question for
* "DS" and "Delivery Service"
* "FS" and "Forward Secrecy"
* "PCS" and "Post-Compromise Security"

It seems that each of these terms is used often enough that the
abbreviations could be used after the terms are first defined.

A few examples (for "DS" and "AS"; "Delivery Services, which is
  responsible ..." has been corrected):
 *  A Delivery Service (DS) which can receive and distribute messages
    between group members.  In the case of group messaging, the
    delivery service 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.
...
 It is important to note that the Authentication Service 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 Delivery Service can be completely
 abstract if users are able to distribute credentials and messages
 without relying on a central Delivery Service (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 Section 5.2).
...
 She sends both of these messages to the Delivery Services, 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.
...
 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>
          </li>
          <li>
            <t>A Delivery Service (DS) which can receive and distribute
messages between group members. In the case of group messaging, the delivery
service 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>

<!-- [rfced] Sections 2.2 and subsequent:  We found the use of
"which" in this document confusing at times.  Please review and let us know how we may update the document. 

We found the following confusing:

 *  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.

 *  A Delivery Service (DS) which can receive and distribute messages
    between group members.  In the case of group messaging, the
    delivery service 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.
...
 Alice, Bob, and Charlie authenticate to the DS and store some initial
 keying material which can be used to send encrypted messages to them
 for the first time.
...
 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.
...
 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.
...
 Each encrypted MLS message carries a "generation" number which is a
 per-sender incrementing counter.
...
 In this section, we consider the case where the signature keys are
 not compromised, which 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.
...
 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>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">
          <li>
            <t>Several secure messaging services today provide a centralized DS and rely on
manual comparison of clients' public keys as the AS.</t>
          </li>
          <li>
            <t>MLS clients connected to a peer-to-peer network could instantiate a
decentralized DS by transmitting MLS messages over that network.</t>
          </li>
          <li>
            <t>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>It is important to note that the Authentication Service can be
completely abstract in the case of a Service Provider that allows MLS
clients to generate, distribute, and validate credentials themselves.
As with the AS, the Delivery Service can be completely abstract if
users are able to distribute credentials and messages without relying
on a central Delivery Service (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"/>).</t>

        <t><xref target="fig-mls-overview"/> 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">
          <name>A Simplified Messaging System</name>
          <artset>
            <artwork type="svg"><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"><![CDATA[
     +----------------+    +--------------+
     | 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">
      <name>Overview of Operation</name>
      <t><xref target="fig-group-formation-example"/> 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">
        <name>Group Formation Example</name>
        <artset>
          <artwork type="svg"><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" stroke-linecap="round">
              <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 104,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 368,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 152,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 336,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="32" y="292">Welcome</text>
                <text x="84" y="292">(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="408" y="324">Welcome</text>
                <text x="464" y="324">(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="32" y="404">Welcome</text>
                <text x="104" y="404">(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="376" y="452">Welcome</text>
                <text x="448" y="452">(Charlie)</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art"><![CDATA[
Alice     Bob       Charlie                     AS        DS

Create account --------------------------------->               |
<------------------------------------- Credential               |
          Create account ----------------------->               | Step 1
          <--------------------------- Credential               |
                    Create account ------------->               |
                    <----------------- Credential               |

Initial Keying Material ----------------------------------->    |
          Initial Keying Material ------------------------->    | Step 2
                    Initial Keying Material --------------->    |

Get Bob Initial Keying Material --------------------------->    |
<------------------------------- Bob Initial Keying Material    |
Add Bob to Group ------------------------------------------>    | Step 3
Welcome (Bob) --------------------------------------------->    |
          <-------------------------------- Add Bob to Group    |
          <----------------------------------- Welcome (Bob)    |

Get Charlie Initial Keying Material ----------------------->    |
<--------------------------- Charlie Initial Keying Material    |
Add Charlie to Group -------------------------------------->    |
Welcome (Charlie) ----------------------------------------->    | Step 4
          <---------------------------- Add Charlie to Group    |
                     <----------------- Add Charlie to Group    |
                     <-------------------- Welcome (Charlie)    |
]]></artwork>
        </artset>
      </figure>

      <t>This process proceeds as follows.</t>
      <section anchor="step-1-account-creation">
        <name>Step 1: Account Creation</name>
        <t>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">
        <name>Step 2: Initial Keying Material</name>
        <t>Alice, Bob, and Charlie authenticate to the DS and store some initial
keying material which can be 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.</t>
      </section>
      <section anchor="step-3-adding-bob-to-the-group">
        <name>Step 3: Adding Bob to the Group</name>
        <t>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">
          <li>
            <t>A message to the entire group (which at this point is just her and Bob)
that adds Bob to the group.</t>
          </li>
          <li>
            <t>A <em>Welcome</em> 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>She sends both of these messages to the Delivery Service, 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">
        <name>Step 4: Adding Charlie to the Group</name>
        <t>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">
          <li>
            <t>A message to the entire group (consisting of her, Bob, and Charlie) adding
Charlie to the group.</t>
          </li>
          <li>
            <t>A <em>Welcome</em> 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>At the completion of this process, we have a group with Alice, Bob, and Charlie,
which means that they share a single encryption key that can be used to
send messages or to key other protocols.

<!-- [rfced] Section 3.4:  "or to key other protocols" reads oddly.
Are some words missing, or does the text indicate that other
protocols are keyed?  In other words, is "key" used as a verb here?

Original:
 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">
        <name>Other Group Operations</name>
        <t>Once the group has been created, clients can perform other actions,
such as:</t>
        <ul spacing="normal">
          <li>
            <t>sending a message to everyone in the group</t>
          </li>
          <li>
            <t>receiving a message from someone in the group</t>
          </li>
          <li>
            <t>adding one or more clients to an existing group</t>
          </li>
          <li>
            <t>removing one or more members from an existing group</t>
          </li>
          <li>
            <t>updating their own key material</t>
          </li>
          <li>
            <t>leaving a group (by asking to be removed)</t>
          </li>
        </ul>
        <t>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">
        <name>Proposals and Commits</name>
        <t>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>
          <dt>Proposal:</dt>
          <dd>
            <t>This message describes the change to be made (e.g., add Bob to the group)
but does not effect a change.</t>
          </dd>
          <dt>Commit:</dt>
          <dd>
            <t>This message changes the group state to include the changes described in
a set of proposals.</t>
          </dd>
        </dl>
        <t>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 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"/>). 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>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">
        <name>Users, Clients, and Groups</name>
        <t>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>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.</t>
        <t>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 might not have been able to decrypt it for some reason.</t>
      </section>
    </section>
    <section anchor="authentication-service">
      <name>Authentication Service</name>
      <t>The Authentication Service (AS) has to provide three services:</t>
      <ol spacing="normal" type="1"><li>
          <t>Issue credentials to clients that attest to bindings between identities and
signature key pairs.</t>
        </li>
        <li>
          <t>Enable a client to verify that a credential presented by another client is
valid with respect to a reference identifier.</t>
        </li>
        <li>
          <t>Enable a group member to verify that a credential represents the same client
as another credential.</t>
        </li>
      </ol>
      <t>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>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">
        <li>
          <t>A PKI could be used as an AS <xref target="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>
          <t>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>
          <t>In a system based on end-user Key Transparency (KT) <xref target="CONIKS"/> <xref target="I-D.ietf-keytrans-architecture"/>, 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>By the nature of its roles 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"/>.</t>
      <t>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 the
security considerations.

<!-- [rfced] Section 4:  Should "the security considerations" be
"Section 8" or some other section?

Original:
 Some
 security trade-offs related to this flexibility are discussed in the
 security considerations. -->

</t>
      <t>In many applications, there are multiple MLS clients that represent a single
entity -- for example, 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">
      <name>Delivery Service</name>
      <t>The Delivery Service (DS) plays two major roles in MLS:</t>
      <ul spacing="normal">
        <li>
          <t>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>
          <t>Routing MLS messages among clients.</t>
        </li>
      </ul>
      <t>While MLS depends on correct behavior by the Authentication Service 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">
        <name>Key Storage and Retrieval</name>
        <t>Upon joining the system, each client stores its initial cryptographic key
material with the Delivery Service. This key material, called a KeyPackage,
advertises the functional abilities of the client such as supported protocol
versions, supported extensions, and the following cryptographic information:</t>
        <ul spacing="normal">
          <li>
            <t>A credential from the Authentication Service attesting to the binding between
the identity and the client's signature key.</t>
          </li>
          <li>
            <t>The client's asymmetric encryption public key.</t>
          </li>
        </ul>
        <t>All the parameters in the KeyPackage are signed with the signature
private key corresponding to the credential.
As noted in <xref target="group-members"/>, users may own multiple clients, each
with their own keying material. Each KeyPackage is specific to an MLS version
and ciphersuite, but a client may want to offer support for multiple protocol
versions and ciphersuites. As such, there may be multiple KeyPackages stored by
each user for a mix of protocol versions, ciphersuites, and end-user devices.</t>
        <t>When a client wishes to establish a group or add clients to a group, it first
contacts the Delivery Service to request KeyPackages for each other client,
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 <tt>init_key</tt> from each KeyPackage.
When a client requests a KeyPackage in order to add a user to a group, the
Delivery Service 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 ciphersuite, 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.

<!-- [rfced] Section 5.1:  The only published RFC to date that
mentions "init_key" is Normative Reference RFC 9420.  May we cite it
here for ease of the reader?

This question also applies to "epoch_authenticator" and any other
parameters mentioned in this document and defined in RFC 9420.

Alternatively, we could add this sentence to the end of the
Introduction section:

 It is expected that readers are familiar with the terms used in
 [RFC9420].

Original:
 When a client wishes to establish a group or add clients to a group,
 it first contacts the Delivery Service to request KeyPackages for
 each other client, authenticates the KeyPackages using the signature
 keys, includes the KeyPackages in Add Proposals, encrypts the
 information needed to join the group (the _GroupInfo_ object) with an
 ephemeral key, then separately encrypts the ephemeral key with the
 init_key from each KeyPackage.

Suggested:
 When a client wishes to establish a group or add clients to a group,
 it first contacts the Delivery Service to request KeyPackages for
 each other client, authenticates the KeyPackages using the signature
 keys, includes the KeyPackages in Add Proposals, and encrypts the
 information needed to join the group (the _GroupInfo_ object) with an
 ephemeral key; it then separately encrypts the ephemeral key with
 the init_key [RFC9420] from each KeyPackage. -->

</t>
        <t>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. The Delivery Service 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"><strong>RECOMMENDATION:</strong> Ensure that "last resort" KeyPackages don't get used by
provisioning enough standard KeyPackages.</t>
            <t indent="3"><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"><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>

<!-- [rfced] Sections 5.1 and subsequent:  Do you think other documents may want to refer to specific recommendations in this document?  We wonder whether it would be helpful to number the recommendations (e.g., Recommendation 1, or Req 1).  

In addition, as <strong> is used for RECOMMENDATION, may we change this to Recommendation?  The use of capitalization seems unnecessary since it's already bold. 
-->

        <t>Overall, it needs to be noted that key packages need to be updated when
signature keys are changed.</t>
      </section>
      <section anchor="delivery-guarantees">
        <name>Delivery of Messages</name>
        <t>The main responsibility of the Delivery Service 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 Delivery Service 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>For the most part, MLS does not require the Delivery Service 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"/>), 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>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 Delivery Service. Per the CAP
theorem <xref target="CAPBR"/>, there are two general classes of distributed systems that the
Delivery Service might fall into:</t>
        <ul spacing="normal">
          <li>
            <t>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>
            <t>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>Strategies for sequencing messages in strongly and eventually consistent systems
are described in the next two subsections. Most Delivery Services 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>However, note that a malicious Delivery Service 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"/>.</t>
        <t>Other forms of Delivery Service misbehavior are still possible that are not easy
to detect. For instance, a Delivery Service 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">
          <name>Strongly Consistent</name>
          <t>With this approach, the Delivery Service 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>As an example, there could be an "ordering server" Delivery Service 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.

<!-- [rfced] Sections 5.2.1 and 8.1.4:  As it appears that "ones" in
these sentences refers to Commits, we changed "ones" to "Commits".
If this is incorrect, please clarify the text.

Original:
 This would allow clients
 to only apply the first valid Commit for an epoch and ignore
 subsequent ones.
...
 As discussed in Section 5, the Delivery Service is trusted to select
 the single Commit message that is applied in each epoch from among
 the ones sent by group members.

Currently:
 This would allow clients
 to only apply the first valid Commit for an epoch and ignore
 subsequent Commits.
...
 As discussed in Section 5, the Delivery Service is trusted to select
 the single Commit message that is applied in each epoch from among
 the Commits sent by group members. -->

</t>
          <t>Alternatively, the Delivery Service 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"/>.</t>
        </section>
        <section anchor="eventually-consistent">
          <name>Eventually Consistent</name>
          <t>With this approach, the Delivery Service is built in a way that may be
significantly more available or performant than a strongly consistent system,
but 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.

<!-- [rfced] Section 5.2.2:  Does "offers" refer to the Delivery
Service or the way?

Original:
 With this approach, the Delivery Service is built in a way that may
 be significantly more available or performant than a strongly
 consistent system, but offers weaker consistency guarantees.

Perhaps (the Delivery Service):
 With this approach, the Delivery Service is built in a way that may
 be significantly more available or performant than a strongly
 consistent system, but it offers weaker consistency guarantees.

Or possibly (the way):
 With this approach, the Delivery Service is built in a way that may
 be significantly more available or performant than a strongly
 consistent system but that offers weaker consistency guarantees. -->

</t>
          <t>This type of Delivery Service 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>Upon receiving a Commit from the Delivery Service, clients can do either of the following:</t>
          <ol spacing="normal" type="1"><li>
              <t>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>
              <t>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>If the Commit references an unknown proposal, group members may need to solicit
the Delivery Service or other group members individually for the contents of the
proposal.</t>
        </section>
        <section anchor="welcome-messages">
          <name>Welcome Messages</name>
          <t>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&nbsp;<xref target="strongly-consistent" format="counter"/> and <xref target="eventually-consistent" format="counter"/>). 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>This is particularly important when groups are being reinitialized. When a group
is reinitialized, it is restarted with a different protocol version and/or
ciphersuite 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>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>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">
        <name>Invalid Commits</name>
        <t>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"/>.</t>
        <t>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>Such "desynchronization" problems can arise even when the Delivery Service 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 allow 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.

<!-- [rfced] Section 5.3:  This sentence does not parse.  If neither
suggestion below is correct, please clarify.

Original:
 The DS can enable clients to choose between Commits, for example by
 providing Commits in the order received and allow clients to reject
 any Commits that violate their view of the group's policies.

Suggestion #1:
 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.

Suggestion #2:
 The DS can enable clients to choose between Commits - for example,
 by providing Commits in the order received - and allow clients to
 reject any Commits that violate their view of the group's policies. -->

</t>
        <t>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>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">
      <name>Functional Requirements</name>
      <t>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 they aim to scale to groups with
tens of thousands of members, typically including many users using multiple devices.</t>
      <section anchor="membership-changes">
        <name>Membership Changes</name>
        <t>MLS aims to provide agreement on group membership, meaning that all group
members have agreed on the list of current group members.</t>
        <t>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.

<!-- [rfced] Section 6.1:  The comma in this sentence makes it
difficult to parse.  Is the comma necessary?

Original:
 Some applications may wish to enforce ACLs to limit addition or
 removal of group members, to privileged clients or users. -->

</t>
        <t>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>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.  The second 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.)

<!-- [rfced] Section 6.1:  Because "primary" is used instead of
"first", should "second" in the next sentence be "secondary"?

Original:
 The primary mechanism is for an authorized member of the group to
 send a Commit that adds or removes other members.  The second
 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. -->

</t>
        <t>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>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>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>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">
        <name>Parallel Groups</name>
        <t>Any user or client may have membership in several groups simultaneously.  The
set of members of any group may or may not form a subset of 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>Applications can strengthen connectivity among parallel groups by requiring
periodic key updates from a user across all groups in which they have
membership.

<!-- [rfced] Section 6.2:  Does "they have" refer to "a user" (in
which case "they have" should be "the user has") or something else?

Original:
 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>MLS provides a pre-shared key (PSK) 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">
        <name>Asynchronous Usage</name>
        <t>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>Messaging systems that implement MLS have to provide a transport layer for
delivering messages asynchronously and reliably.</t>
      </section>
      <section anchor="access-control">
        <name>Access Control</name>
        <t>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.

<!-- [rfced] Section 6.4:

a) We see "add and remove operations" here but "Remove Proposal" in
Section 3.6 and "Remove group operation" in Section 8.3.1.3.  Should
"add and remove operations" be changed to "Add and Remove operations"?

Original:
 On the one hand, an application could
 decide that a group administrator will be the only member to perform
 add and remove operations.

b) Regarding "Remove Proposal" and "Add Proposal" as used in this
document:  RFC 9420 uses "Remove proposal" and "Add proposal" in its
text.  Would you like to use lowercase "proposal" in this document
per RFC 9420? -->

</t>
        <t>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"/>) 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.

<!-- [rfced] Section 6.4:  It is not clear what "for example" refers
to in this sentence.  If the suggested text is not correct, please
clarify.

Original:
 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.

Suggested (removing the comma after "allowed"):
 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. -->

</t>
        <t>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"><strong>RECOMMENDATION:</strong> Avoid using inconsistent access control policies in the
case of encrypted group operations.</t>
        <t>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"><strong>RECOMMENDATION:</strong> Have an explicit group policy setting the conditions under
which external joins are allowed.</t>
      </section>
      <section anchor="handling-authentication-failures">
        <name>Handling Authentication Failures</name>
        <t>Within an MLS group, every member is authenticated to every other member by
means of credentials issued and verified by the Authentication Service.  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"><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"><strong>RECOMMENDATION:</strong> Have a uniform policy for how invalid credentials are
handled.</t>
        <t>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"><strong>RECOMMENDATION:</strong> Proactively rotate credentials, especially if a credential
is about to become invalid.</t>
      </section>
      <section anchor="state-loss">
        <name>Recovery After State Loss</name>
        <t>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>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>Reinitializing in this way does not provide the member with access to group
messages exchanged during the state loss window, but it 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">
        <name>Support for Multiple Devices</name>
        <t>It is typically expected that users within a group will own various 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">
        <name>Extensibility</name>
        <t>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">
        <name>Application Data Framing and Type Advertisements</name>
        <t>Application messages carried by MLS are opaque to the protocol; they 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"><strong>RECOMMENDATION:</strong> Use the default content mechanism defined in
<xref section="3.3" sectionFormat="of" target="I-D.ietf-mls-extensions"/>, unless the specific application defines another
mechanism that more appropriately addresses the same requirements for that
application of MLS.

<!-- [rfced] Section 6.9:  We do not see the word "default" or any
indication of a default mechanism in Section 3.3 of
[I-D.ietf-mls-extensions].  Please confirm that the text and citation
are correct and will be clear to readers.

Original:
 *RECOMMENDATION:* Use the default content mechanism defined in
 Section 3.3 of [I-D.ietf-mls-extensions], unless the specific
 application defines another mechanism which more appropriately
 addresses the same requirements for that application of MLS. -->

</t>
        <t>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">
        <name>Federation</name>
        <t>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, ciphersuites, application content, and
infrastructure functionalities. Federation is described in more detail in
<xref target="I-D.ietf-mls-federation"/>.</t>
      </section>
      <section anchor="compatibility-with-future-versions-of-mls">
        <name>Compatibility with Future Versions of MLS</name>
        <t>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 version agreed upon will be the highest version supported in
common by the group.</t>
        <t>In MLS 1.0, the creator of the group is responsible for selecting the best
ciphersuite supported across clients. Each client is able to verify availability
of protocol version, ciphersuites, and extensions at all times once it has at
least received the first group operation message.</t>
        <t>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 ciphersuite or protocol version.</t>
      </section>
    </section>
    <section anchor="operational-requirements">
      <name>Operational Requirements</name>
      <t>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.

<!-- [rfced] Section 7:  This sentence is difficult to parse.  To
what does ", or for two deployments to potentially interoperate"
refer?  If the suggested text is not correct, please clarify.

Original:
 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.

Suggested:
 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 so that two
 deployments can potentially interoperate. -->

</t>
      <t>The protocol has a built-in ability to negotiate protocol versions,
ciphersuites, 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"/>) 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>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">
        <li>
          <t>An <strong>Authentication Service</strong>, described fully in <xref target="authentication-service"/>,
defines the types of credentials that may be used in a deployment and
provides methods for:
          </t>
          <ol spacing="normal" type="1"><li>
              <t>Issuing new credentials with a relevant credential lifetime,</t>
            </li>
            <li>
              <t>Validating a credential against a reference identifier,</t>
            </li>
            <li>
              <t>Validating whether or not two credentials represent the same client, and</t>
            </li>
            <li>
              <t>Optionally revoking credentials that are no longer authorized.</t>
            </li>
          </ol>
        </li>
        <li>
          <t>A <strong>Delivery Service</strong>, described fully in <xref target="delivery-service"/>, provides
methods for:
          </t>
          <ol spacing="normal" type="1"><li>
              <t>Delivering messages for a group to all members in the group.</t>
            </li>
            <li>
              <t>Delivering Welcome messages to new members of a group.</t>
            </li>
            <li>
              <t>Uploading new KeyPackages for a user's own clients.</t>
            </li>
            <li>
              <t>Downloading KeyPackages for specific clients. Typically, KeyPackages are
used once and consumed.</t>
            </li>
          </ol>
        </li>
        <li>
          <t>Additional services may or may not be required, depending on the application
design:  </t>
          <ul spacing="normal">
            <li>
              <t>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 (1)&nbsp;clients that do not have the ability to send the full public
state in a Welcome message when inviting a user or (2)&nbsp;a client that needs 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>
              <t>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>
              <t>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>
              <t>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"/>), 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>
              <t>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>MLS requires the following parameters to be defined, which must be the same for
two implementations to interoperate:</t>
      <ul spacing="normal">
        <li>
          <t>The maximum total lifetime that is acceptable for a KeyPackage.</t>
        </li>
        <li>
          <t>How long to store the resumption PSK for past epochs of a group.</t>
        </li>
        <li>
          <t>The degree of tolerance that's allowed for out-of-order message delivery:  </t>
          <ul spacing="normal">
            <li>
              <t>How long to keep unused nonce and key pairs for a sender.</t>
            </li>
            <li>
              <t>A maximum number of unused key pairs to keep.</t>
            </li>
            <li>
              <t>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>
              <t>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>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>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">
        <li>
          <t>Application data, sent as the payload of an encrypted message.</t>
        </li>
        <li>
          <t>Additional authenticated data, sent unencrypted in an otherwise encrypted
message.</t>
        </li>
        <li>
          <t>Group IDs, as decided by group creators and used to uniquely identify a group.</t>
        </li>
        <li>
          <t>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"/>).</t>
        </li>
      </ul>
      <t>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">
        <li>
          <t>A policy on which ciphersuites are acceptable.</t>
        </li>
        <li>
          <t>A policy on any mandatory or forbidden MLS extensions.</t>
        </li>
        <li>
          <t>A policy on when to send proposals and commits in plaintext instead of
encrypted.</t>
        </li>
        <li>
          <t>A policy for which proposals are valid to have in a commit, including but not
limited to:
          </t>
          <ul spacing="normal">
            <li>
              <t>When a member is allowed to add or remove other members of the group.</t>
            </li>
            <li>
              <t>When, and under what circumstances, a reinitialization proposal is allowed.</t>
            </li>
            <li>
              <t>When proposals from external senders are allowed and how to authorize
those proposals.</t>
            </li>
            <li>
              <t>When external joiners are allowed and how to authorize those external
commits.</t>
            </li>
            <li>
              <t>Which other proposal types are allowed.</t>
            </li>
          </ul>
        </li>
        <li>
          <t>A policy of when members should commit pending proposals in a group.</t>
        </li>
        <li>
          <t>A policy of how to protect and share the GroupInfo objects needed for
external joins.</t>
        </li>
        <li>
          <t>A policy for when two credentials represent the same client. Note that many
credentials may be issued attesting the same identity but for different
signature keys, because each credential corresponds to a different client
owned by the same application user. However, one device may control multiple
signature keys -- for instance, if the device has keys corresponding to multiple
overlapping time periods -- but should still only be considered a single
client.

<!-- [rfced] Section 7:  As it appears that "they have" refers to
"one device", we changed "they have" to "the device has".  If this is
incorrect, please clarify the text.

Original:
 However, one device may control multiple signature keys -
 for instance if they have keys corresponding to multiple
 overlapping time periods - but should still only be considered a
 single client.

Currently:
 However, one device may control multiple signature keys -
 for instance, if the device has keys corresponding to multiple
 overlapping time periods - but should still only be considered a
 single client. -->

</t>
        </li>
        <li>
          <t>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>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">
        <li>
          <t>When and how to pad messages.</t>
        </li>
        <li>
          <t>When to send a reinitialization proposal.</t>
        </li>
        <li>
          <t>How often clients should update their leaf keys.</t>
        </li>
        <li>
          <t>Whether to prefer sending full commits or partial/empty commits.</t>
        </li>
        <li>
          <t>Whether there should be a <tt>required_capabilities</tt> extension in groups.</t>
        </li>
      </ul>
    </section>
    <section anchor="security-and-privacy-considerations">
      <name>Security and Privacy Considerations</name>
      <t>MLS adopts the Internet threat model <xref target="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"/> in the face of
attackers who can:</t>
      <ul spacing="normal">
        <li>
          <t>Monitor the entire network.</t>
        </li>
        <li>
          <t>Read unprotected messages.</t>
        </li>
        <li>
          <t>Generate, inject, and delete any message in the unprotected
transport layer.</t>
        </li>
      </ul>
      <t>While MLS should be run over a secure transport such as QUIC <xref target="RFC9000"/> or TLS
<xref target="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>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>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">
        <name>Assumptions on Transport Security Links</name>
        <t>As discussed above, MLS provides the highest level of security when its messages
are delivered over an encrypted transport.  The main use of the secure transport
layer for MLS is to protect 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"><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"/> or QUIC <xref target="RFC9000"/>.</t>
        <t>MLS avoids needing 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>Even though some of this metadata information does not consist of sensitive
information, in correlation 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">
          <name>Integrity and Authentication of Custom Metadata</name>
          <t>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"><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">
          <name>Metadata Protection for Unencrypted Group Operations</name>
          <t>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"><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">
          <name>DoS Protection</name>
          <t>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 Delivery Service to perform a trivial DoS attack from which it is
hard to recover. This can be achieved through the secure transport layer.</t>
          <t>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 Delivery Service or the MLS
clients.</t>
              <t indent="3"><strong>RECOMMENDATION:</strong> Use credentials uncorrelated with specific users to help
prevent DoS attacks, in a manner that preserves privacy. 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">
          <name>Message Suppression and Error Correction</name>
          <t>As noted above, MLS is designed to provide some robustness in the face of
tampering within the secure transport, i.e., tampering by the Delivery Service.
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.

<!-- [rfced] Section 8.1.4:  Is tampering by the Delivery Service the
only type of tampering scenario (in which case "i.e.," is correct),
or is it one example of a tampering scenario (in which case "e.g.,"
would be correct)?

Original:
 As noted above, MLS is designed to provide some robustness in the
 face of tampering within the secure transport, i.e., tampering by the
 Delivery Service. -->

</t>
          <t>Each encrypted MLS message carries a "generation" number which is a per-sender
incrementing counter.  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>As discussed in <xref target="delivery-service"/>, the Delivery Service 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>
          <t>While it is difficult or impossible to prevent a network adversary from
suppressing payloads in transit, in certain infrastructures such as banks or
government settings, unidirectional transports can be used and be enforced via
electronic or physical devices such as diodes. This can lead to payload
corruption, which does not affect the security or privacy properties of the MLS
protocol but does affect the reliability of the service. In that case, specific
measures can be taken to ensure the appropriate level of redundancy and quality
of service for MLS.</t>
        </section>
      </section>
      <section anchor="intended-security-guarantees">
        <name>Intended Security Guarantees</name>
        <t>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">
          <name>Message Secrecy and Authentication</name>
          <t>MLS enforces the encryption of application messages and thus generally
guarantees authentication and confidentiality of application messages sent in a
group.</t>
          <t>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>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>Message content can be deniable if the signature keys are exchanged over a
deniable channel prior to signing messages.</t>
          <t>Depending on the group settings, handshake messages can be encrypted as well. If
that is the case, the same security guarantees apply.</t>
          <t>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">
          <name>Forward and Post-Compromise Security</name>

<!-- [rfced] Section 8.2.2:  Does "Forward" here refer to Forward
Secrecy (FS) or forward security as mentioned in Section 8.4.2?
Please note that we only see one instance of "forward security" in
this document (Section 8.4.2) and do not see this term used in
RFC 9420.

Original:
 8.2.2.  Forward and Post-Compromise Security -->

          <t>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>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>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 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>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"/>.</t>
          <t>Confidentiality is mainly ensured on the client side.  Because FS and PCS rely on the active deletion and
replacement of keying material, any client that 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>MLS partially defends against this problem by active members including
freshness. However, not much can be done on the inactive side especially in the
case where the client has not processed messages.

<!-- [rfced] Section 8.2.2:  We had trouble following this sentence.
Does "by active members including freshness" mean "by active members
ensuring freshness of data" or something else?

Original:
 MLS partially defends against this problem by active members
 including freshness, 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"><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>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.

<!-- [rfced] Section 8.2.2:  "followed" read oddly in this sentence.
We updated the text.  If this is incorrect, please clarify the
meaning of "followed".

Original:
 These recommendations will reduce the ability of idle compromised
 clients to decrypt a potentially long set of messages that might have
 followed the point of the compromise.

Currently:
 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>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">
          <name>Non-Repudiation vs. Deniability</name>
          <t>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 that allow the receiver to prove a message's origin
to a third party. This is often called "non-repudiation".</t>
          <t>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">
          <name>Associating a User's Clients</name>
          <t>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>This risk only arises when the leaf nodes for the clients in question provide
data that can be used to correlate the clients.  So, 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>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 clients' state remain 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.

<!-- [rfced] Section 8.2.4:  Should "the clients' state remain" be
"the clients' state remains" or "the clients' states remain"?

Original:
 However, the application would need
 to provide a synchronization mechanism so that the clients' state
 remain consistent across changes to the MLS group. -->

</t>
        </section>
      </section>
      <section anchor="endpoint-compromise">
        <name>Endpoint Compromise</name>
        <t>The MLS protocol adopts a threat model that 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>In this section, we will explore the consequences and recommendations regarding
the following compromise scenarios:</t>
        <ul spacing="normal">
          <li>
            <t>The attacker has access to a symmetric encryption key.</t>
          </li>
          <li>
            <t>The attacker has access to an application ratchet secret.</t>
          </li>
          <li>
            <t>The attacker has access to the group secrets for one group.</t>
          </li>
          <li>
            <t>The attacker has access to a signature oracle for any group.</t>
          </li>
          <li>
            <t>The attacker has access to the signature key for one group.</t>
          </li>
          <li>
            <t>The attacker has access to all secrets of a user for all groups (full state
compromise).</t>
          </li>
        </ul>
        <section anchor="symmetric-key-compromise">
          <name>Compromise of Symmetric Keying Material</name>
          <t>As described above, each MLS epoch creates a new Group Secret.</t>
          <t>These group secrets are then used to create a per-sender Ratchet Secret, which
in turn is used to create a per-sender with an additional data (Authenticated Encryption with
   Associated Data (AEAD)) key <xref target="RFC5116"/>
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.

<!-- [rfced] Section 8.3.1:  "a per-sender with" in this sentence is
difficult to follow.  If the suggested text is not correct, please
clarify.

Original:
 These group secrets are then used to create a per-sender Ratchet
 Secret, which in turn is used to create a per-sender with additional
 data (AEAD) [RFC5116] key that is then used to encrypt MLS Plaintext
 messages.

Suggested:
 These group secrets are then used to create a per-sender Ratchet
 Secret, which in turn is used to create a per-sender key with
 additional data (Authenticated Encryption with Associated Data
 (AEAD); see [RFC5116]) that is then used to encrypt MLS Plaintext
 messages. -->

</t>
          <t>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">
            <name>Compromise of AEAD Keys</name>
            <t>In some circumstances, adversaries may have access to specific AEAD keys and
nonces that 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>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 sent the message.

<!-- [rfced] Section 8.3.1.1:  For ease of the reader, we expanded
"HPKE" as "Hybrid Public Key Encryption".  If this is incorrect,
please provide the correct definition.

Original:
 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 HPKE encryption.

Currently:
 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). -->

</t>
            <t>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"/>.

<!-- [rfced] Section 8.3.1.1:  This sentence as written appeared to
say that the compromise cannot forge the signature.  We updated it to
indicate that the attacker cannot forge the signature.  If this is
incorrect, please provide clarifying text.

Original:
 Compromise of the AEAD keys allows the attacker to send an encrypted
 message using that key, but cannot send a message to a group which
 appears to be from any valid client since they cannot forge the
 signature.

Currently:
 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. -->

</t>
          </section>
          <section anchor="compromise-of-ratchet-secret-material">
            <name>Compromise of Ratchet Secret Material</name>
            <t>When a Ratchet Secret is compromised, the adversary can compute both the current
AEAD keys for a given sender as well as 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.

<!-- [rfced] Section 8.3.1.2:  Does "both the current AEAD keys for a
given sender as well as any future keys" mean "both of the current
AEAD keys for a given sender, as well as any future keys", "both
(1) the current AEAD keys for a given sender and (2) any future
keys", or something else?

Original:
 When a Ratchet Secret is compromised, the adversary can compute both
 the current AEAD keys for a given sender as well as any future keys
 for that sender in this epoch. -->

</t>
            <t>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">
            <name>Compromise of the Group Secrets of a Single Group for One or More Group Epochs</name>
            <t>An adversary who gains access to a set of Group secrets -- for example, 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, which 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>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>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>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">
          <name>Compromise by an Active Adversary with the Ability to Sign Messages</name>
          <t>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
but realistic scenario, the attacker has compromised a client but the client
signature keys are protected with dedicated hardware features that do not allow
direct access to the value of the private key and instead provide a signature
API.</t>
          <t>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>Note that under this compromise scenario, the attacker can perform all
operations that 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">
          <name>Compromise of the Authentication with Access to a Signature Key</name>
          <t>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>There is a significant difference, however, in terms of recovery after a
compromise.</t>
          <t>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>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>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"><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.

<!-- [rfced] Section 8.3.3:  Given "dedicated hardware features" in
this sentence, we expanded "HSM" as "Hardware Security Module" for
ease of the reader.  If this is incorrect, please provide the correct
definition.

Original:
 *RECOMMENDATION:* Signature private keys should be
 compartmentalized from other secrets and preferably protected by
 an HSM or dedicated hardware features to allow recovery of the
 authentication for future messages after a compromise.

Currently:
 *RECOMMENDATION:* 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"><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">
          <name>Security Considerations in the Context of a Full State Compromise</name>
          <t>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>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"><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"><strong>RECOMMENDATION:</strong> If the threat model of the system is against 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>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>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>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"><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>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">
        <name>Service Node Compromise</name>
        <section anchor="general-considerations">
          <name>General Considerations</name>
          <section anchor="privacy-of-the-network-connections">
            <name>Privacy of the Network Connections</name>
            <t>There are many scenarios leading to communication between the application on a
device and the Delivery Service or the Authentication Service -- in particular,
when:</t>
            <ul spacing="normal">
              <li>
                <t>The application connects to the Authentication Service to generate or validate
a new credential before distributing it.</t>
              </li>
              <li>
                <t>The application fetches credentials at the Delivery Service prior to creating
a messaging group (one-to-one or more than two clients).</t>
              </li>
              <li>
                <t>The application fetches service provider information or messages on the
Delivery Service.</t>
              </li>
              <li>
                <t>The application sends service provider information or messages to the Delivery
Service.</t>
              </li>
            </ul>
            <t>In all these cases, the application will often connect to the device via a
secure transport that leaks information about the origin of the request, such as
the IP address and -- depending on the protocol -- the Media Access Control (MAC) address of the device.</t>
            <t>Similar concerns exist in the peer-to-peer use cases for MLS.</t>
                <t indent="3"><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"/>, Top-of-Rack (ToR) switches, or a VPN can improve metadata
protection.

<!-- [rfced] Section 8.4.1.1:  For ease of the reader, we expanded
"MASQUE" and "ToR".  If the definition of "ToR" is incorrect, please
provide the correct definition. (The definition of "MASQUE" was taken
from draft-schinazi-masque-proxy.)

Original:
 *RECOMMENDATION:* In the case where privacy or anonymity is
 important, using adequate protection such as MASQUE
 [I-D.schinazi-masque-proxy], ToR, or a VPN can improve metadata
 protection.

Currently:
 *RECOMMENDATION:* In the case where privacy or anonymity is
 important, using adequate protection such as Multiplexed
 Application Substrate over QUIC Encryption (MASQUE)
 [MASQUE-PROXY], Top-of-Rack (ToR) switches, or a VPN can improve
 metadata protection. -->

</t>
            <t>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">
            <name>Storage of Metadata and Encryption at Rest on the Servers</name>
            <t>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 an "encryption at
rest" mechanism to be able to prevent access to the data when not using it.</t>
                <t indent="3"><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"><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">
          <name>Delivery Service Compromise</name>
          <t>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>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"/>, 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>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 it does allow it to attack forward security to a limited
extent. This threat can be mitigated by having initial keys expire.</t>
          <t>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"><strong>RECOMMENDATION:</strong> Prefer a Credential type in KeyPackages that 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">
            <name>Privacy of Delivery and Push Notifications</name>
            <t>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 Delivery Service (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; this saves a round trip with the DS.</t>
            <t>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>Even though they can't necessarily access the content, which is typically
encrypted MLS messages, the service provider and the push notification provider
have to be trusted to avoid making correlation on which devices are recipients
of the same message.

<!-- [rfced] Section 8.4.2.1:  We had trouble parsing this sentence.
Are some words missing?  If the suggested text is not correct, please
clarify "they" and "content, which is typically encrypted MLS
messages".

Original:
 Even though they can't necessarily access the content, which is
 typically encrypted MLS messages, the service provider and the push
 notification provider have to be trusted to avoid making correlation
 on which devices are recipients of the same message.

Suggested:
 Even though the service provider and the push notification provider
 can't necessarily access the content (typically encrypted MLS
 messages), they have to be trusted to avoid making correlations
 regarding which devices are recipients of the same message. -->

</t>
            <t>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"><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>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"><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 Delivery Service without the need of a dedicated push notification
infrastructure.</t>
            <t>Applications can also consider anonymous systems for server fanout (for
example, <xref target="Loopix"/>).</t>
          </section>
        </section>
        <section anchor="as-compromise">
          <name>Authentication Service Compromise</name>
          <t>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">
            <li>
              <t>The attacker can link an identity to a credential.</t>
            </li>
            <li>
              <t>The attacker can generate new credentials.</t>
            </li>
            <li>
              <t>The attacker can sign new credentials.</t>
            </li>
            <li>
              <t>The attacker can publish or distribute credentials.</t>
            </li>
          </ul>
          <t>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"><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>Note that historically some systems generate signature keys on the
Authentication Service 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">
            <name>Authentication Compromise: Ghost Users and Impersonations</name>
            <t>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 Authentication
Service 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>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>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"><strong>RECOMMENDATION:</strong> Select the MLS Credential type with the strongest security
that is supported by all target members of an MLS group.</t>
                <t indent="3"><strong>RECOMMENDATION:</strong> Do not use the same signature keypair 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>If the AS is compromised, it could validate a signature
keypair (or generate a new one) for an attacker. The attacker could then use this keypair 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 keypairs
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"><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"><strong>RECOMMENDATION:</strong> Provide a key transparency mechanism for the
Authentication Service to allow public verification of the credentials
authenticated by this service.</t>
            <t>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
"authentication_secret" generated for each user at each epoch of the group is a
one-time, per-client authentication secret that 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.

<!-- [rfced] Section 8.4.3.1:  In this document's XML file, all other
parameters containing underscores are placed in <tt>s except for
"authentication_secret".  May we place it in <tt>s and remove the
quotes?

Original:
 The "authentication_secret" 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 identity to each other. -->

</t>
                <t indent="3"><strong>RECOMMENDATION:</strong> Provide one or more out-of-band authentication mechanisms
to limit the impact of an Authentication Service compromise.</t>
            <t>We note, again, that the Authentication Service 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>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">
            <name>Privacy of the Group Membership</name>
            <t>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, they 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 Delivery Service.

<!-- [rfced] Section 8.4.3.2:  It is not clear to us whether "they"
in the second sentence refers to "all clients" or "the server" in the
first sentence.  Please clarify.

Original (the run-on sentence has been fixed):
 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, they may learn this information through traffic analysis. -->

</t>
            <t>While this knowledge is not a breach of the protocol's authentication or
confidentiality guarantees, it is a serious issue for privacy.</t>
            <t>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"><strong>RECOMMENDATION:</strong> Use encrypted group operation messages to limit privacy
risks whenever possible.</t>
            <t>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"><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">
        <name>Considerations for Attacks Outside of the Threat Model</name>
        <t>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>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>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"><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="cryptographic-analysis-of-the-mls-protocol">
        <name>Cryptographic Analysis of the MLS Protocol</name>
        <t>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"/> (regarding MLS Draft 7), <xref target="ACDT21"/> (regarding MLS Draft 11), and <xref target="AJM20"/> (regarding MLS Draft 12).</t>
        <t>Individual components of various drafts of the MLS protocol have been analyzed
in isolation and with differing adversarial models. For example, <xref target="BBR18"/>,
<xref target="ACDT19"/>, <xref target="ACCKKMPPWY19"/>, <xref target="AJM20"/>, <xref target="ACJM20"/>, and <xref target="AHKM21"/> analyze the
ratcheting tree sub-protocol of MLS that facilitates key agreement; <xref target="WPBB22"/>
analyzes the sub-protocol of MLS for group state agreement and authentication;
and <xref target="BCK21"/> analyzes the key derivation paths in the ratchet tree and key
schedule. Finally, <xref target="CHK21"/> analyzes the authentication and cross-group healing
guarantees provided by MLS.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>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">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>

<!-- draft-ietf-mls-protocol (RFC 9420; published) -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9420.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml"/>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>

<!-- draft-ietf-keytrans-architecture (I-D Exists) -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-keytrans-architecture.xml"/>

        <reference anchor="CONIKS" target="https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-melara.pdf">
          <front>
            <title>CONIKS: Bringing Key Transparency to End Users</title>
            <author initials="M. S." surname="Melara" fullname="Marcela S. Melara">
              <organization/>
            </author>
            <author initials="A." surname="Blankstein" fullname="Aaron Blankstein">
              <organization/>
            </author>
            <author initials="J." surname="Bonneau" fullname="Joseph Bonneau">
              <organization/>
            </author>
            <author initials="E. W." surname="Felten" fullname="Edward W. Felten">
              <organization/>
            </author>
            <author initials="M. J." surname="Freedman" fullname="Michael J. Freedman">
              <organization/>
            </author>
            <date month="August" year="2015"/>
          </front>
          <refcontent>Proceedings of the 24th USENIX Security Symposium</refcontent>
        </reference>

        <reference anchor="CAPBR" target="https://dl.acm.org/doi/10.1145/343477.343502">
          <front>
            <title>Towards robust distributed systems (abstract)</title>
            <author fullname="Eric A. Brewer" initials="E. A." surname="Brewer">
              <organization>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="ACCKKMPPWY19" target="https://eprint.iacr.org/2019/1489">
          <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/>
            </author>
            <author initials="M." surname="Capretto" fullname="Margarita Capretto">
              <organization/>
            </author>
            <author initials="M." surname="Cueto" fullname="Miguel Cueto">
              <organization/>
            </author>
            <author initials="C." surname="Kamath" fullname="Chethan Kamath">
              <organization/>
            </author>
            <author initials="K." surname="Klein" fullname="Karen Klein">
              <organization/>
            </author>
            <author initials="I." surname="Markov" fullname="Ilia Markov">
              <organization/>
            </author>
            <author initials="G." surname="Pascual-Perez" fullname="Guillermo Pascual-Perez">
              <organization/>
            </author>
            <author initials="K." surname="Pietrzak" fullname="Krzysztof Pietrzak">
              <organization/>
            </author>
            <author initials="M." surname="Walter" fullname="Michael Walter">
              <organization/>
            </author>
            <author initials="M." surname="Yeo" fullname="Michelle Yeo">
              <organization/>
            </author>
            <date year="2019"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>

        <reference anchor="ACDT19" target="https://eprint.iacr.org/2019/1189.pdf">
          <front>
            <title>Security Analysis and Improvements for the IETF MLS Standard for Group Messaging</title>
            <author initials="J." surname="Alwen" fullname="Joel Alwen">
              <organization/>
            </author>
            <author initials="S." surname="Coretti" fullname="Sandro Coretti">
              <organization/>
            </author>
            <author initials="Y." surname="Dodis" fullname="Yevgeniy Dodis">
              <organization/>
            </author>
            <author initials="Y." surname="Tselekounis" fullname="Yiannis Tselekounis">
              <organization/>
            </author>
            <date year="2019"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>

        <reference anchor="ACDT21" target="https://eprint.iacr.org/2021/1083.pdf">
          <front>
            <title>Modular Design of Secure Group Messaging Protocols and the Security of MLS</title>
            <author initials="J." surname="Alwen" fullname="Joel Alwen">
              <organization/>
            </author>
            <author initials="S." surname="Coretti" fullname="Sandro Coretti">
              <organization/>
            </author>
            <author initials="Y." surname="Dodis" fullname="Yevgeniy Dodis">
              <organization/>
            </author>
            <author initials="Y." surname="Tselekounis" fullname="Yiannis Tselekounis">
              <organization/>
            </author>
            <date year="2021"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>

        <reference anchor="ACJM20" target="https://eprint.iacr.org/2020/752.pdf">
          <front>
            <title>Continuous Group Key Agreement with Active Security</title>
            <author initials="J." surname="Alwen" fullname="Joel Alwen">
              <organization/>
            </author>
            <author initials="S." surname="Coretti" fullname="Sandro Coretti">
              <organization/>
            </author>
            <author initials="D." surname="Jost" fullname="Daniel Jost">
              <organization/>
            </author>
            <author initials="M." surname="Mularczyk" fullname="Marta Mularczyk">
              <organization/>
            </author>
            <date year="2020"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>

        <reference anchor="AHKM21" target="https://eprint.iacr.org/2021/1456.pdf">
          <front>
            <title>Server-Aided Continuous Group Key Agreement</title>
            <author initials="J." surname="Alwen" fullname="Joel Alwen">
              <organization/>
            </author>
            <author initials="D." surname="Hartmann" fullname="Dominik Hartmann">
              <organization/>
            </author>
            <author initials="E." surname="Kiltz" fullname="Eike Kiltz">
              <organization/>
            </author>
            <author initials="M." surname="Mularczyk" fullname="Marta Mularczyk">
              <organization/>
            </author>
            <date year="2021"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>

        <reference anchor="AJM20" target="https://eprint.iacr.org/2020/1327.pdf">
          <front>
            <title>On The Insider Security of MLS</title>
            <author initials="J." surname="Alwen" fullname="Joel Alwen">
              <organization/>
            </author>
            <author initials="D." surname="Jost" fullname="Daniel Jost">
              <organization/>
            </author>
            <author initials="M." surname="Mularczyk" fullname="Marta Mularczyk">
              <organization/>
            </author>
            <date year="2020"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>

        <reference anchor="BBN19" target="https://inria.hal.science/hal-02425229/document">
          <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/>
            </author>
            <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche">
              <organization/>
            </author>
            <author initials="P." surname="Naldurg" fullname="Prasad Naldurg">
              <organization/>
            </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">
          <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/>
            </author>
            <author initials="R." surname="Barnes" fullname="Richard Barnes">
              <organization/>
            </author>
            <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
              <organization/>
            </author>
            <date year="2018"/>
          </front>
          <seriesInfo name="HAL ID" value="hal-02425247"/>
        </reference>

        <reference anchor="BCK21" target="https://eprint.iacr.org/2021/137.pdf">
          <front>
            <title>Security Analysis of the MLS Key Distribution</title>
            <author initials="C." surname="Brzuska" fullname="Chris Brzuska">
              <organization/>
            </author>
            <author initials="E." surname="Cornelissen" fullname="Eric Cornelissen">
              <organization/>
            </author>
            <author initials="K." surname="Kohbrok" fullname="Konrad Kohbrok">
              <organization/>
            </author>
            <date year="2021"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>

<!-- [rfced] [BCK21]:  We updated this listing to use the title
found on the provided URL, as we found "Cryptographic Security of the
MLS RFC, Draft 11" on <https://eprint.iacr.org/2021/137> but again
found "Security Analysis of the MLS Key Distribution" when we clicked
"PDF" under "Available format(s)".  Please let us know any concerns.

Original:
 [BCK21]    Brzuska, C., Cornelissen, E., and K. Kohbrok,
            "Cryptographic Security of the MLS RFC, Draft 11", 2021,
            <https://eprint.iacr.org/2021/137.pdf>.

Currently:
 [BCK21]    Brzuska, C., Cornelissen, E., and K. Kohbrok, "Security
            Analysis of the MLS Key Distribution", Cryptology ePrint
            Archive, 2021, <https://eprint.iacr.org/2021/137.pdf>. -->

        <reference anchor="CHK21" target="https://www.usenix.org/system/files/sec21-cremers.pdf">
          <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/>
            </author>
            <author initials="B." surname="Hale" fullname="Britta Hale">
              <organization/>
            </author>
            <author initials="K." surname="Kohbrok" fullname="Konrad Kohbrok">
              <organization/>
            </author>
            <date month="August" year="2021"/>
          </front>
          <refcontent>Proceedings of the 30th USENIX Security Symposium</refcontent>
        </reference>

        <reference anchor="WPBB22" target="https://eprint.iacr.org/2022/1732.pdf">
          <front>
            <title>TreeSync: Authenticated Group Management for Messaging Layer Security</title>
            <author initials="T." surname="Wallez" fullname="Théophile Wallez">
              <organization/>
            </author>
            <author initials="J." surname="Protzenko" fullname="Jonathan Protzenko">
              <organization/>
            </author>
            <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche">
              <organization/>
            </author>
            <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan">
              <organization/>
            </author>
            <date year="2022"/>
          </front>
          <refcontent>Cryptology ePrint Archive</refcontent>
        </reference>

        <reference anchor="Loopix" target="">
          <front>
            <title>The Loopix Anonymity System</title>
            <author initials="A. M." surname="Piotrowska" fullname="Ania M. Piotrowska">
              <organization/>
            </author>
            <author initials="J." surname="Hayes" fullname="Jamie Hayes">
              <organization/>
            </author>
            <author initials="T." surname="Elahi" fullname="Tariq Elahi">
              <organization/>
            </author>
            <author initials="S." surname="Meiser" fullname="Sebastian Meiser">
              <organization/>
            </author>
            <author initials="G." surname="Danezis" fullname="George Danezis">
              <organization/>
            </author>
            <date month="August" year="2017"/>
          </front>
         <refcontent>Proceedings of the 26th USENIX Security Symposium</refcontent>
        </reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6120.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>

<!-- draft-ietf-mls-extensions (I-D Exists) -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-mls-extensions.xml"/>

<!-- draft-ietf-mls-federation (Expired) -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-mls-federation.xml"/>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>

<!-- draft-schinazi-masque-proxy (I-D Exists) -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.schinazi-masque-proxy.xml"/>

      </references>
    </references>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact initials="R." surname="Barnes" fullname="Richard Barnes">
        <organization>Cisco</organization>
        <address>
          <email>rlb@ipv.sx</email>
        </address>
      </contact>
      <contact initials="K." surname="Cohn-Gordon" fullname="Katriel Cohn-Gordon">
        <organization>Meta Platforms</organization>
        <address>
          <email>me@katriel.co.uk</email>
        </address>
      </contact>
      <contact initials="C." surname="Cremers" fullname="Cas Cremers">
        <organization>CISPA Helmholtz Center for Information Security</organization>
        <address>
          <email>cremers@cispa.de</email>
        </address>
      </contact>
      <contact initials="B." surname="Hale" fullname="Britta Hale">
        <organization>Naval Postgraduate School</organization>
        <address>
          <email>britta.hale@nps.edu</email>
        </address>
      </contact>
      <contact initials="A." surname="Kwon" fullname="Albert Kwon">
        <organization>Badge Inc.</organization>
        <address>
          <email>kwonalbert@badgeinc.com</email>
        </address>
      </contact>
      <contact initials="K." surname="Kohbrok" fullname="Konrad Kohbrok">
        <organization>Phoenix R&amp;D</organization>
        <address>
          <email>konrad.kohbrok@datashrine.de</email>
        </address>
      </contact>
      <contact initials="R." surname="Mahy" fullname="Rohan Mahy">
        <organization>Wire</organization>
        <address>
          <email>rohan.mahy@wire.com</email>
        </address>
      </contact>
      <contact initials="B." surname="McMillion" fullname="Brendan McMillion">
        <organization/>
        <address>
          <email>brendanmcmillion@gmail.com</email>
        </address>
      </contact>
      <contact initials="T. van der" surname="Merwe" fullname="Thyla van der Merwe">
        <organization/>
        <address>
          <email>tjvdmerwe@gmail.com</email>
        </address>
      </contact>
      <contact initials="J." surname="Millican" fullname="Jon Millican">
        <organization>Meta Platforms</organization>
        <address>
          <email>jmillican@meta.com</email>
        </address>
      </contact>
      <contact initials="R." surname="Robert" fullname="Raphael Robert">
        <organization>Phoenix R&amp;D</organization>
        <address>
          <email>ietf@raphaelrobert.com</email>
        </address>
      </contact>
    </section>
  </back>

<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed.  Updates of this nature
typically result in more precise language, which is helpful for
readers.

Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->

<!-- [rfced] Please let us know if any changes are needed for the
following:

a) The following term was used inconsistently in this document.
We chose to use the latter form.  Please let us know any objections.

 last resort (2 instances) / "last resort" (4 instances)
   (per Normative Reference RFC 9420)

b) The following terms appear to be used inconsistently in this
document.  Please let us know which form is preferred.
Would you like us to follow usage in Normative Reference RFC 9420
("The Messaging Layer Security (MLS) Protocol")?

Most of the terms listed below are also used in RFC 9420.  We have
marked them with asterisks ("*").

 * Application message (3 instances) /
     application message (12 instances)
     (e.g., "an Application message", "an application message")
     (RFC 9420 uses "application message".)

 * authentication service (Abstract) /
     Authentication Service (16 instances)
     (RFC 9420 uses "Authentication Service".)

 * commit (>=13 instances) / Commit (>50 instances)
     (e.g., "the commit", "the Commit", "any commits", "any Commits")
     (RFC 9420 uses both forms but appears to use lowercase when this
     term is used generally.  Please review usage in this document
     and advise.)

 * credential type (1 instance) / Credential type (8 instances)
     (We also see "credential types" in Section 7.)
     (RFC 9420 uses "credential type".)

 * delivery service (2 instances) / Delivery Service (>40 instances)
     (RFC 9420 uses "Delivery Service".)

 Eventually Consistent / eventually consistent (1 instance each)
   (We also see "strongly and eventually consistent systems" in
   Section 5.2.)

 * forward secrecy (3 instances) / Forward Secrecy (1 instance
     other than where defined)
     (RFC 9420 uses "forward secrecy".  We changed "forward-secrecy"
     in this document to "forward secrecy" for now.)

 * group / Group (used generally)
     (e.g., "a group", "a Group", "the group", "that group",
     "that Group")
     (RFC 9420 uses "a group", "the group", "that group", etc.)

 group operation message (7 instances) /
   Group Operation message (2 instances in Section 8.3.1.1)

 * group secret (10 instances) / Group Secret (2 instances) /
     Group secret (1 instance)
     (RFC 9420 uses "group secret".)

 * Handshake message (2 instances) / handshake message (9 instances)
     (RFC 9420 uses "handshake message".)

 Key Transparency (2 instances) /
   key transparency (2 instances) (e.g., "Key Transparency [KT]",
   "key transparency mechanism")

 * keypair (4 instances) / key pair (5 instances)
     (RFC 9420 uses "key pair".)

 * Member (3 instances) / member (>50 instances) (used generally)
     (e.g., "When a client is part of a Group, it is called a
     Member", "all Members", "all members")
     (RFC 9420 uses "member".)

 * Plaintext (1 instance) / plaintext (3 instances)
     ("MLS Plaintext messages", "plaintext and ciphertext messages")
     (RFC 9420 uses "plaintext" in running text.)

 * post-compromise security / Post-Compromise Security
     (RFC 9420 uses "post-compromise security".)

 * proposal (23 instances) / Proposal (5 instances)
     (used generally, e.g., "the proposal", "the Proposal",
     "of proposals", "of Proposals")
     RFC 9420 uses initial capitalization when referring to a
     Proposal object and lowercase when used generally.  We
     cannot determine general uses versus referring to a
     Proposal object here.  Please review and advise.

 push notification (adj.) (5 instances) /
   push-notification (adj.) (1 instance)
   (e.g., "push notification provider", "push notification
   infrastructure", "push-notification system")
   (Usage in post-6000 published RFCs is mixed.)

 push tokens (1 instance) / push-tokens (3 instances)
   (No precedent in published RFCs.)

 * ratchet secret (1 instance) / Ratchet Secret (11 instances)
     (RFC 9420 uses "ratchet secret".)

 ReInit proposal (3 instances in Section 5.2.3) /
   reinitialization proposal (2 instances in Section 7)

 Service Provider (2 instances) / service provider (10 instances)

 Strongly Consistent (2 instances) / strongly consistent (1 instance)

 * x509 / X.509 ("x509 Credential type", "X.509 certificates")
     (RFC 9420 uses "X509Credential" and "X.509 credential".)

c) In the XML file, we see that emphasis ("<em>") for
"Welcome message" is applied three times, while all other instances
of "<em>" are used only once for a given word or term (where the term
is first used).  Is "Welcome message" a special case, or should the
second and third instances of "<em>" be removed for this term?

d) Would you like spacing to be consistent?

 Welcome (Bob) / Add(Bob)
   (RFC 9420 does not use spacing between "Welcome" or "Add" and the
   parenthetical item that follows those terms.)

 Notes re. the SVG:
 In the SVG for Figure 2, we found that a closing parenthesis was
 missing after the first "Bob":  <text x="84" y="292">(Bob</text>
 We added the closing parenthesis.  However, as a result, there
 isn't a space between "(Bob)" and the arrow line.

 If you want to change "Welcome (Bob)" to "Welcome(Bob)" in line with
 RFC 9420, we will need you to modify the entries in the SVG.
 If you want to have a space after the first "Bob" in Figure 2, we
 will need you to make that update as well. -->

</rfc>