rfc9750.original.xml   rfc9750.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.3. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType
3) --> ="IETF" docName="draft-ietf-mls-architecture-15" number="9750" category="info" t
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ocInclude="true" sortRefs="true" symRefs="true" version="3" consensus="true" upd
-ietf-mls-architecture-15" category="info" tocInclude="true" sortRefs="true" sym ates="" obsoletes="" xml:lang="en">
Refs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.22.0 -->
<front> <front>
<title abbrev="MLS Architecture">The Messaging Layer Security (MLS) Architec ture</title> <title abbrev="MLS Architecture">The Messaging Layer Security (MLS) Architec ture</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mls-architecture-15"/> <seriesInfo name="RFC" value="9750"/>
<author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche"> <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche">
<organization>Inria &amp; Mozilla</organization> <organization>Inria &amp; Mozilla</organization>
<address> <address>
<email>ietf@beurdouche.com</email> <email>ietf@beurdouche.com</email>
</address> </address>
</author> </author>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla"> <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization>Windy Hill Systems, LLC</organization>
<address> <address>
<email>ekr@rtfm.com</email> <email>ekr@rtfm.com</email>
</address> </address>
</author> </author>
<author initials="E." surname="Omara" fullname="Emad Omara"> <author initials="E." surname="Omara" fullname="Emad Omara">
<organization/> <organization/>
<address> <address>
<email>emad.omara@gmail.com</email> <email>emad.omara@gmail.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Inguva" fullname="Srinivas Inguva"> <author initials="S." surname="Inguva" fullname="Srinivas Inguva">
<organization/> <organization/>
<address> <address>
<email>singuva@yahoo.com</email> <email>singuva@yahoo.com</email>
</address> </address>
</author> </author>
<author initials="A." surname="Duric" fullname="Alan Duric"> <author initials="A." surname="Duric" fullname="Alan Duric">
<organization>Wire</organization>
<address> <address>
<email>alan@wire.com</email> <email>alan@duric.net</email>
</address> </address>
</author> </author>
<date year="2024" month="August" day="03"/> <date year="2025" month="April"/>
<area>Security</area>
<keyword>Internet-Draft</keyword> <area>SEC</area>
<workgroup>mls</workgroup>
<keyword>security</keyword>
<keyword>authenticated key exchange</keyword>
<keyword>end-to-end encryption</keyword>
<abstract> <abstract>
<?line 222?>
<t>The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol) <t>The Messaging Layer Security (MLS) protocol (RFC 9420)
provides a Group Key Agreement protocol for messaging applications. provides a group key agreement protocol for messaging applications.
MLS is meant to protect against eavesdropping, tampering, message MLS is designed to protect against eavesdropping, tampering, and message
forgery, and provide Forward Secrecy (FS) and Post-Compromise Security forgery, and to provide forward secrecy (FS) and post-compromise security
(PCS).</t> (PCS).
</t>
<t>This document describes the architecture for using MLS in a general <t>This document describes the architecture for using MLS in a general
secure group messaging infrastructure and defines the security goals secure group messaging infrastructure and defines the security goals
for MLS. It provides guidance on building a group messaging system for MLS. It provides guidance on building a group messaging system
and discusses security and privacy tradeoffs offered by multiple and discusses security and privacy trade-offs offered by multiple
security mechanisms that are part of the MLS protocol (e.g., frequency security mechanisms that are part of the MLS protocol (e.g., frequency
of public encryption key rotation). The document also provides of public encryption key rotation). The document also provides
guidance for parts of the infrastructure that are not standardized by guidance for parts of the infrastructure that are not standardized by
MLS and are instead left to the application.</t> MLS and are instead left to the application.</t>
<t>While the recommendations of this document are not mandatory to follow in order <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 to interoperate at the protocol level, they affect the overall security
guarantees that are achieved by a messaging application. This is especially true 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 in the case of active adversaries that are able to compromise clients, the
delivery service, or the authentication service.</t> Delivery Service (DS), or the Authentication Service (AS).</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
MLS Working Group mailing list (mls@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ml
s/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/mlswg/mls-architecture"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 245?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH</t> <t>End-to-end security is used in the vast majority of instant messaging s
<t>The source for this draft is maintained in GitHub. Suggested changes s ystems
hould and is also deployed in systems for other purposes such as calling and conferenc
be submitted as pull requests at https://github.com/mlswg/mls-architecture. ing.
Instructions are on that page as well. Editorial changes can be
managed in GitHub, but any substantive change should be discussed on
the MLS mailing list.</t>
<t>End-to-end security is used in the vast majority of instant messaging s
ystems,
and also deployed in systems for other purposes such as calling and conferencing
.
In this context, "end-to-end" captures In this context, "end-to-end" captures
the notion that users of the system enjoy some level of security -- with the 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 precise level depending on the system design -- even in the face of malicious
actions by the operator of the messaging system.</t> actions by the operator of the messaging system.</t>
<t>Messaging Layer Security (MLS) specifies an architecture (this document ) and a <t>Messaging Layer Security (MLS) specifies an architecture (this document ) and a
protocol <xref target="I-D.ietf-mls-protocol"/> for providing end-to-end securit y in this 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 setting. MLS is not intended as a full instant messaging protocol but rather is
intended to be embedded in concrete protocols, such as XMPP <xref target="RFC612 0"/>. 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 Implementations of the MLS protocol will interoperate at the cryptographic
level, though they may have incompatibilities in terms of how protected messages level, though they may have incompatibilities in terms of how protected messages
are delivered, contents of protected messages, and identity/authentication are delivered, contents of protected messages, and identity/authentication
infrastructures. infrastructures.
The MLS protocol has been designed to provide the same security guarantees to 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> all users, for all group sizes, including groups of only two clients.</t>
</section> </section>
<section anchor="general-setting"> <section anchor="general-setting">
<name>General Setting</name> <name>General Setting</name>
<section anchor="protocol-overview"> <section anchor="protocol-overview">
<name>Protocol Overview</name> <name>Protocol Overview</name>
<t>MLS provides a way for <em>clients</em> to form <em>groups</em> withi n which they can <t>MLS provides a way for <em>clients</em> to form <em>groups</em> withi n which they can
communicate securely. For example, a set of users might use clients on their 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 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 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>membe r</em> large as hundreds of thousands. A client that is part of a group is a <em>membe r</em>
of that group. As groups change membership and group or member properties, they 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 gr oup advance from one <em>epoch</em> to another and the cryptographic state of the gr oup
evolves.</t> evolves.</t>
<t>The group is represented as a tree, which represents the members as t he leaves <t>The group is represented as a tree, which represents the members as t he leaves
of a tree. It is used to efficiently encrypt to subsets of the members. Each 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 identi ty, member has a state called a <em>LeafNode</em> object holding the client's identi ty,
credentials, and capabilities.</t> credentials, and capabilities.</t>
<t>Various messages are used in the evolution from epoch to epoch. <t>Various messages are used in the evolution from epoch to epoch.
A <em>Proposal</em> message proposes A <em>Proposal</em> message proposes
a change to be made in the next epoch, such as adding or removing a member. 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 gr oup to A <em>Commit</em> message initiates a new epoch by instructing members of the gr oup to
implement a collection of proposals. Proposals and Commits are collectively implement a collection of proposals. Proposals and Commits are collectively
called <em>Handshake messages</em>. called <em>handshake messages</em>.
A <em>KeyPackage</em> provides keys that can be used to add the client to a grou p, A <em>KeyPackage</em> provides keys that can be used to add the client to a grou p,
including its LeafNode, and <em>Signature Key</em>. including a public encryption key and a signature key (both stored in
the KeyPackage's <tt>LeafNode</tt> object).
A <em>Welcome</em> message provides a new member to the group with the informati on to A <em>Welcome</em> message provides a new member to the group with the informati on to
initialize their state for the epoch in which they were added.</t> 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 g roup messages. <t>Of course most (but not all) applications use MLS to send encrypted g roup messages.
An <em>application message</em> is an MLS message with an arbitrary application payload.</t> 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 <t>Finally, a <em>PublicMessage</em> contains an integrity-protected MLS
Handshake message, handshake message,
while a <em>PrivateMessage</em> contains a confidential, integrity-protected Han while a <em>PrivateMessage</em> contains a confidential, integrity-protected han
dshake dshake
or application message.</t> or application message.</t>
<t>For a more detailed explanation of these terms, please consult the ML S protocol <t>For a more detailed explanation of these terms, please consult the ML S protocol
specification <xref target="RFC9420"/>.</t> specification <xref target="RFC9420"/>.</t>
</section> </section>
<section anchor="abstract-services"> <section anchor="abstract-services">
<name>Abstract Services</name> <name>Abstract Services</name>
<t>MLS is designed to operate within the context of a messaging service, which <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 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 peer-to-peer system. The service needs to provide two services that
facilitate client communication using MLS:</t> facilitate client communication using MLS:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>An Authentication Service (AS) which is responsible for <t>An Authentication Service (AS), which is responsible for
attesting to bindings between application-meaningful identifiers and the attesting to bindings between application-meaningful identifiers and the
public key material used for authentication in the MLS protocol. The public key material used for authentication in the MLS protocol. The
AS must also be able to generate credentials that encode these AS must also be able to generate credentials that encode these
bindings and validate credentials provided by MLS clients.</t> bindings and validate credentials provided by MLS clients.
</t>
</li> </li>
<li> <li>
<t>A Delivery Service (DS) which can receive and distribute <t>A Delivery Service (DS), which can receive and distribute
messages between group members. In the case of group messaging, the delivery messages between group members. In the case of group messaging, the DS
service may also be responsible for acting as a "broadcaster" where the sender 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 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 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 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> secret key establishment that is part of the MLS protocol.</t>
</li> </li>
</ul> </ul>
<t>For presentation purposes, this document treats the AS and DS as conv entional <t>For presentation purposes, this document treats the AS and DS as conv entional
network services, however MLS does not require a specific implementation 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 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 servers, they may be distributed between server and client components, and they
may even involve some action by users. For example:</t> may even involve some action by users. For example:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Several secure messaging services today provide a centralized DS, and rely on <t>Several secure messaging services today provide a centralized DS and rely on
manual comparison of clients' public keys as the AS.</t> manual comparison of clients' public keys as the AS.</t>
</li> </li>
<li> <li>
<t>MLS clients connected to a peer-to-peer network could instantiate a <t>MLS clients connected to a peer-to-peer network could instantiate a
decentralized DS by transmitting MLS messages over that network.</t> decentralized DS by transmitting MLS messages over that network.</t>
</li> </li>
<li> <li>
<t>In an MLS group using a Public Key Infrastructure (PKI) for authe ntication, <t>In an MLS group using a Public Key Infrastructure (PKI) for authe ntication,
the AS would comprise the certificate issuance and validation processes, the AS would comprise the certificate issuance and validation processes,
both of which involve logic inside MLS clients as well as various both of which involve logic inside MLS clients as well as various
existing PKI roles (ex: Certification Authorities).</t> existing PKI roles (e.g., Certification Authorities).</t>
</li> </li>
</ul> </ul>
<t>It is important to note that the Authentication Service can be <t>It is important to note that the AS can be
completely abstract in the case of a Service Provider which allows MLS completely abstract in the case of a service provider which allows MLS
clients to generate, distribute, and validate credentials themselves. clients to generate, distribute, and validate credentials themselves.
As with the AS, the Delivery Service can be completely abstract if As with the AS, the DS can be completely abstract if
users are able to distribute credentials and messages without relying users are able to distribute credentials and messages without relying
on a central Delivery Service (as in a peer-to-peer system). Note, on a central DS (as in a peer-to-peer system). Note,
though, that in such scenarios, clients will need to implement logic though, that in such scenarios, clients will need to implement logic
that assures the delivery properties required of the DS (see that assures the delivery properties required of the DS (see
<xref target="delivery-guarantees"/>).</t> <xref target="delivery-guarantees"/>).</t>
<t><xref target="fig-mls-overview"/> shows the relationship of these con
cepts,
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"> <figure anchor="fig-mls-overview">
<name>A Simplified Messaging System</name> <name>A Simplified Messaging System</name>
<artset> <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"> <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 8,32 L 8,80" fill="none" stroke="black"/>
<path d="M 80,144 L 80,176" 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 144,32 L 144,80" fill="none" stroke="black"/>
<path d="M 168,144 L 168,176" 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 184,32 L 184,80" fill="none" stroke="black"/>
<path d="M 208,144 L 208,176" fill="none" stroke="black"/> <path d="M 208,144 L 208,176" fill="none" stroke="black"/>
skipping to change at line 276 skipping to change at line 270
/ . | \ . / . | \ .
+--------+-+ . +----+-----+ +----------+ . +--------+-+ . +----+-----+ +----------+ .
| Client 1 | . | Client 2 | | Client 3 | . | Client 1 | . | Client 2 | | Client 3 | .
+----------+ . +----------+ +----------+ . +----------+ . +----------+ +----------+ .
. Member 1 Member 2 . . Member 1 Member 2 .
. . . .
.................................. ..................................
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t><xref target="fig-mls-overview"/> shows the relationship of these con
cepts,
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>
</section> </section>
</section> </section>
<section anchor="overview-of-operation"> <section anchor="overview-of-operation">
<name>Overview of Operation</name> <name>Overview of Operation</name>
<t><xref target="fig-group-formation-example"/> shows the formation of an example <t><xref target="fig-group-formation-example"/> shows the formation of an example
group consisting of Alice, Bob, and Charlie, with Alice group consisting of Alice, Bob, and Charlie, with Alice
driving the creation of the group.</t> driving the creation of the group.</t>
<figure anchor="fig-group-formation-example"> <figure anchor="fig-group-formation-example">
<name>Group Formation Example</name> <name>Group Formation Example</name>
<artset> <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"> <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">
<path d="M 528,64 L 528,144" fill="none" stroke="black"/> <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,176 L 528,208" fill="none" stroke="black"/>
<path d="M 528,240 L 528,320" 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 528,352 L 528,448" fill="none" stroke="black"/>
<path d="M 128,64 L 392,64" 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 8,80 L 304,80" fill="none" stroke="black"/>
<path d="M 208,96 L 392,96" 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 88,112 L 304,112" fill="none" stroke="black"/>
<path d="M 288,128 L 392,128" 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 168,144 L 304,144" fill="none" stroke="black"/>
<path d="M 200,176 L 480,176" 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 280,192 L 480,192" fill="none" stroke="black"/>
<path d="M 360,208 L 480,208" 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 264,240 L 480,240" fill="none" stroke="black"/>
<path d="M 8,256 L 256,256" 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 144,272 L 480,272" fill="none" stroke="black"/>
<path d="M 104,288 L 480,288" fill="none" stroke="black"/> <path d="M 112,288 L 480,288" fill="none" stroke="black"/>
<path d="M 88,304 L 344,304" fill="none" stroke="black"/> <path d="M 88,304 L 344,304" fill="none" stroke="black"/>
<path d="M 88,320 L 368,320" fill="none" stroke="black"/> <path d="M 88,320 L 376,320" fill="none" stroke="black"/>
<path d="M 296,352 L 480,352" fill="none" stroke="black"/> <path d="M 296,352 L 480,352" fill="none" stroke="black"/>
<path d="M 8,368 L 224,368" 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 176,384 L 480,384" fill="none" stroke="black"/>
<path d="M 152,400 L 480,400" fill="none" stroke="black"/> <path d="M 144,400 L 480,400" fill="none" stroke="black"/>
<path d="M 88,416 L 312,416" fill="none" stroke="black"/> <path d="M 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,432 L 312,432" fill="none" stroke="black"/>
<path d="M 176,448 L 336,448" fill="none" stroke="black"/> <path d="M 176,448 L 344,448" fill="none" stroke="black"/>
<polygon class="arrowhead" points="488,400 476,394.4 476,405.6" fi <polygon class="arrowhead" points="488,400 476,394.4 476,405.6 " f
ll="black" transform="rotate(0,480,400)"/> ill="black" transform="rotate(0,480,400)"/>
<polygon class="arrowhead" points="488,384 476,378.4 476,389.6" fi <polygon class="arrowhead" points="488,384 476,378.4 476,389.6 " f
ll="black" transform="rotate(0,480,384)"/> ill="black" transform="rotate(0,480,384)"/>
<polygon class="arrowhead" points="488,352 476,346.4 476,357.6" fi <polygon class="arrowhead" points="488,352 476,346.4 476,357.6 " f
ll="black" transform="rotate(0,480,352)"/> ill="black" transform="rotate(0,480,352)"/>
<polygon class="arrowhead" points="488,288 476,282.4 476,293.6" fi <polygon class="arrowhead" points="488,288 476,282.4 476,293.6 " f
ll="black" transform="rotate(0,480,288)"/> ill="black" transform="rotate(0,480,288)"/>
<polygon class="arrowhead" points="488,272 476,266.4 476,277.6" fi <polygon class="arrowhead" points="488,272 476,266.4 476,277.6 " f
ll="black" transform="rotate(0,480,272)"/> ill="black" transform="rotate(0,480,272)"/>
<polygon class="arrowhead" points="488,240 476,234.4 476,245.6" fi <polygon class="arrowhead" points="488,240 476,234.4 476,245.6 " f
ll="black" transform="rotate(0,480,240)"/> ill="black" transform="rotate(0,480,240)"/>
<polygon class="arrowhead" points="488,208 476,202.4 476,213.6" fi <polygon class="arrowhead" points="488,208 476,202.4 476,213.6 " f
ll="black" transform="rotate(0,480,208)"/> ill="black" transform="rotate(0,480,208)"/>
<polygon class="arrowhead" points="488,192 476,186.4 476,197.6" fi <polygon class="arrowhead" points="488,192 476,186.4 476,197.6 " f
ll="black" transform="rotate(0,480,192)"/> ill="black" transform="rotate(0,480,192)"/>
<polygon class="arrowhead" points="488,176 476,170.4 476,181.6" fi <polygon class="arrowhead" points="488,176 476,170.4 476,181.6 " f
ll="black" transform="rotate(0,480,176)"/> ill="black" transform="rotate(0,480,176)"/>
<polygon class="arrowhead" points="400,128 388,122.4 388,133.6" fi <polygon class="arrowhead" points="400,128 388,122.4 388,133.6 " f
ll="black" transform="rotate(0,392,128)"/> ill="black" transform="rotate(0,392,128)"/>
<polygon class="arrowhead" points="400,96 388,90.4 388,101.6" fill <polygon class="arrowhead" points="400,96 388,90.4 388,101.6 " fil
="black" transform="rotate(0,392,96)"/> l="black" transform="rotate(0,392,96)"/>
<polygon class="arrowhead" points="400,64 388,58.4 388,69.6" fill= <polygon class="arrowhead" points="400,64 388,58.4 388,69.6 " fill
"black" transform="rotate(0,392,64)"/> ="black" transform="rotate(0,392,64)"/>
<polygon class="arrowhead" points="184,448 172,442.4 172,453.6" fi <polygon class="arrowhead" points="184,448 172,442.4 172,453.6 " f
ll="black" transform="rotate(180,176,448)"/> ill="black" transform="rotate(180,176,448)"/>
<polygon class="arrowhead" points="184,432 172,426.4 172,437.6" fi <polygon class="arrowhead" points="184,432 172,426.4 172,437.6 " f
ll="black" transform="rotate(180,176,432)"/> ill="black" transform="rotate(180,176,432)"/>
<polygon class="arrowhead" points="176,144 164,138.4 164,149.6" fi <polygon class="arrowhead" points="176,144 164,138.4 164,149.6 " f
ll="black" transform="rotate(180,168,144)"/> ill="black" transform="rotate(180,168,144)"/>
<polygon class="arrowhead" points="96,416 84,410.4 84,421.6" fill= <polygon class="arrowhead" points="96,416 84,410.4 84,421.6 " fill
"black" transform="rotate(180,88,416)"/> ="black" transform="rotate(180,88,416)"/>
<polygon class="arrowhead" points="96,320 84,314.4 84,325.6" fill= <polygon class="arrowhead" points="96,320 84,314.4 84,325.6 " fill
"black" transform="rotate(180,88,320)"/> ="black" transform="rotate(180,88,320)"/>
<polygon class="arrowhead" points="96,304 84,298.4 84,309.6" fill= <polygon class="arrowhead" points="96,304 84,298.4 84,309.6 " fill
"black" transform="rotate(180,88,304)"/> ="black" transform="rotate(180,88,304)"/>
<polygon class="arrowhead" points="96,112 84,106.4 84,117.6" fill= <polygon class="arrowhead" points="96,112 84,106.4 84,117.6 " fill
"black" transform="rotate(180,88,112)"/> ="black" transform="rotate(180,88,112)"/>
<polygon class="arrowhead" points="16,368 4,362.4 4,373.6" fill="b <polygon class="arrowhead" points="16,368 4,362.4 4,373.6 " fill="
lack" transform="rotate(180,8,368)"/> black" transform="rotate(180,8,368)"/>
<polygon class="arrowhead" points="16,256 4,250.4 4,261.6" fill="b <polygon class="arrowhead" points="16,256 4,250.4 4,261.6 " fill="
lack" transform="rotate(180,8,256)"/> black" transform="rotate(180,8,256)"/>
<polygon class="arrowhead" points="16,80 4,74.4 4,85.6" fill="blac <polygon class="arrowhead" points="16,80 4,74.4 4,85.6 " fill="bla
k" transform="rotate(180,8,80)"/> ck" transform="rotate(180,8,80)"/>
<g class="text"> <g class="text">
<text x="24" y="36">Alice</text> <text x="24" y="36">Alice</text>
<text x="96" y="36">Bob</text> <text x="96" y="36">Bob</text>
<text x="192" y="36">Charlie</text> <text x="192" y="36">Charlie</text>
<text x="396" y="36">AS</text> <text x="396" y="36">AS</text>
<text x="476" y="36">DS</text> <text x="476" y="36">DS</text>
<text x="28" y="68">Create</text> <text x="28" y="68">Create</text>
<text x="88" y="68">account</text> <text x="88" y="68">account</text>
<text x="356" y="84">Credential</text> <text x="356" y="84">Credential</text>
<text x="108" y="100">Create</text> <text x="108" y="100">Create</text>
skipping to change at line 378 skipping to change at line 370
<text x="96" y="244">Initial</text> <text x="96" y="244">Initial</text>
<text x="156" y="244">Keying</text> <text x="156" y="244">Keying</text>
<text x="220" y="244">Material</text> <text x="220" y="244">Material</text>
<text x="280" y="260">Bob</text> <text x="280" y="260">Bob</text>
<text x="328" y="260">Initial</text> <text x="328" y="260">Initial</text>
<text x="388" y="260">Keying</text> <text x="388" y="260">Keying</text>
<text x="452" y="260">Material</text> <text x="452" y="260">Material</text>
<text x="16" y="276">Add</text> <text x="16" y="276">Add</text>
<text x="48" y="276">Bob</text> <text x="48" y="276">Bob</text>
<text x="76" y="276">to</text> <text x="76" y="276">to</text>
<text x="112" y="276">Group</text> <text x="112" y="276">group</text>
<text x="556" y="276">Step</text> <text x="556" y="276">Step</text>
<text x="584" y="276">3</text> <text x="584" y="276">3</text>
<text x="32" y="292">Welcome</text> <text x="52" y="292">Welcome(Bob)</text>
<text x="84" y="292">(Bob</text>
<text x="368" y="308">Add</text> <text x="368" y="308">Add</text>
<text x="400" y="308">Bob</text> <text x="400" y="308">Bob</text>
<text x="428" y="308">to</text> <text x="428" y="308">to</text>
<text x="464" y="308">Group</text> <text x="464" y="308">group</text>
<text x="408" y="324">Welcome</text> <text x="436" y="324">Welcome(Bob)</text>
<text x="464" y="324">(Bob)</text>
<text x="16" y="356">Get</text> <text x="16" y="356">Get</text>
<text x="64" y="356">Charlie</text> <text x="64" y="356">Charlie</text>
<text x="128" y="356">Initial</text> <text x="128" y="356">Initial</text>
<text x="188" y="356">Keying</text> <text x="188" y="356">Keying</text>
<text x="252" y="356">Material</text> <text x="252" y="356">Material</text>
<text x="264" y="372">Charlie</text> <text x="264" y="372">Charlie</text>
<text x="328" y="372">Initial</text> <text x="328" y="372">Initial</text>
<text x="388" y="372">Keying</text> <text x="388" y="372">Keying</text>
<text x="452" y="372">Material</text> <text x="452" y="372">Material</text>
<text x="16" y="388">Add</text> <text x="16" y="388">Add</text>
<text x="64" y="388">Charlie</text> <text x="64" y="388">Charlie</text>
<text x="108" y="388">to</text> <text x="108" y="388">to</text>
<text x="144" y="388">Group</text> <text x="144" y="388">group</text>
<text x="32" y="404">Welcome</text> <text x="68" y="404">Welcome(Charlie)</text>
<text x="104" y="404">(Charlie)</text>
<text x="556" y="404">Step</text> <text x="556" y="404">Step</text>
<text x="584" y="404">4</text> <text x="584" y="404">4</text>
<text x="336" y="420">Add</text> <text x="336" y="420">Add</text>
<text x="384" y="420">Charlie</text> <text x="384" y="420">Charlie</text>
<text x="428" y="420">to</text> <text x="428" y="420">to</text>
<text x="464" y="420">Group</text> <text x="464" y="420">group</text>
<text x="336" y="436">Add</text> <text x="336" y="436">Add</text>
<text x="384" y="436">Charlie</text> <text x="384" y="436">Charlie</text>
<text x="428" y="436">to</text> <text x="428" y="436">to</text>
<text x="464" y="436">Group</text> <text x="464" y="436">group</text>
<text x="376" y="452">Welcome</text> <text x="420" y="452">Welcome(Charlie)</text>
<text x="448" y="452">(Charlie)</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
Alice Bob Charlie AS DS Alice Bob Charlie AS DS
Create account ---------------------------------> | Create account ---------------------------------> |
<------------------------------------- Credential | <------------------------------------- Credential |
Create account -----------------------> | Step 1 Create account -----------------------> | Step 1
<--------------------------- Credential | <--------------------------- Credential |
Create account -------------> | Create account -------------> |
<----------------- Credential | <----------------- Credential |
Initial Keying Material -----------------------------------> | Initial Keying Material -----------------------------------> |
Initial Keying Material -------------------------> | Step 2 Initial Keying Material -------------------------> | Step 2
Initial Keying Material ---------------> | Initial Keying Material ---------------> |
Get Bob Initial Keying Material ---------------------------> | Get Bob Initial Keying Material ---------------------------> |
<------------------------------- Bob Initial Keying Material | <------------------------------- Bob Initial Keying Material |
Add Bob to Group ------------------------------------------> | Step 3 Add Bob to group ------------------------------------------> | Step 3
Welcome (Bob)----------------------------------------------> | Welcome(Bob) ----------------------------------------------> |
<-------------------------------- Add Bob to Group | <-------------------------------- Add Bob to group |
<----------------------------------- Welcome (Bob) | <------------------------------------ Welcome(Bob) |
Get Charlie Initial Keying Material -----------------------> | Get Charlie Initial Keying Material -----------------------> |
<--------------------------- Charlie Initial Keying Material | <--------------------------- Charlie Initial Keying Material |
Add Charlie to Group --------------------------------------> | Add Charlie to group --------------------------------------> |
Welcome (Charlie) -----------------------------------------> | Step 4 Welcome(Charlie) ------------------------------------------> | Step 4
<---------------------------- Add Charlie to Group | <---------------------------- Add Charlie to group |
<----------------- Add Charlie to Group | <----------------- Add Charlie to group |
<-------------------- Welcome (Charlie) | <--------------------- Welcome(Charlie) |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>This process proceeds as follows.</t> <t>This process proceeds as follows.</t>
<section anchor="step-1-account-creation"> <section anchor="step-1-account-creation">
<name>Step 1: Account Creation</name> <name>Step 1: Account Creation</name>
<t>Alice, Bob, and Charlie create accounts with a service provider and o btain <t>Alice, Bob, and Charlie create accounts with a service provider and o btain
credentials from the AS. This is a one-time setup phase.</t> credentials from the AS. This is a one-time setup phase.</t>
</section> </section>
<section anchor="step-2-initial-keying-material"> <section anchor="step-2-initial-keying-material">
<name>Step 2: Initial Keying Material</name> <name>Step 2: Initial Keying Material</name>
<t>Alice, Bob, and Charlie authenticate to the DS and store some initial <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 keying material which is used to send encrypted messages to them
for the first time. This keying material is authenticated with their for the first time. This keying material is authenticated with their
long-term credentials. Although in principle this keying material long-term credentials. Although in principle this keying material
can be reused for multiple senders, in order to provide forward secrecy 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 it is better for this material to be regularly refreshed so that each
sender can use a new key.</t> sender can use a new key and delete older keys.</t>
</section> </section>
<section anchor="step-3-adding-bob-to-the-group"> <section anchor="step-3-adding-bob-to-the-group">
<name>Step 3: Adding Bob to the Group</name> <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 <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> up his initial keying material. She then generates two messages:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A message to the entire group (which at this point is just her an d Bob) <t>A message to the entire group (which at this point is just her an d Bob)
that adds Bob to the group.</t> that adds Bob to the group.</t>
</li> </li>
<li> <li>
<t>A <em>Welcome</em> message just to Bob encrypted with his initial keying material that <t>A Welcome message just to Bob encrypted with his initial keying m aterial that
includes the secret keying information necessary to join the group.</t> includes the secret keying information necessary to join the group.</t>
</li> </li>
</ul> </ul>
<t>She sends both of these messages to the Delivery Services, which is r <t>She sends both of these messages to the DS, which is responsible
esponsible
for sending them to the appropriate people. Note that the security of MLS 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 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 is encrypted for him; it is simply not necessary for other group members
to receive it.</t> to receive it.</t>
</section> </section>
<section anchor="step-4-adding-charlie-to-the-group"> <section anchor="step-4-adding-charlie-to-the-group">
<name>Step 4: Adding Charlie to the Group</name> <name>Step 4: Adding Charlie to the Group</name>
<t>If Alice then wants to add Charlie to the group, she follows a simila r procedure <t>If Alice then wants to add Charlie to the group, she follows a simila r procedure
as with Bob: she first uses the DS to look as with Bob. She first uses the DS to look
up his initial keying material and then generates two messages:</t> up his initial keying material and then generates two messages:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A message to the entire group (consisting of her, Bob, and Charli e) adding <t>A message to the entire group (consisting of her, Bob, and Charli e) adding
Charlie to the group.</t> Charlie to the group.</t>
</li> </li>
<li> <li>
<t>A <em>Welcome</em> message just to Charlie encrypted with his ini tial keying material that <t>A Welcome message just to Charlie encrypted with his initial keyi ng material that
includes the secret keying information necessary to join the group.</t> includes the secret keying information necessary to join the group.</t>
</li> </li>
</ul> </ul>
<t>At the completion of this process, we have a group with Alice, Bob, a nd Charlie, <t>At the completion of this process, we have a group with Alice, Bob, a nd Charlie,
which means that they share a single encryption key which can be used to which means that they share a single encryption key which can be used to
send messages or to key other protocols.</t> send messages or to key other protocols.
</t>
</section> </section>
<section anchor="other-group-operations"> <section anchor="other-group-operations">
<name>Other Group Operations</name> <name>Other Group Operations</name>
<t>Once the group has been created, clients can perform other actions, <t>Once the group has been created, clients can perform other actions,
such as:</t> such as:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>sending a message to everyone in the group</t> <t>sending a message to everyone in the group</t>
</li> </li>
<li> <li>
<t>receiving a message from someone in the group</t> <t>receiving a message from someone in the group</t>
</li> </li>
<li> <li>
<t>adding one or more clients to an existing group</t> <t>adding one or more clients to an existing group</t>
</li> </li>
<li> <li>
<t>remove one or more members from an existing group</t> <t>removing one or more members from an existing group</t>
</li> </li>
<li> <li>
<t>updating their own key material</t> <t>updating their own key material</t>
</li> </li>
<li> <li>
<t>leave a group (by asking to be removed)</t> <t>leaving a group (by asking to be removed)</t>
</li> </li>
</ul> </ul>
<t>Importantly, MLS does not itself enforce any access control on group <t>Importantly, MLS does not itself enforce any access control on group
operations. For instance, any member of the group can send a message operations. For instance, any member of the group can send a message
to add a new member or to evict an existing member. 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 This is in contrast to some designs in which there is a single group
controller who can modify the group. MLS-using applications are controller who can modify the group. MLS-using applications are
responsible for setting their own access control policies. For instance, responsible for setting their own access control policies. For instance,
if only the group administrator is allowed to change group members, if only the group administrator is allowed to change group members,
then it is the responsibility of the application to inform members then it is the responsibility of the application to inform members
of this policy and who the administrator is.</t> of this policy and who the administrator is.</t>
</section> </section>
<section anchor="proposals-and-commits"> <section anchor="proposals-and-commits">
<name>Proposals and Commits</name> <name>Proposals and Commits</name>
<t>The general pattern for any change in the group state (e.g., to add o r remove <t>The general pattern for any change in the group state (e.g., to add o r remove
a user) is that it consists of two messages:</t> a user) is that it consists of two messages:</t>
<dl> <dl>
<dt>Proposal</dt> <dt>Proposal:</dt>
<dd> <dd>
<t>This message describes the change to be made (e.g., add Bob to th e group) <t>This message describes the change to be made (e.g., add Bob to th e group)
but does not effect a change.</t> but does not effect a change.</t>
</dd> </dd>
<dt>Commit</dt> <dt>Commit:</dt>
<dd> <dd>
<t>This message changes the group state to include the changes descr ibed in <t>This message changes the group state to include the changes descr ibed in
a set of proposals.</t> a set of proposals.</t>
</dd> </dd>
</dl> </dl>
<t>The simplest pattern is for a client to just send a Commit which cont ains one or <t>The simplest pattern is for a client to just send a Commit which cont ains one or
more Proposals, for instance Alice could send a Commit with the Proposal 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 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 which one client might send a Proposal and another might send the corresponding Commit. For
instance, Bob might wish to remove himself from the group and send a Remove 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 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 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> 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 Proposal s <t>It is also possible for a Commit to apply to an empty set of Proposal s,
in which case it just updates the cryptographic state of the group in which case it just updates the cryptographic state of the group
without changing its membership.</t> without changing its membership.</t>
</section> </section>
<section anchor="group-members"> <section anchor="group-members">
<name>Users, Clients, and Groups</name> <name>Users, Clients, and Groups</name>
<t>While it's natural to think of a messaging system as consisting of gr oups of <t>While it's natural to think of a messaging system as consisting of gr oups of
users, possibly using different devices, in MLS the basic unit of operation is 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 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 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 public encryption key, and a public signature key. As usual, a user demonstrates
ownership of the client by demonstrating knowledge of the associated secret ownership of the client by demonstrating knowledge of the associated secret
values.</t> values.</t>
<t>In some messaging systems, clients belonging to the same user must al l share the <t>In some messaging systems, clients belonging to the same user must al l share the
same signature key pair, but MLS does not assume this; instead a user may have 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 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 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 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 messages to and from a given user identically regardless of which client they
are associated with, or may choose to distinguish them.</t> are associated with, or it may choose to distinguish them.
<t>When a client is part of a Group, it is called a Member. A group in It is also possible to have multiple clients associated with
MLS is the same user share state, as described in <xref target="associating-a-users-cli
ents"/>.</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 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 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 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 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 client is a member of the group; for instance, the newly added member might not
have received the Welcome message or been unable to decrypt it for some reason.< /t> have received the Welcome message or been unable to decrypt it for some reason.< /t>
</section> </section>
</section> </section>
<section anchor="authentication-service"> <section anchor="authentication-service">
<name>Authentication Service</name> <name>Authentication Service</name>
<t>The Authentication Service (AS) has to provide three services:</t> <t>The Authentication Service (AS) has to provide three services:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Issue credentials to clients that attest to bindings between identi ties and <t>Issue credentials to clients that attest to bindings between identi ties and
signature key pairs</t> signature key pairs.</t>
</li> </li>
<li> <li>
<t>Enable a client to verify that a credential presented by another cl ient is <t>Enable a client to verify that a credential presented by another cl ient is
valid with respect to a reference identifier</t> valid with respect to a reference identifier.</t>
</li> </li>
<li> <li>
<t>Enable a group member to verify that a credential represents the sa me client <t>Enable a group member to verify that a credential represents the sa me client
as another credential</t> as another credential.</t>
</li> </li>
</ol> </ol>
<t>A member with a valid credential authenticates its MLS messages by sign ing them <t>A member with a valid credential authenticates its MLS messages by sign ing them
with the private key corresponding to the public key bound by its credential.</t > 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 and par t of this <t>The AS is considered an abstract layer by the MLS specification; part o f this
service could be, for instance, running on the members' devices, while another service could be, for instance, running on the members' devices, while another
part is a separate entity entirely. The following examples illustrate the part is a separate entity entirely. The following examples illustrate the
breadth of this concept:</t> breadth of this concept:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A PKI could be used as an AS <xref target="RFC5280"/>. The issuanc e function would be <t>A PKI could be used as an AS <xref target="RFC5280"/>. The issuanc e function would be
provided by the certificate authorities in the PKI, and the verification provided by the certificate authorities in the PKI, and the verification
function would correspond to certificate verification by clients.</t> function would correspond to certificate verification by clients.</t>
</li> </li>
<li> <li>
<t>Several current messaging applications rely on users verifying each other's <t>Several current messaging applications rely on users verifying each other's
key fingerprints for authentication. In this scenario, the issuance function 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 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). identifier and public key, with no information to assist in verification).
The verification function is the application function that enables users The verification function is the application function that enables users
to verify keys.</t> to verify keys.</t>
</li> </li>
<li> <li>
<t>In a system based on <xref target="CONIKS"/> end user Key Transpare ncy (KT) <xref target="KT"/>, the <t>In a system based on end-user Key Transparency (KT) <xref target="I -D.ietf-keytrans-architecture"/>, the
issuance function would correspond to the insertion of a key in a KT log under 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 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 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 mechanisms for a user to monitor and control which keys are associated with
their identity.</t> their identity.</t>
</li> </li>
</ul> </ul>
<t>By the nature of its roles in MLS authentication, the AS is invested wi th a <t>By the nature of its role in MLS authentication, the AS is invested wit h a
large amount of trust and the compromise of the AS could large amount of trust and the compromise of the AS could
allow an adversary to, among other things, impersonate group members. We discuss allow an adversary to, among other things, impersonate group members. We discuss
security considerations regarding the compromise of the different AS security considerations regarding the compromise of the different AS
functions in detail in <xref target="as-compromise"/>.</t> functions in detail in <xref target="as-compromise"/>.</t>
<t>The association between members' identities and their signature keys is fairly <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 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 belonging to a given user have the same signature key (in fact, having duplicate
signature keys in a group is forbidden). A member can signature keys in a group is forbidden). A member can
also rotate the signature key they use within a group. These mechanisms allow 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 clients to use different signature keys in different contexts and at different
points in time, providing unlinkability and post-compromise security benefits. points in time, providing unlinkability and post-compromise security benefits.
Some security trade-offs related to this flexibility are discussed in the Some security trade-offs related to this flexibility are discussed in
security considerations.</t> <xref target="security-and-privacy-considerations"/>.
</t>
<t>In many applications, there are multiple MLS clients that represent a s ingle <t>In many applications, there are multiple MLS clients that represent a s ingle
entity, for example a human user with a mobile and desktop version of an entity, such as a human user with a mobile and desktop version of an
application. Often the same set of clients is represented in exactly the same 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 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 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 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 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 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 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 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 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 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> across groups is more of a detection mechanism than a prevention mechanism.</t>
</section> </section>
<section anchor="delivery-service"> <section anchor="delivery-service">
<name>Delivery Service</name> <name>Delivery Service</name>
<t>The Delivery Service (DS) plays two major roles in MLS:</t> <t>The Delivery Service (DS) plays two major roles in MLS:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>As a directory service providing the initial keying material for <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 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> encrypted messages to other clients even if they're offline.</t>
</li> </li>
<li> <li>
<t>Routing MLS messages among clients.</t> <t>Routing MLS messages among clients.</t>
</li> </li>
</ul> </ul>
<t>While MLS depends on correct behavior by the Authentication Service in <t>While MLS depends on correct behavior by the AS in
order to provide endpoint authentication and hence confidentiality of order to provide endpoint authentication and hence confidentiality of
the group key, these properties do not depend on correct behavior by 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 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 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 be able to determine group membership or prevent changes to the
group from taking place (e.g., by blocking group change messages).</t> group from taking place (e.g., by blocking group change messages).</t>
<section anchor="key-storage-and-retrieval"> <section anchor="key-storage-and-retrieval">
<name>Key Storage and Retrieval</name> <name>Key Storage and Retrieval</name>
<t>Upon joining the system, each client stores its initial cryptographic key <t>Upon joining the system, each client stores its initial cryptographic key
material with the Delivery Service. This key material, called a KeyPackage, material with the DS. This key material, called a KeyPackage,
advertises the functional abilities of the client such as supported protocol advertises the functional abilities of the client (e.g., supported protocol
versions, supported extensions, and the following cryptographic information:</t> versions, supported extensions, etc.) and the following cryptographic informatio
n:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A credential from the Authentication Service attesting to the bin ding between <t>A credential from the AS attesting to the binding between
the identity and the client's signature key.</t> the identity and the client's signature key.</t>
</li> </li>
<li> <li>
<t>The client's asymmetric encryption public key.</t> <t>The client's asymmetric encryption public key.</t>
</li> </li>
</ul> </ul>
<t>All the parameters in the KeyPackage are signed with the signature <t>All the parameters in the KeyPackage are signed with the signature
private key corresponding to the credential. private key corresponding to the credential.
As noted in <xref target="group-members"/>, users may own multiple clients, each 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 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 and cipher suite, but a client may want to offer support for multiple protocol
versions and ciphersuites. As such, there may be multiple KeyPackages stored by versions and cipher suites. As such, there may be multiple KeyPackages stored by
each user for a mix of protocol versions, ciphersuites, and end-user devices.</t each user for a mix of protocol versions, cipher suites, and end-user devices.</
> t>
<t>When a client wishes to establish a group or add clients to a group, it first <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, contacts the DS to request KeyPackages for each of the other clients,
authenticates the KeyPackages using the signature keys, includes the KeyPackages authenticates the KeyPackages using the signature keys, includes the KeyPackages
in Add Proposals, encrypts the information needed to join the group in Add proposals, and encrypts the information needed to join the group
(the <em>GroupInfo</em> object) with an ephemeral key, then separately encrypts (the <em>GroupInfo</em> object) with an ephemeral key; it then separately encryp
the ts the
ephemeral key with the <tt>init_key</tt> from each KeyPackage. ephemeral key with the public encryption key (<tt>init_key</tt>) from each KeyPa
ckage.
When a client requests a KeyPackage in order to add a user to a group, the 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 DS should provide the minimum number of KeyPackages necessary to
satisfy the request. For example, if the request specifies the MLS version, the 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 DS might provide one KeyPackage per supported cipher suite, even if it has
multiple such KeyPackages to enable the corresponding client to be added to multiple such KeyPackages to enable the corresponding client to be added to
multiple groups before needing to upload more fresh KeyPackages.</t> multiple groups before needing to upload more fresh KeyPackages.
</t>
<t>In order to avoid replay attacks and provide forward secrecy for mess ages sent <t>In order to avoid replay attacks and provide forward secrecy for mess ages sent
using the initial keying material, KeyPackages are intended to be used only using the initial keying material, KeyPackages are intended to be used only
once. The Delivery Service is responsible for ensuring that each KeyPackage is once, and <tt>init_key</tt> is intended to be deleted by the client after decryp
only used to add its client to a single group, with the possible exception of a tion
"last resort" KeyPackage that is specially designated by the client to be used of the Welcome message. The DS is responsible for ensuring that
multiple times. Clients are responsible for providing new KeyPackages as each KeyPackage is only used to add its client to a single group, with the
necessary in order to minimize the chance that the "last resort" KeyPackage will possible exception of a "last resort" KeyPackage that is specially designated
be used.</t> by the client to be used multiple times. Clients are responsible for providing
<ul empty="true"> new KeyPackages as necessary in order to minimize the chance that the "last
<li> resort" KeyPackage will be used.</t>
<t><strong>RECOMMENDATION:</strong> Ensure that "last resort" KeyPac
kages don't get used by <t indent="3"><strong>Recommendation:</strong> Ensure that "last resor
t" KeyPackages don't get used by
provisioning enough standard KeyPackages.</t> provisioning enough standard KeyPackages.</t>
</li> <t indent="3"><strong>Recommendation:</strong> Rotate "last resort"
</ul> KeyPackages as soon as possible
<ul empty="true">
<li>
<t><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. 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> Overall, avoid reusing "last resort" KeyPackages as much as possible.</t>
</li> <t indent="3"><strong>Recommendation:</strong> Ensure that the clien
</ul> t for which a "last resort" KeyPackage
<ul empty="true">
<li>
<t><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> has been used is updating leaf keys as early as possible.</t>
</li>
</ul> <t indent="3"><strong>Recommendation:</strong> Ensure that clients d
elete the private component
of their <tt>init_key</tt> after processing a Welcome message, or after the
rotation of the "last resort" KeyPackage.</t>
<t>Overall, it needs to be noted that key packages need to be updated wh en <t>Overall, it needs to be noted that key packages need to be updated wh en
signature keys are changed.</t> signature keys are changed.</t>
</section> </section>
<section anchor="delivery-guarantees"> <section anchor="delivery-guarantees">
<name>Delivery of Messages</name> <name>Delivery of Messages</name>
<t>The main responsibility of the Delivery Service is to ensure delivery of <t>The main responsibility of the DS is to ensure delivery of
messages. Some MLS messages need only be delivered to specific clients (e.g., a 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 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 delivered to all the members of a group. The DS may enable the
latter delivery pattern via unicast channels (sometimes known as "client latter delivery pattern via unicast channels (sometimes known as "client
fanout"), broadcast channels ("server fanout"), or a mix of both.</t> fanout"), broadcast channels ("server fanout"), or a mix of both.</t>
<t>For the most part, MLS does not require the Delivery Service to deliv er messages <t>For the most part, MLS does not require the DS to deliver messages
in any particular order. Applications can set policies that control their in any particular order. Applications can set policies that control their
tolerance for out-of-order messages (see <xref target="operational-requirements" />), and tolerance for out-of-order messages (see <xref target="operational-requirements" />), and
messages that arrive significantly out-of-order can be dropped without otherwise messages that arrive significantly out of order can be dropped without otherwise
affecting the protocol. There are two exceptions to this. First, Proposal affecting the protocol. There are two exceptions to this. First, Proposal
messages should all arrive before the Commit that references them. Second, 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 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 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 must agree on a single MLS Commit message that ends each epoch and begins the
next one.</t> next one.</t>
<t>In practice, there's a realistic risk of two members generating Commi t messages <t>In practice, there's a realistic risk of two members generating Commi t messages
at the same time, based on the same epoch, and both attempting to send them to 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 the group at the same time. The extent to which this is a problem, and the
appropriate solution, depends on the design of the Delivery Service. Per the CAP appropriate solution, depend on the design of the DS. Per the CAP
theorem <xref target="CAPBR"/>, there are two general classes of distributed sys theorem <xref target="CAPBR"/>, there are two general classes of distributed sys
tem that the tems that the
Delivery Service might fall into:</t> DS might fall into:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Consistent and Partition-tolerant, or Strongly Consistent, system <t>Consistent and Partition-tolerant, or Strongly Consistent, system
s can provide s, which can provide
a globally consistent view of data but has the inconvenience of clients needing a globally consistent view of data but have the inconvenience of clients needing
to handle rejected messages;</t> to handle rejected messages.</t>
</li> </li>
<li> <li>
<t>Available and Partition-tolerant, or Eventually Consistent, syste ms continue <t>Available and Partition-tolerant, or Eventually Consistent, syste ms, which continue
working despite network issues but may return different views of data to working despite network issues but may return different views of data to
different users.</t> different users.</t>
</li> </li>
</ul> </ul>
<t>Strategies for sequencing messages in strongly and eventually consist ent systems <t>Strategies for sequencing messages in strongly and eventually consist ent systems
are described in the next two subsections. Most Delivery Services will use the are described in the next two subsections. Most DSs will use the
Strongly Consistent paradigm but this remains a choice that can be handled in strongly consistent paradigm, but this remains a choice that can be handled in
coordination with the client and advertized in the KeyPackages.</t> coordination with the client and advertised in the KeyPackages.</t>
<t>However, note that a malicious Delivery Service could also reorder me <t>However, note that a malicious DS could also reorder messages or
ssages or
provide an inconsistent view to different users. The "generation" counter in provide an inconsistent view to different users. The "generation" counter in
MLS messages provides per-sender loss detection and ordering that cannot be MLS messages provides per-sender loss detection and ordering that cannot be
manipulated by the DS, but this does not provide complete protection against 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 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., 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 confirming that all clients have the same <tt>epoch_authenticator</tt> value). A
mechanism for more robust protections is discussed in mechanism for more robust protections is discussed in
<xref target="I-D.ietf-mls-extensions"/>.</t> <xref target="I-D.ietf-mls-extensions"/>.</t>
<t>Other forms of Delivery Service misbehavior are still possible that a <t>Other forms of DS misbehavior are still possible that are not easy
re not easy to detect. For instance, a DS can simply refuse to relay messages
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 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> cannot generally detect this form of Denial-of-Service (DoS) attack.</t>
<section anchor="strongly-consistent"> <section anchor="strongly-consistent">
<name>Strongly Consistent</name> <name>Strongly Consistent</name>
<t>With this approach, the Delivery Service ensures that some types of incoming <t>With this approach, the DS ensures that some types of incoming
messages have a linear order and all members agree on that order. The Delivery 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 Service is trusted to break ties when two members send a Commit message at the
same time.</t> same time.</t>
<t>As an example, there could be an "ordering server" Delivery Service that <t>As an example, there could be an "ordering server" DS that
broadcasts all messages received to all users and ensures that all clients see 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 messages in the same order. This would allow clients to only apply the first
valid Commit for an epoch and ignore subsequent ones. Clients that send a Commit valid Commit for an epoch and ignore subsequent Commits. Clients that send a Com mit
would then wait to apply it until it is broadcast back to them by the Delivery would then wait to apply it until it is broadcast back to them by the Delivery
Service, assuming they do not receive another Commit first.</t> Service, assuming that they do not receive another Commit first.
<t>Alternatively, the Delivery Service can rely on the <tt>epoch</tt> </t>
and <tt>content_type</tt> <t>Alternatively, the DS can rely on the <tt>epoch</tt> and <tt>conten
t_type</tt>
fields of an MLSMessage to provide an order only to handshake messages, and fields of an MLSMessage to provide an order only to handshake messages, and
possibly even filter or reject redundant Commit messages proactively to prevent possibly even filter or reject redundant Commit messages proactively to prevent
them from being broadcast. There is some risk associated with filtering, which them from being broadcast. There is some risk associated with filtering; this
is discussed further in <xref target="invalid-commits"/>.</t> is discussed further in <xref target="invalid-commits"/>.</t>
</section> </section>
<section anchor="eventually-consistent"> <section anchor="eventually-consistent">
<name>Eventually Consistent</name> <name>Eventually Consistent</name>
<t>With this approach, the Delivery Service is built in a way that may be <t>With this approach, the DS is built in a way that may be
significantly more available or performant than a strongly consistent system, significantly more available or performant than a strongly consistent system,
but offers weaker consistency guarantees. Messages may arrive to different but where it offers weaker consistency guarantees. Messages may arrive to differ ent
clients in different orders and with varying amounts of latency, which means clients in different orders and with varying amounts of latency, which means
clients are responsible for reconciliation.</t> clients are responsible for reconciliation.
<t>This type of Delivery Service might arise, for example, when group </t>
members are <t>This type of DS might arise, for example, when group members are
sending each message to each other member individually, or when a distributed sending each message to each other member individually or when a distributed
peer-to-peer network is used to broadcast messages.</t> peer-to-peer network is used to broadcast messages.</t>
<t>Upon receiving a Commit from the Delivery Service, clients can eith er:</t> <t>Upon receiving a Commit from the DS, clients can either:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Pause sending new messages for a short amount of time to accoun t for a <t>Pause sending new messages for a short amount of time to accoun t for a
reasonable degree of network latency and see if any other Commits are reasonable degree of network latency and see if any other Commits are
received for the same epoch. If multiple Commits are received, the clients 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 can use a deterministic tie-breaking policy to decide which to accept, and
then resume sending messages as normal.</t> then resume sending messages as normal.</t>
</li> </li>
<li> <li>
<t>Accept the Commit immediately but keep a copy of the previous g roup state for <t>Accept the Commit immediately but keep a copy of the previous g roup state for
a short period of time. If another Commit for a past epoch is received, 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 clients use a deterministic tie-breaking policy to decide if they should
continue using the Commit they originally accepted or revert and use the 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 later one. Note that any copies of previous or forked group states must be
deleted within a reasonable amount of time to ensure the protocol provides deleted within a reasonable amount of time to ensure that the protocol provides
forward-secrecy.</t> forward secrecy.</t>
</li> </li>
</ol> </ol>
<t>If the Commit references an unknown proposal, group members may nee d to solicit <t>If the Commit references an unknown proposal, group members may nee d to solicit
the Delivery Service or other group members individually for the contents of the the DS or other group members individually for the contents of the
proposal.</t> proposal.</t>
</section> </section>
<section anchor="welcome-messages"> <section anchor="welcome-messages">
<name>Welcome Messages</name> <name>Welcome Messages</name>
<t>Whenever a commit adds new members to a group, MLS requires the com mitter to <t>Whenever a commit adds new members to a group, MLS requires the com mitter to
send a Welcome message to the new members. Applications should ensure that send a Welcome message to the new members. Applications should ensure that
Welcome messages are coupled with the tie-breaking logic for commits, discussed Welcome messages are coupled with the tie-breaking logic for commits (see
in <xref target="strongly-consistent"/> and <xref target="eventually-consistent" Sections&nbsp;<xref target="strongly-consistent" format="counter"/> and <xref ta
/>. That is, when multiple rget="eventually-consistent" format="counter"/>). That is, when multiple
commits are sent for the same epoch, applications need to ensure that only commits are sent for the same epoch, applications need to ensure that only
Welcome messages corresponding to the commit that "succeeded" are processed by Welcome messages corresponding to the commit that "succeeded" are processed by
new members.</t> new members.</t>
<t>This is particularly important when groups are being reinitialized. When a group <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 is reinitialized, it is restarted with a different protocol version and/or
ciphersuite but identical membership. Whenever an authorized member sends and cipher suite but identical membership. Whenever an authorized member sends and
commits a ReInit proposal, this immediately freezes the existing group 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> 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 com mitted the <t>Ideally, the new group would be created by the same member that com mitted the
<tt>ReInit</tt> proposal (including sending Welcome messages for the new group t o all <tt>ReInit</tt> proposal (including sending Welcome messages for the new group t o all
of the previous group's members). However this operation is not always atomic, 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 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 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 member to continue the reinitialization by creating the new group and sending
out Welcome messages.</t> out Welcome messages.</t>
<t>This has the potential to create a race condition, where multiple m embers try to <t>This has the potential to create a race condition, where multiple m embers try to
continue the reinitialization at the same time, and members receive multiple continue the reinitialization at the same time, and members receive multiple
Welcome messages for each attempt at reinitializing the same group. Ensuring Welcome messages for each attempt at reinitializing the same group. Ensuring
that all members agree on which reinitialization attempt is "correct" is key to that all members agree on which reinitialization attempt is "correct" is key to
prevent this from causing forks.</t> prevent this from causing forks.</t>
</section> </section>
skipping to change at line 894 skipping to change at line 885
and reject the Commit. For example, a buggy client might send an encrypted 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 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="o f" target="RFC9420"/>.</t> malformed Commit of the form described in <xref section="16.12" sectionFormat="o f" target="RFC9420"/>.</t>
<t>In situations where the DS is attempting to filter redundant Commits, the DS <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 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 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 rejec t any example, the DS might think that the current epoch is now <tt>n+1</tt> and rejec t any
commits from other epochs, while the members think the epoch is <tt>n</tt>, and as a 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 result, the group is stuck -- no member can send a Commit that the DS will
accept.</t> accept.</t>
<t>Such “desynchronization” problems can arise even when the Delivery Se rvice takes <t>Such "desynchronization" problems can arise even when the DS takes
no stance on which Commit is "correct" for an epoch. The DS can enable clients 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 to choose between Commits, for example by providing Commits in the order
received and allow clients to reject any Commits that received and allowing clients to reject any Commits that
violate their view of the group's policies. As such, all honest and 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 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 choose to process it. Malicious or buggy clients that process a different Commit
will end up in a forked view of the group.</t> will end up in a forked view of the group.
</t>
<t>When these desynchronizations happen, the application may choose to t ake action <t>When these desynchronizations happen, the application may choose to t ake action
to restore the functionality of the group. These actions themselves can have to restore the functionality of the group. These actions themselves can have
security implications. For example, a client developer might have a client security implications. For example, a client developer might have a client
automatically rejoin a group, using an external join, when it processes an automatically rejoin a group, using an external join, when it processes an
invalid Commit. In this operation, however, the client trusts that the invalid Commit. In this operation, however, the client trusts that the
GroupInfo provided by the DS faithfully represents the state of the group, and 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 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 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 invalid Commit. In certain scenarios, this trust can enable the DS or a
malicious insider to undermine the post-compromise security guarantees provided malicious insider to undermine the post-compromise security guarantees provided
skipping to change at line 924 skipping to change at line 916
implications. For example, if a recovery mechanism relies on external joins, a implications. For example, if a recovery mechanism relies on external joins, a
malicious member that deliberately posts an invalid Commit could also post 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. corrupted GroupInfo object in order to prevent victims from rejoining the group.
Thus, careful analysis of security implications should be made for any system Thus, careful analysis of security implications should be made for any system
for recovering from desynchronization.</t> for recovering from desynchronization.</t>
</section> </section>
</section> </section>
<section anchor="functional-requirements"> <section anchor="functional-requirements">
<name>Functional Requirements</name> <name>Functional Requirements</name>
<t>MLS is designed as a large-scale group messaging protocol and hence aim s to <t>MLS is designed as a large-scale group messaging protocol and hence aim s to
provide both performance and security (e.g. integrity and confidentiality) provide both performance and security (e.g., integrity and confidentiality)
to its users. Messaging systems that implement MLS provide support for to its users. Messaging systems that implement MLS provide support for
conversations involving two or more members, and aim to scale to groups with conversations involving two or more members, and aim to scale to groups with
tens of thousands of members, typically including many users using multiple devi ces.</t> tens of thousands of members, typically including many users using multiple devi ces.</t>
<section anchor="membership-changes"> <section anchor="membership-changes">
<name>Membership Changes</name> <name>Membership Changes</name>
<t>MLS aims to provide agreement on group membership, meaning that all g roup <t>MLS aims to provide agreement on group membership, meaning that all g roup
members have agreed on the list of current group members.</t> members have agreed on the list of current group members.</t>
<t>Some applications may wish to enforce ACLs to limit addition or remov <t>Some applications may wish to enforce Access Control Lists (ACLs) to
al of group limit addition or removal of group
members, to privileged clients or users. Others may wish to require members to privileged clients or users. Others may wish to require
authorization from the current group members or a subset thereof. Such policies 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 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 not allow for or support addition or removal of group members without informing
all other members.</t> all other members.
</t>
<t>Membership of an MLS group is managed at the level of individual clie nts. In <t>Membership of an MLS group is managed at the level of individual clie nts. In
most cases, a client corresponds to a specific device used by a user. If a user 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 has multiple devices, the user will generally be represented in a group by
multiple clients (although applications could choose to have devices share multiple clients (although applications could choose to have devices share
keying material). If an application wishes to implement operations at the level 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 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> user and ensure that they are added/removed consistently.</t>
<t>MLS provides two mechanisms for changing the membership of a group. The primary <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 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 removes other members. A secondary mechanism is an "external join": A member of
the group publishes certain information about the group, which a new member can 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 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; group. (There is no similarly unilateral way for a member to leave the group;
they must be removed by a remaining member.)</t> they must be removed by a remaining member.)
</t>
<t>With both mechanisms, changes to the membership are initiated from in side the <t>With both mechanisms, changes to the membership are initiated from in side the
group. When members perform changes directly, this is clearly the case. group. When members perform changes directly, this is clearly the case.
External joins are authorized indirectly, in the sense that a member publishing 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 a GroupInfo object authorizes anyone to join who has access to the GroupInfo
object, subject to whatever access control policies the application applies object, subject to whatever access control policies the application applies
for external joins.</t> for external joins.</t>
<t>Both types of joins are done via a Commit message, which could be <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 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 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 requires that clients all share a consistent policy. In the unfortunate event
skipping to change at line 982 skipping to change at line 976
that are not accessible to the client. Compromise of a member removed from a 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. 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 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 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 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> any secrets that could be used to derive them.</t>
</section> </section>
<section anchor="parallel-groups"> <section anchor="parallel-groups">
<name>Parallel Groups</name> <name>Parallel Groups</name>
<t>Any user or client may have membership in several groups simultaneous ly. The <t>Any user or client may have membership in several groups simultaneous ly. The
set of members of any group may or may not form a subset of the members of set of members of any group may or may not overlap with the members of
another group. MLS guarantees that the FS and PCS goals within a given group are 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, maintained and not weakened by user membership in multiple groups. However,
actions in other groups likewise do not strengthen the FS and PCS guarantees 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 within a given group, e.g., key updates within a given group following a device
compromise does not provide PCS healing in other groups; each group must be compromise do not provide PCS healing in other groups; each group must be
updated separately to achieve these security objectives. This also applies to 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 future groups that a member has yet to join, which are likewise unaffected by
updates performed in current groups.</t> updates performed in current groups.</t>
<t>Applications can strengthen connectivity among parallel groups by req uiring <t>Applications can strengthen connectivity among parallel groups by req uiring
periodic key updates from a user across all groups in which they have periodic key updates from a user across all groups in which they have
membership.</t> membership.
<t>MLS provides a pre-shared key (PSK) that can be used to link healing </t>
properties <t>MLS provides a pre-shared key (PSK) mechanism that can be used to lin
k healing properties
among parallel groups. For example, suppose a common member M of two groups A 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 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 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, 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 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> version of M, not to the old, possibly compromised version of M.</t>
</section> </section>
<section anchor="asynchronous-usage"> <section anchor="asynchronous-usage">
<name>Asynchronous Usage</name> <name>Asynchronous Usage</name>
<t>No operation in MLS requires two distinct clients or members to be on line <t>No operation in MLS requires two distinct clients or members to be on line
simultaneously. In particular, members participating in conversations protected simultaneously. In particular, members participating in conversations protected
using MLS can update the group's keys, add or remove new members, and send using MLS can update the group's keys, add or remove new members, and send
messages without waiting for another user's reply.</t> messages without waiting for another user's reply.</t>
<t>Messaging systems that implement MLS have to provide a transport laye r for <t>Messaging systems that implement MLS have to provide a transport laye r for
delivering messages asynchronously and reliably.</t> delivering messages asynchronously and reliably.</t>
</section> </section>
<section anchor="access-control"> <section anchor="access-control">
<name>Access Control</name> <name>Access Control</name>
<t>Because all clients within a group (members) have access to the share d <t>Because all clients within a group (members) have access to the share d
cryptographic material, MLS protocol allows each member of the messaging group cryptographic material, the MLS protocol allows each member of the messaging gro up
to perform operations. However, every service/infrastructure has control over to perform operations. However, every service/infrastructure has control over
policies applied to its own clients. Applications managing MLS clients can be policies applied to its own clients. Applications managing MLS clients can be
configured to allow for specific group operations. On the one hand, an 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 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 perform Add and Remove operations. On the other hand, in many settings such as
open discussion forums, joining can be allowed for anyone.</t> open discussion forums, joining can be allowed for anyone.
<t>While MLS Application messages are always encrypted, </t>
<t>While MLS application messages are always encrypted,
MLS handshake messages can be sent either encrypted (in an MLS MLS handshake messages can be sent either encrypted (in an MLS
PrivateMessage) or unencrypted (in an MLS PublicMessage). Applications PrivateMessage) or unencrypted (in an MLS PublicMessage). Applications
may be designed such that intermediaries need to see handshake may be designed such that intermediaries need to see handshake
messages, for example to enforce policy on which commits are allowed, messages, for example to enforce policy on which commits are allowed,
or to provide MLS ratchet tree data in a central location. If or to provide MLS ratchet tree data in a central location. If
handshake messages are unencrypted, it is especially important that handshake messages are unencrypted, it is especially important that
they be sent over a channel with strong transport encryption they be sent over a channel with strong transport encryption
(see <xref target="security-and-privacy-considerations"/>) in order to prevent e xternal (see <xref target="security-and-privacy-considerations"/>) in order to prevent e xternal
attackers from monitoring the status of the group. Applications that attackers from monitoring the status of the group. Applications that
use unencrypted handshake messages may take additional steps to reduce use unencrypted handshake messages may take additional steps to reduce
the amount of metadata that is exposed to the intermediary. Everything the amount of metadata that is exposed to the intermediary. Everything
else being equal, using encrypted handshake messages provides stronger else being equal, using encrypted handshake messages provides stronger
privacy properties than using unencrypted handshake messages, privacy properties than using unencrypted handshake messages,
as it prevents intermediaries from learning about the structure as it prevents intermediaries from learning about the structure
of the group.</t> of the group.
</t>
<t>If handshake messages are encrypted, any access <t>If handshake messages are encrypted, any access
control policies must be applied at the client, so the application must ensure 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 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 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 might not accept or reject a group operation and end up in different
cryptographic states, breaking their ability to communicate.</t> cryptographic states, breaking their ability to communicate.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Avoid using inconsistent access c
<li> ontrol policies,
<t><strong>RECOMMENDATION:</strong> Avoid using inconsistent access especially when using encrypted group operations.</t>
control policies in the
case of encrypted group operations.</t>
</li>
</ul>
<t>MLS allows actors outside the group to influence the group in two way s: External <t>MLS allows actors outside the group to influence the group in two way s: External
signers can submit proposals for changes to the group, and new joiners can use 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> 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 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 above.</t> proposals, but any other policies must be assured to be consistent, as noted abo
<ul empty="true"> ve.</t>
<li> <t indent="3"><strong>Recommendation:</strong> Have an explicit grou
<t><strong>RECOMMENDATION:</strong> Have an explicit group policy se p policy setting the conditions under
tting the conditions under
which external joins are allowed.</t> which external joins are allowed.</t>
</li>
</ul>
</section> </section>
<section anchor="handling-authentication-failures"> <section anchor="handling-authentication-failures">
<name>Handling Authentication Failures</name> <name>Handling Authentication Failures</name>
<t>Within an MLS group, every member is authenticated to every other mem ber by <t>Within an MLS group, every member is authenticated to every other mem ber by
means of credentials issued and verified by the Authentication Service. MLS means of credentials issued and verified by the AS. MLS
does not prescribe what actions, if any, an application should take in the event 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 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 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 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 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> credentials in a group are valid, and how to respond to invalid credentials.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Have a uniform creden
<li> tial validation process to ensure
<t><strong>RECOMMENDATION:</strong> Have a uniform credential valida
tion process to ensure
that all group members evaluate other members' credentials in the same way.</t> that all group members evaluate other members' credentials in the same way.</t>
</li> <t indent="3"><strong>Recommendation:</strong> Have a uniform policy
</ul> for how invalid credentials are
<ul empty="true">
<li>
<t><strong>RECOMMENDATION:</strong> Have a uniform policy for how in
valid credentials are
handled.</t> handled.</t>
</li> <t>In some authentication systems, it is possible for a previously valid
</ul> credential
<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 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 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 allow a client to replace an old credential with a new one. This is best done
before the old credential becomes invalid.</t> before the old credential becomes invalid.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Proactively rotate cr
<li> edentials, especially if a credential
<t><strong>RECOMMENDATION:</strong> Proactively rotate credentials,
especially if a credential
is about to become invalid.</t> is about to become invalid.</t>
</li>
</ul>
</section> </section>
<section anchor="state-loss"> <section anchor="state-loss">
<name>Recovery After State Loss</name> <name>Recovery After State Loss</name>
<t>Group members whose local MLS state is lost or corrupted can reinitia lize their <t>Group members whose local MLS state is lost or corrupted can reinitia lize their
state by re-joining the group as a new member and removing the member state by rejoining the group as a new member and removing the member
representing their earlier state. An application can require that a client representing their earlier state. An application can require that a client
performing such a reinitialization prove its prior membership with a PSK that performing such a reinitialization prove its prior membership with a PSK that
was exported from the prevoius state.</t> was exported from the previous state.</t>
<t>There are a few practical challenges to this approach. For example, the <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, 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 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 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> 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 <t>Reinitializing in this way does not provide the member with access to group
messages from during the state loss window, but enables proof of prior messages exchanged during the state loss window, but enables proof of prior
membership in the group. Applications may choose various configurations for membership in the group. Applications may choose various configurations for
providing lost messages to valid group members that are able to prove prior providing lost messages to valid group members that are able to prove prior
membership.</t> membership.</t>
</section> </section>
<section anchor="support-for-multiple-devices"> <section anchor="support-for-multiple-devices">
<name>Support for Multiple Devices</name> <name>Support for Multiple Devices</name>
<t>It is typically expected for users within a group to own various devi ces. A new <t>It is common for users within a group to own multiple devices. A new
device can be added to a group and be considered as a new client by the 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 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 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 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 provide such a mechanism outside of MLS. Such mechanisms, if used, may reduce
the FS and PCS guarantees provided by MLS.</t> the FS and PCS guarantees provided by MLS.</t>
</section> </section>
<section anchor="extensibility"> <section anchor="extensibility">
<name>Extensibility</name> <name>Extensibility</name>
<t>The MLS protocol provides several extension points where additional i nformation <t>The MLS protocol provides several extension points where additional i nformation
can be provided. Extensions to KeyPackages allow clients to disclose additional can be provided. Extensions to KeyPackages allow clients to disclose additional
information about their capabilities. Groups can also have extension data information about their capabilities. Groups can also have extension data
associated with them, and the group agreement properties of MLS will confirm 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> that all members of the group agree on the content of these extensions.</t>
</section> </section>
<section anchor="application-data-framing-and-type-advertisements"> <section anchor="application-data-framing-and-type-advertisements">
<name>Application Data Framing and Type Advertisements</name> <name>Application Data Framing and Type Advertisements</name>
<t>Application messages carried by MLS are opaque to the protocol; they <t>Application messages carried by MLS are opaque to the protocol and ca
can contain n contain
arbitrary data. Each application which uses MLS needs to define the format of 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 forma t of its <tt>application_data</tt> and any mechanism necessary to determine the forma t of
that content over the lifetime of an MLS group. In many applications this means 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 managing format migrations for groups with multiple members who may each be
offline at unpredictable times.</t> offline at unpredictable times.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Use the content mecha
<li> nism defined in
<t><strong>RECOMMENDATION:</strong> Use the default content mechanis <xref target="I-D.ietf-mls-extensions"/>, unless the specific application define
m defined in s another
<xref section="3.3" sectionFormat="of" target="I-D.ietf-mls-extensions"/>, unles mechanism that more appropriately addresses the same requirements for that
s the specific application defines another application of MLS.
mechanism which more appropriately addresses the same requirements for that </t>
application of MLS.</t>
</li>
</ul>
<t>The MLS framing for application messages also provides a field where clients can <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 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 be used by servers that handle the message, but group members are assured that
it has not been tampered with.</t> it has not been tampered with.</t>
</section> </section>
<section anchor="federation"> <section anchor="federation">
<name>Federation</name> <name>Federation</name>
<t>The protocol aims to be compatible with federated environments. While this <t>The protocol aims to be compatible with federated environments. While this
document does not specify all necessary mechanisms required for federation, document does not specify all necessary mechanisms required for federation,
multiple MLS implementations can interoperate to form federated systems if they multiple MLS implementations can interoperate to form federated systems if they
use compatible authentication mechanisms, ciphersuites, application content, and use compatible authentication mechanisms, cipher suites, application content, an d
infrastructure functionalities. Federation is described in more detail in infrastructure functionalities. Federation is described in more detail in
<xref target="I-D.ietf-mls-federation"/>.</t> <xref target="I-D.ietf-mls-federation"/>.</t>
</section> </section>
<section anchor="compatibility-with-future-versions-of-mls"> <section anchor="compatibility-with-future-versions-of-mls">
<name>Compatibility with Future Versions of MLS</name> <name>Compatibility with Future Versions of MLS</name>
<t>It is important that multiple versions of MLS be able to coexist in t he <t>It is important that multiple versions of MLS be able to coexist in t he
future. Thus, MLS offers a version negotiation mechanism; this mechanism future. Thus, MLS offers a version negotiation mechanism; this mechanism
prevents version downgrade attacks where an attacker would actively rewrite prevents version downgrade attacks where an attacker would actively rewrite
messages with a lower protocol version than the ones originally offered by the messages with a lower protocol version than the messages originally offered by t he
endpoints. When multiple versions of MLS are available, the negotiation protocol endpoints. When multiple versions of MLS are available, the negotiation protocol
guarantees that the version agreed upon will be the highest version supported in guarantees that the creator is able to select the best version out of those
common by the group.</t> supported in common by the group.</t>
<t>In MLS 1.0, the creator of the group is responsible for selecting the best <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 cipher suite supported across clients. Each client is able to verify availabilit
of protocol version, ciphersuites and extensions at all times once he has at y
of protocol version, cipher suites, and extensions at all times once it has at
least received the first group operation message.</t> least received the first group operation message.</t>
<t>Each member of an MLS group advertises the protocol functionality the y support. <t>Each member of an MLS group advertises the protocol functionality the y support.
These capability advertisements can be updated over time, e.g., if client 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 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 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> is safe to upgrade to a new cipher suite or protocol version.</t>
</section> </section>
</section> </section>
<section anchor="operational-requirements"> <section anchor="operational-requirements">
<name>Operational Requirements</name> <name>Operational Requirements</name>
<t>MLS is a security layer that needs to be integrated with an application . A <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 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 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 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 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 still need to be aligned within a given MLS deployment, or for two deployments
to potentially interoperate.</t> to potentially interoperate.
</t>
<t>The protocol has a built-in ability to negotiate protocol versions, <t>The protocol has a built-in ability to negotiate protocol versions,
ciphersuites, extensions, credential types, and additional proposal types. For cipher suites, extensions, credential types, and additional proposal types. For
two deployments to interoperate, they must have overlapping support in each of two deployments to interoperate, they must have overlapping support in each of
these categories. The <tt>required_capabilities</tt> extension (Section 7.2 of these categories. The <tt>required_capabilities</tt> extension (<xref section="7
<xref target="RFC9420"/>) can promote interoperability with a wider set of clien .2" sectionFormat="of" target="RFC9420"/>) can promote interoperability with a w
ts by ider set of clients by
ensuring that certain functionality continues to be supported by a group, even 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> if the clients in the group aren't currently relying on it.</t>
<t>MLS relies on the following network services, that need to be compatibl e in <t>MLS relies on the following network services, which need to be compatib le in
order for two different deployments based on them to interoperate.</t> order for two different deployments based on them to interoperate.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>An <strong>Authentication Service</strong>, described fully in <xre f target="authentication-service"/>, <t>An <strong>Authentication Service</strong>, described fully in <xre f target="authentication-service"/>,
defines the types of credentials which may be used in a deployment and defines the types of credentials which may be used in a deployment and
provides methods for: provides methods for:
</t> </t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Issuing new credentials with a relevant credential lifetime,</t > <t>Issuing new credentials with a relevant credential lifetime,</t >
</li> </li>
skipping to change at line 1239 skipping to change at line 1213
<li> <li>
<t>Uploading new KeyPackages for a user's own clients.</t> <t>Uploading new KeyPackages for a user's own clients.</t>
</li> </li>
<li> <li>
<t>Downloading KeyPackages for specific clients. Typically, KeyPac kages are <t>Downloading KeyPackages for specific clients. Typically, KeyPac kages are
used once and consumed.</t> used once and consumed.</t>
</li> </li>
</ol> </ol>
</li> </li>
<li> <li>
<t>Additional services may or may not be required depending on the app lication <t>Additional services may or may not be required, depending on the ap plication
design: </t> design: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>In cases where group operations are not encrypted, the DS has t he ability to <t>In cases where group operations are not encrypted, the DS has t he ability to
observe and maintain a copy of the public group state. In particular, this observe and maintain a copy of the public group state. In particular, this
is useful for clients that do not have the ability to send the full public is useful for either (1)&nbsp;clients that do not have the ability to send the f
state in a Welcome message when inviting a user, or for a client that needs to ull public
recover from losing their state. Such public state can contain privacy state in a Welcome message when inviting a user or (2)&nbsp;clients that need to
sensitive information such as group members' credentials and related public recover from losing their state. Such public state can contain privacy-sensitive
keys, hence services need to carefully evaluate the privacy impact of 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> storing this data on the DS.</t>
</li> </li>
<li> <li>
<t>If external joiners are allowed, there must be a method to publ ish a <t>If external joiners are allowed, there must be a method for pub lishing a
serialized <tt>GroupInfo</tt> object (with an <tt>external_pub</tt> extension) t hat serialized <tt>GroupInfo</tt> object (with an <tt>external_pub</tt> extension) t hat
corresponds to a specific group and epoch, and keep that object in sync with corresponds to a specific group and epoch, and for keeping that object in sync w ith
the state of the group.</t> the state of the group.</t>
</li> </li>
<li> <li>
<t>If an application chooses not to allow external joining, it may <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 instead provide a method for external users to solicit group members (or a
designated service) to add them to a group.</t> designated service) to add them to a group.</t>
</li> </li>
<li> <li>
<t>If the application uses PSKs that members of a group may not ha ve access to <t>If the application uses PSKs that members of a group may not ha ve access to
(e.g., to control entry into the group or to prove membership in the group (e.g., to control entry into the group or to prove membership in the group
in the past, as in <xref target="state-loss"/>) there must be a method for distr in the past, as discussed in <xref target="state-loss"/>), there must be a metho
ibuting d for distributing
these PSKs to group members who might not have them, for instance if they these PSKs to group members who might not have them -- for instance, if they
joined the group after the PSK was generated.</t> joined the group after the PSK was generated.</t>
</li> </li>
<li> <li>
<t>If an application wishes to detect and possibly discipline memb ers that send <t>If an application wishes to detect and possibly discipline memb ers that send
malformed commits with the intention of corrupting a group's state, there malformed commits with the intention of corrupting a group's state, there
must be a method for reporting and validating malformed commits.</t> must be a method for reporting and validating malformed commits.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
skipping to change at line 1291 skipping to change at line 1264
<li> <li>
<t>The maximum total lifetime that is acceptable for a KeyPackage.</t> <t>The maximum total lifetime that is acceptable for a KeyPackage.</t>
</li> </li>
<li> <li>
<t>How long to store the resumption PSK for past epochs of a group.</t > <t>How long to store the resumption PSK for past epochs of a group.</t >
</li> </li>
<li> <li>
<t>The degree of tolerance that's allowed for out-of-order message del ivery: </t> <t>The degree of tolerance that's allowed for out-of-order message del ivery: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>How long to keep unused nonce and key pairs for a sender</t> <t>How long to keep unused nonce and key pairs for a sender.</t>
</li> </li>
<li> <li>
<t>A maximum number of unused key pairs to keep.</t> <t>A maximum number of unused key pairs to keep.</t>
</li> </li>
<li> <li>
<t>A maximum number of steps that clients will move a secret tree ratchet <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> forward in response to a single message before rejecting it.</t>
</li> </li>
<li> <li>
<t>Whether to buffer messages that aren't able to be understood ye <t>Whether to buffer messages that aren't yet able to be understoo
t due to d due to
other messages not arriving first, and if so, how many and for how long. For 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 example, Commit messages that arrive before a proposal they reference or
application messages that arrive before the Commit starting an epoch.</t> application messages that arrive before the Commit starting an epoch.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>If implementations differ in these parameters, they will interoperate t o some <t>If implementations differ in these parameters, they will interoperate t o some
extent but may experience unexpected failures in certain situations, such as extent but may experience unexpected failures in certain situations, such as
extensive message reordering.</t> extensive message reordering.</t>
<t>MLS provides the following locations where an application may store arb itrary <t>MLS provides the following locations where an application may store arb itrary
data. The format and intention of any data in these locations must align for two data. The format and intention of any data in these locations must align for two
skipping to change at line 1327 skipping to change at line 1300
<t>Application data, sent as the payload of an encrypted message.</t> <t>Application data, sent as the payload of an encrypted message.</t>
</li> </li>
<li> <li>
<t>Additional authenticated data, sent unencrypted in an otherwise enc rypted <t>Additional authenticated data, sent unencrypted in an otherwise enc rypted
message.</t> message.</t>
</li> </li>
<li> <li>
<t>Group IDs, as decided by group creators and used to uniquely identi fy a group.</t> <t>Group IDs, as decided by group creators and used to uniquely identi fy a group.</t>
</li> </li>
<li> <li>
<t>Application-level identifiers of public key material (specifically <t>Application-level identifiers of public key material (specifically,
the <tt>application_id</tt> extension as defined in <xref section="5.3.3" sectio nFormat="of" target="RFC9420"/>).</t> the <tt>application_id</tt> extension as defined in <xref section="5.3.3" sectio nFormat="of" target="RFC9420"/>).</t>
</li> </li>
</ul> </ul>
<t>MLS requires the following policies to be defined, which restrict the s et of <t>MLS requires the following policies to be defined, which restrict the s et of
acceptable behavior in a group. These policies must be consistent between acceptable behaviors in a group. These policies must be consistent between
deployments for them to interoperate:</t> deployments for them to interoperate:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A policy on which ciphersuites are acceptable.</t> <t>A policy on which cipher suites are acceptable.</t>
</li> </li>
<li> <li>
<t>A policy on any mandatory or forbidden MLS extensions.</t> <t>A policy on any mandatory or forbidden MLS extensions.</t>
</li> </li>
<li> <li>
<t>A policy on when to send proposals and commits in plaintext instead of <t>A policy on when to send proposals and commits in plaintext instead of
encrypted.</t> encrypted.</t>
</li> </li>
<li> <li>
<t>A policy for which proposals are valid to have in a commit, includi ng but not <t>A policy for which proposals are valid to have in a commit, includi ng but not
skipping to change at line 1377 skipping to change at line 1350
</ul> </ul>
</li> </li>
<li> <li>
<t>A policy of when members should commit pending proposals in a group .</t> <t>A policy of when members should commit pending proposals in a group .</t>
</li> </li>
<li> <li>
<t>A policy of how to protect and share the GroupInfo objects needed f or <t>A policy of how to protect and share the GroupInfo objects needed f or
external joins.</t> external joins.</t>
</li> </li>
<li> <li>
<t>A policy for when two credentials represent the same client. Note t <t>A policy for when two credentials represent the same client, distin
hat many guishing
credentials may be issued attesting the same identity but for different the following two cases:
signature keys, because each credential corresponds to a different client </t>
owned by the same application user. However, one device may control multiple <ul>
signature keys -- for instance if they have keys corresponding to multiple <li>
overlapping time periods -- but should still only be considered a single <t>When there are multiple devices for a given user.</t>
client.</t> </li>
<li>
<t>When a single device has multiple signature keys -- for instanc
e,
if the device has keys corresponding to multiple overlapping time
periods.</t>
</li>
</ul>
</li> </li>
<li> <li>
<t>A policy on how long to allow a member to stay in a group without u pdating its <t>A policy on how long to allow a member to stay in a group without u pdating its
leaf keys before removing them.</t> leaf keys before removing them.</t>
</li> </li>
</ul> </ul>
<t>Finally, there are some additional application-defined behaviors that a re <t>Finally, there are some additional application-defined behaviors that a re
partially an individual application's decision but may overlap with partially an individual application's decision but may overlap with
interoperability:</t> interoperability:</t>
<ul spacing="normal"> <ul spacing="normal">
skipping to change at line 1425 skipping to change at line 1403
security services described in <xref target="intended-security-guarantees"/> in the face of security services described in <xref target="intended-security-guarantees"/> in the face of
attackers who can:</t> attackers who can:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Monitor the entire network.</t> <t>Monitor the entire network.</t>
</li> </li>
<li> <li>
<t>Read unprotected messages.</t> <t>Read unprotected messages.</t>
</li> </li>
<li> <li>
<t>Can generate, inject and delete any message in the unprotected <t>Generate, inject, and delete any message in the unprotected
transport layer.</t> transport layer.</t>
</li> </li>
</ul> </ul>
<t>While MLS should be run over a secure transport such as QUIC <xref targ et="RFC9000"/> or TLS <t>While MLS should be run over a secure transport such as QUIC <xref targ et="RFC9000"/> or TLS
<xref target="RFC8446"/>, the security guarantees of MLS do not depend on the <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 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 because MLS is designed to provide security even in the face of compromised
network elements, especially the DS.</t> network elements, especially the DS.</t>
<t>Generally, MLS is designed under the assumption that the transport laye r is <t>Generally, MLS is designed under the assumption that the transport laye r is
present to keep metadata private from network observers, while the MLS protocol present to keep metadata private from network observers, while the MLS protocol
provides confidentiality, integrity, and authentication guarantees for the provides confidentiality, integrity, and authentication guarantees for the
application data (which could pass through multiple systems). Additional application data (which could pass through multiple systems). Additional
properties such as partial anonymity or deniability could also be achieved in properties such as partial anonymity or deniability could also be achieved in
specific architecture designs.</t> specific architecture designs.</t>
<t>In addition, these guarantees are intended to degrade gracefully in the presence <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 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> elements of the messaging system, as described in the remainder of this section. </t>
<section anchor="assumptions-on-transport-security-links"> <section anchor="assumptions-on-transport-security-links">
<name>Assumptions on Transport Security Links</name> <name>Assumptions on Transport Security Links</name>
<t>As discussed above, MLS provides the highest level of security when i ts messages <t>As discussed above, MLS provides the highest level of security when i ts messages
are delivered over an encrypted transport. The main use of the secure transport are delivered over an encrypted transport, thus preventing attackers from
layer for MLS is to protect the already limited amount of metadata. Very little selectively interfering with MLS communications as well as
protecting the already limited amount of metadata. Very little
information is contained in the unencrypted header of the MLS protocol message information is contained in the unencrypted header of the MLS protocol message
format for group operation messages, and application messages are always format for group operation messages, and application messages are always
encrypted in MLS.</t> encrypted in MLS.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Use transports that p
<li> rovide reliability and metadata
<t><strong>RECOMMENDATION:</strong> Use transports that provide reli
ability and metadata
confidentiality whenever possible, e.g., by transmitting MLS messages over confidentiality whenever possible, e.g., by transmitting MLS messages over
a protocol such as TLS <xref target="RFC8446"/> or QUIC <xref target="RFC9000"/> .</t> a protocol such as TLS <xref target="RFC8446"/> or QUIC <xref target="RFC9000"/> .</t>
</li> <t>MLS avoids the need to send the full list of recipients to the server
</ul> for
<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 dispatching messages because that list could potentially contain tens of
thousands of recipients. Header metadata in MLS messages typically consists 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 gro up (the an opaque <tt>group_id</tt>, a numerical value to determine the epoch of the gro up (the
number of changes that have been made to the group), and whether the message is number of changes that have been made to the group), and whether the message is
an application message, a proposal, or a commit.</t> an application message, a proposal, or a commit.</t>
<t>Even though some of this metadata information does not consist of sen sitive <t>Even though some of this metadata information does not consist of sen sitive
information, in correlation with other data a network observer might be able to information, when correlated with other data a network observer might be able to
reconstruct sensitive information. Using a secure channel to transfer this reconstruct sensitive information. Using a secure channel to transfer this
information will prevent a network attacker from accessing this MLS protocol information will prevent a network attacker from accessing this MLS protocol
metadata if it cannot compromise the secure channel.</t> metadata if it cannot compromise the secure channel.</t>
<section anchor="integrity-and-authentication-of-custom-metadata"> <section anchor="integrity-and-authentication-of-custom-metadata">
<name>Integrity and Authentication of Custom Metadata</name> <name>Integrity and Authentication of Custom Metadata</name>
<t>MLS provides an authenticated "Additional Authenticated Data" (AAD) field for <t>MLS provides an authenticated "Additional Authenticated Data" (AAD) field for
applications to make data available outside a PrivateMessage, while applications to make data available outside a PrivateMessage, while
cryptographically binding it to the message.</t> cryptographically binding it to the message.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Use the "Additional
<li> Authenticated Data" field of the
<t><strong>RECOMMENDATION:</strong> Use the "Additional Authentica
ted Data" field of the
PrivateMessage instead of using other unauthenticated means of sending PrivateMessage instead of using other unauthenticated means of sending
metadata throughout the infrastructure. If the data should be kept private, the metadata throughout the infrastructure. If the data should be kept private, the
infrastructure should use encrypted Application messages instead.</t> infrastructure should use encrypted application messages instead.</t>
</li>
</ul>
</section> </section>
<section anchor="metadata-protection-for-unencrypted-group-operations"> <section anchor="metadata-protection-for-unencrypted-group-operations">
<name>Metadata Protection for Unencrypted Group Operations</name> <name>Metadata Protection for Unencrypted Group Operations</name>
<t>Having no secure channel to exchange MLS messages can have a seriou s impact on <t>Having no secure channel to exchange MLS messages can have a seriou s impact on
privacy when transmitting unencrypted group operation messages. Observing the privacy when transmitting unencrypted group operation messages. Observing the
contents and signatures of the group operation messages may lead an adversary to contents and signatures of the group operation messages may lead an adversary to
extract information about the group membership.</t> extract information about the group membership.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Never use the unenc
<li> rypted mode for group operations
<t><strong>RECOMMENDATION:</strong> Never use the unencrypted mode
for group operations
without using a secure channel for the transport layer.</t> without using a secure channel for the transport layer.</t>
</li>
</ul>
</section> </section>
<section anchor="dos-protection"> <section anchor="dos-protection">
<name>DoS protection</name> <name>DoS Protection</name>
<t>In general we do not consider Denial of Service (DoS) resistance to <t>In general, we do not consider DoS resistance to be the
be the
responsibility of the protocol. However, it should not be possible for anyone 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 aside from the DS to perform a trivial DoS attack from which it is
hard to recover. This can be achieved through the secure transport layer.</t> hard to recover. This can be achieved through the secure transport layer,
which prevents selective attack on MLS communications by network
attackers.</t>
<t>In the centralized setting, DoS protection can typically be perform ed by using <t>In the centralized setting, DoS protection can typically be perform ed by using
tickets or cookies which identify users to a service for a certain number of 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 connections. Such a system helps in preventing anonymous clients from sending
arbitrary numbers of group operation messages to the Delivery Service or the MLS arbitrary numbers of group operation messages to the DS or the MLS
clients.</t> clients.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Use credentials unc
<li> orrelated with specific users to help
<t><strong>RECOMMENDATION:</strong> Use credentials uncorrellated prevent DoS attacks, in a privacy-preserving manner. Note that the privacy of
with specific users to help
prevent DoS attacks, in a privacy preserving manner. Note that the privacy of
these mechanisms has to be adjusted in accordance with the privacy expected these mechanisms has to be adjusted in accordance with the privacy expected
from secure transport links. (See more discussion in the next section.)</t> from secure transport links. (See more discussion in the next section.)</t>
</li>
</ul>
</section> </section>
<section anchor="message-suppression-and-error-correction"> <section anchor="message-suppression-and-error-correction">
<name>Message Suppression and Error Correction</name> <name>Message Suppression and Error Correction</name>
<t>As noted above, MLS is designed to provide some robustness in the f ace of <t>As noted above, MLS is designed to provide some robustness in the f ace of
tampering within the secure transport, i.e., tampering by the Delivery Service. tampering within the secure transport, e.g., tampering by the DS.
The confidentiality and authenticity properties of MLS prevent the DS from The confidentiality and authenticity properties of MLS prevent the DS from
reading or writing messages. MLS also provides a few tools for detecting reading or writing messages. MLS also provides a few tools for detecting
message suppression, with the caveat that message suppression cannot always be message suppression, with the caveat that message suppression cannot always be
distinguished from transport failure.</t> distinguished from transport failure.
<t>Each encrypted MLS message carries a "generation" number which is a </t>
per-sender <t>Each encrypted MLS message carries a per-sender incrementing "generation" num
incrementing counter. If a group member observes a gap in the generation ber.
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 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 sender. MLS also provides a facility for group members to send authenticated
acknowledgments of application messages received within a group.</t> acknowledgments of application messages received within a group.</t>
<t>As discussed in <xref target="delivery-service"/>, the Delivery Ser <t>As discussed in <xref target="delivery-service"/>, the DS is truste
vice is trusted to select d to select
the single Commit message that is applied in each epoch from among the ones sent the single Commit message that is applied in each epoch from among the Commits s
ent
by group members. Since only one Commit per epoch is meaningful, it's not 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 useful for the DS to transmit multiple Commits to clients. The risk remains
that the DS will use the ability maliciously.</t> 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
governments 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> </section>
<section anchor="intended-security-guarantees"> <section anchor="intended-security-guarantees">
<name>Intended Security Guarantees</name> <name>Intended Security Guarantees</name>
<t>MLS aims to provide a number of security guarantees, covering authent ication, as <t>MLS aims to provide a number of security guarantees, covering authent ication, as
well as confidentiality guarantees to different degrees in different scenarios.< /t> well as confidentiality guarantees to different degrees in different scenarios.< /t>
<section anchor="message-secrecy-authentication"> <section anchor="message-secrecy-authentication">
<name>Message Secrecy and Authentication</name> <name>Message Secrecy and Authentication</name>
<t>MLS enforces the encryption of application messages and thus genera lly <t>MLS enforces the encryption of application messages and thus genera lly
guarantees authentication and confidentiality of application messages sent in a guarantees authentication and confidentiality of application messages sent in a
skipping to change at line 1568 skipping to change at line 1526
message's integrity.</t> message's integrity.</t>
<t>Message content can be deniable if the signature keys are exchanged over a <t>Message content can be deniable if the signature keys are exchanged over a
deniable channel prior to signing messages.</t> deniable channel prior to signing messages.</t>
<t>Depending on the group settings, handshake messages can be encrypte d as well. If <t>Depending on the group settings, handshake messages can be encrypte d as well. If
that is the case, the same security guarantees apply.</t> that is the case, the same security guarantees apply.</t>
<t>MLS optionally allows the addition of padding to messages, mitigati ng the amount <t>MLS optionally allows the addition of padding to messages, mitigati ng the amount
of information leaked about the length of the plaintext to an observer on the of information leaked about the length of the plaintext to an observer on the
network.</t> network.</t>
</section> </section>
<section anchor="fs-and-pcs"> <section anchor="fs-and-pcs">
<name>Forward and Post-Compromise Security</name> <name>Forward Secrecy and Post-Compromise Security</name>
<t>MLS provides additional protection regarding secrecy of past messag es and future <t>MLS provides additional protection regarding secrecy of past messag es and future
messages. These cryptographic security properties are Forward Secrecy (FS) and messages. These cryptographic security properties are forward secrecy (FS) and p
Post-Compromise Security (PCS).</t> ost-compromise security (PCS).</t>
<t>FS means that access to all encrypted traffic history combined with <t>FS means that access to all encrypted traffic history combined with
access to all current keying material on clients will not defeat the access to all current keying material on clients will not defeat the
secrecy properties of messages older than the oldest key of the secrecy properties of messages older than the oldest key of the
compromised client. Note that this means that clients have to delete the approp riate compromised client. Note that this means that clients have to delete the approp riate
keys as soon as they have been used with the expected message, keys as soon as they have been used with the expected message;
otherwise the secrecy of the messages and the security for MLS is otherwise, the secrecy of the messages and the security of MLS are
considerably weakened.</t> considerably weakened.</t>
<t>PCS means that if a group member's state is compromised at some tim e t1 but the <t>PCS means that if a group member's state is compromised at some tim e t1 but the
group member subsequently performs an update at some time t2, then all MLS 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 by other guarantees apply to messages sent by the member after time t2 and to messages se nt by other
members after they have processed the update. For example, if an attacker learns 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 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 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 the attacker is unable to violate any of the MLS security properties after the
updates have been processed.</t> updates have been processed.</t>
<t>Both of these properties are satisfied even against compromised DSs and ASs in <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 the case where some other mechanism for verifying keys is in use, such as Key
Transparency <xref target="KT"/>.</t> Transparency <xref target="I-D.ietf-keytrans-architecture"/>.</t>
<t>Confidentiality is mainly ensured on the client side. Because Forw <t>Confidentiality is mainly ensured on the client side. Because FS a
ard Secrecy nd PCS rely on the active deletion and
(FS) and Post-Compromise Security (PCS) rely on the active deletion and
replacement of keying material, any client which is persistently offline may replacement of keying material, any client which is persistently offline may
still be holding old keying material and thus be a threat to both FS and PCS if still be holding old keying material and thus be a threat to both FS and PCS if
it is later compromised.</t> it is later compromised.</t>
<t>MLS partially defends against this problem by active members includ ing <t>MLS partially defends against this problem by active members includ ing
freshness, however not much can be done on the inactive side especially in the new keying material. However, not much can be done on the inactive side especial
case where the client has not processed messages.</t> ly in the
<ul empty="true"> case where the client has not processed messages.
<li> </t>
<t><strong>RECOMMENDATION:</strong> Mandate key updates from clien <t indent="3"><strong>Recommendation:</strong> Mandate key updates
ts that are not otherwise from clients that are not otherwise
sending messages and evict clients which are idle for too long.</t> sending messages and evict clients that are idle for too long.</t>
</li>
</ul>
<t>These recommendations will reduce the ability of idle compromised c lients to <t>These recommendations will reduce the ability of idle compromised c lients to
decrypt a potentially long set of messages that might have followed the point of decrypt a potentially long set of messages that might have been sent after the p
the compromise.</t> oint of compromise.
</t>
<t>The precise details of such mechanisms are a matter of local policy and beyond <t>The precise details of such mechanisms are a matter of local policy and beyond
the scope of this document.</t> the scope of this document.</t>
</section> </section>
<section anchor="Non-Repudiation-vs-Deniability"> <section anchor="Non-Repudiation-vs-Deniability">
<name>Non-Repudiation vs Deniability</name> <name>Non-Repudiation vs. Deniability</name>
<t>MLS provides strong authentication within a group, such that a grou p member <t>MLS provides strong authentication within a group, such that a grou p member
cannot send a message that appears to be from another 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 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 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 abuse. MLS supports both of these use cases. In some deployments, these services
are provided by mechanisms which allow the receiver to prove a message's origin are provided by mechanisms which allow the receiver to prove a message's origin
to a third party. This is often called "non-repudiation".</t> to a third party. This is often called "non-repudiation".</t>
<t>Roughly speaking, "deniability" is the opposite of "non-repudiation ", i.e., the <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 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 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 may be possible to operate MLS in ways that provide certain deniability
properties, but defining the specific requirements and resulting notions of properties, but defining the specific requirements and resulting notions of
deniability requires further analysis.</t> deniability requires further analysis.</t>
</section> </section>
<section anchor="associating-a-users-clients"> <section anchor="associating-a-users-clients">
<name>Associating a User's Clients</name> <name>Associating a User's Clients</name>
<t>When a user has multiple devices, the base MLS protocol only descri bes how to <t>When a user has multiple devices, the base MLS protocol only descri bes how to
operate each device as a distinct client in the MLS groups that the user is a 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 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 which of a user's devices sent each message and, therefore, which device the use r
was using at the time. Group members would also be able to detect when 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, adds or removes authorized devices from their account. For some applications,
this may be an unacceptable breach of the user's privacy.</t> 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 questi on provide <t>This risk only arises when the leaf nodes for the clients in questi on provide
data that can be used to correlate the clients. So one way to mitigate this data that can be used to correlate the clients. One way to mitigate this
risk is by only doing client-level authentication within MLS. If user-level risk is by only doing client-level authentication within MLS. If user-level
authentication is still desirable, the application would have to provide it authentication is still desirable, the application would have to provide it
through some other mechanism.</t> through some other mechanism.</t>
<t>It is also possible to maintain user-level authentication while hid ing <t>It is also possible to maintain user-level authentication while hid ing
information about the clients that a user owns. This can be done by having the 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 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 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 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 leaking the user's authorized devices. However, the application would need to
provide a synchronization mechanism so that the clients' state remain consistent provide a synchronization mechanism so that the state of each client remains con sistent
across changes to the MLS group. Flaws in this synchronization mechanism may 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 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 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 to use one compromised device to establish exclusive control of a user's
account, locking them out entirely and preventing them from recovering.</t> account, locking them out entirely and preventing them from recovering.
</t>
</section> </section>
</section> </section>
<section anchor="endpoint-compromise"> <section anchor="endpoint-compromise">
<name>Endpoint Compromise</name> <name>Endpoint Compromise</name>
<t>The MLS protocol adopts a threat model which includes multiple forms of <t>The MLS protocol adopts a threat model which includes multiple forms of
endpoint/client compromise. While adversaries are in a strong position if endpoint/client compromise. While adversaries are in a strong position if
they have compromised an MLS client, there are still situations where security 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 guarantees can be recovered thanks to the PCS properties achieved by the MLS
protocol.</t> protocol.</t>
<t>In this section we will explore the consequences and recommendations regarding <t>In this section we will explore the consequences and recommendations regarding
the following compromise scenarios:</t> the following compromise scenarios:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The attacker has access to a symmetric encryption key</t> <t>The attacker has access to a symmetric encryption key.</t>
</li> </li>
<li> <li>
<t>The attacker has access to a application ratchet secret</t> <t>The attacker has access to an application ratchet secret.</t>
</li> </li>
<li> <li>
<t>The attacker has access to the group secrets for one group</t> <t>The attacker has access to the group secrets for one group.</t>
</li> </li>
<li> <li>
<t>The attacker has access to a signature oracle for any group</t> <t>The attacker has access to a signature oracle for any group.</t>
</li> </li>
<li> <li>
<t>The attacker has access to the signature key for one group</t> <t>The attacker has access to the signature key for one group.</t>
</li> </li>
<li> <li>
<t>The attacker has access to all secrets of a user for all groups ( full state <t>The attacker has access to all secrets of a user for all groups ( full state
compromise)</t> compromise).</t>
</li> </li>
</ul> </ul>
<section anchor="symmetric-key-compromise"> <section anchor="symmetric-key-compromise">
<name>Compromise of Symmetric Keying Material</name> <name>Compromise of Symmetric Keying Material</name>
<t>As described above, each MLS epoch creates a new Group Secret.</t> <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 Se <t>These group secrets are then used to create a per-sender ratchet se
cret, which cret, which
in turn is used to create a per-sender with additional data (AEAD) <xref target= in turn is used to create a per-sender Authenticated Encryption with
"RFC5116"/> Associated Data (AEAD) <xref target="RFC5116"/> key
key that is then used to encrypt MLS Plaintext messages. Each time a message is 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 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 corresponding AEAD key. Because of the properties of the key derivation
function, it is not possible to compute a Ratchet Secret from its corresponding function, it is not possible to compute a ratchet secret from its corresponding
AEAD key or compute Ratchet Secret n-1 from Ratchet Secret n.</t> AEAD key or compute ratchet secret n-1 from ratchet secret n.
</t>
<t>Below, we consider the compromise of each of these pieces of keying material in <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 turn, in ascending order of severity. While this is a limited kind of
compromise, it can be realistic in cases of implementation vulnerabilities where compromise, it can be realistic in cases of implementation vulnerabilities where
only part of the memory leaks to the adversary.</t> only part of the memory leaks to the adversary.</t>
<section anchor="compromise-of-aead-keys"> <section anchor="compromise-of-aead-keys">
<name>Compromise of AEAD Keys</name> <name>Compromise of AEAD Keys</name>
<t>In some circumstances, adversaries may have access to specific AE AD keys and <t>In some circumstances, adversaries may have access to specific AE AD keys and
nonces which protect an Application or a Group Operation message. Compromise of nonces which protect an application message or a group operation message. Compro mise of
these keys allows the attacker to decrypt the specific message encrypted with 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 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 secret, it cannot generate the next ratchet secret and hence not the next AEAD
key.</t> key.</t>
<t>In the case of an Application message, an AEAD key compromise mea ns that the <t>In the case of an application message, an AEAD key compromise mea ns that the
encrypted application message will be leaked as well as the signature over that encrypted application message will be leaked as well as the signature over that
message. This means that the compromise has both confidentiality and privacy 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 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 group operation message, only the privacy is affected, as the signature is
revealed, because the secrets themselves are protected by HPKE encryption. Note revealed, because the secrets themselves are protected by Hybrid Public Key Encr
yption (HPKE). Note
that under that compromise scenario, authentication is not affected in either of 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 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 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 messages, the authentication provided by the AEAD encryption layer of the common
framing mechanism is weak. Successful decryption of an AEAD encrypted message framing mechanism is weak. Successful decryption of an AEAD encrypted message
only guarantees that some member of the group sent the message.</t> only guarantees that some member of the group -- or in this case an attacker
who has compromised the AEAD keys -- sent the message.</t>
<t>Compromise of the AEAD keys allows the attacker to send an encryp ted message <t>Compromise of the AEAD keys allows the attacker to send an encryp ted message
using that key, but cannot send a message to a group which appears to be from using that key, but the attacker cannot send a message to a group that appears t
any valid client since they cannot forge the signature. This applies to all the o be from
forms of symmetric key compromise described in <xref target="symmetric-key-compr any valid client because the attacker cannot forge the signature. This applies t
omise"/>.</t> o all the
forms of symmetric key compromise described in <xref target="symmetric-key-compr
omise"/>.
</t>
</section> </section>
<section anchor="compromise-of-ratchet-secret-material"> <section anchor="compromise-of-ratchet-secret-material">
<name>Compromise of Ratchet Secret material</name> <name>Compromise of Ratchet Secret Material</name>
<t>When a Ratchet Secret is compromised, the adversary can compute b <t>When a ratchet secret is compromised, the adversary can compute b
oth the current oth the current
AEAD keys for a given sender as well as any future keys for that sender in this AEAD keys for a given sender and any future keys for that sender in this
epoch. Thus, it can decrypt current and future messages by the corresponding epoch. Thus, it can decrypt current and future messages by the corresponding
sender. However, because it does not have previous Ratchet Secrets, it cannot sender. However, because it does not have previous ratchet secrets, it cannot
decrypt past messages as long as those secrets and keys have been deleted.</t> decrypt past messages as long as those secrets and keys have been deleted.
<t>Because of its Forward Secrecy guarantees, MLS will also retain s </t>
ecrecy of all <t>Because of its forward secrecy guarantees, MLS will also retain s
ecrecy of all
other AEAD keys generated for <em>other</em> MLS clients, outside this dedicated chain 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 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 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 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 attacker does not have access to more secret material they won't be able to
access any protected messages from future epochs.</t> access any protected messages from future epochs.</t>
</section> </section>
<section anchor="compromise-of-the-group-secrets-of-a-single-group-for -one-or-more-group-epochs"> <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 m <name>Compromise of the Group Secrets of a Single Group for One or M
ore group epochs</name> ore Group Epochs</name>
<t>An adversary who gains access to a set of Group secrets--as when <t>An adversary who gains access to a set of group secrets -- as whe
a member of the n a member of the
group is compromised--is significantly more powerful. In this section, we group is compromised -- is significantly more powerful. In this section, we
consider the case where the signature keys are not compromised, which can occur consider the case where the signature keys are not compromised. This can occur
if the attacker has access to part of the memory containing the group secrets 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> 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 <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 ratchet secrets for the epoch and their corresponding AEAD encryption keys and
thus can encrypt and decrypt all messages for the compromised epochs.</t> thus can encrypt and decrypt all messages for the compromised epochs.</t>
<t>If the adversary is passive, it is expected from the PCS properti es of the MLS <t>If the adversary is passive, it is expected from the PCS properti es of the MLS
protocol that, as soon as the compromised party remediates the compromise and 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 > 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 proto col itself and <t>If the adversary is active, the adversary can engage in the proto col itself and
perform updates on behalf of the compromised party with no ability for an honest 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 group to recover message secrecy. However, MLS provides PCS against active
adaptive attackers through its Remove group operation. This means that, as long 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 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 secrecy for all messages exchanged in the epochs after the compromised party has
been removed.</t> been removed.</t>
</section> </section>
</section> </section>
<section anchor="compromise-by-an-active-adversary-with-the-ability-to-s ign-messages"> <section anchor="compromise-by-an-active-adversary-with-the-ability-to-s ign-messages">
<name>Compromise by an active adversary with the ability to sign messa ges</name> <name>Compromise by an Active Adversary with the Ability to Sign Messa ges</name>
<t>If an active adversary has compromised an MLS client and can sign m essages, two <t>If an active adversary has compromised an MLS client and can sign m essages, two
different settings emerge. In the strongest compromise scenario, the attacker different scenarios emerge. In the strongest compromise scenario, the attacker
has access to the signing key and can forge authenticated messages. In a weaker, has access to the signing key and can forge authenticated messages. In a weaker,
yet realistic scenario, the attacker has compromised a client but the client yet realistic scenario, the attacker has compromised a client but the client
signature keys are protected with dedicated hardware features which do not allow signature keys are protected with dedicated hardware features which do not allow
direct access to the value of the private key and instead provide a signature direct access to the value of the private key and instead provide a signature
API.</t> API.</t>
<t>When considering an active adaptive attacker with access to a signa ture oracle, <t>When considering an active adaptive attacker with access to a signa ture oracle,
the compromise scenario implies a significant impact on both the secrecy and the compromise scenario implies a significant impact on both the secrecy and
authentication guarantees of the protocol, especially if the attacker also has authentication guarantees of the protocol, especially if the attacker also has
access to the group secrets. In that case both secrecy and authentication are 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 broken. The attacker can generate any message, for the current and future
epochs, until the compromise is remediated and the formerly compromised client epochs, until the compromise is remediated and the formerly compromised client
sends an honest update.</t> sends an honest update.</t>
<t>Note that under this compromise scenario, the attacker can perform all <t>Note that under this compromise scenario, the attacker can perform all
operations which are available to a legitimate client even without access to the operations which are available to a legitimate client even without access to the
actual value of the signature key.</t> actual value of the signature key.</t>
</section> </section>
<section anchor="compromise-of-the-authentication-with-access-to-a-signa ture-key"> <section anchor="compromise-of-the-authentication-with-access-to-a-signa ture-key">
<name>Compromise of the authentication with access to a signature key< /name> <name>Compromise of Authentication with Access to a Signature Key</nam e>
<t>The difference between having access to the value of the signature key and only <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 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 network attacker to perform different operations during the time of the
compromise, the attacker can perform every operation available to a legitimate compromise; the attacker can perform every operation available to a legitimate
client in both cases.</t> client in both cases.</t>
<t>There is a significant difference, however in terms of recovery aft er a <t>There is a significant difference, however, in terms of recovery af ter a
compromise.</t> compromise.</t>
<t>Because of the PCS guarantees provided by the MLS protocol, when a previously <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 compromised client recovers from compromise and performs an honest Commit, both
secrecy and authentication of future messages can be recovered as long as the 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 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 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 compromised party, even if they still have control over some group keys by
colluding with other members of the group.</t> colluding with other members of the group.</t>
<t>This is in contrast with the case where the signature key is leaked . In that <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 case, the compromised endpoint needs to refresh its credentials and invalidate
the old credentials before the attacker will be unable to authenticate messages. </t> 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 adapti ve attacker <t>Beware that in both oracle and private key access, an active adapti ve attacker
can follow the protocol and request to update its own credential. This in turn 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 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 the full value of the private key, depending on the architecture of the service
provider.</t> provider.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Signature private k
<li> eys should be compartmentalized from
<t><strong>RECOMMENDATION:</strong> Signature private keys should other secrets and preferably protected by a Hardware Security Module (HSM) or de
be compartmentalized from dicated hardware
other secrets and preferably protected by an HSM or dedicated hardware
features to allow recovery of the authentication for future messages after a features to allow recovery of the authentication for future messages after a
compromise.</t> compromise.
</li> </t>
</ul> <t indent="3"><strong>Recommendation:</strong> When the credential
<ul empty="true"> type supports revocation, the users of
<li>
<t><strong>RECOMMENDATION:</strong> When the credential type suppo
rts revocation, the users of
a group should check for revoked keys.</t> a group should check for revoked keys.</t>
</li>
</ul>
</section> </section>
<section anchor="security-consideration-in-the-context-of-a-full-state-c <section anchor="security-considerations-in-the-context-of-a-full-state-
ompromise"> compromise">
<name>Security consideration in the context of a full state compromise <name>Security Considerations in the Context of a Full State Compromis
</name> e</name>
<t>In real-world compromise scenarios, it is often the case that adver saries target <t>In real-world compromise scenarios, it is often the case that adver saries target
specific devices to obtain parts of the memory or even the ability to execute specific devices to obtain parts of the memory or even the ability to execute
arbitrary code in the targeted device.</t> arbitrary code in the targeted device.</t>
<t>Also, recall that in this setting, the application will often retai n the <t>Also, recall that in this setting, the application will often retai n the
unencrypted messages. If so, the adversary does not have to break encryption at 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 all to access sent and received messages. Messages may also be sent by using the
application to instruct the protocol implementation.</t> application to instruct the protocol implementation.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> If messages are sto
<li> red on the device, they should be
<t><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 protected using encryption at rest, and the keys used should be stored
securely using dedicated mechanisms on the device.</t> securely using dedicated mechanisms on the device.</t>
</li> <t indent="3"><strong>Recommendation:</strong> If the threat model
</ul> of the system includes an adversary
<ul empty="true"> that can access the messages on the device without even needing to attack
<li>
<t><strong>RECOMMENDATION:</strong> If the threat model of the sys
tem is against an adversary
which can access the messages on the device without even needing to attack
MLS, the application should delete plaintext and ciphertext messages as soon MLS, the application should delete plaintext and ciphertext messages as soon
as practical after encryption or decryption.</t> as practical after encryption or decryption.</t>
</li>
</ul>
<t>Note that this document makes a clear distinction between the way s ignature keys <t>Note that this document makes a clear distinction between the way s ignature keys
and other group shared secrets must be handled. In particular, a large set of 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 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 enclave features. This is especially true because these keys are frequently used
and changed with each message received by a client.</t> and changed with each message received by a client.</t>
<t>However, the signature private keys are mostly used by clients to s end a <t>However, the signature private keys are mostly used by clients to s end a
message. They also provide strong authentication guarantees to other clients, message. They also provide strong authentication guarantees to other clients;
hence we consider that their protection by additional security mechanisms should hence, we consider that their protection by additional security mechanisms shoul
d
be a priority.</t> be a priority.</t>
<t>Overall there is no way to detect or prevent these compromises, as <t>Overall, there is no way to detect or prevent these compromises, as
discussed in discussed in
the previous sections, performing separation of the application secret states the previous sections: Performing separation of the application secret states
can help recovery after compromise, this is the case for signature keys but can help recovery after compromise; this is the case for signature keys, but
similar concern exists for client's encryption private keys.</t> similar concerns exist for a client's encryption private keys.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> The secret keys use
<li> d for public key encryption should be
<t><strong>RECOMMENDATION:</strong> The secret keys used for publi
c key encryption should be
stored similarly to the way the signature keys are stored, as keys can be used 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 decrypt the group operation messages and contain the secret material used
to compute all the group secrets.</t> to compute all the group secrets.</t>
</li> <t>Even if secure enclaves are not perfectly secure or are even comple
</ul> tely broken,
<t>Even if secure enclaves are not perfectly secure, or even completel
y broken,
adopting additional protections for these keys can ease recovery of the secrecy adopting additional protections for these keys can ease recovery of the secrecy
and authentication guarantees after a compromise where, for instance, an and authentication guarantees after a compromise where, for instance, an
attacker can sign messages without having access to the key. In certain 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 contexts, the rotation of credentials might only be triggered by the AS through
ACLs, hence be outside of the capabilities of the attacker.</t> ACLs and hence be beyond the capabilities of the attacker.</t>
</section> </section>
</section> </section>
<section anchor="service-node-compromise"> <section anchor="service-node-compromise">
<name>Service Node Compromise</name> <name>Service Node Compromise</name>
<section anchor="general-considerations"> <section anchor="general-considerations">
<name>General considerations</name> <name>General Considerations</name>
<section anchor="privacy-of-the-network-connections"> <section anchor="privacy-of-the-network-connections">
<name>Privacy of the network connections</name> <name>Privacy of the Network Connections</name>
<t>There are many scenarios leading to communication between the app lication on a <t>There are many scenarios leading to communication between the app lication on a
device and the Delivery Service or the Authentication Service. In particular device and the DS or the AS. In particular,
when:</t> when:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The application connects to the Authentication Service to gen erate or validate <t>The application connects to the AS to generate or validate
a new credential before distributing it.</t> a new credential before distributing it.</t>
</li> </li>
<li> <li>
<t>The application fetches credentials at the Delivery Service p rior to creating <t>The application fetches credentials at the DS prior to creati ng
a messaging group (one-to-one or more than two clients).</t> a messaging group (one-to-one or more than two clients).</t>
</li> </li>
<li> <li>
<t>The application fetches service provider information or messa ges on the <t>The application fetches service provider information or messa ges on the
Delivery Service.</t> DS.</t>
</li> </li>
<li> <li>
<t>The application sends service provider information or message s to the Delivery <t>The application sends service provider information or message s to the Delivery
Service.</t> Service.</t>
</li> </li>
</ul> </ul>
<t>In all these cases, the application will often connect to the dev ice via a <t>In all these cases, the application will often connect to the dev ice via a
secure transport which leaks information about the origin of the request such as secure transport which leaks information about the origin of the request, such a
the IP address and depending on the protocol the MAC address of the device.</t> s
<t>Similar concerns exist in the peer-to-peer use cases of MLS.</t> the IP address and -- depending on the protocol -- the MAC address of the device
<ul empty="true"> .</t>
<li> <t>Similar concerns exist in the peer-to-peer use cases for MLS.</t>
<t><strong>RECOMMENDATION:</strong> In the case where privacy or <t indent="3"><strong>Recommendation:</strong> In the case where
anonymity is privacy or anonymity is
important, using adequate protection such as MASQUE important, using adequate protection such as Multiplexed Application Substrate o
<xref target="I-D.schinazi-masque-proxy"/>, ToR, or a VPN can improve metadata ver QUIC Encryption (MASQUE)
protection.</t> <xref target="I-D.schinazi-masque-proxy"/>, Tor <xref target="Tor"/>, or a VPN c
</li> an improve metadata
</ul> protection.
<t>More generally, using anonymous credentials in an MLS based archi </t>
tecture might <t>More generally, using anonymous credentials in an MLS-based archi
tecture might
not be enough to provide strong privacy or anonymity properties.</t> not be enough to provide strong privacy or anonymity properties.</t>
</section> </section>
<section anchor="storage-of-metadata-and-ecryption-at-rest-on-the-serv <section anchor="storage-of-metadata-and-encryption-at-rest-on-the-ser
ers"> vers">
<name>Storage of Metadata and Ecryption at rest on the Servers</name <name>Storage of Metadata and Encryption at Rest on the Servers</nam
> e>
<t>In the case where private data or metadata has to be persisted on the servers <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 for functionality (mappings between identities and push tokens, group
metadata...), it should be stored encrypted at rest and only decrypted upon need metadata, etc.), it should be stored encrypted at rest and only decrypted upon n
during the execution. Honest Service Providers can rely on such encryption at eed
rest mechanism to be able to prevent access to the data when not using it.</t> during the execution. Honest service providers can rely on such "encryption at
<ul empty="true"> rest" mechanisms to be able to prevent access to the data when not using it.</t>
<li> <t indent="3"><strong>Recommendation:</strong> Store cryptograph
<t><strong>RECOMMENDATION:</strong> Store cryptographic material ic material used for server-side
used for server-side decryption of sensitive metadata on the clients and only send it when needed.
decryption of sensitive meta-data on the clients and only send it when needed.
The server can use the secret to open and update encrypted data containers 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 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> which case those can be provided by the client.</t>
</li> <t indent="3"><strong>Recommendation:</strong> Rely on group sec
</ul> rets exported from the MLS session for
<ul empty="true">
<li>
<t><strong>RECOMMENDATION:</strong> Rely on group secrets export
ed from the MLS session for
server-side encryption at rest and update the key after each removal from the server-side encryption at rest and update the key after each removal from the
group. Rotate those keys on a regular basis otherwise.</t> group. Otherwise, rotate those keys on a regular basis.</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="delivery-service-compromise"> <section anchor="delivery-service-compromise">
<name>Delivery Service Compromise</name> <name>Delivery Service Compromise</name>
<t>MLS is intended to provide strong guarantees in the face of comprom ise of the <t>MLS is intended to provide strong guarantees in the face of comprom ise of the
DS. Even a totally compromised DS should not be able to read messages or inject 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 messages that will be acceptable to legitimate clients. It should also not b
able to undetectably remove, reorder or replay messages.</t> e
able to undetectably remove, reorder, or replay messages.</t>
<t>However, a malicious DS can mount a variety of DoS attacks on the s ystem, <t>However, a malicious DS can mount a variety of DoS attacks on the s ystem,
including total DoS attacks (where it simply refuses to forward any messages) 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 and partial DoS attacks (where it refuses to forward messages to and from
specific clients). As noted in <xref target="delivery-guarantees"/>, these atta cks are only specific clients). As noted in <xref target="delivery-guarantees"/>, these atta cks are only
partially detectable by clients without an out-of-band channel. Ultimately, 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 failure of the DS to provide reasonable service must be dealt with as a customer
service matter, not via technology.</t> service matter, not via technology.</t>
<t>Because the DS is responsible for providing the initial keying mate rial to <t>Because the DS is responsible for providing the initial keying mate rial to
clients, it can provide stale keys. This does not inherently lead to compromise clients, it can provide stale keys. This does not inherently lead to compromise
of the message stream, but does allow it to attack forward security to a limited of the message stream, but does allow the DS to attack post-compromise security to a limited
extent. This threat can be mitigated by having initial keys expire.</t> extent. This threat can be mitigated by having initial keys expire.</t>
<t>Initial keying material (KeyPackages) using the <tt>basic</tt> Cred ential type is more <t>Initial keying material (KeyPackages) using the <tt>basic</tt> cred ential type is more
vulnerable to replacement by a malicious or compromised DS, as there is no 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 built-in cryptographic binding between the identity and the public key of the
client.</t> client.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Prefer a credential
<li> type in KeyPackages which includes a
<t><strong>RECOMMENDATION:</strong> Prefer a Credential type in Ke strong cryptographic binding between the identity and its key (for example, the
yPackages which includes a <tt>x509</tt> credential type). When using the <tt>basic</tt> credential type, t
strong cryptographic binding between the identity and its key (for example the ake extra
<tt>x509</tt> Credential type). When using the <tt>basic</tt> Credential type ta care to verify the identity (typically out of band).</t>
ke extra
care to verify the identity (typically out-of-band).</t>
</li>
</ul>
<section anchor="privacy-of-delivery-and-push-notifications"> <section anchor="privacy-of-delivery-and-push-notifications">
<name>Privacy of delivery and push notifications</name> <name>Privacy of Delivery and Push Notifications</name>
<t>An important mechanism that is often ignored from the privacy con <t>Push tokens provide an important mechanism that is often ignored
siderations are from the standpoint of privacy considerations. In many modern messaging architec
the push-tokens. In many modern messaging architectures, applications are using tures, applications are using
push notification mechanisms typically provided by OS vendors. This is to make push notification mechanisms typically provided by OS vendors. This is to make
sure that when messages are available at the Delivery Service (or by other sure that when messages are available at the DS (or via other
mechanisms if the DS is not a central server), the recipient application on a 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 device knows about it. Sometimes the push notification can contain the
application message itself which saves a round trip with the DS.</t> application message itself, which saves a round trip with the DS.</t>
<t>To "push" this information to the device, the service provider an d the OS <t>To "push" this information to the device, the service provider an d the OS
infrastructures use unique per-device, per-application identifiers called infrastructures use unique per-device, per-application identifiers called
push-tokens. This means that the push notification provider and the service push tokens. This means that the push notification provider and the service
provider have information on which devices receive information and at which provider have information on which devices receive information and at which
point in time. Alternatively, non-mobile applications could use a websocket or point in time. Alternatively, non-mobile applications could use a WebSocket or
persistent connection for notifications directly from the DS.</t> persistent connection for notifications directly from the DS.</t>
<t>Even though they can't necessarily access the content, which is t <t>Even though the service provider and the push notification provid
ypically er
encrypted MLS messages, the service provider and the push notification provider can't necessarily access the content (typically encrypted MLS
have to be trusted to avoid making correlation on which devices are recipients messages), no technical mechanism in MLS prevents them from determining
of the same message.</t> which devices are recipients of the same message.</t>
<t>For secure messaging systems, push notifications are often sent r <t>For secure messaging systems, push notifications are often sent i
eal-time as it n real time, as it
is not acceptable to create artificial delays for message retrieval.</t> is not acceptable to create artificial delays for message retrieval.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> If real-time noti
<li> fications are not necessary, one can
<t><strong>RECOMMENDATION:</strong> If real time notifications a
re not necessary, one can
delay notifications randomly across recipient devices using a mixnet or other delay notifications randomly across recipient devices using a mixnet or other
techniques.</t> techniques.</t>
</li> <t>Note that with a legal request to ask the service provider for th
</ul> e push token
<t>Note that with a legal request to ask the service provider for th
e push-token
associated with an identifier, it is easy to correlate the token with a second 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 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 about the device, which is often linked with a real identity via a cloud
account, a credit card or other information.</t> account, a credit card, or other information.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> If stronger priva
<li> cy guarantees are needed with regard to
<t><strong>RECOMMENDATION:</strong> If stronger privacy guarante
es are needed with regard to
the push notification provider, the client can choose to periodically connect the push notification provider, the client can choose to periodically connect
to the Delivery Service without the need of a dedicated push notification to the DS without the need of a dedicated push notification
infrastructure.</t> infrastructure.</t>
</li>
</ul>
<t>Applications can also consider anonymous systems for server fanou t (for <t>Applications can also consider anonymous systems for server fanou t (for
example <xref target="Loopix"/>).</t> example, <xref target="Loopix"/>).</t>
</section> </section>
</section> </section>
<section anchor="as-compromise"> <section anchor="as-compromise">
<name>Authentication Service Compromise</name> <name>Authentication Service Compromise</name>
<t>The Authentication Service design is left to the infrastructure des igners. In <t>The Authentication Service design is left to the infrastructure des igners. In
most designs, a compromised AS is a serious matter, as the AS can serve most designs, a compromised AS is a serious matter, as the AS can serve
incorrect or attacker-provided identities to clients.</t> incorrect or attacker-provided identities to clients.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The attacker can link an identity to a credential</t> <t>The attacker can link an identity to a credential.</t>
</li> </li>
<li> <li>
<t>The attacker can generate new credentials</t> <t>The attacker can generate new credentials.</t>
</li> </li>
<li> <li>
<t>The attacker can sign new credentials</t> <t>The attacker can sign new credentials.</t>
</li> </li>
<li> <li>
<t>The attacker can publish or distribute credentials</t> <t>The attacker can publish or distribute credentials.</t>
</li> </li>
</ul> </ul>
<t>An attacker that can generate or sign new credentials may or may no t have access <t>An attacker that can generate or sign new credentials may or may no t have access
to the underlying cryptographic material necessary to perform such to the underlying cryptographic material necessary to perform such
operations. In that last case, it results in windows of time for which all operations. In that last case, it results in windows of time for which all
emitted credentials might be compromised.</t> emitted credentials might be compromised.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Use HSMs to store t
<li> he root signature keys to limit the
<t><strong>RECOMMENDATION:</strong> Use HSMs to store the root sig
nature keys to limit the
ability of an adversary with no physical access to extract the top-level ability of an adversary with no physical access to extract the top-level
signature private key.</t> signature private key.</t>
</li>
</ul>
<t>Note that historically some systems generate signature keys on the <t>Note that historically some systems generate signature keys on the
Authentication Service and distribute the private keys to clients along with AS and distribute the private keys to clients along with
their credential. This is a dangerous practice because it allows the AS or an 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> attacker who has compromised the AS to silently impersonate the client.</t>
<section anchor="authentication-compromise-ghost-users-and-impersonati ons"> <section anchor="authentication-compromise-ghost-users-and-impersonati ons">
<name>Authentication compromise: Ghost users and impersonations</nam <name>Authentication Compromise: Ghost Users and Impersonation</name
e> >
<t>One important property of MLS is that all Members know which othe <t>One important property of MLS is that all members know which othe
r members are r members are
in the group at all times. If all Members of the group and the Authentication in the group at all times. If all members of the group and the AS
Service are honest, no parties other than the members of the current group can 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> read and write messages protected by the protocol for that group.</t>
<t>This guarantee applies to the cryptographic identities of the mem bers. <t>This guarantee applies to the cryptographic identities of the mem bers.
Details about how to verify the identity of a client depend on the MLS Details about how to verify the identity of a client depend on the MLS
Credential type used. For example, cryptographic verification of credentials can credential type used. For example, cryptographic verification of credentials can
be largely performed autonomously (e.g., without user interaction) by the be largely performed autonomously (e.g., without user interaction) by the
clients themselves for the <tt>x509</tt> Credential type.</t> clients themselves for the <tt>x509</tt> credential type.</t>
<t>In contrast, when MLS clients use the <tt>basic</tt> Credential t <t>In contrast, when MLS clients use the <tt>basic</tt> credential t
ype, then some other ype, some other
mechanism must be used to verify identities. For instance the Authentication mechanism must be used to verify identities. For instance, the Authentication
Service could operate some sort of directory server to provide keys, or users Service could operate some sort of directory server to provide keys, or users
could verify keys via an out-of-band mechanism.</t> could verify keys via an out-of-band mechanism.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Select the MLS cr
<li> edential type with the strongest security
<t><strong>RECOMMENDATION:</strong> Select the MLS Credential ty
pe with the strongest security
which is supported by all target members of an MLS group.</t> which is supported by all target members of an MLS group.</t>
</li> <t indent="3"><strong>Recommendation:</strong> Do not use the sa
</ul> me signature key pair across
<ul empty="true">
<li>
<t><strong>RECOMMENDATION:</strong> Do not use the same signatur
e keypair across
groups. Update all keys for all groups on a regular basis. Do not preserve groups. Update all keys for all groups on a regular basis. Do not preserve
keys in different groups when suspecting a compromise.</t> keys in different groups when suspecting a compromise.</t>
</li> <t>If the AS is compromised, it could validate a signature
</ul> key pair (or generate a new one) for an attacker. The attacker could then use th
<t>If the AS is compromised, it could validate a (or generate a new) is key pair to join a
signature
keypair 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 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 MLS clients running the MLS protocol, it possibly has many signature key pairs
for multiple devices. These attacks could be very difficult to detect, 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 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 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 which it is possible to determine every key for a given user, then this
would allow for detection of surreptitiously created false credentials.</t> would allow for detection of surreptitiously created false credentials.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Make sure that ML
<li> S clients reflect all the membership
<t><strong>RECOMMENDATION:</strong> Make sure that MLS clients r
eflect all the membership
changes to the users as they happen. If a choice has to be made because the 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 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> of the device so that the user can examine it.</t>
</li> <t indent="3"><strong>Recommendation:</strong> Provide a key tra
</ul> nsparency mechanism for the
<ul empty="true"> AS to allow public verification of the credentials
<li>
<t><strong>RECOMMENDATION:</strong> Provide a key transparency m
echanism for the
Authentication Services to allow public verification of the credentials
authenticated by this service.</t> authenticated by this service.</t>
</li>
</ul>
<t>While the ways to handle MLS credentials are not defined by the p rotocol or the <t>While the ways to handle MLS credentials are not defined by the p rotocol or the
architecture documents, the MLS protocol has been designed with a mechanism that architecture documents, the MLS protocol has been designed with a mechanism that
can be used to provide out-of-band authentication to users. The 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 <tt>authentication_secret</tt> generated for each user at each epoch of the grou
one-time, per client, authentication secret which can be exchanged between users p is a
to prove their identity to each other. This can be done for instance using a QR one-time, per-client authentication secret which can be exchanged between users
code that can be scanned by the other parties.</t> to prove their identities to each other. This can be done, for instance, using a
<ul empty="true"> QR
<li> code that can be scanned by the other parties.
<t><strong>RECOMMENDATION:</strong> Provide one or more out-of-b </t>
and authentication mechanisms <t indent="3"><strong>Recommendation:</strong> Provide one or mo
to limit the impact of an Authentication Service compromise.</t> re out-of-band authentication mechanisms
</li> to limit the impact of an AS compromise.</t>
</ul> <t>We note, again, that the AS may not be a centralized
<t>We note, again, that the Authentication Service may not be a cent system and could be realized by many mechanisms such as establishing prior
ralized
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 one-to-one deniable channels, gossiping, or using trust on first use (TOFU) for
credentials used by the MLS Protocol.</t> credentials used by the MLS protocol.</t>
<t>Another important consideration is the ease of redistributing new keys on client <t>Another important consideration is the ease of redistributing new keys on client
compromise, which helps recovering security faster in various cases.</t> compromise, which helps recovering security faster in various cases.</t>
</section> </section>
<section anchor="privacy-of-the-group-membership"> <section anchor="privacy-of-the-group-membership">
<name>Privacy of the Group Membership</name> <name>Privacy of the Group Membership</name>
<t>Group membership is itself sensitive information and MLS is desig ned to limit <t>Group membership is itself sensitive information, and MLS is desi gned to limit
the amount of persistent metadata. However, large groups often require an the amount of persistent metadata. However, large groups often require an
infrastructure which provides server fanout. In the case of client fanout, the 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 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 not need this information. However, servers may learn this information through
traffic analysis. Unfortunately, in a server-side fanout model, the Delivery 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 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 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.</ membership list is stored on some server associated with the DS.
t> </t>
<t>While this knowledge is not a breach of the protocol's authentica tion or <t>While this knowledge is not a breach of the protocol's authentica tion or
confidentiality guarantees, it is a serious issue for privacy.</t> confidentiality guarantees, it is a serious issue for privacy.</t>
<t>Some infrastructure keep a mapping between keys used in the MLS p rotocol and <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 user identities. An attacker with access to this information due to compromise
or regulation can associate unencrypted group messages (e.g., Commits and or regulation can associate unencrypted group messages (e.g., Commits and
Proposals) with the corresponding user identity.</t> Proposals) with the corresponding user identity.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Use encrypted gro
<li> up operation messages to limit privacy
<t><strong>RECOMMENDATION:</strong> Use encrypted group operatio
n messages to limit privacy
risks whenever possible.</t> risks whenever possible.</t>
</li>
</ul>
<t>In certain cases, the adversary can access specific bindings betw een public keys <t>In certain cases, the adversary can access specific bindings betw een public keys
and identities. If the signature keys are reused across groups, the adversary and identities. If the signature keys are reused across groups, the adversary
can get more information about the targeted user.</t> can get more information about the targeted user.</t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Ensure that linki
<li> ng between public keys and identities
<t><strong>RECOMMENDATION:</strong> Ensure that linking between
public keys and identities
only happens in expected scenarios.</t> only happens in expected scenarios.</t>
</li>
</ul>
</section> </section>
</section> </section>
</section> </section>
<section anchor="considerations-for-attacks-outside-of-the-threat-model"> <section anchor="considerations-for-attacks-outside-of-the-threat-model">
<name>Considerations for attacks outside of the threat model</name> <name>Considerations for Attacks Outside of the Threat Model</name>
<t>Physical attacks on devices storing and executing MLS principals are not <t>Physical attacks on devices storing and executing MLS principals are not
considered in depth in the threat model of the MLS protocol. While considered in depth in the threat model of the MLS protocol. While
non-permanent, non-invasive attacks can sometimes be equivalent to software non-permanent, non-invasive attacks can sometimes be equivalent to software
attacks, physical attacks are considered outside of the MLS threat model.</t> attacks, physical attacks are considered outside of the MLS threat model.</t>
<t>Compromise scenarios typically consist of a software adversary, which can <t>Compromise scenarios typically consist of a software adversary, which can
maintain active adaptive compromise and arbitrarily change the behavior of the maintain active adaptive compromise and arbitrarily change the behavior of the
client or service.</t> client or service.</t>
<t>On the other hand, security goals consider that honest clients will a lways run <t>On the other hand, security goals consider that honest clients will a lways run
the protocol according to its specification. This relies on implementations of the protocol according to its specification. This relies on implementations of
the protocol to securely implement the specification, which remains non-trivial. </t> the protocol to securely implement the specification, which remains non-trivial. </t>
<ul empty="true"> <t indent="3"><strong>Recommendation:</strong> Additional steps shou
<li> ld be taken to protect the device and
<t><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 the MLS clients from physical compromise. In such settings, HSMs and secure
enclaves can be used to protect signature keys.</t> enclaves can be used to protect signature keys.</t>
</li>
</ul>
</section> </section>
<section anchor="no-protection-against-replay-by-insiders">
<name>No Protection Against Replay by Insiders</name>
<t>MLS does not protect against one group member replaying a PrivateMessag
e sent by another
group member within the same epoch that the message was originally sent. Similar
ly, MLS
does not protect against the replay (by a group member or otherwise) of a Public
Message
within the same epoch that the message was originally sent. Applications for
whom replay is an important risk should apply mitigations at the application lay
er, as
discussed below.</t>
<t>In addition to the risks discussed in <xref target="symmetric-key-compr
omise"/>, an attacker
with access to the ratchet secrets for an endpoint can replay PrivateMessage
objects sent by other members of the group by taking the signed content of the
message and re-encrypting it with a new generation of the original sender's
ratchet. If the other members of the group interpret a message with a new
generation as a fresh message, then this message will appear fresh. (This is
possible because the message signature does not cover the <tt>generation</tt> fi
eld
of the message.) Messages sent as PublicMessage objects similarly lack replay
protections. There is no message counter comparable to the <tt>generation</tt>
field
in PrivateMessage.</t>
<t>Applications can detect replay by including a unique identifier for the
message
(e.g., a counter) in either the message payload or the <tt>authenticated_data</t
t>
field, both of which are included in the signatures for
PublicMessage and PrivateMessage.</t></section>
<section anchor="cryptographic-analysis-of-the-mls-protocol"> <section anchor="cryptographic-analysis-of-the-mls-protocol">
<name>Cryptographic Analysis of the MLS Protocol</name> <name>Cryptographic Analysis of the MLS Protocol</name>
<t>Various academic works have analyzed MLS and the different security g uarantees <t>Various academic works have analyzed MLS and the different security g uarantees
it aims to provide. The security of large parts of the protocol has been it aims to provide. The security of large parts of the protocol has been
analyzed by <xref target="BBN19"/> (draft 7), <xref target="ACDT21"/> (draft 11) analyzed by <xref target="BBN19"/> (for MLS Draft 7), <xref target="ACDT
and <xref target="AJM20"/> (draft 12).</t> 21"/> (for MLS Draft 11), and <xref target="AJM20"/> (for MLS Draft 12).</t>
<t>Individual components of various drafts of the MLS protocol have been <t>Individual components of various drafts of the MLS protocol have been
analyzed analyzed in isolation and with differing adversarial models. For
in isolation and with differing adversarial models, for example, <xref target="B example, <xref target="BBR18"/>, <xref target="ACDT19"/>, <xref target="ACCKKMPP
BR18"/>, WY19"/>, <xref target="AJM20"/>,
<xref target="ACDT19"/>, <xref target="ACCKKMPPWY19"/>, <xref target="AJM20"/>, <xref target="ACJM20"/>, <xref target="AHKM21"/>, <xref target="CGWZ25"/>, and <
<xref target="ACJM20"/>, and <xref target="AHKM21"/> analyze the xref target="WPB25"/> analyze the
ratcheting tree sub-protocol of MLS that facilitates key agreement, <xref target ratcheting tree sub-protocol of MLS that facilitates key agreement;
="WPBB22"/> <xref target="WPBB22"/> analyzes the sub-protocol of MLS for group state agreeme
analyzes the sub-protocol of MLS for group state agreement and authentication, nt
while <xref target="BCK21"/> analyzes the key derivation paths in the ratchet tr and authentication; and <xref target="BCK21"/> analyzes the key derivation paths
ee and key in
schedule. Finally, <xref target="CHK21"/> analyzes the authentication and cross- the ratchet tree and key schedule. Finally, <xref target="CHK21"/> analyzes the
group healing authentication and cross-group healing guarantees provided by MLS.</t>
guarantees provided by MLS.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes no requests of IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <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"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="I-D.ietf-mls-protocol">
<front> <!-- draft-ietf-mls-protocol (RFC 9420; published) -->
<title>The Messaging Layer Security (MLS) Protocol</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="Richard Barnes" initials="R." surname="Barnes"> 420.xml"/>
<organization>Cisco</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
</author> 116.xml"/>
<author fullname="Benjamin Beurdouche" initials="B." surname="Beurdo
uche">
<organization>Inria &amp; Mozilla</organization>
</author>
<author fullname="Raphael Robert" initials="R." surname="Robert">
<organization>Phoenix R&amp;D</organization>
</author>
<author fullname="Jon Millican" initials="J." surname="Millican">
<organization>Meta Platforms</organization>
</author>
<author fullname="Emad Omara" initials="E." surname="Omara">
<organization>Google</organization>
</author>
<author fullname="Katriel Cohn-Gordon" initials="K." surname="Cohn-G
ordon">
<organization>University of Oxford</organization>
</author>
<date day="27" month="March" year="2023"/>
<abstract>
<t>Messaging applications are increasingly making use of end-to-en
d security mechanisms to ensure that messages are only accessible to the communi
cating endpoints, and not to any servers involved in delivering messages. Estab
lishing keys to provide such protections is challenging for group chat settings,
in which more than two clients need to agree on a key but may not be online at
the same time. In this document, we specify a key establishment protocol that p
rovides efficient asynchronous group key establishment with forward secrecy (FS)
and post-compromise security (PCS) for groups in size ranging from two to thous
ands.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mls-protocol-20"/>
</reference>
<reference anchor="RFC9420">
<front>
<title>The Messaging Layer Security (MLS) Protocol</title>
<author fullname="R. Barnes" initials="R." surname="Barnes"/>
<author fullname="B. Beurdouche" initials="B." surname="Beurdouche"/
>
<author fullname="R. Robert" initials="R." surname="Robert"/>
<author fullname="J. Millican" initials="J." surname="Millican"/>
<author fullname="E. Omara" initials="E." surname="Omara"/>
<author fullname="K. Cohn-Gordon" initials="K." surname="Cohn-Gordon
"/>
<date month="July" year="2023"/>
<abstract>
<t>Messaging applications are increasingly making use of end-to-en
d security mechanisms to ensure that messages are only accessible to the communi
cating endpoints, and not to any servers involved in delivering messages. Establ
ishing keys to provide such protections is challenging for group chat settings,
in which more than two clients need to agree on a key but may not be online at t
he same time. In this document, we specify a key establishment protocol that pro
vides efficient asynchronous group key establishment with forward secrecy (FS) a
nd post-compromise security (PCS) for groups in size ranging from two to thousan
ds.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9420"/>
<seriesInfo name="DOI" value="10.17487/RFC9420"/>
</reference>
<reference anchor="RFC5116">
<front>
<title>An Interface and Algorithms for Authenticated Encryption</tit
le>
<author fullname="D. McGrew" initials="D." surname="McGrew"/>
<date month="January" year="2008"/>
<abstract>
<t>This document defines algorithms for Authenticated Encryption w
ith Associated Data (AEAD), and defines a uniform interface and a registry for s
uch algorithms. The interface and registry can be used as an application-indepen
dent set of cryptoalgorithm suites. This approach provides advantages in efficie
ncy and security, and promotes the reuse of crypto implementations. [STANDARDS-T
RACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5116"/>
<seriesInfo name="DOI" value="10.17487/RFC5116"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="KT">
<front>
<title>Key Transparency Architecture</title>
<author fullname="Brendan McMillion" initials="B." surname="McMillio
n">
</author>
<date day="4" month="March" year="2024"/>
<abstract>
<t> This document defines the terminology and interaction patter
ns
involved in the deployment of Key Transparency (KT) in a general
secure group messaging infrastructure, and specifies the security
properties that the protocol provides. It also gives more general,
non-prescriptive guidance on how to securely apply KT to a number of
common applications.
</t> <!-- draft-ietf-keytrans-architecture (I-D Exists) -->
</abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
</front> .ietf-keytrans-architecture.xml"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-keytrans-architect
ure-01"/> <reference anchor="CAPBR" target="https://dl.acm.org/doi/10.1145/343477.
</reference> 343502">
<reference anchor="CONIKS" target="https://www.usenix.org/system/files/c
onference/usenixsecurity15/sec15-paper-melara.pdf">
<front>
<title>CONIKS: Bringing Key Transparency to End Users</title>
<author initials="M." surname="Melara" fullname="Marcela Melara">
<organization/>
</author>
<author initials="A." surname="Blankstein" fullname="Aaron Blankstei
n">
<organization/>
</author>
<author initials="J." surname="Bonneau" fullname="Joseph Bonneau">
<organization/>
</author>
<author initials="E." surname="Felten" fullname="Edward Felten">
<organization/>
</author>
<author initials="M." surname="Freedman" fullname="Michael Freedman"
>
<organization/>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="CAPBR">
<front> <front>
<title>Towards robust distributed systems (abstract)</title> <title>Towards robust distributed systems (abstract)</title>
<author fullname="Eric A. Brewer" initials="E." surname="Brewer"> <author fullname="Eric A. Brewer" initials="E. A." surname="Brewer">
<organization>UC Berkeley and Inktomi</organization> <organization>UC Berkeley and Inktomi</organization>
</author> </author>
<date month="July" year="2000"/> <date month="July" year="2000"/>
</front> </front>
<seriesInfo name="Proceedings of the nineteenth annual ACM symposium o n Principles of distributed" value="computing"/> <refcontent>Proceedings of the nineteenth annual ACM symposium on Prin ciples of distributed computing, p. 7</refcontent>
<seriesInfo name="DOI" value="10.1145/343477.343502"/> <seriesInfo name="DOI" value="10.1145/343477.343502"/>
<refcontent>ACM</refcontent>
</reference> </reference>
<reference anchor="ACCKKMPPWY19" target="https://eprint.iacr.org/2019/14 89"> <reference anchor="ACCKKMPPWY19" target="https://eprint.iacr.org/2019/14 89">
<front> <front>
<title>Keep the Dirt: Tainted TreeKEM, Adaptively and Actively Secur e Continuous Group Key Agreement</title> <title>Keep the Dirt: Tainted TreeKEM, Adaptively and Actively Secur e Continuous Group Key Agreement</title>
<author initials="J." surname="Alwen" fullname="Joel Alwen"> <author initials="J." surname="Alwen" fullname="Joel Alwen">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Capretto" fullname="Margarita Caprett o"> <author initials="M." surname="Capretto" fullname="Margarita Caprett o">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Cueto" fullname="Miguel Cueto"> <author initials="M." surname="Cueto" fullname="Miguel Cueto">
skipping to change at line 2347 skipping to change at line 2168
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Walter" fullname="Michael Walter"> <author initials="M." surname="Walter" fullname="Michael Walter">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Yeo" fullname="Michelle Yeo"> <author initials="M." surname="Yeo" fullname="Michelle Yeo">
<organization/> <organization/>
</author> </author>
<date year="2019"/> <date year="2019"/>
</front> </front>
<refcontent>Cryptology ePrint Archive</refcontent>
</reference> </reference>
<reference anchor="ACDT19" target="https://eprint.iacr.org/2019/1189.pdf "> <reference anchor="ACDT19" target="https://eprint.iacr.org/2019/1189.pdf ">
<front> <front>
<title>Security Analysis and Improvements for the IETF MLS Standard for Group Messaging</title> <title>Security Analysis and Improvements for the IETF MLS Standard for Group Messaging</title>
<author initials="J." surname="Alwen" fullname="Joel Alwen"> <author initials="J." surname="Alwen" fullname="Joel Alwen">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Coretti" fullname="Sandro Coretti"> <author initials="S." surname="Coretti" fullname="Sandro Coretti">
<organization/> <organization/>
</author> </author>
<author initials="Y." surname="Dodis" fullname="Yevgeniy Dodis"> <author initials="Y." surname="Dodis" fullname="Yevgeniy Dodis">
<organization/> <organization/>
</author> </author>
<author initials="Y." surname="Tselekounis" fullname="Yiannis Tselek ounis"> <author initials="Y." surname="Tselekounis" fullname="Yiannis Tselek ounis">
<organization/> <organization/>
</author> </author>
<date year="2019"/> <date year="2019"/>
</front> </front>
<refcontent>Cryptology ePrint Archive</refcontent>
</reference> </reference>
<reference anchor="ACDT21" target="https://eprint.iacr.org/2021/1083.pdf "> <reference anchor="ACDT21" target="https://eprint.iacr.org/2021/1083.pdf ">
<front> <front>
<title>Modular Design of Secure Group Messaging Protocols and the Se curity of MLS</title> <title>Modular Design of Secure Group Messaging Protocols and the Se curity of MLS</title>
<author initials="J." surname="Alwen" fullname="Joel Alwen"> <author initials="J." surname="Alwen" fullname="Joel Alwen">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Coretti" fullname="Sandro Coretti"> <author initials="S." surname="Coretti" fullname="Sandro Coretti">
<organization/> <organization/>
</author> </author>
<author initials="Y." surname="Dodis" fullname="Yevgeniy Dodis"> <author initials="Y." surname="Dodis" fullname="Yevgeniy Dodis">
<organization/> <organization/>
</author> </author>
<author initials="Y." surname="Tselekounis" fullname="Yiannis Tselek ounis"> <author initials="Y." surname="Tselekounis" fullname="Yiannis Tselek ounis">
<organization/> <organization/>
</author> </author>
<date year="2021"/> <date year="2021"/>
</front> </front>
<refcontent>Cryptology ePrint Archive</refcontent>
</reference> </reference>
<reference anchor="ACJM20" target="https://eprint.iacr.org/2020/752.pdf" > <reference anchor="ACJM20" target="https://eprint.iacr.org/2020/752.pdf" >
<front> <front>
<title>Continuous Group Key Agreement with Active Security</title> <title>Continuous Group Key Agreement with Active Security</title>
<author initials="J." surname="Alwen" fullname="Joel Alwen"> <author initials="J." surname="Alwen" fullname="Joel Alwen">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Coretti" fullname="Sandro Coretti"> <author initials="S." surname="Coretti" fullname="Sandro Coretti">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Jost" fullname="Daniel Jost"> <author initials="D." surname="Jost" fullname="Daniel Jost">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Mularczyk" fullname="Marta Mularczyk" > <author initials="M." surname="Mularczyk" fullname="Marta Mularczyk" >
<organization/> <organization/>
</author> </author>
<date year="2020"/> <date year="2020"/>
</front> </front>
<refcontent>Cryptology ePrint Archive</refcontent>
</reference> </reference>
<reference anchor="AHKM21" target="https://eprint.iacr.org/2021/1456.pdf "> <reference anchor="AHKM21" target="https://eprint.iacr.org/2021/1456.pdf ">
<front> <front>
<title>Server-Aided Continuous Group Key Agreement</title> <title>Server-Aided Continuous Group Key Agreement</title>
<author initials="J." surname="Alwen" fullname="Joel Alwen"> <author initials="J." surname="Alwen" fullname="Joel Alwen">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Hartmann" fullname="Dominik Hartmann" > <author initials="D." surname="Hartmann" fullname="Dominik Hartmann" >
<organization/> <organization/>
</author> </author>
<author initials="E." surname="Kiltz" fullname="Eike Kiltz"> <author initials="E." surname="Kiltz" fullname="Eike Kiltz">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Mularczyk" fullname="Marta Mularczyk" > <author initials="M." surname="Mularczyk" fullname="Marta Mularczyk" >
<organization/> <organization/>
</author> </author>
<date year="2021"/> <date year="2021"/>
</front> </front>
<refcontent>Cryptology ePrint Archive</refcontent>
</reference> </reference>
<reference anchor="AJM20" target="https://eprint.iacr.org/2020/1327.pdf" > <reference anchor="AJM20" target="https://eprint.iacr.org/2020/1327.pdf" >
<front> <front>
<title>On The Insider Security of MLS</title> <title>On The Insider Security of MLS</title>
<author initials="J." surname="Alwen" fullname="Joel Alwen"> <author initials="J." surname="Alwen" fullname="Joel Alwen">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Jost" fullname="Daniel Jost"> <author initials="D." surname="Jost" fullname="Daniel Jost">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Mularczyk" fullname="Marta Mularczyk" > <author initials="M." surname="Mularczyk" fullname="Marta Mularczyk" >
<organization/> <organization/>
</author> </author>
<date year="2020"/> <date year="2020"/>
</front> </front>
<refcontent>Cryptology ePrint Archive</refcontent>
</reference> </reference>
<reference anchor="BBN19" target="https://inria.hal.science/hal-02425229 /document"> <reference anchor="BBN19" target="https://inria.hal.science/hal-02425229 /document">
<front> <front>
<title>Formal Models and Verified Protocols for Group Messaging: Att acks and Proofs for IETF MLS</title> <title>Formal Models and Verified Protocols for Group Messaging: Att acks and Proofs for IETF MLS</title>
<author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhar gavan"> <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhar gavan">
<organization/> <organization/>
</author> </author>
<author initials="B." surname="Beurdouche" fullname="Benjamin Beurdo uche"> <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdo uche">
<organization/> <organization/>
</author> </author>
<author initials="P." surname="Naldurg" fullname="Prasad Naldurg"> <author initials="P." surname="Naldurg" fullname="Prasad Naldurg">
<organization/> <organization/>
</author> </author>
<date year="2019"/> <date year="2019"/>
</front> </front>
<seriesInfo name="HAL ID" value="hal-02425229"/>
</reference> </reference>
<reference anchor="BBR18" target="https://hal.inria.fr/hal-02425247/file /treekem+%281%29.pdf"> <reference anchor="BBR18" target="https://hal.inria.fr/hal-02425247/file /treekem+%281%29.pdf">
<front> <front>
<title>TreeKEM: Asynchronous Decentralized Key Management for Large Dynamic Groups A protocol proposal for Messaging Layer Security (MLS)</title> <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 Bhar gavan"> <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhar gavan">
<organization/> <organization/>
</author> </author>
<author initials="R." surname="Barnes" fullname="Richard Barnes"> <author initials="R." surname="Barnes" fullname="Richard Barnes">
<organization/> <organization/>
</author> </author>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla"> <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization/> <organization/>
</author> </author>
<date year="2018"/> <date year="2018"/>
</front> </front>
<seriesInfo name="HAL ID" value="hal-02425247"/>
</reference> </reference>
<reference anchor="BCK21" target="https://eprint.iacr.org/2021/137.pdf"> <reference anchor="BCK21" target="https://eprint.iacr.org/2021/137.pdf">
<front> <front>
<title>Cryptographic Security of the MLS RFC, Draft 11</title> <title>Security Analysis of the MLS Key Distribution</title>
<author initials="C." surname="Brzuska" fullname="Chris Brzuska"> <author initials="C." surname="Brzuska" fullname="Chris Brzuska">
<organization/> <organization/>
</author> </author>
<author initials="E." surname="Cornelissen" fullname="Eric Corneliss en"> <author initials="E." surname="Cornelissen" fullname="Eric Corneliss en">
<organization/> <organization/>
</author> </author>
<author initials="K." surname="Kohbrok" fullname="Konrad Kohbrok"> <author initials="K." surname="Kohbrok" fullname="Konrad Kohbrok">
<organization/> <organization/>
</author> </author>
<date year="2021"/> <date year="2021"/>
</front> </front>
<refcontent>Cryptology ePrint Archive</refcontent>
</reference> </reference>
<reference anchor="CHK21" target="https://www.usenix.org/system/files/se c21-cremers.pdf"> <reference anchor="CHK21" target="https://www.usenix.org/system/files/se c21-cremers.pdf">
<front> <front>
<title>The Complexities of Healing in Secure Group Messaging: Why Cr oss-Group Effects Matter</title> <title>The Complexities of Healing in Secure Group Messaging: Why Cr oss-Group Effects Matter</title>
<author initials="C." surname="Cremers" fullname="Cas Cremers"> <author initials="C." surname="Cremers" fullname="Cas Cremers">
<organization/> <organization/>
</author> </author>
<author initials="B." surname="Hale" fullname="Britta Hale"> <author initials="B." surname="Hale" fullname="Britta Hale">
<organization/> <organization/>
</author> </author>
<author initials="K." surname="Kohbrok" fullname="Konrad Kohbrok"> <author initials="K." surname="Kohbrok" fullname="Konrad Kohbrok">
<organization/> <organization/>
</author> </author>
<date year="2021"/> <date month="August" year="2021"/>
</front> </front>
<refcontent>Proceedings of the 30th USENIX Security Symposium</refcont ent>
</reference> </reference>
<reference anchor="WPBB22" target="https://eprint.iacr.org/2022/1732.pdf "> <reference anchor="WPBB22" target="https://eprint.iacr.org/2022/1732.pdf ">
<front> <front>
<title>TreeSync: Authenticated Group Management for Messaging Layer Security</title> <title>TreeSync: Authenticated Group Management for Messaging Layer Security</title>
<author initials="T." surname="Wallez" fullname="Théophile Wallez"> <author initials="T." surname="Wallez" fullname="Théophile Wallez">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Protzenko" fullname="Jonathan Protzen ko"> <author initials="J." surname="Protzenko" fullname="Jonathan Protzen ko">
<organization/> <organization/>
</author> </author>
<author initials="B." surname="Beurdouche" fullname="Benjamin Beurdo uche"> <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdo uche">
<organization/> <organization/>
</author> </author>
<author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhar gavan"> <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhar gavan">
<organization/> <organization/>
</author> </author>
<date year="2022"/> <date year="2022"/>
</front> </front>
<refcontent>Cryptology ePrint Archive</refcontent>
</reference> </reference>
<reference anchor="Loopix">
<reference anchor="CGWZ25" target="https://eprint.iacr.org/2025/229.pdf"
>
<front>
<title>ETK: External-Operations TreeKEM and the Security of MLS in R
FC 9420</title>
<author initials="C." surname="Cremers" fullname="Cas Cremers">
<organization/>
</author>
<author initials="E." surname="Günsay" fullname="Esra Günsay">
<organization/>
</author>
<author initials="V." surname="Wesselkamp" fullname="Vera Wesselkamp
">
<organization/>
</author>
<author initials="M." surname="Zhao" fullname="Mang Zhao">
<organization/>
</author>
<date year="2025"/>
</front>
</reference>
<reference anchor="WPB25" target="https://eprint.iacr.org/2025/410.pdf">
<front>
<title>TreeKEM: A Modular Machine-Checked Symbolic Security Analysis
of Group Key Agreement in Messaging Layer Security</title>
<author initials="T." surname="Wallez" fullname="Théophile Wallez">
<organization/>
</author>
<author initials="J." surname="Protzenko" fullname="Jonathan Protzen
ko">
<organization/>
</author>
<author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhar
gavan">
<organization/>
</author>
<date year="2025"/>
</front>
</reference>
<reference anchor="Loopix" target="">
<front> <front>
<title>The Loopix Anonymity System</title> <title>The Loopix Anonymity System</title>
<author initials="A. M." surname="Piotrowska" fullname="Ania M. Piot rowska"> <author initials="A. M." surname="Piotrowska" fullname="Ania M. Piot rowska">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Hayes" fullname="Jamie Hayes"> <author initials="J." surname="Hayes" fullname="Jamie Hayes">
<organization/> <organization/>
</author> </author>
<author initials="T." surname="Elahi" fullname="Tariq Elahi"> <author initials="T." surname="Elahi" fullname="Tariq Elahi">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Meiser" fullname="Sebastian Meiser"> <author initials="S." surname="Meiser" fullname="Sebastian Meiser">
<organization/> <organization/>
</author> </author>
<author initials="G." surname="Danezis" fullname="George Danezis"> <author initials="G." surname="Danezis" fullname="George Danezis">
<organization/> <organization/>
</author> </author>
<date year="2017"/> <date month="August" year="2017"/>
</front>
</reference>
<reference anchor="RFC6120">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</titl
e>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<date month="March" year="2011"/>
<abstract>
<t>The Extensible Messaging and Presence Protocol (XMPP) is an app
lication profile of the Extensible Markup Language (XML) that enables the near-r
eal-time exchange of structured yet extensible data between any two or more netw
ork entities. This document defines XMPP's core protocol methods: setup and tear
down of XML streams, channel encryption, authentication, error handling, and com
munication primitives for messaging, network availability ("presence"), and requ
est-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="6120"/>
<seriesInfo name="DOI" value="10.17487/RFC6120"/>
</reference>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper"/>
<author fullname="S. Santesson" initials="S." surname="Santesson"/>
<author fullname="S. Farrell" initials="S." surname="Farrell"/>
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="W. Polk" initials="W." surname="Polk"/>
<date month="May" year="2008"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
icate revocation list (CRL) for use in the Internet. An overview of this approac
h and model is provided as an introduction. The X.509 v3 certificate format is d
escribed in detail, with additional information regarding the format and semanti
cs of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="5280"/> <refcontent>Proceedings of the 26th USENIX Security Symposium</refconte
<seriesInfo name="DOI" value="10.17487/RFC5280"/> nt>
</reference> </reference>
<reference anchor="I-D.ietf-mls-extensions">
<reference anchor="Tor" target="https://torproject.org/">
<front> <front>
<title>The Messaging Layer Security (MLS) Extensions</title> <title>The Tor Project</title>
<author fullname="Raphael Robert" initials="R." surname="Robert"> <author>
<organization>Phoenix R&amp;D</organization> <organization/>
</author> </author>
<date day="24" month="April" year="2024"/>
<abstract>
<t> This document describes extensions to the Messaging Layer Se
curity
(MLS) protocol.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/mlswg/mls-extensions.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mls-extensions-04" />
</reference> </reference>
<reference anchor="I-D.ietf-mls-federation">
<front>
<title>The Messaging Layer Security (MLS) Federation</title>
<author fullname="Emad Omara" initials="E." surname="Omara">
<organization>Google</organization>
</author>
<author fullname="Raphael Robert" initials="R." surname="Robert">
<organization>Phoenix R&amp;D</organization>
</author>
<date day="9" month="September" year="2023"/>
<abstract>
<t> This document describes how the Messaging Layer Security (ML
S)
protocol can be used in a federated environment.
Discussion Venues <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.61
20.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
80.xml"/>
This note is to be removed before publishing as an RFC. <!-- draft-ietf-mls-extensions (I-D Exists) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-mls-extensions.xml"/>
Source for this draft and an issue tracker can be found at <!-- draft-ietf-mls-federation (Expired) -->
https://github.com/mlswg/mls-federation. <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-mls-federation.xml"/>
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.35
</abstract> 52.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
<seriesInfo name="Internet-Draft" value="draft-ietf-mls-federation-03" 00.xml"/>
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
</reference> 46.xml"/>
<reference anchor="RFC3552">
<front> <!-- draft-schinazi-masque-proxy (I-D Exists) -->
<title>Guidelines for Writing RFC Text on Security Considerations</t <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
itle> .schinazi-masque-proxy.xml"/>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="B. Korver" initials="B." surname="Korver"/>
<date month="July" year="2003"/>
<abstract>
<t>All RFCs are required to have a Security Considerations section
. Historically, such sections have been relatively weak. This document provides
guidelines to RFC authors on how to write a good Security Considerations section
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="72"/>
<seriesInfo name="RFC" value="3552"/>
<seriesInfo name="DOI" value="10.17487/RFC3552"/>
</reference>
<reference anchor="RFC9000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communica
tion, low-latency connection establishment, and network path migration. QUIC inc
ludes security measures that ensure confidentiality, integrity, and availability
in a range of deployment circumstances. Accompanying documents describe the int
egration of TLS for key negotiation, loss detection, and an exemplary congestion
control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="I-D.schinazi-masque-proxy">
<front>
<title>The MASQUE Proxy</title>
<author fullname="David Schinazi" initials="D." surname="Schinazi">
<organization>Google LLC</organization>
</author>
<date day="28" month="February" year="2024"/>
<abstract>
<t> MASQUE (Multiplexed Application Substrate over QUIC Encrypti
on) is a
set of protocols and extensions to HTTP that allow proxying all kinds
of Internet traffic over HTTP. This document defines the concept of
a "MASQUE Proxy", an Internet-accessible node that can relay client
traffic in order to provide privacy guarantees.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-schinazi-masque-proxy-0
2"/>
</reference>
</references> </references>
</references> </references>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse"> <section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse">
<name>Contributors</name> <name>Contributors</name>
<contact initials="R." surname="Barnes" fullname="Richard Barnes"> <contact initials="R." surname="Barnes" fullname="Richard Barnes">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<email>rlb@ipv.sx</email> <email>rlb@ipv.sx</email>
</address> </address>
</contact> </contact>
skipping to change at line 2743 skipping to change at line 2510
</address> </address>
</contact> </contact>
<contact initials="R." surname="Robert" fullname="Raphael Robert"> <contact initials="R." surname="Robert" fullname="Raphael Robert">
<organization>Phoenix R&amp;D</organization> <organization>Phoenix R&amp;D</organization>
<address> <address>
<email>ietf@raphaelrobert.com</email> <email>ietf@raphaelrobert.com</email>
</address> </address>
</contact> </contact>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA9S9/ZLbVpYn+P99CowcM1K6SMqS7a6yvOt2OlOyVbIsjVIu
T8fOhgSSYBJOEmABYKZolTrmQXYfYJ9j32SeZM/3PRcA03J3b2ysoioskcTF
/Tz3fPzO70yn09CV3aZ4lL1eF9nzom3zy7K6zH7MD0WTXRSLfVN2h+ze8x8v
TrLTZrEuu2LR7Zsi5PN5U1w/yuCb9ItlvajyLbS4bPJVNy2LbjXdbtpp7n40
ffBlWORdcVk3h0dZWa3qEMpd8yjrmn3bPfzss68+exjypsgfWR/CVXG4qZvl
o+xp1RVNVXTTc3xBCG2XV8s3+aau4KWHog278lH2v3X1YpK1ddM1xaqFvx22
+Jf/PYR8363r5lHIpiGDP2XVPsq+m2XfFftmWe8X64I+5iF8V1S/5tuy6n9b
N5d5Vf6Wd2VdYYeaMs/+S/a8/q3cbHL6RbHNyw0MDUb/7dweni3qbfLix7Ps
VdEu6kYe49c+bspF+nn6wl/KannIfoCXZReHtiu2MMAffzzzLy6umm+bbrUd
e+OLbd4kr9vmS/ehtgCfzmr89NtL/GTQ0sUMRn65v/ZNXTRlVV7nrf9G2mtL
+ujbQ76u60Fjp7PsHNZ54do63eSV+7A/BU3hW8/hx9/ewIfUcljUVdeU832H
Kz2VBl+Vi3XeLLPvctg+baAmH2VnJcxzsIaazfzbcnc9a9/Zc89yaKvYZGf1
upp+D3uwrvTh50WXZy83ebeqm20bW9kW317xU9Cf2f7K2jqDuTlrim3RxA48
vXh5mv1QbLbretP9lp0VuMEzaBFmEdulIceDYC9ZcDvfLsp2l8+Whb3kO/gd
9OuHfFPoS37Kr/NN9rJuu8smX+7h7GUXC1iITWxuTk/N1vDUt9WunRXLvbV4
upkXTZc9u4lD/y5fXhbQw8UsNnEF3+f002/n+HUJ3+J62EzWFbwd/rOeN/WV
tvRyXRdV+S579V/OXVP009kV//TbZd7l7Rp2V+EH+qpewx55nq8P2pbsC11M
/H62he/j3oiTVFRLfHrxHA5SSQOzmaCvtostf+MOgD79en3Y5Nk1PL+EtXpe
NDfutd2v18stfjTy4F9hKemFi/x3d9GvW/nht1v4RdLMq3y3zmFPvqpxtm+d
SZJBDf++oZ/zGSl1c10XjwL8/NlrEGXT85mT2yBzuyavUuGNvz178dPTZxeP
6ATCny5vLovuUbbuul376P79m5ub2b7FrsygX/dbElL3V+WmaO/D0VwVMMGL
4j7/pJWN/eDL+/DXB19Od/muaKbbYgOyZ7ZbruwtfFPdkZfjNq/otnpWHLLX
2M9djg0fsq7OHlfL7OcWjscdfRy2EDz98DO4e+QTuwr0j87ucxgvvB4WZqNS
Mfn+NG9gGb8DmXMFIyur4S/+WrfFbp19V1dVke+H3z9e3qAoelJsumLk8eco
qmB5nzRFsdzCTsE5P3353atH2fmLp7MHn80ePPjiy/uff/H5F3/+8wz+8yVc
mPCb07OzZ8+ev3z5y788+IrHpZP2rCh2WQeX/HnZwEq9zkuQMkuYtqJ49vj5
JDtd5jvcCptDBtdpdrqQf5DYKUD2VV1Z7et9m33f1PsdzfnpJTy9BXHFc2wT
/FUYzm6cGBjW6ebGRu3m/DKHfZCDjNw1RdfV/R+Ul3uUwvti8NXZuuhQEjzL
YT+ve18+w02RPdvEddJvnm7g3ob3XtXXvW++38PJK5ptnb3M28U+30xfwp79
rd9y89uh/a2rV9lLOC7Nb/nVoMu8jL/ksMzNyJcFvCX7l4LH0z9FxQ42eDcr
80VDxwhn9v6DL/7yFa/0+ev+Gpu+dgpS+NCWLS3l0+2uqa9pnVq6VXAXPH38
+gnpbheoPeFWxG94aU0N/I9Y1gtovqlh/+CSlr0v/6W4vgQRcMjO62XZ9r8s
86qCMbxui01xVe8r+cXHTdODv3xFskOm6uGDdKqe18s9nO3svGjLyyqDJZSN
3puC7GVTgypZb3gucepsluEhmMF0kh4++P/LJD18cP/BZ3/5PE7SX58//Cyd
pNsPfXZTdmsRFDYpvdn47D98Ns5BCYTnQL52QwECwuM5Luvit8PVx07DZ/f/
/OVDm4Ufnj3vb5WLormG++i0XIK8/CNy8N+2F85rMDjKK9Demg4kf//rx+VV
kT0rQVH8jxk+7IIvvvwnG/9wE7yoyDZ8WrXl0tuEo7v/37Te/y8s6YPPH/5Z
x/Tddz/1BeUTVHw2YLAtCznYfyuaclXCAsfzPiIQ4eYHFXlxxc/AT+sV/07F
6R+QmHAtdWtYzAPcW9+t8fK7zvszc8z+jL942eQtaNQ/5ZvlvrkcnaASzVNU
62ftoiS9C/4+/ezhFw+/fPjwq/tgr+9x7/JUvXrwl3SqREGAkbeHarEGvQf3
/nmxgEeafFP+BnOGZ+B5XuWXLBdwQn7ETmTnB+gl2LI0jW12mu1kdvEvu7qF
NcAf3+536M3pX/6dczqwApPTNbC8dTbv6HTiRPKUrho3k1/8mfTb+x3M11Wx
/dN/fviXB//5Id1Bd2hqz571BctZc9h19SWq5vBWf7DwmsHL+dWTs0lGbo7s
wYM/IFzOwFJqQT/+bd9e5WNDBNlaFZuybQeHcWCifawU+dwO3NkPg6GiBDmr
t7tN8a7syqLFQf5QwPaBNS+rI3cvWHPrA1jLddtO+avHqxXYIC1stg70qT8y
IYnZnRyxxFb+gzNxm50DtszDB1Ox0XVqfnn53XcPHw5P2AWcLThi0Hc4QCW6
xpY6G+m5OnZUenPx8Ja5eL3+v/+vGrYcaJ6gl24GWi1YqDlp0ygKfyuqq762
/ftS6fg5/Ii99PD+gz9/bjfyj3W9K98NdxN/DppuXR22eGzYE9YTFn8emwcz
t8Tz9HwG+nvdNfVNPC3mhKrQRBj5Qa+Vv85gCx1Mnujjf4V5KpJves+9nmWP
N/m67D33Giyhvyff9J67mMFWKFszKswBV8zztivRr+G/7j39/Qwv3eK3st/f
74ua5LZ8CX+m02mWz1uQ9Qu4Ij7CS2wi/h46E8z9qx+fBLRGQJWAO3RUq7Tn
cbtv7V35boeuEHSFtbOAwhEk3LbI4Qmw9vEhkAxZfgl2bdtlRX5dtKBE7nbw
7AR23XZXNPRXbrEIKxxoc5jQTS5dykAvILMchtQUCxjRExgQXfWgm0xRgDWg
nbVR3Q33Xp5dnMxwYqA7epVmMLpFU85hjCjJvfOERrVHXygJeDhEeQbafQFX
aWhZCl7SpMSRl9UKLvmu2XMD2J1lsSoraV3dJ9llnW/aQELiR9ge2dMus6m+
3JfLHK7+rK6yOdi2S5rSwatYgAV6RQl2L9wPbXwBz1R5naOHBURjUa9WKMnR
nbPM5odsu990Jcj4YI9sC7hswSbZYl9zWB8YwA6Eg7/k4oYpZpezSbZqir/v
0Y0T4Ee7/RyWPYN/4mWJflCQKhk8QTvhZEa6qc07TEBtgw42aJwTfGurr+1N
qXWtqrusFYOYNJv5gbYajhy/x71VwJ2wKVa07Wh148aEffALyVX8HDZQvd2i
I5H2LL/abxJ94Rbf19UNua1W9WZT3+C+qBtQtwN8hI4a2MmwRTp4W0eN25xt
iutiM8HPYH3odqTvwd6HHbWxtYO5yBs4K0XhFiKHbQmP09Ll40cN5xf6DP8r
2l2xKKFNXPt9EaCH+KJFDqcBhpazGZgv4cUtCK/kPXOckjpbxPOz2JTojqCO
B1DC4VkYP8ir63JRTDJxUuTxPsSVl69nLJS25XIJWy18ggGhBsz5Bf4oBNCZ
ssfnT1+/eAXa8Y+PTy8eZ68eP3/xt8fZ6x8eZ09e/Pjji1+e/vR99vL01en3
r05f/sBSra33jWwVXibSulDGoKcM/g/zBGP+vux+2M/hdF3sLy+LFu9p3OGX
eE7W9X6zDHNoaz+HKwm/A7Vjt4d1oC3dwgaEKdGr7xLMZ2gKZuU+CMiby/v9
KNksgNFFm5Q2EE5lXfG07kCEYeM3xWYDnXm8LGEDwepYZxZwA8yLsCXtwfV8
AscfVqU6YCdxq9Oy8VMyAnjOTv8S3hj0oKI7GfcH6I0dLMLjajnt6ins8Cgi
YL72Lb8Pn7qGQwaP/VqrYosHCEV2X+S0ExI6dH6XxW5TH7gR+ZaWpYYW4Rzv
GzAccLpB78ApWMCepF0Lz5tvGT7A2eOlxGBQ8a6bZHcK6/IdeG6Hk9zS8OAc
ljq3e/Qaq6TgDoD8+bWGKau3BZ84/NoGDZuRXCG4l3dw7HGD869gKPAu7F1d
+eaW7HWCB+Fnlc7WKl/QWQLTtFyUYGaFXJYeDiidahICOBXcuf4swqL8zuVM
h3iFpxP2R3Iv3UuEE996eTA58/79fxq9zj98YOlKMhdfW4ztCl4IuBa6Dlcm
k+sbpR9Kt2rJRyXPVnhYhpvEuoGbF6YANwK0Z8+CcIFNW2znxXLJGwfWHK7w
LkpKjAHLjvlvz1++hAH9M0iKf3rw8LMPH2CroGmCA/fCunc93ZTUt6EwXng7
LphErveXaxbM2/yQrUEjgadRBsI75nCSyA7CqSmaLb1xDYJfFBkYhCgqLcbB
MxGRxXLCu7niu2z4a9Zn4PqDg90d7qcSNKT3HuhRr/uDXMP8zIuiki3Kc6vq
Ee1g0BOdzuGulTrgjUOnZ0KbAv/JGkYLlyl8CMPf7GmXXLJDAIZQV3ij3NR6
JcxQon/PGhHsXtow8NEn5pjJXlzjPVDchCA9V23yBqYZ3/tGmnrDF2qzzd7w
+97QOYUpv4GFkrXBMBxe1PuKzC4eWrE5gFQFbTAr3uW4NWBa4RtSW1g8bMvL
NYkK7bec8LIJu3WNuhk8vAERU+9warJfa1b1aDpYVMV3kvQo4DpmGTfLTlUz
yw94n8CatFucTfiLmypTmOBVbYndzGBjttiRWv9mZ+gEO5S3YUOOGWhova+W
sKFkr4O0gV61MOpTaZ6FIZxS1de09xhWyN5s8bQ1bwI9DT+k76Dnra6t3Cn8
u3Zd8rC5CdLs8XPyAxUNHgVWYgJoEKyzgaYAc1pkb4pdvVjTWuYV3wHqiU8O
HipuXaEnl94Tiut6c437nDa6db8Bq7Noi6pTsYNOm4nsCvuyFRlL/aepX6Nc
R8si0HTgUzNUs/XWgy4Wq1WJXrYOdrUorfgxXrZF1D+lUbD9YNGDTMWausKj
wEsNO5e9+bHIVz/Vy+JNVs9/RfVuXbP2ThNAK3W3tQM/CSD16O/5RmQB3HO5
ihuYiL+BcoYePBUYpFb4OxvnbE+3IS0BzT6NDP8yC6fZm5fiu3ujjYg3D2WV
LjtL5C0YCdpuBVcwNxIlcb7ky7GBWd/COSajhKeD3gQWFyhS8T1lBcOA+cGJ
qoob6dz8QFcGKUrQgq6Y3wkonUqV8fAwyJFNQZeriFEaECyIjo09vPx+niN9
BKOiQdbnzQ94aNb5VWHz+YY6Dibty3xxBR+8iRIKLBfRilk7s00D0+CWkz7h
bk9CFJnYD90MvLJvLkBC53R7w/v4xb8UG5AsRbI0Kh9xxmSvie3Cc6PKS1Y6
uAlOGM02unhZssne1BAiT34qTW8K1PfxEoat9mIFk7ZvQEZuwXzO7uHljVc+
zN1JYs+THEVhjicFNQc5OcUysVBx/55W2Rv3qH7zhqRSxWqqjJyGRWrOvARz
FewL/+AuP2zqHLv5pKzQrEER/+YlmZvPtVG8a9GhgM3gzX+Jl9403rr4usEW
mIQbMgKxObSWu2KkPVJVSzmpk9HGreGAkns4Zuw6fgOzSxoCtIx7sni324DW
r3sblgUml3SMSQYHAO01eHcLpvpAxQmiHsp7WEX66gtWkfAOPhVHUHbBplgb
1BPj1QVVj+SypZ3NKjhfI05tVYOPtlBAPQmvO8KKbQr9Wvdwg0u0AvHWkH+U
dV4yFkkxvyph59SrsCuKBlVQ/K8qxuQm0OaqAq89r9fc1PolH9AAqjiKTBLF
fCjjfY1TYx6cR2CMZrApT1NTVeYnu3cKSjefD7p32h1MfYn2MJyikGXox25J
aqHALMlWQAWsu0EdzC36FF1d8CUoyCLsQYtvLCgNTYmn5Ir0TVhvtAZJwJAq
lnZPVsWvPU0RRgDhAO1bcaXMo/HOTiqcj3jBsDCDw1qzcthiAzYK7No1iI9l
/ymZdvI7YBei5gdTmZ2rN8Dm8BzmUCYRBSdYWAX5GthLxTg/fLNdaTp/Kjzk
sn2auix6zi/SP1TRRjyZbhfclTobvRUktwdeWnii78wbECjQOoYmoL9FIxoz
2igNNQgHOu5uk1O6PXCJsFV0QYo2kZNCsih3tAdl2Vi3ydQqPL/g7X1OB5F6
2u9mi94BsZFlhOxZJAF/ZPOgz6JsBstkvik5QQs4TfEK0b616EHtqEHY4LCJ
yna9HdMqB/uQpZroYCKrxeaf9DxooIDloqadspMO5iAng/8aNxuCEUMFm6Fu
ruyAT9DOAhuN3KTQVsF2qIwWl0eEYFYmRmHQew9eBX+TWW+LKDlwo0C3UaKo
uc/GEuIH8JllSb7Sqgv8mei8mci9uJmXtoXlYVLkTBDB2rL3TE7/gSSnuBJI
5WWJyO4DXD8yWlKTBiTXp3DGyFEoVs9QMqOYXELbKinh3nJx3/ML7gLaSxkB
KLd5tUcvFFq5TdnyFSQb567bZaZPn17MsB9+fy0QM0c3IClCiTjXxVyQo0oc
BSXZ4vD2ZZH2jk4I4gLRG6cud5MS6CPl7SitUk9ASIgewfKBJX2esWZAsYqn
qff43stnT09GpOwEeiT75Ya6S/5PdA6RFEKrZ8X2X9m2ezJ6nMikfY+nC33w
2NQcbB+cTREXss6b+hJ3KoEzklkU5yD+95pVfmijeFfybQNdzpp6U6AN+e5R
dmadwdeeUriMDAYMbbCBA4ehbjoJt8CBEa85DXD87hMX5ILCvh0BC1V96DuP
7ZmXctPLKHN0hrc4rqDjclfRxJ2YyfHrBt60bQu2A8E8NVF1esEif3DhiHY+
2vFVYPvf+7VjL5L3Yodss+Fba3ReQXPo0aireJZGrry85dDQiC5zAsf4J5j/
SWAX00REasVWVQuN4nqDdNApI8cVKj3Y2WgF0dYJ7KWHDdhIPMm88dE0j1eB
CGw4Wvfaogjv3+uvp9ET9OED7pp//dd/zfK8vWZMSvanae/Pn0Y+/RP/9h/9
HfUP/jSLEwX/1N+mupb+NlEe/vExffhT0ofRP/f1L/+Q//53/+33cvUdfXgm
f/6hf/nvs96fo0/Dm2e9d/feDj/oPW3D/RMMdCb//tPo5P9p+PQ/sjO+bx7A
X2fu3w91iuXfn+O/j7576t49vvAj706HBf9/zlbrA/1M/v1wdNyDp2/9c/vT
v/sH93l4/yj7ZFVekmO8Fu8kgxX+1zun2QUeOQaXRe+8oBU+BDhD/Uc/fMBI
zE0rYcQNG8noQTN7Dt3bxQ5UgCDirCmiJxIFD3rO2IXgdIcWZgz/9TmINxRC
Xgdznkldd1SL6IfRBVgdxNEX0E2rnlj86gUZfRSB4xHR76bmUJiK2pEMLrob
qHFVTQJ3Bs1Uua/g69MNWYrf1XMe0tk6b6CnE4Gh4rdhCfa2+cZQOYxGsPU7
CiZ6htYZGpUVl1ZHdwNc5PLn/CKEM2wfdSzQRWC6+rJl8OebfnP/CP/L7z6E
fxC4JJfKsIn494/rz7AX2UVX7LIHrqXbuvWRnfm4bo1MyVgTw/7c2ovwlM0a
1NVI6VOD5iPm+ptBN/5wY9/4aX04OqCPbFM7E74HSwq36L9hYNrG7221W9vn
Jk6XS/oVKBGM2/mI+Rybk8+DOCmze9Dcyce34sdz2+7oD23Q8T/cBLaSdNqv
jIqMP7g6H7Myv9t2XBn95R9cHe2FjU7aOfn41U0W94uPndZstNPHhcCYFPj3
NzH1C2tD5yb8zX7kMtNLnt/8xG6zx/w1Xu+EnxFDTt0lZJ0x0qdlxyrL4EfZ
qYjJM7m8Qjhy7fH1ZnJVzJp84DJlZWCOXmcfGuLYjhjghvHJUW2YdiU5LToY
0W4NFprr4cNHx3bi8Y46o7jQuMM5e2vQLSWuCnVFXXGz5oSKbj8XL+nFCMzI
4ta35qlZlU0LJiqMR8bYbx3HnGBu1Tgsm7Cpq8sp+s29UTcDRUMi+yXa52W1
KGkfjLQepNdNYW5YBciJT5BC4okzjZws4gJkH9riEEoywOdFp2nB9DYbRCee
yUtMk9igC2oFttwaPeS1eGgxysivpKnEcAuHg6DLbnk/f4RHCscg4hInkc2a
8As6J1ljusnFENc9qJFVi1XRJmhtBfat2JbnFOLZ1PVVgN/TrpPt1Ju7WXax
LtghqtY+h751rcl7dWo+VOkrrpIhKO+JD6Hj+drVZUUT+Su6tzWMjMKc/DRo
BS/hZLqRq8aILxoG1qgZ+CU+EPcibaBbBsbhhUzmKkI4xVkqeE8TJFWBciNn
bCBhCHzHLsS73JpziK2D3oEY+BfayWhMgs5NK4AlPEgO4tjUsNlxsXdFDRt4
Ri6I6AJq06ygYG5VRkCpPxTWXza3aukqfHVWGQ5SixiBaewCgg9tfrGL63L7
dcaHgmAPB3pTnKoIFksCAIil1NhB2blt/4Vte3eZuK3/VIwP3o+2+/P09rGF
kZ3P4p3c/dsSUw1J+C+JO0PENQzy0b/rmKgD+N9zSlIra41Rtr4MP5FAfchG
B/y7R0Qf+v/omJwKTIv9eWYSxnsZjkPBAK3ch8SPWZyBDw9G5Fo7AgdYyLxx
wcseZHnsIiOZ7BzSdAvgjwXqqNA13qsv6ENWNczabkN4UfHWlK4bgoul8zL6
AfHl8BwhogRIw/jCSRBABvIATDOTAbnfORgpOKBbIYlC0e/5VKVPkIKBV/v4
I4r8gC/xXkQ9wHl4yRUgmzJ5z7a+LpKHFOxBrzvy2H6H/nQWOCWIhpsqCXTx
jwjYY+t/DyHR7ZUGZgt59fIkIFSQHeEIGUhCSGXXFpsVLDzMMDnzD6ieod5H
dCT1BsUg96u29ZtRTIYjGQtyYx8UpJF4ZnDxaLvYFAeRQQmwg/dQAVK+S6ZD
QTWq6jFEssM4BmlUKIM5ht8mkA4EvbuYJfdehrMhP31NXdvWy3J1cMcOp2Yq
wRMP9YAzEgbhSYb5ufXpzduuRkRs0Z+sUCp+MDqwlpg9i956xMlSPBTEMKuN
Ak1KLgX0omPYrJMAbLwPMf5vyXgefkGQfDpEerGYOMFucp4Ezgs92OvPTLGM
Q5SRgNQE+rijFLeK40qwJ6Tz/iQJHkdQgLIbFEsFtwxF/U54YBgh6NSjxtio
9J7QLoVHrCrrOU5TWYboLnl7Hm1s699JQMSPHY+C0xMUIgYzwQPvv1Eh7P1x
0rzTdeC60loHMRwYDKUZIV0C76e4R9vZvJYMKs8d6IquKzlj3DWV2grbYckT
SPLYGjIAUzelqAocoOw1ppEnm2tQO9idYNBlWcWBFpr9wEHriRxKvGrastvL
qYKhc1exhzIihqhKFyzflnDdgqN0v5ALErpJZyxEgYRd4R/elC0hAUUMgxpG
8s5MyehClpe+4o2ow6VYGcoaCh5l799fCATvwcPZg9nnuGwRcHSClFyLHE0V
7AHIGErOgYYJsM9TOhmRcQxfoffMMkPwoYzCQ0wagplhFC8MbiVN9FFoEiG3
BPosk0QPuuZRIBDKjcOjnHlUtw4aosuOS6pvxu5ud91Bt6m9OqRvhsdoN9LV
pWfv99CuGmOkfipkMOJvWfT8zPjsM03AweWS9Oz3n7CbQx75oNlMJSJMCWjI
a4iorqsBlIszGxh94RRKQ3oHQYbLJB0ksm6YCDjIYpuUHH/Hgc3zFsa6ByWR
sOJ6ayL4H7cD/gSb9XkB+NkdPgJ3GPGwVXifHAy+0GgBQjqpDLFtGWPRcrxT
QAuwVfYu6ySnhMnsHgIDBXt7MsGEibF8NZ7lXJtqDbaJ5jdCpvftHlGALLFh
IrZ1RVcGIo1vKoFPy1rLIEBBib/Dibyq6ptNgZxceme1bb0oGSpHmnPgMeCe
rfjGH6bhmBY2L9ABIgqQYVmof4IP24jGi/AzBrr4cYGgLRvONkqUJAw1b9lh
8rXl08nANU8i2AGNIWwRnfQinXGBgOkGQlyJoLww6wfO0YRdHzJlFAfnPAy8
Am+qsSMlCRQM6t6NJPmh3r4s0DFUgqzFnA1y3RBcid9schm/EeRNquSVnYCF
CBnmzXV8Oeuy2WWJgB6aGB7wgrLvmuIS7OcNqkeGBjHEPgLom2TpceYII4kv
RMa31jALSMhHIn1NqUPk4fGHJAL/v2e7lmfFsOkchaWUAXUASWZP4ATVpaJ8
RNqZho/qCC3EYNPSllLYr2xbA5BFkDp/P0SXscMyc96JPUzcJg4Lvg9kHeV6
3faCn0oc2P9SjE9CZSAtC6zbNXGGEApkrjbbGPh80vtO7jI7CWxABi+dRiyA
rxM1g6EroPgjOoWGorcfXdXQfqAJFofHctzZ0rCluK8MylJwykLJbAMkJMCM
bCm3NXxyBOrDKtZtEFg0SpNEIoxXK8YMtM8HcG5hOnrAnTrdMQyWHUXKikTg
xLYlev+HwggU7Iez7DGP1et9tI4HeYfrQRazRNAcFKXJlgnfQgoES6eGMmQF
vd8UwnHnwLohfO5e762QWzvRy0chAch9wA7gVaQds2dCONWWJSzA/XSterd3
S/IwwcbBeHEC1REYTP7uGNFOk7qoG7aWlu6acEjSeb2vaOpIAbN3i0Z+SnBV
UhaWlECOGprirDaUvCgAV+xZikynTHQDL1BmoUC3JIF10jsszb6qXBqmnMS7
UecQyD5PJQMjRE2Av+OA5cZh3xmlh702Lx/lPXLIB+Zys9nz5U2neg7HZ6nO
WR4wIjfEM4c4PO0ze4VoQXFyGH3/5cO/IPqe32Y4wdW+Ys35Rp5FCK9DVfcB
hnlE9KkEhTcbfpQ3nyYJZv3m4zrTkXTt+ufwvRHJHaGli31Dt/M4lYNiRyWt
jk8Bzaelw93Fk4b7Ca6Uy6IhwpB2BG+JlAdy9ysIjqXkYNrQsWi+486MbgOi
mMjI7pWzYjZJD6SGEIjRJB5v3pS2+wWXUtVZmlWDYh/uXlwGP3sniEN63VuK
uBDinPBqiH0nIHyUKy1PIwY0TKKQVqTIVlXTQa+m3G7YZcym+eEDZu6ytjGg
07z37PUJ/PLZ6w8fOGM/O7oV071Cs1+1uGP81NIl+uw1IhDh7mFwPKuALpVt
dst0jL0rbp2c9wu2hf6C1mU84BvV7M/LbRFTZdGBclmQIDVhx12k/eeILPh5
mim0JesKc++j8lBr0JJhzkNtjGHBZRNHGsJ3vA/lxsJEedjiDNAVpaqHLZbY
LbvyrpmIgGW9ZnhuKZCMYqfh3WpGvpIwiHYBrZAICuQqIzEsLA5osk6wJZSc
YlzhtTtBFCnll6IQ6GVZ/GLsAZEGRKW8nflLFwIa9iiq9KcXQRedZoKznPBv
79/n7TQ+ShlKr53VQxJJtAMT96maIMuQaArkHF3B0d8cwgrZqvC25iVARZds
GJTS8/q6UF8MZbIrRjYmOaCFJAIxJNZUotqTlmYXe6q13IMXr+A6nOCvyFje
8/kHg6vX6ZhczI6teQlKIfKjmCaAic6cHFJ3cjn1XkdRDHS4SOJWrr4nSXRw
Z4C2isdk42Nx2Ya9i99JKhivAExTTIqgCC1fUHA0J45UYF9tyuoqF58sCVok
5HE7x7baHET5qsQ76KL2mepEWDMlxhqCVKp+j9NF6yxtN578gqXGsX3MhvSW
/PzuSvMuOjNkPTSfdoepdeZcDyqIVjFJA75c77e57BVR5rb1nJUVTOZpr7p6
h8KvNRhlSAhcXqy6IslGSUyxXjZ0SRjMRSf3Ij4R0PsVPTlkYCc3uGY6cWCB
Rb7wMpglLCZQ8KGoxbpYXKnCy2auOY84gdr3bH7oj0Ebo/0Jj/KlsMVMTLSv
KSmyxHRsTHVkoW3MGij00J9MNscKcywTcAz9GJVAfDhvxMck7kjzSdD7inc7
Jd1xOgKSIex2Rd7QyVQeBGexm+fKmXswtatomLjW0HlC/q7RNvMV4kLEVNvk
wtvcgsLXYbivrBm2T0dK5REHO/FaXJpbY50PhsHGJP3YhxQtmwEPh1zbZskj
kb/Fh3NPGhlvNzgNloalx4WToALl60i2m22GhSiupiTIHMFGwCIPrAls2A9G
GtBdG2m+QP5AnSsMM9SNJJ2gF2chGbUi2TIivkN3eSEZZPE7YqboQyn40hnP
WdyBFSPxeKTASe5z1v9x7ZdwaSyI/inFbun1eCxCzgmkqQgWmFOu0INo45qb
BMUN+1hQ5KuzHnODRvFU3uZtJcWMLunDXZrG1QYp+XEwr2BDDHKsWHeIZgE7
lMkhSMAQos2g1Vsg1hyvudrsviMOhbIKA8gUNMX4nl6iK45vTXa4z7fmwF5I
HEm0DdvCZ70s6x6EZaSj1Mj5xdc8NV7CnF+Yo2e51NgwZi+JJGiIIewaOb58
P1ykJ7IHCasQW0rocpSsa7QYJwoZUbIQc+WojzJR0MiT3OgGj8E2Oq8CvOeI
Tk7hb9jEC4vywcLMN/XiygLskeWDF/yEgwxoQVzAniaWKpi7VwXWwrhGz8TP
oK8TREP3t6Zxk8Gn5xqBgeyW0O2fumqvKOdRMYKqr/ePYUT92bGZRPdl5GiY
BNJ4u1IBOKpzoqPEqHpS/7sGAtr9DvEAxTJm0ctlTIxD+iVoPEUln6oqHp0H
6eCcwShuAieSI3Bz/HQkGeUUQmFfmSrDkpSYuNDjsO62vegEvv+1/xok+naL
y5kEOaLdi3gbCZuh52SLu9CcDnHKJYBJlAHRua+vDr/rZvLuJNPKySxIY1hg
sAphD1wv6PLvhxYkRBCBn4oPSeGISNTiu4/+A80T5rgeHklZeeIyW5Q7EJ3t
vsSYApGuWWAWunIjmZTEnqj7JMWIDvZT1mu2pdgRbsT0Do1NxA63fKaI0ZBO
GikfohWV75RMigiW4v71L+N9i/ReEqQiz9kgboBBYpYn/sox2h+UhR7oox5y
dDgjCI6wJflCnJ2De7WrlUovGRtpzOYwkhdMQurkTDdgK/HHgRlkPFXDRzBI
i5hzFzCWM6B6r4ekFRJgSPFo4R7+9Q1FVLC8j/L6nBhfSQFzviXXmV5Llbkh
I6sQvTEkv40H6S1KzTfw0Vsh8Ul376y3ZpGdMNniDprMOCP1ediqYRcGayQs
gp40DDEw2/02q/Ya1vAL4dF7oYXpawVJJP3qU3GxAmIbIXLaqbNYNrD070LU
WO0QQiTcMHfx/BW9U6vqTslxo4je3ifTybtdYijk0PACK+pg88KiTrEtUQfm
xQr1Utw1IuXA1K/zJaurBOj2b2TTMy7PdV1iGj5qnHgDGEX9EUi549Ylglcw
vuNpOKJwTpIRMxtqQr+3Z5fi5hDQxS2cFP3NMWRBgZlr9w2/XLDqqaANBPHy
XEkUT3BcSR6cNomnwOAYxTt0uat9HO5sEPUG3YAlv+PfpdwUkeqUIXG5M0CT
5cROxaVEEwtk8pmmYTZDvpCo2iNmL5lQsPDsHPijR2dHOJhI3Vo43PXRoWCs
O0gPYbN8k3366avHZy+eP3/80/np66cvfnr06afZY5x5ae1YS6gGV3e77LLo
eA3gAvmGx4FnjCkfKSFCiXN7+3T81a/YCXX8raha1ajBt7aO0BTbupyUyvut
UXvEmaly1YkZD2YXGCGooCXG8Ayae8E0uRM7QHwKXKf6fdqK2qd9+qi5dfsG
+yR5CUdeA+0ZhJd52dqIYN0U+cr4MwpK90g7YyMqu8hzNC9EQaLecHDDZG88
v4Q1QugiaIk9Dx4RoJGqv2QN3w42WvMqSN5/MkYHwCYy0ugeAVeOCQmSqDSD
y/gmQ0rMMnLuJaYmjYRExdzxZRK4VRW1Hm9iHvoBcWM8YyxzxNWiXowb9kQj
haRo+OkLySsVOebgAIk3dThmYnCxOyRsCKboyBgEtnhd5hnRULVsu1VYwOQe
On9I+pAbhg6NQKDCKofT2d2Bjhs9kXvwjvDLxF95jRCzSoSPhwZTE36y6Xq4
Z6XOOaaxySAioyl6cqqDd7CRtAN11vsVGfHcGfiXd6/GWEhXD129gf2uHN8w
hGm9mrLotI0hYEMDj+WbqfPVI10FqbYOhsPE1Q0milAUHANQ5JBMXiBYfmKZ
dz4x2hmgBReB+bj1Wk2ItsQ9jL4hu5xadUjPsieoCk8iTjRe1axbERcod1AU
h84wkepeFgAC858gYXUBU7ecBHVjJiw3zD2Jvpwc82ta8kfBDiCOP/Zoj0Jb
AmPBkLxfY+s8ORHOOAKaRFgm0/NuWMEdbczudeymjM3yETjmuWxZX2AqQlR4
5sVlWbFuTISTNXmnnmKuHiY7LDRog5YsIlvQuQ2SoSnbqwiK5nFqUBjzgpK3
t0GzntAZzY5VC6ja50J1SZ3C7Cw8wNudWuYKusUcK+cA6jfMWhQ5D0jnUOex
5mvCpgKJsTWfQvCpWq0QeU68s43ia1b0bNxr8lJglGenL7FvsL+2GCjG+oMS
AXb7VwHrC7jOWnaTeCIrCTgbymko+Eg5X+VMrlyTx+PMogBcfQEFBeXdynnv
SE5dgCCADXJwP58YYzglu7D2S9Hly009J5UuRhgy5a7A4qJkoq9zNeSYQozK
JflwiejnHGCHnb3coI73a8rB/DX6bK7zcsNQn+MDeIwuuD31anQIXGsM+4/0
VBQAhAsUTBPjwaIARkt9Z0AhXNk+2IYjbG2IVDcxfsnQxBAuCK1yWYoh3XL5
BUZUi9xBdiGdbXIDxJ67+ZSOC2N1hOVzbBuPIzEtIhfuQpJfnuOdMshPZKjm
nqmywsg6k29pWV5uaeh0Hhosd8rUmuu6VCVZhDQvFaUILOoaY89spZutIOoZ
xSTZF/hb7Hqq0Jp/NrJgJX7fAZ2UiGzi5evdTXWj5VA4GtPfnITUTNeL9Yc7
EbJyJ6MUcBK6IVGJjPsV66lK/u8GoyEx8kHp4dgnM8DEac3FA8rdfuOtH2R8
sxk3BUCHoIxZyktOL+CKLASpoiNABPDI83jBUUC+jDL7PoV4zg+Zf5Icv3Bj
pl7nrzNB/PKFXAiBKiuDdmvPhXZbmelYCwwUGEBH+eUgbN8Lzr9lJmrnVaqb
twwMx0B7iFGklaangXjGOy3OB8ltH2AO79//c8KsHz3FhGngrD8qDIzneER8
thaOIJ9qh0fHTN+ktEmRt4cgoYFFN8g8G2dCE5gUKBT7Vhxw6GWwu3AMtMzz
N8t+EZ2IgpNk52DdhHKZuMomaZApyAaUe4WM8I5DrAxt2PI8VOijoLqdGnKr
sVgPOT/IRvlk7III4Rc+8nh94l2Zi/d0OHi2P0QdpBF0hx1fcMTjj/eAHTXJ
HhUNik85V7TYRArxqCZBi6LyJtZA8BYQwnbEugBF5SqjIAQaZ4mWkqYYqX4k
l23UIwJ6ySPDkl7ihj2Er+6YHGCj4M6IMo9ZuWZHtDI6mYIINWb7R4jyyGns
ZtKfL+SQ83eMHTWZHBfXZ3CScx3T6ZbEmrWkUAfGucpkcOqcUw5B6SHCCbyA
8I4j9dB5bHil/YQGfnnHid8+madUaLmwM5hxNc8R1cBMFCY2e+s7YfC3mAYH
jTRGZls+EToOHBrFVdAElAD/LdyFCqkkTzCN/i0N/62UjniD+/htWJXFhun/
2RR4HnN93Z3EW1nT8tcDvnO2nSyph1ymqxJ7yiFO4qwHq3iPFdW7viad0QkU
yALnUaBmEWjySKSwr8emV60n9NIR4gEV9x7ATt5PnL5MLJ3I3NW+odmlaFFZ
0ZaZcu5bK0TXn4yrZn9AeOCW2EM3GLWAlSlocwnIIbUq6abITWFENyFnaecM
JSNTSEXZQN2aUJYlxZGQ8hPWpok/WvgSHbPoqSFOYzYgvYph+JwEsUVbgE8y
Te913jDOcsvUM7CDUEmAlymvBKXGW2NjjlCMfVfIsa2Fs+io48Y8csuhkYAX
d5HgoyYsEJMIN6UYawo7mYc+iz1GiQQXh+FR2Ox7ThIj9xzFRpwRE0Y5aF3V
h3j6I1M9R7p9arweZ43g9keZZuoXJfaScyNekpKkY2K3lKwkOzkZ7eMwn8jh
g7JK+IToV5gvwMkctM+WBd9HKxuRrKKgQgr0rKKfxgsjnt0si9JeyXai0Us4
JvOK+xoK+tDE6dyURxFZaRS2wHY53HlTuv0IisDp1ZymguJJrGEaZrHrJpr7
QeIadtx+GyctQlJQZ8WcwBnlg5zSo95/Um63YORxsA2P1lVR7Iiwf2ceSxRT
pOz7/GQG5Nhi9LzNhO3qyXWBmbWd1lKIl+iEZkW2wx+fGfWJS00ybEuMSRf2
NH8RMk405SXXQZDJLCSVHG0h2hBqjUFbuE8acq24RCtKUq93gpSwGapJeb2K
OV0dBWPJ1UN5C+geLFR0k7R0e3S4owv1q7sieFbxD1qTSNdUIl0zom9xo3WO
MdxzFTtMNT160hMlKCfVx9uSH7ILo/J+nHImES52UnwFp45qhvHL5epRp7QK
a46wE2N5LjnaTFUU3dNpLB1tQPFwSuYwPdRRPCmIftN3fQuuwrXZc8eK67GI
cY2++1zrpOx3G4/qSHYq81XjTMiNO4k3c6AbWW+6abzpPnygHfj+fXQ7JN+i
UkCRO7kOrA7lwsmeVsMvAw+dH6UuthsmxzQHYx2HpTgX7J12v1gQCuAO170U
Nm8Kofl5DsbKET3iqGEa43a843gorBM1RSzQsgRbi68t9qSSJHFfa+5mg6CM
JiYLuFu+D//AKb8PIs1FxEkcWi6qTy3P4hatNNvot5iUKJUPQDrbimSvCqSS
cyePvZpO+K7gevpNtnDK60JNwe18eUl7f52yvXLgxhH58Adv6ZM35fItCoVl
wRe+bnr5udpDinT1sGNN1uMwxFZKPOIJfsuDeRtpFu5FMjS9gQY7SDdjfD1b
TmH0lrlrufwnhhHkOfNp8VJg5waRp3kHRupiEtqaU/h79AQx9/CyViSnBFhl
dKy29BaK1E2JOvCsy3Viw6C7jnq2RsAyAomYQiBh6NJcu9gNu6IY3WHbN6aX
jb7OQKzEqw6d60+0HjD17u7qzmDakcOuyRkluizZKcGwdlNjTNAyTOX2vg7j
A0wGz02omWdianRnkKYqQYOMIjpJdNLalyl/LCiKYEb2wO2g9c0GneV3lBg0
ZITrnUxgkzBSRYqy+wV1V3TZYRfwXhdCm6eVt7zhyrqI3CREvUF1D3hKvbMU
MbT7y8tDBHRziRQfyhKuB1NLMBfXDS/NtFY447kVmPR4WPEiBS5a8asC98+E
+KRf8S/pmqdTqSJaOnhyF/Lh8kz0eWg0smpDH2k2wLdo9xXmwpDBkdcr8ag7
8pR/mj14iD/0tZqQ4CGuQKxFIzViklCUWOt9G71VYHGQWocEDxBMLjkiNqL4
Ugof/Zi8GruYTmALuSakrFyHgRdp33LK4Y5tZG4rcYGbCjG21rxcwTu0MsN6
MUVJBF9IDqqp2aD0ZW+rPz14m7mtABqs3U9cfpA0Oo2B3lhpZ5MF8pYiNvy2
eitsHzDNSHQFZ9yFOMlv0e0XV1j7tVIvnif38jtfhkRYHt7+GK1BBMr//B//
B2wHya2Qg/w//8f/qfFAf+jII8Nuw9H4fH5FySWZ0BeZnFBryEsF71GzokNk
rLK6rhYdkW0R1YSm4Nme8slN84MDRKmdWLowcjArU3ypqQswrps9TXop3Job
SXErG4vy2SLcbR2hmCFoUaZQ5c5OFBUaM2iaVjGjiNBVik+JA8UL+zvM5OiF
4R1uzpg3lAsYBc7zY4JQfJH6W6+nqWMSe+DPj1hZg9EqQrej9IbBrtFLmjdp
UmYuIQzBfSJ8gUykyeS9XYKWd6CeNHVQCxl3VouFtg2RvcQywduoiA+FscjL
JZbXRY3HJyfpt4j4rTGqoFQpvuzqRGv5VBRQJwGG34vRUNp0k2kYyuRKc8nl
pm6lKUyGDES/feSFDIb0HWToIxtqDiIOix67ZDfheRjwO7F7A660Cey1A1Nf
ESGlFmYUmjLW2mJu5JJRY1W9LDh5b6kqTifwWCm7Jxel6NWZ0hXwr5lwaAP3
j+CQHVFshnSD5XZs1uB9SBiA4C9XmYaa5rxkJz1kTshVFe9Jrm1ECiJdNJTS
wmrckRRQV5RYpzxwDTN0outOrDX/hmX94GCwCMWoLW8x9s/GDNTz+iLctmPR
eaavOLgMswYmsSAoRrIL0ZHuRu1tjWTacdStVzRETrsoM/4EGkMJtieNKW5B
qSGbsk6zfsdrKDcfnxxdXpEjr+HKxvwZDAUikVy+ObRlm5RC9xPiyskTU6Ay
GbLbOqgXWGrRjS8C5dw9idk4rxxwa1h7kkFMmP4+bUECxMynQR3xmBeW45hJ
zeWQB2F1zP8uNblsfBQzjtU6NevfZ5adoHgsu1bD9bHmi+I6WKu1OkyuirVP
BAkEQWlaY/jDgl+0Ijd1n/5UVI6SGJt56DHTjDgHMKacVHqmQvP6dHfYiciM
ZivlNXMMj+WmmUIx9QM0/+cxreyMoV68LjKvMZSEVsiWY26DjLRJJuUtY4hQ
EGGiafERxCYMZKVpyarbpTQEgdO/E98O5d0Ih6GStJ6e/Ujd3JTiVmNhpyya
HGJO+jLhUZXXoA1eOpWgbnTFKWSfvk7ccUFdI8JnoZGA0TGwwcCVozlcW68Q
x4f6n+ovyjHvdRTRR/xVTnQ6E5q5eicJuDM4TMokFgGdQQr0gqJFiMqYm3Tb
3FiXFQTJ4X00R3EtE/orWBq3Zyz6GPVj2Hj5ZRzHBi98DrqrL9USSvFSDgRL
Rba31qkJ0TsnvlEDAfPuVSy7ZLVI6jX+NawJ5p3udb7hJQkfd6eBE4gbOEmg
12yn+WHIY3cv1/IByc5k4R2VLdru8mpO1+0XRsAqcBRRSNY5Jl9F8RKphpMZ
DVrKfvI7ZHfInAD2iieaU3ZAR2ZBaeAu2G/6D1MqcN7LfaVRTtL8ZywwDKzE
6IaEbsUYLZ31pbsngVXDudzmzcFBcZTndcwt2asQPmaCkaO9RkMEO972tnIm
dYVRS8qSdyKeIrnf7zyKVBxJ7jGlTtKyqaLk08jyueTZW3aLJA84zmdk9hBs
zqKWQuhJB+6MwmdpaKnPP0kDhtHds2A7GojMY4+5OFVJISDMvc0PA3ciU2lb
n78OtA0k4mNbgM4eg/YcQfWJxNjpGo67YNJLVPabgFORuDC84JCkHqYfCtlA
KqaUBd04hEu29dQJjd4Zzq4g6UxFUB4n2hrv6rijUDhpGwpkgZMQ8YE8O7LY
JBiHapm1h/uHuNY1fRDppAmjzbzYnatPgA0EbgATjrklggrDfJBHfpxLe3DU
GZ3dBrbQ/WCRoAjXw/BPcQqW2EtMSuhDkHSnKsIoUOJ4YvwYPoQ/NewBn0oa
t/rwbKL5yAXykjUGwvDhrtwcWLjbMEtJ7Zo1Z+qTCOT0Cn0+pM8bcME4TnOP
u+Boq9WT3uNx7fbEhaToFYqHIq/iQOagbJAOsfGJsk/Zuxz5e6c8y4SFQcPF
LRVX57HC1DHVX5kAS7olJM3PTgoZDEStlXjOEB0qt2Iv7Ue0C1GviQQxZo6j
fxgV+MsKxxeMApODWOUupxuaKU0cZxycOV5Yy+jzBYK4H6GfkSsR/es6cs2R
kwjJcVmQkbFm+CjP6EE66HbXBTcTosDgtDrtA7N8iOazVV4DtNLIftN/rxKt
ta0T2gIKFA6PqbapKkeU/eZSlFvSiGBi8JfClhJuMe2Gzx+KXQrXWAMqWyXc
KDhYcqPiPIYEDcqd9KdDYZt4gBwll0kvbZ6xnkIWEZl9md9dRmzlYJI009jh
somL8Dz5yVKzQR3rQE/c066XmtUw3aSLcHBHWVRxFZjKgyOpph1js8w/IrVA
2sW6WO43UWDBqbfYXEjWjuwGJkjFat7ClZpUyeDcM8Iz8FD3iFjKqYdkiJEF
LI1KJNHTP1KggnFZfOyxWkCOqiYowczTjXuWLTPsheMUIK3RzRT6XISEUUxB
uMJBI82rAoxA5bAMEqnwqWpa5pNZE5g7GJeYLk2zSUR9ig8GBbjEEhDeGWM+
7Sdc/uvlGXxdI+FSJBwj+LCE9RqEoJfk0xIPMPaBIG4ijpg1OhlxL7E60qmE
PNLIuV7C7imvCszXUhQmKFBFddmpx9x31sYSxno8yTivEAWjErePjiwSf+Qq
8JwfawCrx1evMVWJqt4knf+a5Y8slmBqNJHTkQYQRmpdFryvvLOMNYcSq2Nn
yh7U1qoMoGdktSdBLLOV6jN4zA5FF28zUU+bIk4r3IIkGRj4oBMjKhibTIn9
26aXnSQCxkWR+vBgC6IDhgiGdnpCNJv+IBoBKloMxBJOWn29wNXZamGKKEep
5SugKCW559FP7BVii5o6UqV7Ly+enWQ+/USPNrLY2VJGpqEwOoq+Q5EM8bYQ
EFCt2mz2XBPXpPOnFF/7jkWgzXLuho/j4y1zSpAOKl6jH30nVk38ebCh4k4U
smN0HeCQnrvGxCbNYPx4wRfvhFSBJltfiE7sshK1DzO+9L1KdYF+Gytlhm90
lEyLvMHExGvBLciDoC5oDSR8tXjsSMSyMFWzgC8/AjMz7iuiniaa/6x0K+Qm
oSQf/VW9WbryBd7B7h9hmX3qic9+pnI94afaQzWqHk7rRknZF533KTmA15y6
DsIw9OU45jcadGgSzRzVxDoRHalL0TQEIX8gjkJUW3mT+HgZa2FJfRkPFZtE
IrFBxXuEzQtawACQwuKGhBVk/n+Mi5RzcZxDMSOqOPJNMV00Ok0l17iH+Ixr
Iflr6IQHlVuKH56yunbGFhIYO5oi61IVUk7M7J5iccQ1mSp8JAt6tSUij4ZI
D/FEM1eb4JS9WyK6rdn/iGPX6l2ufJSlo7GiKiRy98tqhcWd0BeA0nuduypU
SDpmZqAk5WbitaayCOpeO03dpxV3x3NZsoDjJKrLfcx+F/+hed2EAMj1+4XE
eSvOzpv0iCtFLxI8q9w6YzWeyB83L6SxjTOggk4XsdfQqnP9sJFe0LbkfpTC
6SlVqazmBxbtqhStSO7butmja0JDJSLsteKUxDs4AzkS33k7LgFOCmrLkCWT
wNu+n3FhVhkhGkrGKBh53z1KrqcijC+ZREu06xPyUFdjv8xeEn2X/jBd9yDh
QYuy0HTwAUUcCOH1mtJxSSB03LodYqKID/07F7yAlw144EGbMpeTUCd0fyQ5
8w40d4y3wusovZWO56LAqmYbsAmUAPXpKoxMIrbuZkO9oEXkfon4SwIVkCqg
014LGpeJFPhOZOCqk0qRHy0IB4FqXVPoz5Q4zhaCZDVS2Q8fTkbDc+qRCZzh
ZjXvhH/aIGEdmM19oExyjGkw+zYZ/dguw2XnoL84/gnvU+wkdLrcL8g14SDa
26LLOc9YeHRQAWhjIQ23XeDOeoziivikQ7FpFdQK1yGKSL6Qbu2fKSU87yjS
eEK9vkDZM9zY7cOdBCo2qtPd9vc2zTX6BDm8bl5Zk7Chh7kARejIrnN7LpYI
DAP3nPpLVT4nPDITru3bA2zgE+x+D2ZrHfP+MVQ7ptlHHdgBbIhMN2nvIC5b
Mi7hWmWVj5UXQxLrO26KSPqQpnxYlRKB9blcsbx/V0TeuV2SlxRGqve0k8yg
5uxk0JA9Oce3W+JO6Y7T9pwSERDvmASLdmwehSL6G67bhZQZtssGd55ERoWd
FUlfW0xOVl91DETA5b3ZF2ldz5LzPvGOeJSpM5ocZVJTBs3yrQPqutBJ9Js7
mCTqb3h16eN7pCzpoRKUccvhdnxDYiq81WfeSF3rt8GymIfJn0dwqToSJ/Y1
JmMZEq0wKVpS0vC0tK1qIfN0g7dM2n505X8QSmQQWpTnoeEZvp1cicqIiWml
esE3MoRiJETAI2E98wdkIcBWetydT/Jyg3PEsY94LatXQRAk5j9OSpZ3Upo1
zWrD4CPVp8UIuaO2JsII1oa4tEJ0SY4TiqIv0hd0xlAnwVApwGAVZCVXbNKP
SAoGhC4SiYt4H3laBscAUA7e4og++5Cw5E2B+S+YiYg1NudKpxB5zCyg+qgo
k8S3xQorWZ6XiAMXn4Eh9AVWKS0h/oRaWs6y10q+5+iFDIUpSkWImgTphE7G
OotCw75JqEHRfJzGmixkfBL3GU0Wn2spSeZKYwzn8jgxGx8DDPFxhCwyz1Ib
vKqKS7REGWgsRW7YKUfW3z1B2Xzk9G7WG4shKEG+fWzf5GhSSXAY88goyYf4
jbJ/uMJ3PZpoq37HSmAvUULzMDaHaf8NgXYEgff19eycoJS/HiBsrP7Kf5t9
+dlXwcVHMNTpBrBgiYSbmqp1URDkSuNgJCXEXI/BUi3k4bgKiRpywQndm6QQ
lEuQoYQ+TUWaF1RFsyqCY5jqPcsjb3XoR9ftpUvyluoTboyTROmmcFGc3284
YEbqVn+qWai+UojdKfnbL6j5H1GZef8J6QRTpDz5EBiIGZEqa/SloZWw4QJT
DD/HYEJL6kiEz3FOfcymYs0i8BPkapwO0HJSIzJG1s3+TGEMwcAjUWVJUJ3I
lZKKVO6OUq7lkVhY7V1ypLAEHCR7oNbMIH7QltPooOwE9KCRjXCT9114nSQl
1eVe+PC46IqwQeXZCsYrRFuI0lmjOzNqHy5rvn82OqauckAWECRjuXhegTB2
FpmNJfZ9EiKEDfWEJEnS6g6S3rN0yxU9iALlF7UkqFMRZ4MvT1oRSuxd1Pum
jYS04vYcbiAX/okrf1fBJFJ2shMQsvHvmNdYUJIw16/SHKBSEMkIwhhEDeKb
ZGXNRaVwNk02IuTlPjEhC+YJuimrZX3DSpfGqKF9LMW64g0U0ujLMaPTYcmv
EQO8bzN1GckvVkaFxGmiLpce+8yyNb1aLJqpAXXe3P1+sZi4cBTbzzVGdM4Q
Ky3iG2GQXNVDnDgMguw5AJGB5Kay0SgmMjvFHRcknK4eISvt7DLWVD2V4ncq
LmJ5145Tg400sLScIT4dyJGDlljqe1TyPsddXJJXj8MvePuhyw0BJfBhrB44
Aoli1W+4sxjpEjxpOacD4Mrp+3VvchlW0tr7MZ1iw1AVw96a2qaxezWOFLHI
4EcPCypXUgSB1T/zSoxG7RIEPsPBkeqDTRW2E5msNPHQRkeDBFOjbSMViySv
LfpJHIJLEZr6ahjEY2N4wkVLCGb7GS7obdxQ0McaD6PwsBJhYDsrVgBv4WBx
D8Ueu46OmtAnTkEzL+bQyV414K7zq/CC8EYUAq1h4mECr0s4IiUDPoZ5IumV
eOTdXXCOLqUnTb5lkb7MXiNLyKlWbBAs+KhbFcNFpS03B392+d9jfRpd5K/Z
t0GEZJxFEfJmXnYNZqviVEkFgOSOIptvj+ki2Lix7XLtW2qeFwoj43jjvnVP
v8FGOfuMQT+65T0ZugP2pK0ZE6r5IgnUVK6IBbYPqqX40KBMFR9PZmox1768
YlteOrnsgeTDhFiUJERei/MzRz+YZBIjQRJoC0swtVhAEz32MR3xZ6aXwNnL
sWCTji7OjNYUhrX5xuU/fs6V449yqE2wehgJSLzbNB7hF5IbNlEIrceXCp9N
zY4spdbkorsN5wqZ6eJZZcV0BDXqm+RdIsmimFnJxiZTYzQ0QCkdMdhMtE0i
clwUhnkdklqT4oVN3QUa7zU3lUpV/yi2N48YaeYDM/2JWC9jhErE+4CDJ/pi
cBokCZRVG4RW5FhCUAQPH/onhXrBeXpijExyCeZMMQg/wf3EVE/8TIEewuuy
qastR65+EWQV1qKuF3uSX3aR8S7gNOJ43hzm2BRKXJWVdWsSknpuFp90dxq5
jdkXQEKGDNXYSY1vCj8L+eHdkHpmaYJ/TUtxJIGyinlDObKehP18ah5dC3GO
JXMmphRzxTQtsDjgJYzTICRZhBLDjrODlZbjCWNF/qYVS3i7q36VRlSiKLlO
f+6T0RY1MT+om5WxKKgN7SVpQYivcovBV8Vl3ZW9CfxapZ38O5ifXx8DPbe6
xBqBVj9BbvUq04iLMtGZKVvcINAyDXljBlJ9Q86sHp8GxSIk5Nl6wh0agvnh
gtayaoXT4+g05Z42TJks4uCtfswYBMtIPjinZr9To0siqevyco0eAP1drJBB
FKqEP/FQRvatYK8ezD4TXz8yK9Q9lP1I/YeW9EC1PtDvkHCOxDdLjMKi048d
9NLBaqXurU/YCyPlbdIjxUGGqJiJKsOk6ljPIltzEB1E2aZg4n5XWZ3TfvuB
C9kYMDeP0/B+kvLSqz1l/UzTakk/kbnAVDzUmkzjO8RGti4sb5T+5pNSiFqp
lMZgEKy6m5xB/rECgGa6j9ekt5wLPoZlzCkNMWJJdMX9QzVgEleLyNTUek63
jebkIpNNm69oYfc7bosMKbKV3DaphyeOkgdfOL/saPZgHrFwDCOhM+JrJ3C6
X9SSU8czMr9SBu/UVQ1bFrtNfdiKjmuqsmJYKK6Wu3I4CHOQjYcafXA13hy0
gsh6+W7Ba/vcXiIHW7PNkkuI2APUlUIvdheOvVcMTCFmpuQ6jgZqSV5iEJdK
jIT01Cp+Ok6zxi0K0tOx0xrurDSQRA3MWetKUcCWt8pgDj2ZvnEi3GIcfYxz
QXtQKV4opTHOxqynWTDvPTE1TvFFMViokrQYbKt2EtLL2Nd28zVAMVtCMjOj
aWgMQfQ1I/F7A+gv4YQPP4W4aAfhcd7AFmRHH1vhWLmVuA0pt4iEA+zauqFb
n4J0qtS88YbiW2cS3lOV+s8zJBQBDeA/GafIiRKqb+uucL3zl38O/1kS21NS
YhYrjiUlfjTPKRVwyqijpy7KfcoUirGwKpS+El+b+J1wB2K5GkGU0i29ocw5
1Hg6CcHGHGy2qxSOq0SIAqIicSXCYKh/Wh1K24MWAfeL6SsDbPtLC/2Zon/3
00/Ho2+ffjpxShoTBXDx6+TnU+kwWDvI8C72DI7NUnZ8UEGMGsb17FtNW3SH
mYkUzerYFt26XpJR8wg+fwAWJej2ykWZNM0bASa4uM7TKrZqnmIXH86yv0k4
idkK4s+EMJwaEao+yTkBy6fBhz9PHoaLghxYsAiE1bypkw7FOstmpymEggf5
xQzuCN6GtFuu6ysuydifL86boGQD9OfHlCRaQ1jCPrfK0cWzKjlx2TyH4XC2
z0dQjRyb8rxhjnXQK2Y0266FAdsUSbubkVt5xpP9M1UiGytaxX0QNKdHDvK8
nsNH+mj/sX5Rnhm6ddj7Oqg0hryOmdYXk5R89J2CWSez7yBKWkKgl7owd2GC
WFhVJICPI2eCdHsU4K9TIrDA3GIxB/qYjsitHlE9Hae3Kd1YvFRoHKrgECOY
pDf06UW5mqYjzBxAfMmyxeY4kQoJGVZ1LNTLvBGcz2BhEne7afkR2pXyPmpO
WZhGGCJZIwMrW84sLrvdwTHY6LUnajKh2djUbQx0ydA4o53HLEwm0Q+XCaqL
e4c3FeV3eW+FlmJNPBBphFkwv6TDudEyrJmJIGzjqLQXoguCC0gMm9UZRpmB
MQuWIN6TPG+KwUOzGj2WsrXOL2a8j1YpPKQHdbEKnopjESlAYY29lNGUOWiE
1DF7awmgbzWF9J5qqBGTA4+7W54TE6il4znyMUrhqtgQDy4TYhqLCELAOLCV
Me/uCG+Njb8HDeF4UKsIe/Z9J3NEDN4lJTfxXod7ochjVUObpCRllcM1nRG2
9jxT95QK2Rf3k8U/8XgnF7CxIfQhd+T9fXnxTE7ciGGj8ieFidP7pQyZMB8i
qgyxqwdOiogaTYS+9rO77DcyO7w/cywdlbeZsKlaBPzDybE9htNndNdc3iYT
xzyPre7NIfl8DcKnAmbLEF+tKGFOLmxtEHC1RECLrkpFExTp4xsmshsIlx9V
uNR8DAyVlDtyPScBQilvnmWRXE8RxsYvR5Us1T8rcVsWcpYXakFauY5GJxGU
DVBZNU5xHZWUwbtNEXU0vVEPdZWTNaeQfN/Gry4vN5VmJVZE3yXZUzcf4WWJ
xsA2f0cFWbu6c5pZdBkTKDOPEBhfOxaa+AFOqhJARB4wYtxm9j9cU6p3aeTW
qV4h3YgU5LGQG/bhbpug6MfqullpvEe0W3yPSFDtK9IXKlMYuOxh2RhlOkEV
6eFTm49okcvz8SlpeHb0CQFH+wRyMvop5yCXjCSGqwt2nTaSlmaN5RHFwyHV
z3S8AsNhlCxF/zvuyy+iAONO2VM56X4lO7KI1D02F8JGWDfYtZi8t6R4GCsn
EgvWmoq1FMKjCAUXpaNCGjDamujPJK5ULQ2GhavAZi02aAiPfuEHX2TP0puj
ccxIY9H/Ucug1kYDJCMt4W6UFxLfsdK+EW8hYbP7B4VtN5Ghra9dLtY3LWXf
u4/R9CDV2bQGF0IHGi4ctq8ijkAgnpSFpYRoxtA5sRwTuaev47pLzSgsm9Qn
SklkhiY8eMd1j82Pj6oFNgMHNl/H0CKtrZeFuLiaW8ETE1/D1frQU6MWcLjF
iUGixwdpsdmJJIWL5zM/UMljdpBGHHV0oyaafhrXcs15pD+Daa0mo+NtzZJ2
GRz29Lylq5OzjsjzIO5J9mW3yoRPetm+Kv++x0CAmKeHRL65sU6ZwyhasUyR
zxovShjNDcvumY8M9M7AGlUSNi6X3mNDXdWoqIuJfjmTqOg/RwfO79w4xgoy
dt8gvKMpLbmftF53R1gBqoiPmQnx4wCg7cCtwg2a7BpB3A4cJbx9hrlCiQu/
KdzNNes/QXF2LFHMxS3JbpmXy6U4FhMIQv9dRWVWU4TXSz0xZS3dbdCawyp3
qqeSbRADrUmzKysE7BpUIK+BgcU0xHdoWXoqh8NBXGideMtoOz7Sy6CKvvqy
9VD6NH0zweOOKOzYEkt75vcluPeibBb7Let3RLc1BjBkER7fHdvzuQlUl151
dskbSMD/DstszhbRTBERY0255m+zsEbbk7YsuYrNItHQuNnSCsakrtsevN/v
mJWUIdASXYyBl9oA6nqIU+FOTb8d6a9k6nKWLRHS4GL1+YPYdGWdCTden8Nn
sPuklNhHuct8qQ+88+EF/jlxJmp6QQfn0UJ61IrRxuDeZYND83iyrE/3ojVq
mVwl+gYHFmt0uUo4KzOoW3x1z2BrXM4sQuEEq0cQRbHDjJm93zWkbR6zcfi0
MmdOvy6Ea8w77knh5jwDahbnRXYKx0O0lrVHCYpSGLQ2zEBUrZ0erDDwmAYB
nT74zAHN0bb64iWV44lVxk3pjMBlJCV5wpFrXwqWYfXudnbXn95Rek9ExZTL
QnLZmcoz/LnH77YWpjIlSyaSXQ/9aATdFSwI45Hf5bFA68x+0Bnp21FBZgZP
DRareTh1qWKufNnEedMXqF6+I1XWKHPJ6aY3Ry2MSfnmPpKyH5yF6NqgeY6E
qvlHhHOUlwFbCp9g/ee9cZa+FCfWWZJ7Kvlpy3onJMRPieid6CdRAQJTBqwu
0DNQrfj8yy8fSmEW6h2r8EgA73AGlq0qCehSH9Qy0VeCWqCwyywTmAhqoIKY
dWjmSBRtrroeJb4+OLU8W1eG/oM6SFY51fR1ibTozljkFe2b55xPS79EqdPE
7uHXr/BeR1ybkisle+oMNrG6MfC+/lWFNnMCCdRPa83TO1xbqO+llAZJ4nhc
/WZfaQaykCDF59QZ+l9/fnomK/XVZ5+BAogb7fWPF4E/+8sXX/yT1HIeJU6W
qLW4kNlhLi7NYC+ToPESeWaUM5/G1O4pBk5VprXwNi02Uj7rtWDNWEnyPp+v
W3/rI+Oak5X0VBxBQ3gFm3dpdok6ZMP3yt85Gbz0eDWDpNMCFijbYBemeB4s
DXrH+fc8L9ovcf83SUEBjzeObCs9YuFJ5B2WqHIaMnSrp+xVec/eyu55Ur5d
TqjIhvhIDWUkEDVkAYiYYwf91Q0mQgtRk9VhS1RCyIlVlRpmcIzUKLGYfojw
QxGF2cCnuPn3jRIMtIwkSkjKYWu4wTHfYxQR6ERCWAhl7lmUjV31uDILys1e
JJRm6VJGAEhZXVGFuJsC+f3pGBATpTECVsugO2vI0yEFGdks65W/5rTppULs
I9aCpDMSxuhmo7j0a+ucye0fsXNUxzXWsqSUVmMUiW4BhW8Zea4NUXA1rQku
qdZNzjSFCiXmtzvu4jssuVifjL8vgoKxsejZchosnasNXCbLg9kuQwaBGSII
8QddB8qOj/UwIEYowUyEusx+aDmmMSQ4fhlwEF+HAZuHgC1FbdzO1BESLwOj
em/BNuv0xNIOJNiYiSbSyusUYEZ5ev5p6YjRU/MTFc2Fyi42rzWbkiLgxPby
DTvXBIcjJxhug8zfBniAB9eGJq1jkisbGKLWpiFEZeNu4GTvLH2Bt0dzreQ8
ZbtDz2cSx1bhT7NCzYh0chAejQUKi3lIWMzjK0Gx5+U3ESwsS9FXaBk+4odQ
MJOkBcQaYRPGZ4F+vuDc171VEYqIfM4VSwCO91DuRqewpd9b6hmhn7eCY7Pn
TnjL3UR9LyoKWK9obDNOnMdUygux7oiAw2uiryPRHhm1CAJrUxNPlSGjZVZY
YkisNSS1uolFqqFYKsdkOjWPqdV8cNFJoChiegPVfhWa4tGI7gxODIdfRLYo
z0pX80ZfSXmKRDSQh1bpUmI/TANlyjcmvdRIbXLxxqlZuUQ8d3E4aSc9kpKN
T5OCAD0oD8zlGag98PLnerZ7BHJVz5d5x3k5T5NvMBfmTnbv9PT8RBIB8Fyl
aR2C8uPliFWFJZUqz1JaIFFDUjINZjYv2VopjQAtOkxvz+H4vf5zz6X65Te9
DjnvmfBwCGdYlU6S0Rto6bdvPAENKTVK0pKC4mcayKWfRq36CnlIRGebSNd6
cHo1+rwjeZzQSQYh+0MXHjOhO/HR4v3zs7u52ANtcFW46X/Iyeau6pFjULwT
RtpEvGlNHTo5nJioMIXK6HHY7+PvC3+BHrsSZ9kLOtCivQcrYko+KXWS9JK+
hs2Q9b7B5cVdvyQ2Oq6oB4YrWgq3sZ9nSVLn+B78iW5IKVabjAyN17Fbv0X+
DnWEjMsd5YEYmme4uuf1heo3lLvyVI3ADeiRakKpFyc7RxWZdDItwXUPGjhB
H3spTiX2weMsG1a+9LWVYlaoObJKcx4J2CnlMCAaspCTBDhafzpzDHPIrlde
Y0dxdCxD+Um2IJjYYi0kkJqhLFmqkvWqGr+aGGPKok2kkGkLfRfBW4RzZdKb
YGo/XuTzwrFcEicsVUEsQeazd2VR11fERsQd11iNwURy9ScokEnCc3aJB2Uc
JZz0BSepCpHDutgwX6hDvbNFFGv8iWWsciomFvIb2lhGY+S8iOgdKzgsGm4w
0N0tYtn7avcV3+CbCGk3i8xmBQcG7el9GneBAP6zyLZVqFzY4mlpvKfYA6Zg
Ir8Ra86lWhFKji3E5a9wTUrMbgFdXNJhMJCGtqMxVWhN5rW/pdBQmiGcuZCk
psjZJyZDhWEaNcBOVEjz/YOZ4pjaVwr11OOmqbFmN9WDowN+SspSan4d81ug
7tXUcxhZRVXfUh8UZ8GVwg5ghQPSAcGEzwoECtmPlUO/tykoL2RgNiSuAvxg
mMcba3xyVTKY1oA2Gt2+TYZpTl5nl8TwQWZigZ7WWoinGKODG14V2TZO7CQu
6wLuq1wzwoa/VDVM2BHnRWCW1Ms9ooGUmMLWXuLsmnITpb+7JyUtGLt8R7x1
8KI7euBFThCxb9FMBSdSQktk9xM4GA1W4ml/6pBekh/Dei8+fplHmJa9J7TF
35nby+NQhP+BYglITWvHR2m9S7b3bQwixfMucAPH1iRf8NURLz7HKMu+b69W
BTjh8PpNsbw0J8eoHWzpTykvwqznoDiKdx4ValoVTqm/MDGM0vkFCzNWxqSM
FKaaA8FmGev7xKzcadYdOuqCRfVjGZeLkmtfYjZeZe/ZafXPTDKloRdg7Wo5
45p4FBV6K2dHTRTqp/rUrDpl7UoX4VltyvZKXENt5Ow7l3Qh1WLUP2Dl4Yi4
lj3DzO+AcTCEBhPxCKZZRmL/EYvI1C466HbYCHhGEAyWUzgMjjv70jROH47O
wHmOjjMwRS5RD+AkXCNQxQzskkkj2CZwvhBPkC2sGMILiqUs80BbAOvBLShQ
sj60ZI9bbSR5/7IE5a51+gepmBT2oQFpMbyYt3972YImGyGTjE4l4+WggBQ1
5ZrxLh3zkQmZ2lPxJRNboN66SNXGJHkyHUiXViXUN0n6eXTradHeBYt5JM+U
dEev0xjVxVN1m5pT8ftIaT9ets0D3IZxgklmBfxSbzQ6QYN6Ufs3kk9ITdNm
EA7YJiyPsWzkrHdNI55uMWpxv/9EJMS05R9N08594LHKRpMC80bWelTkWdli
q/7lU2t73viRyoBHG6bwAcrQ4HJp+2h/MXgZgE2Cqg/gSIsM4FaSEhWhj66S
H476lOT6I6wJrcWIOSZ3TuoBx0v3QmtETXqXDV8XbFwlV1hSMkLvUOQfSMrC
0KiTnwhmbLQjkd6QM6rl47ttjKAY63gkI5GzxyGMjYb2+wAAznBk41u95cGe
UYORybXwDoOnE9UphPN+9onkeZi0PE75HNUZiVEQu7Feg6xNtZIKTtCHsdAe
rroWXatj5pPQkpKosVJ/K4ybG5DBvONwmZWXuUXy2IEfqEZf3C0bLNSxdDb8
hio4mBFrcCm0waroL5QoY4y64ql/IihZCl5j4VdXosaE2ftPVi1TKy/aD30n
W5KCqaYk1zGg2I2IExqyJ58ibCvRDoSo/77mFMuUgFa74a4M3C3adRVY956A
tY+BpKPjuPfy7ALxek8u/KGPPE85lX528Rm8/I15aVFv56Vmz4b0KS200asm
iHOeYJY56Lsqcj3u3PX0Mowhhg2HTJXfAP7Z0jvUx+drJViRIW8lpuJNu6Lp
0hI9792Cgc8jiM+aoZBRWyYfO+kUZmYYElcFXYigULn7df2dJFGh705SjGsF
Y+7G/AOtSwPrhqxTbjhl30bQfAKOZsWpwWwFtBcZi/+AlItOa9ip4KPiO2hB
YHKreD7IhyxQlLSRh2JY4OKj4tKXA/5c8z0ktqWKWU7T0LZIRZOrx4qzuiJU
NPtaRpsnjrs1GxZHdsQaRKxNvJVWuMPqc5xuUI3BXcKzkuAgMTZLP7jLVaCm
GJ2RNmR/cOF4qckgyyAoM5hebj1Oo6+SYu+USWS6c+0zJt5VxjkhFeeJmTjG
HkdFgs6WlcKJW9ZmTivuGUFWT6ZgCY+WyHsJD6E5s34znV/w4E8v8NoLejkI
OpxjQqJBKNkRbm2+NnFyafoIjsNFrFTXflYcAoenMbMAjsz7989eU6DwrKfv
UDHXEnUV1mOtdq/kCuLhAUGg5TZ6gjKooDwu8ElQUoa3ZXISOUus7oVyVshP
lY2hJ/uYhV2Z9dT232GuvxQozZTSCvPQGJsHd/EaxBxd4pvlQJyapkhQLQFP
oZcL19RR05VIDEackfikXz7F+hs8DqUxBjx1qUlmKi8xZsgvpO6dpgDLGQkr
sCvWFRX5lXL1JN23e6p1xioP2rwygWUlLZGv2DOz8rXs9pBbSaV2ikffKTzj
XsnnBMUuhlWZkhxWTa81YQ2tKYwukdFE6RwvMcvYLpfiA+9qzt1mCoi2IKf1
FjbFUtMmcGGZQjCxulGtwUaGlxhl8sUycD5iTRhMq6zmM1U4HEpnnuH3IieJ
80dLw8Z3GWMFQiCVn4njXikXolYQ5MqW8D1z2wo0lG3rQw3HgW6zBYgTiwkr
Q5boWj/V1fRVsdsvhUjouuWghczH+096P5het1P3A9C8UtVLCmP0DKTUbzRx
ZUXSyzKIA1BwmmkJ290Obg51IB+1J2YhBiTRNCHhZyDCHpeuwQk8DRVnX7Iv
PqhpLQNs9ElLlM7jVaqmlnIO+NIenC0Y8jkIPy6WJ5wXLQsKE/7EEoZJ6OQ/
oN67nAmFSOmAglR/NKZLt0fkXBAwmF0V5MVzGaY2jLvKURUoRgKL1SxJHh0i
SbRAYpHmd5ndqWArNHFb3EHCWgz8wHEAMUJFGSbZHQcRu6NWS42VzUrOGx40
Y+5v5kPFa/AgipWxinl3l6xU0uVjSxTcEiV+VHMPMVUP3RDkG+mVP3OjQW9w
p9VyfJc0YYy0xooqOGQJBki9a64xh7hjRYUw1Iao13BNQjnISe4tOh0pbCxg
slXwqDzL/1ntGzooORyKA9x1jEMjIBpxgrKt/jNzO5xJ3Y4g+SVUN+94oXTk
PEnBV+SxUFBcK6DsoDNDXlvB4RMjT68SmnrRjTTLMZlRV9AJHIygagaDoJOM
c8E9Op7tYrRnetY1Qhj4sNRaGP5uG92O2Ccp2aVQnAQHLT5GHpH2khi1JcIs
aFKiie8Rk6ewSemUZDzfaFVKak+Kk2danNxVG9aearC3pDrQaKazJs5wfYcb
mQS2wnj7cvFil+HVCLmQvfxuqy5SuqGQ1w192bTOeVMKY0Ylhn++gv24jMhU
z90DtkyriHs8DiHWEOqVT1TgkVc9yHtfk9ceabDRnGHnhLA/Uq9KKgnJe7Cm
AA49K3l54xcTEQ4/JXrhhn8Yej9EDCdpgxj4ayIJX5KzTqvZr11XokuuceCs
VBGfKWEiR3OcKDHCkNirQfcpLLAmHu1xruCehiWlZG8qqwDq1cI5GXWG+rDs
B6ofNCzAI4WJNHbFFzSfaYnhGIc1znJITjWRhsPvSy7n239ECVXUNT8Hc3tV
coyqqoMQ82yk/E9yBPnkaViJFInoX00PsVH8hE0sJKRbfnjCHAZjfO2FTsRI
rvNMyxFqpkk0wNzc6SLdFVeBlF2K6ZNB6RDTAj9uMp9s8pvWiLiPvxXNGoQJ
lU1f7zX5GjEeWjk1xVOTAbFiQRNsZnpebB7IoB/5gS/ZEkVqWwp02LkHUAEh
vHGVKuEqXmswU1BMIUdK8Q7sHsqfdjkmKr+DiMAJ6sa6tMQyLqkeUh3SYTno
BzRkGT/nYSNtuNB0umLZI+ThkkxjRiBn0PR87HaJshMCbmzlAL0vW9/ZA0Jt
q0E89QhwdRHWtEmZIgm1CtEtk3iaKlfFMUnjIoEWM9PVXSAWt/cfiZSQeWGe
X4wCykbsVW41NJD4l3wUTeE/joDwhokLqRqTZvTj3pfYuSo7qQVn3lwSKzG5
2e1ViyYZFUaSoeS8pbBRoW1Me/axIbBWf/dBLwO0SqG4pG5/1AcD2AtG7BeV
srz8bo8tVFE3+SJivz7q8UGs44+93Lnu7MRZuSPR2e4RVJzEQMjcqggAJ606
f2HT/4y9K8/Vu/L+E1uaKfRzGhv6wOgDy70QfA7pLhTxo2A+JfMXWnCBtS/y
OXXmG0hXQRJuq6iIUAsJQCR7JSvNLUkcLaD03TeV0HQdfZhZm2KIgpN1Th8j
zpdpGL988OCfPnxAn2bm4j2xS1qYnsp5WmjFIXYID0P+zGgGgX7UqgDoDWC0
xzhfvZ+Rf5VqXqSJr9h33EXOvxfRi72IOg6KCjUzQEZ5IbUcEzmWnBKE672n
/vT6IkWeezm4QbvCYEB+tvdkNX3AT/c/R0dsscEaKDcxEzdLXTQ4DKceo7e2
RFbxEWcjeWJhPzCGDoWRYKyWGmLHK4ZsychgzlgkzZaBe2vJoER9/0TQ6iyN
c8yhgFNTKnFd3Wc7ya73m0qzZUultgukHuN9HWMgW4wnoRpkEsKwI+wr6h9a
mmo4r20stdWnDHD3Fl79vfLJZtnqonHOFdH4tJEwQbLhE+w1oal6KGoLTaf9
FIpUbt7FPVW2kcHF5ykxt/XcxOCbFPXJOdzFvAyszn/tMlsKPxxKt3JVyd3Z
Cyo8YvqBppPSzwi2OHIAmcGOiNT0V/hClBYOWisFKnvT5pRf66Xf3C6Q1RE7
uYWgh42YLa2x35hJl14vUrMi74It0OteELB3xvC64VS8EXijcgTiPrdECGV3
ZUp6Glq8yEX2oI25BmGJvpveLIUjW2nCdqQ3REqF/1BN1/5Y0QiFY51v8Fu/
J/R66WJxTXHdSW4xqEo/vHz22HVbwqa84zRTNe/GNJxJ3zAsPd5J0HJcPdpx
BpOTEd0nSdHJxF/C5IwsRtOtrdc9WYo4rS2lQw0OOT7lr902LXnMBhrrd+id
dCWk6ZSmw/KeTuuO09g4G1FGwMz1QYtuRBsIq2jBniV4N3YTUX0iAowKKWk6
hjhYcPZJ9lumzhxOn5FrRNTM2SA31YmLcfEkczTSm31rRMvQADsPj7jQY0Eq
8QsP3OkBtUcpeqgxOymUdtBWYdUvi3TPy2lmXKbph7gt1MJx2nVP3vRy+o+q
eh/Gb6CedNSL1zyXQy3H2UWT9I5LtjoJH9pDjKEIvX2feJG95MMpFCFkvzZm
QuUcAyHB7GTKqd95AJfhNiIYxSVQHmRre51HndnmnFDBU7o6KBKt5+qWvZlp
3SVkMa4eMoZj7izx6jYKNKHb85FthnBQXDtqg6iq9dExHltovPnkB2sKZk2L
QA3YVIzicOfFWCRpnj+lrz91xi40G0suE2h/KQllJLGCKjEGHmDVg5nHPUo/
yf309nmSjX0c5GM815XGbvNlvuO/6EEXF48QKGKqX0+6GSGkgwklgJiIXxbI
mlYrjMwc6XaIUppSJ9r0GPHBv6mRUNBldMpDuNOHzBis5ciu5aGMH93BtcCW
pDgBWVCpTYrMzrXxMXOrYPz5nDJk9aA5Tm1kjsl+7w286TQXb3WeiuxgRUuc
kJhO0U+BuD7kaSOAAHVlh2Vf4N4QkG90ZqDtEFLbIQ2ij0AM08xTI2JDmVAv
YAcpB/4Rc3xEjZcc6rRKqUxA0KpQY34A44vXPF6iERTOeMlVgR25yam4to3d
1JBUpPKKeD+jt+iqg0u76gkkix3wlpaAS9lkI4Zn6rFhG4IAGYt4Zwoxi/x9
s3Ebtu6beMu4cZUF2EaEOIy8RZ+jGqyR9VH1+54zbAxJjod30j+9vgccyLTi
0/0f0BhbxoggD1SFGLw0YUJrBL0zTlbJmWbPtGXfsIQ9MlYWVmM3ZVFdOmIb
GxhI+WKzou5pdqHiPZDRqVjnm9VQjup4yTMCNpXuFvEN8/iC0d+rd7o/hngB
JpAEXA8TwDSgMJC+kRsF76lXzJrXy9MbmC0TvRVD3t4WdMQzzmOYpLNFK2KX
oGl1euupim17NWKR/b3kYGYjcwqyItCtzIFDzVJ20nh+SO4lE6mKpvRU8kjy
Y2QiQWib+08q/dOoA5rB8nmVtjVhStGYCCAA6QxOQHOpuRSFOL2L9ogV5KVk
GHd5CtrNusEabT/dXD1pyE7DaM9mEpA/N/pcxt86HLxVeU0CcmHkHojXKc19
1FYw9ZbqNiFIl3JHNK+FrTw0GwIn3fRGzFwW5oxjjiId/pBi3ToVTl8+nYke
rbeZEOseVWB6lYeHLupJD+5kU0g+K07Sc3dtTGeP+rgeDRQwxymReqnT/aLj
yXpJvdQ23OKa76XyUG9cTwbpIDB/86a+KirJ/LKXLRxnmCcIm8RraKD8s61A
iVVduelfBFRjTW6JpQGYKUO62RySnagbr3dtCGY3hIjRVmdDogsd2/BUK0gz
yVFJj/UyIjIvclPQztgUl2VXbqn8A58O07gxQJcsBSxMtzdaFs2x8qdnKNLk
VyPB/iMblEI9uFQqghaFUtZqSPyWg5WGUqhyV7U5hMGDuUkgidmom8ai9S4e
OzxqYUBz4pL4o+x0C+AqfWux2C6B6N+yluwUilnqR5cwRNwOO+3IsaTF4sv+
qY4zHEGqRPcjzgK53Q9yq+Wut6lFqbrWkZrPXS88O1GtX41gWKHh8dDXKz41
UbkSCH6idU1o6OEWoQAd7hvzg6BqYmT3rDa0wmIWw2XRl/QUfvnOeRzjfSyP
BysO4+7BSeLeSfKwYspHT3MLAy1jYiXIqTUOLEsgWiLzuMzkJ4uofKwWBgsj
+H7HLjROVBwUicjQiA6TU31q+XEzi1DX5KU2Sc7Y5oHir3F+KwnYFISp5khT
r8hMWUnVBy5DjuBw/xPHT+/uSPaZx2yC0SmnjX6TK1BVT5ZIDfOC611OG2Fy
2+UcWNUxLGjELJDrlWBZRHPO2RAEtMESTzYcxYFyiDOUFUKn274MzaBZXzBb
2L0ir2dPW2DTteEQPsaLj+orwzJOnk4wzbxV+E1zFI9+YZ1272gdPxCVfms6
CqMxQQl5SL+RDeqdX8z3SmlBiTcfJvyHi+dMlNhX5JDOQlU5I+81wTd+e1F5
4p4EURH5TQoiHx/0LwrR69UtjEhkLIimKb2dwIFa5vJQ57HyW68L5IghPOJ1
fcXFMzRr19xeC884qzYLpWC+69jfE0ECbgTkWEBFewq3HZNpDyAdan4zKtkE
AHvFXNixy0G97yILpWIlEao755pTxGea+k8wfela2nXmT/EORganPbK6LJBn
SAbGrzKsErIjbLByBqwre8TzLgK0lO6G3pDUvaE6nB0ZbMyDh9lD1cD33xJg
sR34XFIPH3r3YSavvJMEhB/1p9YbpFWF03ge4jueey4nBaoq4F3DDyn5KLH5
C+Vb6hxIItNH9+lTl0XBMKXapRPx5Mq1ZQeW2Gv08HG3khFTVQMD7vJpJ8RD
PPL8Gko5QTfXRocXT6/D1ieduW0ktDE8HExFFVMKlW3iG9ZVRJYq8wHqPb9O
r+T4ftObac862kYWttAY6EHDrSZDl4TLmKJLljHVWkhgJequQmHQKtMv5j+R
DPIp9Y2LpiV2RZKAQkDAluxjhI0qCpyYv0Xzxh4j0De1lQMp2F1M/JB0PxXK
Wn2Ci9cvOdzrsYmgvOJR1eIWKf5HNCEtFV8y6xRzXWth0CNynjdOEP+oSfiY
QuHZiZt94QPErfMDrBrL+cQ9SuNVxw9dmx6NHg8tpTcYVXyCVG3H7zt82bZu
9UXYQkx2kgiiD9oXh4Rz5kiyT8r4wAul8ZjA6IUUX8MAgLLxydo4GF/oUW4U
dwR5+4Y51xIqa8n0f3FNdA3YYiMGloLFBVdPhB/GgdT6m0cqwjhGG6ZT0LCZ
OPnhZ2IJcDY5FhBSJX9wyjioQndcS2oYsm31rZzUIuPdYpcaldBM3UXzPXqQ
iH8BZ3JRNFgQgzhOY2nIu60/ln7lj0qs1wZVcDKSinvFAjauTS9/RUy3ygqh
hglN/njggx+hOedyCjEFAOnDUmDOUdY0Yd/Qy3IQxorNWeiB90fPySNEquWq
F+iIQRpcdNgBmONEv5iYoqBs9ygtyPMzCYQGJvt/jI3AAg968MmpnrfFQA0U
mzLczgIumqDXlcgYSsv04Q0YEms/8cLaRTLq8iAL86nxAwVR5ASpYZp/ndYf
5kiS1rfomvLykmxdRXBcqOc9nJ79aAU655HEVKMFrvKBnTMZCYO0lVjqJ9TJ
PFAbdVIhgU9V0lZCky+NtU6CJuxmcVSA6s0giYmOO1NEiX1I7ltEnOwrXR1/
i3mJgApJ0AQoUUiOUf6NV4ruoe0DOjYixtmX3eQR2BKON4ffmlcS08LVqs0E
BuoMBjFqfQVJLrU9fPmqwJBez2zuxodrHCoEP+WylApewVcI33JdFdOunvqg
MDNR3BjZ1smtfRmkc/qkmbrpK1jQiyHv3kjz7FP96MZ7PI/wltj400rFk2K0
bjUSZIW1SdlW12UOe2xAlsg6JWM8x7OFOAtUD4I6BrRgHX729CUKtIYhACPl
lV2Ms8ien57Zr6VNU5kv0uur5fvLIopF0eBS439jTqxwGB5XuJ0pyL4gI6Rs
XPGCEmlgMZUUBBkioiVPbwnDxSPg1BDlQXh+evFff34MT71//89Pp+ezFonN
89/K6TZvYY6m8Mi7A1Ldva5fCT33317+RBK23O6knKuRvccXYOo/QRtijQrp
TOQVdceHK9yhV5MrzSdOEJK0QShhi4ppWAfK2uiExHC1ojUu4GpG7RInXAmN
iSCzb1Tpul9wpYsUgerWoBMO5toxtkc+UKVgMDNPCmcE9npUwiZHPBBbLqrU
moCVclOl6AK7fYsDh0u4FWYqY/uezWYnnj83Ahwc1FXGpW58VULQsNzVbF8F
51hnpwDFh39gl7AKtZciB/hyV+YK2lKpOU7vi/jELskGNU6/5DKm+SOHNi44
7xmSw0ccXlQNMs3hSxQkVjJp0qd4QUI7KSQykrfjZE592WtXMINnjCyHUjJY
uU7ZDBp8betKE5JCYyV5msnUxA0ZF4Vep8UgGjy+rPCwRFMXtiMPUrUqBs0I
CiGVb+HnlKrHjIfO2m61Spyoov2AgplX49P8StY4NSmLdyhpPESE+WKY8xSR
Xt/4qR/xXPhJEVVM7e6cSjZua7i0rX1oT9ICX9UdP1PrhGCjmDxFyZAgRco2
hhWU47p/O3tlSvhvx+o2iYRxWunR2j0aSTi/mGWkdecZlSfuhSzPL3pM13oo
kLDWXdaN1F8K8YpFq9KyvWNyMzw7CD62VIxKXkQGLr8t6BMYD0UpS05exlFM
tFYr52TvNvnBe+/N+s4jkSeOBrcVV0DJQc1qyoJjfY5x2QQg15cJkQCJ6zf7
n95j+YryDH1rVEWXqpRDn1dGohY7dkJGhBbzGW9ppAmvt1BcmphE1aNqehdB
yZkrOWWC9YW5lMBCX4wKNQVLPfuNzHXhHRIWG660RPRc/SJYmyH7ecNrCldo
EGJgVTmYqVV3KWydtubwiyps6jFaFvlGQkqUkrygUg5FYywgTLgyof2BOhZ0
dF3Vm/ry4EKT8kqKzAuju6TncRf04pAadIO0oa4OBl8VaHA8YflGLHgpx6Xe
3rJaU/R3czA6VOdQ71EmwkEt8u3EEZpSAIKLPyj/uyy+uV446suJSVIHWToh
/k0RmZqSv3Tp5G6oJA7LhlXd8Qm4FyuQtyfRyZy9RXG1eJud9eIXCMqC6y1o
qpOKiMgERa6xeBDrpidlNJNDPUZhvi833RQDjcmVqWUyvGlnxS7VlnOuEo2X
3n5rvOSKgflwYJUrxt72M4lzcrqQyP2DvcTwHnbv3irytMm98fbdl599NZji
kxlHj35/LZDNNqPyDhiUoghm7eg5Yz/uRVZ/d55PZkOTXOVIVO6Q7mSluT+E
BDZl3qtRkjrJhlJ5WZGiZ3ewKsKpR4DAO7yK7XrKWiSZ22T1owu/qZxd6hVw
dB764iw4eC5QMOi092PGefDKxosLmLVqWTfOfdxxtZcgNMF5p6VnfbkqQ2kc
M7XvwZo7Wj/rR7lykovAAFqgQZSTE3H0GGfSMacG0vm1YlSCTppdgAxFxUsY
HQaTwZkX5sALY8lmAizlI9CyVy4DHQfPXFPuIg6ASv69rrM7+J474kx1tm5i
KGtNxJ7drif5xUXok2CjgOda4JTSq83g3323fflvpkwKyYYaS4AbTsygQ/0A
txaOdm6GKiHDMO721N6vyMzhrGUGPODUE0HN6YYqCaOmj9YoEjRt6zmxEPjN
vbDiOIiPnLc1luDAUH4k03P+M7r9klObMVxxc3AlSi56taxUrb+bhmNcPEzo
fI3I2J0ml7zoy+b8zoofX4Ng8dTC89ZTrTQ8lsw9EItlDRYib9zZafVKJube
mB32xMJITshIlcbJiPBj/YkEXMvopXwz5cTvFpln9CgnCrCmeDfUUEkU65tc
spViWAnOVXFNNXGPRjfxdWxTDXvlo2gHrr6MVM/f8Mt6D4B+uKy3tLiUBROF
jE6fVuvZlu8q2mkiwb5hJQxPZJsEG1mNQ20/33iIS95eje8BhWDGgxpy4cfS
wFvuT7ZlAOTtYchYRA1oJ1qsgobklNaLTpBHRCLKMQ25Wen1yRaUWDF5aZOa
SSE67lQQ2UHgTYHlUazzvFx2A5OTEPTrer+MZCk5+ZtI7WyWNstJwbZb9oPA
syOjfq+Up9QsT3nVuFLMLUdv4kxvvizWNdqzjH4s62Us84fyhmM9o3efGhHs
DyiEID1G+Ad9GJQFQ1RHIgcxQI8mo8Uzo+dOzq1zrYAlXOH7UfEKqni9f/9j
Xe/Kdx8+iPZzzE3vAK7vP8nblAvj9XH3vhTnJRDcynZfr9yZFLRpSNsJ/09j
19bTxhGF3+dXWOlDg2RQ4aWXB0uGtAlFNDQNjfpUATbBjbNredeJEsR/75zv
XGe8dvvUFNt7m9mZc/ku1BVWk9Zx0VYikVkBdYrrmCZFQmOZcpaLG6bslb10
UG+Uds2hBTqhcte7XcaW/AhMHvJM9vdP8xEvjg7+yLoaZRejG/wyHtL/+SIC
/O4BQAftg8zLX02D4LGpm8Uey9DJ2O18jf9UHL0kgwZk9hLp0o5ini25ERxM
NccAzHY8+5IwlKwjj9yfRPRQtvmccwiK4mibovWd5rAJSqY5ucnNZwONvtsC
ULnXpurVH5eMM+gVJrluibhc9ompYENJp+QnFUC6ZKs0rbuGeLlUzeZ4VV6J
vttkGBRRbCGssi6rCwuJyittQ1ldrbSNdryIaJj4jLEspPd7tVoqgMCiOAHi
2xYUE9qJhApZ01to1tuB/Bv45PmtRMXfu79EmazJKtqRJabPkqsJC/KhooJJ
ocSnaVp1o36sn0YvH2gNYQghkk47EGdtr3NA4GmbiX2KS9VCGa6kZS5wYHgl
iVBjH3HClLOp9xIzrviHSDqAk4uHKblZEviVN5JsxAJ1q2GqJfrP/UMUwa/w
ysrhMAkF+GvhVOSuFWBcBZCo6J4ZcfxlBD87VyzQ7XHKYjEIy6rjGuF+lF6I
pjBHDizNOZifY2eUPbewhAeTsU77qYVQyb6Xl4RTBCx8XDnoCZGOCIGyXOd+
DrhD27QfgdUfPWf/Y3dvRFiSV70bpBgH8ghNtrB3pQ2N7IaLG9x0VUS50AQC
idwaFTtqHqK67+KOKcjtSWVR1ZXkSfsA8UNTfMa+qcgZl6qo8mrUMvOXcykC
rkqYEcqdLH/frvlNTHwUuQwsOggDy6JqFKfc0U+CV5P1MurpYNm48/VMVW7i
MaoAjwW7Ri8sILSFz00TVA53Xc2LVrpgc8+pioUZeoecWmhvJD/5a5H+Xy5L
SRNRMNvulBzpmcQHkTYkVs6PJkbyc0yjbkN1ctHXLTDagg3lYKpgfy/UFVtx
GPmnVLRx4hgFDgeBrKd3WGkpHlWhCw7ai5AYV0b0l3nC/NO6KxGyRxgjfwbq
RXS2S0lY12TVyrcowZkzLdXMUnyT1pvGSOklN2dhsl/MH2WQTT2G3A+udYjV
okV7Cnfa20Xs73ZpBgEcp1LrnuGgPm4SjlyfS1BDQ76e32PKK3ZMpThvCWGr
0VnH8fM2CpDBOosVmNAg00PcLTorBH2aJgXj1UIOzS3JmZ6l0n2qSEJXYPaC
iy6pwDCV94NRo7R0aZ9a0TrEKyzXBWY5SVmWLqJ7dP0/EH1Ay5HFUFfPy+18
qTBc6phKkGCuLqsVUSdht5hTPVr8HCkAN/UAnM1Hc9eysqiAkmkOcvIYFimk
dPqc9rps3+N5QKxwUiJVCp1Wm960y9Eo7Gm5X9nh9wy17Ez5EMMhY6CHSFuh
3kh59/fUY1JxmbErLgycZF6CPUMz2f8VSGkevgjWkioO5MgHYhS59gKEouhu
KbQV+qiQ9WKBGDFPlbpEWbNPlRK0jlPcoSogJIvGcq18np6Vn/7NffhnlVwM
OucY0Js+WkkW4SG0xoE6y6Ekyrymo1pdgqAYHLZ/G73DtBXDm3Bv0vUI7WNK
y9qCtNqWBsvQZ45QTiuI/f4mgYUSRbQ7QrH7iPHqLcHrf07YiK7b88y9dcAF
F8vSjLfNOlrDqVCxF77DPCN0KnEhxv6+7fixJsjAfgcX6SRNc4EEyy4Ayv5X
sUfgdriDyAXfZaLCC4ZItesUsIa15RvhimhRXoHCg9gKuxqVhSlsuM87FYcj
z9++/uX6ABiPwpW5KzmqVy6OO5W91lOjikUlUj8iXUfFugDFpIqCJqLC947Q
cp6d7GPtGsfB7yoHwEzHJXAC0GdC5h3CybKuzqUv7KlQt89/AVKEOzeOH6o7
EQOOyphLbMHEaAlyavPGgsG5XPGj2MKVP8VeHzdN1cVxaUnxLIm1uW11QNk1
+GO2piDPs0Vja3AUWRUzKwlorZHPsGatOwPTuGG0QzvvEtfKkYCX7ap8NZHI
8QVTHw5aA50twVGrR5yZPYxG1/S1ftMwPkLVfBxxJGVJMJRKu15PP9hodS2F
o9LrBMG84EDrrkaUYkoFG4TlNQQdr8LUakoQi6xaE2gc72XAPptqS6BHu0AX
M+sXaLSVlfyh8nDYG2UcyRrZWfqVM4Lua99u+YHS277TBlXbBl5AXXTdRgEi
6rJAPdO6RPthPl8BxwD8o+0pTtQIzhmR4Js4Vw45ZyxPVqoIW9NqtjEhXkWT
rCUtsu6tPd1RZCqqLY8UOySBV39kuCKu2xzd5hXxIBC5C4WneOlf9pYT6/MO
MEVsl1IN0QmMLDhXgxCBxtpSExCvlgjDLlSQlECpWChBXjg01bEgTFuLg3C+
03N0PWePZO6F8aJWnT5xQbnnbXoYzG2EVHqIO5/dz40H8FRkj1MrXP6ovHwK
k5ulBuvIaUwJq3TxzQNeACzurRPQ1RyPSJRM6cpKuY6MM1MWqssCJj1TAC6p
hmPiLxpKtDx+NTk2fkNmOeV5MM7uADUzvj6qzUyixId5QuX4AcEf/S/R/zsn
2XOo1hnWgeK/vAHlJB5MszZ/dN+D/C3fH4didUDDhautHg9dWLzgUk3UGSmO
KBEHCdHWk/P7JApKc8ncRmoJgUoCQ7nP1Inn6BbXRgIRn4jDUUCeRtL54sX1
dROiUco5xsGztkUlsCAFisJGYVZ6s0TSst4oM0+Xubu8bigPh5YXfSejdBeZ
dTO3o6Qid6KKG8gLrdOA7bv8usbj6gMUV3dMixyMfVrsaZtPA62xn6+i6oBZ
gUtdOKahtFxObBroMwF4wqZRVKY8F6S5Ww2j30JDKDzViRPctjMunL5cmuRt
Lsq6U4kx4hTVYDalPyWIvLnLSfvH/HWiVYlSKKKTr4LO0Cp8FADbMjMm+8TK
svxICYti5X4vcWDB6d/KP5Od+5YMLU9Pfzv+8elp9HyWA6d+9P3BOP9xevbi
7cmx//X4mO0p8ye/Xp58Fz44OcBmMcujPtvIILQNRidfgMbR+HI3tMQE4VS9
LmpmLLp26TEyC4Lh6TBVRRQO8vmwFHTM87PiO93Vm+Mfnp7Gie+F7pDv6+zi
4vLq6t1f9he+H/5Q/y23+uriEg9BLgxvtrhccMIzp/LP7aGXBO5llbqhgPmO
enUoeQGwTobvH7F8Pj6+uzo9PTl5etKxECHtgWPRfQmeHlh2O8yAys44sSNS
vv2zi3jlfPjSeyDPkv7BMOpq3oF7ElHb1OU/zTZLcrRdiJ/g4+PZq4FDDznC
0+59yJf+QDlo8z7t0CpiTtM3o/Ppb9Nqv5TOT8Wab1qFtGBO0e+O0r8j6udy
4okBAA==
</rfc> </rfc>
 End of changes. 346 change blocks. 
1806 lines changed or deleted 820 lines changed or added

This html diff was produced by rfcdiff 1.48.