<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.3.3) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType="IETF" docName="draft-ietf-mls-architecture-15" number="9750" category="info" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.22.0 -->version="3" consensus="true" updates="" obsoletes="" xml:lang="en"> <front> <title abbrev="MLS Architecture">The Messaging Layer Security (MLS) Architecture</title> <seriesInfoname="Internet-Draft" value="draft-ietf-mls-architecture-15"/>name="RFC" value="9750"/> <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche"> <organization>Inria & Mozilla</organization> <address> <email>ietf@beurdouche.com</email> </address> </author> <author initials="E." surname="Rescorla" fullname="Eric Rescorla"> <organization>Windy Hill Systems, LLC</organization> <address> <email>ekr@rtfm.com</email> </address> </author> <author initials="E." surname="Omara" fullname="Emad Omara"> <organization/> <address> <email>emad.omara@gmail.com</email> </address> </author> <author initials="S." surname="Inguva" fullname="Srinivas Inguva"> <organization/> <address> <email>singuva@yahoo.com</email> </address> </author> <author initials="A." surname="Duric" fullname="Alan Duric"> <organization>Wire</organization> <address> <email>alan@wire.com</email> </address> </author> <dateyear="2024" month="August" day="03"/> <area>Security</area> <keyword>Internet-Draft</keyword>year="2025" month="February"/> <area>SEC</area> <workgroup>mls</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>. --> <abstract><?line 222?><t>The Messaging Layer Security (MLS) protocol(I-D.ietf-mls-protocol)(RFC 9420) provides a Group Key Agreement protocol for messaging applications. MLS is meant to protect against eavesdropping, tampering, and messageforgery,forgery and to provide Forward Secrecy (FS) and Post-Compromise Security(PCS).</t>(PCS). <!-- [rfced] Abstract: We do not see "Group Key Agreement protocol" in the text of any published RFC. Should this term be lowercased or perhaps explained in the body of the document? Original: The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol) provides a Group Key Agreement protocol for messaging applications. --> </t> <t>This document describes the architecture for using MLS in a general secure group messaging infrastructure and defines the security goals for MLS. It provides guidance on building a group messaging system and discusses security and privacytradeoffstrade-offs offered by multiple security mechanisms that are part of the MLS protocol (e.g., frequency of public encryption key rotation). The document also provides guidance for parts of the infrastructure that are not standardized by MLS and are instead left to the application.</t> <t>While the recommendations of this document are not mandatory to follow in order to interoperate at the protocol level, they affect the overall security guarantees that are achieved by a messaging application. This is especially true in the case of active adversaries that are able to compromise clients, the delivery service, or the authentication service.</t> </abstract><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/mls/"/>.</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> <middle><?line 245?><section anchor="introduction"> <name>Introduction</name><t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH</t> <t>The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/mlswg/mls-architecture. 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 messagingsystems,systems and is also deployed in systems for other purposes such as calling and conferencing. In this context, "end-to-end" captures the notion that users of the system enjoy some level of security -- with the precise level depending on the system design -- even in the face of malicious actions by the operator of the messaging system.</t> <t>Messaging Layer Security (MLS) specifies an architecture (this document) and a protocol <xreftarget="I-D.ietf-mls-protocol"/>target="RFC9420"/> for providing end-to-end security in this setting. MLS is not intended as a full instant messaging protocol but rather is intended to be embedded in concrete protocols, such asXMPPthe Extensible Messaging and Presence Protocol (XMPP) <xref target="RFC6120"/>. Implementations of the MLS protocol will interoperate at the cryptographic level, though they may have incompatibilities in terms of how protected messages are delivered, contents of protected messages, and identity/authentication infrastructures. The MLS protocol has been designed to provide the same security guarantees to all users, for all group sizes, including groups of only two clients.</t> </section> <section anchor="general-setting"> <name>General Setting</name> <section anchor="protocol-overview"> <name>Protocol Overview</name> <t>MLS provides a way for <em>clients</em> to form <em>groups</em> within which they can communicate securely. For example, a set of users might use clients on their phones or laptops to join a group and communicate with each other. A group may be as small as two clients (e.g., for simpleperson to personperson-to-person messaging) or as large as hundreds of thousands. A client that is part of a group is a <em>member</em> of that group. As groups change membership and group or member properties, they advance from one <em>epoch</em> to another and the cryptographic state of the group evolves.</t> <t>The group is represented as a tree, which represents the members as the leaves of a tree. It is used to efficiently encrypt to subsets of the members. Each member has a state called a <em>LeafNode</em> object holding the client's identity, credentials, and capabilities.</t> <t>Various messages are used in the evolution from epoch to epoch. A <em>Proposal</em> message proposes a change to be made in the next epoch, such as adding or removing a member. A <em>Commit</em> message initiates a new epoch by instructing members of the group to implement a collection of proposals. Proposals and Commits are collectively called <em>Handshakemessages</em>.messages</em>. A <em>KeyPackage</em> provides keys that can be used to add the client to a group, including its LeafNode, and <em>SignatureKey</em>.Key</em>. A <em>Welcome</em> message provides a new member to the group with the information to initialize their state for the epoch in which they were added.</t> <t>Of course most (but not all) applications use MLS to send encrypted group messages. An <em>application message</em> is an MLS message with an arbitrary application payload.</t> <t>Finally, a <em>PublicMessage</em> contains an integrity-protected MLS Handshake message, while a <em>PrivateMessage</em> contains a confidential, integrity-protected Handshake or application message.</t> <t>For a more detailed explanation of these terms, please consult the MLS protocol specification <xref target="RFC9420"/>.</t> </section> <section anchor="abstract-services"> <name>Abstract Services</name> <t>MLS is designed to operate within the context of a messaging service, which may be a single service provider, a federated system, or some kind of peer-to-peer system. The service needs to provide two services that facilitate client communication using MLS:</t> <ul spacing="normal"> <li> <t>An Authentication Service (AS) which is responsible for attesting to bindings between application-meaningful identifiers and the public key material used for authentication in the MLS protocol. The AS must also be able to generate credentials that encode these bindings and validate credentials provided by MLSclients.</t>clients. <!-- [rfced] Sections 2.2 and subsequent: After the initial definition of "AS" in Section 2.2, we see alternating use of "AS" and "Authentication Service". Would you like to use the abbreviation in running text after the initial definition? We have the same question for * "DS" and "Delivery Service" * "FS" and "Forward Secrecy" * "PCS" and "Post-Compromise Security" It seems that each of these terms is used often enough that the abbreviations could be used after the terms are first defined. A few examples (for "DS" and "AS"; "Delivery Services, which is responsible ..." has been corrected): * A Delivery Service (DS) which can receive and distribute messages between group members. In the case of group messaging, the delivery service may also be responsible for acting as a "broadcaster" where the sender sends a single message which is then forwarded to each recipient in the group by the DS. ... It is important to note that the Authentication Service can be completely abstract in the case of a Service Provider which allows MLS clients to generate, distribute, and validate credentials themselves. As with the AS, the Delivery Service can be completely abstract if users are able to distribute credentials and messages without relying on a central Delivery Service (as in a peer-to-peer system). Note, though, that in such scenarios, clients will need to implement logic that assures the delivery properties required of the DS (see Section 5.2). ... She sends both of these messages to the Delivery Services, which is responsible for sending them to the appropriate people. Note that the security of MLS does not depend on the DS forwarding the Welcome message only to Bob, as it is encrypted for him; it is simply not necessary for other group members to receive it. ... The Authentication Service design is left to the infrastructure designers. In most designs, a compromised AS is a serious matter, as the AS can serve incorrect or attacker-provided identities to clients. --> </t> </li> <li> <t>A Delivery Service (DS) which can receive and distribute messages between group members. In the case of group messaging, the delivery service may also be responsible for acting as a "broadcaster" where the sender sends a single message which is then forwarded to each recipient in the group by the DS. The DS is also responsible for storing and delivering initial public key material required by MLS clients in order to proceed with the group secret key establishment that is part of the MLS protocol.</t> </li> </ul> <!-- [rfced] Sections 2.2 and subsequent: We found the use of "which" in this document confusing at times. Please see "Restrictive (that) and non-restrictive (which) clauses" on <https://www.rfc-editor.org/styleguide/tips/>. When reviewing usage, it might help to ask this question: Does "which" here mean "sometimes" (in which case it should be "that"), or "always" (in which case "which" preceded by a comma is correct)? We found the following confusing: * An Authentication Service (AS) which is responsible for attesting to bindings between application-meaningful identifiers and the public key material used for authentication in the MLS protocol. The AS must also be able to generate credentials that encode these bindings and validate credentials provided by MLS clients. * A Delivery Service (DS) which can receive and distribute messages between group members. In the case of group messaging, the delivery service may also be responsible for acting as a "broadcaster" where the sender sends a single message which is then forwarded to each recipient in the group by the DS. The DS is also responsible for storing and delivering initial public key material required by MLS clients in order to proceed with the group secret key establishment that is part of the MLS protocol. ... Alice, Bob, and Charlie authenticate to the DS and store some initial keying material which can be used to send encrypted messages to them for the first time. ... The simplest pattern is for a client to just send a Commit which contains one or more Proposals, for instance Alice could send a Commit with the Proposal Add(Bob) embedded to add Bob to the group. ... In the centralized setting, DoS protection can typically be performed by using tickets or cookies which identify users to a service for a certain number of connections. ... Each encrypted MLS message carries a "generation" number which is a per-sender incrementing counter. ... In this section, we consider the case where the signature keys are not compromised, which can occur if the attacker has access to part of the memory containing the group secrets but not to the signature keys which might be stored in a secure enclave. ... This in turn induces a signature key rotation which could provide the attacker with part or the full value of the private key depending on the architecture of the service provider. --> <t>For presentation purposes, this document treats the AS and DS as conventional networkservices, howeverservices. However, MLS does not require a specific implementation for the AS or DS. These services may reside on the same server or different servers, they may be distributed between server and client components, and they may even involve some action by users. For example:</t> <ul spacing="normal"> <li> <t>Several secure messaging services today provide a centralizedDS,DS and rely on manual comparison of clients' public keys as the AS.</t> </li> <li> <t>MLS clients connected to a peer-to-peer network could instantiate a decentralized DS by transmitting MLS messages over that network.</t> </li> <li> <t>In an MLS group using a Public Key Infrastructure (PKI) for authentication, the AS would comprise the certificate issuance and validation processes, both of which involve logic inside MLS clients as well as various existing PKI roles(ex:(e.g., Certification Authorities).</t> </li> </ul> <t>It is important to note that the Authentication Service can be completely abstract in the case of a Service Providerwhichthat allows MLS clients to generate, distribute, and validate credentials themselves. As with the AS, the Delivery Service can be completely abstract if users are able to distribute credentials and messages without relying on a central Delivery Service (as in a peer-to-peer system). Note, though, that in such scenarios, clients will need to implement logic that assures the delivery properties required of the DS (see <xref target="delivery-guarantees"/>).</t> <t><xref target="fig-mls-overview"/> shows the relationship of these concepts, with three clients and one group, and clients 2 and 3 being part of the group and client 1 not being part of any group.</t> <figure anchor="fig-mls-overview"> <name>A Simplified Messaging System</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="256" width="456" viewBox="0 0 456 256" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,32 L 8,80" fill="none" stroke="black"/> <path d="M 80,144 L 80,176" fill="none" stroke="black"/> <path d="M 144,32 L 144,80" fill="none" stroke="black"/> <path d="M 168,144 L 168,176" fill="none" stroke="black"/> <path d="M 184,32 L 184,80" fill="none" stroke="black"/> <path d="M 208,144 L 208,176" fill="none" stroke="black"/> <path d="M 248,80 L 248,144" fill="none" stroke="black"/> <path d="M 296,144 L 296,176" fill="none" stroke="black"/> <path d="M 304,32 L 304,80" fill="none" stroke="black"/> <path d="M 336,144 L 336,176" fill="none" stroke="black"/> <path d="M 424,144 L 424,176" fill="none" stroke="black"/> <path d="M 8,32 L 144,32" fill="none" stroke="black"/> <path d="M 184,32 L 304,32" fill="none" stroke="black"/> <path d="M 8,80 L 144,80" fill="none" stroke="black"/> <path d="M 184,80 L 304,80" fill="none" stroke="black"/> <path d="M 80,144 L 168,144" fill="none" stroke="black"/> <path d="M 208,144 L 296,144" fill="none" stroke="black"/> <path d="M 336,144 L 424,144" fill="none" stroke="black"/> <path d="M 80,176 L 168,176" fill="none" stroke="black"/> <path d="M 208,176 L 296,176" fill="none" stroke="black"/> <path d="M 336,176 L 424,176" fill="none" stroke="black"/> <path d="M 304,80 L 336,144" fill="none" stroke="black"/> <path d="M 152,144 L 184,80" fill="none" stroke="black"/> <g class="text"> <text x="76" y="52">Authentication</text> <text x="244" y="52">Delivery</text> <text x="56" y="68">Service</text> <text x="108" y="68">(AS)</text> <text x="224" y="68">Service</text> <text x="276" y="68">(DS)</text> <text x="432" y="100">Group</text> <text x="212" y="116">........</text> <text x="284" y="116">........</text> <text x="388" y="116">................</text> <text x="184" y="132">.</text> <text x="448" y="132">.</text> <text x="184" y="148">.</text> <text x="448" y="148">.</text> <text x="116" y="164">Client</text> <text x="152" y="164">1</text> <text x="184" y="164">.</text> <text x="244" y="164">Client</text> <text x="280" y="164">2</text> <text x="372" y="164">Client</text> <text x="408" y="164">3</text> <text x="448" y="164">.</text> <text x="184" y="180">.</text> <text x="448" y="180">.</text> <text x="184" y="196">.</text> <text x="236" y="196">Member</text> <text x="272" y="196">1</text> <text x="364" y="196">Member</text> <text x="400" y="196">2</text> <text x="448" y="196">.</text> <text x="184" y="212">.</text> <text x="448" y="212">.</text> <text x="316" y="228">..................................</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ +----------------+ +--------------+ | Authentication | | Delivery | | Service (AS) | | Service (DS) | +----------------+ +-------+------+ / | \ Group / ........|........\................ / . | \ . +--------+-+ . +----+-----+ +----------+ . | Client 1 | . | Client 2 | | Client 3 | . +----------+ . +----------+ +----------+ . . Member 1 Member 2 . . . .................................. ]]></artwork> </artset> </figure><t><xref target="fig-mls-overview"/> shows the relationship of these concepts, with three clients and one group, and clients 2 and 3 being part of the group and client 1 not being part of any group.</t></section> </section> <section anchor="overview-of-operation"> <name>Overview of Operation</name> <t><xref target="fig-group-formation-example"/> shows the formation of an example group consisting of Alice, Bob, and Charlie, with Alice driving the creation of the group.</t> <figure anchor="fig-group-formation-example"> <name>Group Formation Example</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="464" width="592" viewBox="0 0 592 464" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 528,64 L 528,144" fill="none" stroke="black"/> <path d="M 528,176 L 528,208" fill="none" stroke="black"/> <path d="M 528,240 L 528,320" fill="none" stroke="black"/> <path d="M 528,352 L 528,448" fill="none" stroke="black"/> <path d="M 128,64 L 392,64" fill="none" stroke="black"/> <path d="M 8,80 L 304,80" fill="none" stroke="black"/> <path d="M 208,96 L 392,96" fill="none" stroke="black"/> <path d="M 88,112 L 304,112" fill="none" stroke="black"/> <path d="M 288,128 L 392,128" fill="none" stroke="black"/> <path d="M 168,144 L 304,144" fill="none" stroke="black"/> <path d="M 200,176 L 480,176" fill="none" stroke="black"/> <path d="M 280,192 L 480,192" fill="none" stroke="black"/> <path d="M 360,208 L 480,208" fill="none" stroke="black"/> <path d="M 264,240 L 480,240" fill="none" stroke="black"/> <path d="M 8,256 L 256,256" fill="none" stroke="black"/> <path d="M 144,272 L 480,272" fill="none" stroke="black"/> <path d="M 104,288 L 480,288" fill="none" stroke="black"/> <path d="M 88,304 L 344,304" fill="none" stroke="black"/> <path d="M 88,320 L 368,320" fill="none" stroke="black"/> <path d="M 296,352 L 480,352" fill="none" stroke="black"/> <path d="M 8,368 L 224,368" fill="none" stroke="black"/> <path d="M 176,384 L 480,384" fill="none" stroke="black"/> <path d="M 152,400 L 480,400" fill="none" stroke="black"/> <path d="M 88,416 L 312,416" fill="none" stroke="black"/> <path d="M 176,432 L 312,432" fill="none" stroke="black"/> <path d="M 176,448 L 336,448" fill="none" stroke="black"/> <polygon class="arrowhead" points="488,400 476,394.4 476,405.6" fill="black" transform="rotate(0,480,400)"/> <polygon class="arrowhead" points="488,384 476,378.4 476,389.6" fill="black" transform="rotate(0,480,384)"/> <polygon class="arrowhead" points="488,352 476,346.4 476,357.6" fill="black" transform="rotate(0,480,352)"/> <polygon class="arrowhead" points="488,288 476,282.4 476,293.6" fill="black" transform="rotate(0,480,288)"/> <polygon class="arrowhead" points="488,272 476,266.4 476,277.6" fill="black" transform="rotate(0,480,272)"/> <polygon class="arrowhead" points="488,240 476,234.4 476,245.6" fill="black" transform="rotate(0,480,240)"/> <polygon class="arrowhead" points="488,208 476,202.4 476,213.6" fill="black" transform="rotate(0,480,208)"/> <polygon class="arrowhead" points="488,192 476,186.4 476,197.6" fill="black" transform="rotate(0,480,192)"/> <polygon class="arrowhead" points="488,176 476,170.4 476,181.6" fill="black" transform="rotate(0,480,176)"/> <polygon class="arrowhead" points="400,128 388,122.4 388,133.6" fill="black" transform="rotate(0,392,128)"/> <polygon class="arrowhead" points="400,96 388,90.4 388,101.6" fill="black" transform="rotate(0,392,96)"/> <polygon class="arrowhead" points="400,64 388,58.4 388,69.6" fill="black" transform="rotate(0,392,64)"/> <polygon class="arrowhead" points="184,448 172,442.4 172,453.6" fill="black" transform="rotate(180,176,448)"/> <polygon class="arrowhead" points="184,432 172,426.4 172,437.6" fill="black" transform="rotate(180,176,432)"/> <polygon class="arrowhead" points="176,144 164,138.4 164,149.6" fill="black" transform="rotate(180,168,144)"/> <polygon class="arrowhead" points="96,416 84,410.4 84,421.6" fill="black" transform="rotate(180,88,416)"/> <polygon class="arrowhead" points="96,320 84,314.4 84,325.6" fill="black" transform="rotate(180,88,320)"/> <polygon class="arrowhead" points="96,304 84,298.4 84,309.6" fill="black" transform="rotate(180,88,304)"/> <polygon class="arrowhead" points="96,112 84,106.4 84,117.6" fill="black" transform="rotate(180,88,112)"/> <polygon class="arrowhead" points="16,368 4,362.4 4,373.6" fill="black" transform="rotate(180,8,368)"/> <polygon class="arrowhead" points="16,256 4,250.4 4,261.6" fill="black" transform="rotate(180,8,256)"/> <polygon class="arrowhead" points="16,80 4,74.4 4,85.6" fill="black" transform="rotate(180,8,80)"/> <g class="text"> <text x="24" y="36">Alice</text> <text x="96" y="36">Bob</text> <text x="192" y="36">Charlie</text> <text x="396" y="36">AS</text> <text x="476" y="36">DS</text> <text x="28" y="68">Create</text> <text x="88" y="68">account</text> <text x="356" y="84">Credential</text> <text x="108" y="100">Create</text> <text x="168" y="100">account</text> <text x="556" y="100">Step</text> <text x="584" y="100">1</text> <text x="356" y="116">Credential</text> <text x="188" y="132">Create</text> <text x="248" y="132">account</text> <text x="356" y="148">Credential</text> <text x="32" y="180">Initial</text> <text x="92" y="180">Keying</text> <text x="156" y="180">Material</text> <text x="112" y="196">Initial</text> <text x="172" y="196">Keying</text> <text x="236" y="196">Material</text> <text x="556" y="196">Step</text> <text x="584" y="196">2</text> <text x="192" y="212">Initial</text> <text x="252" y="212">Keying</text> <text x="316" y="212">Material</text> <text x="16" y="244">Get</text> <text x="48" y="244">Bob</text> <text x="96" y="244">Initial</text> <text x="156" y="244">Keying</text> <text x="220" y="244">Material</text> <text x="280" y="260">Bob</text> <text x="328" y="260">Initial</text> <text x="388" y="260">Keying</text> <text x="452" y="260">Material</text> <text x="16" y="276">Add</text> <text x="48" y="276">Bob</text> <text x="76" y="276">to</text> <text x="112" y="276">Group</text> <text x="556" y="276">Step</text> <text x="584" y="276">3</text> <text x="32" y="292">Welcome</text> <text x="84"y="292">(Bob</text>y="292">(Bob)</text> <text x="368" y="308">Add</text> <text x="400" y="308">Bob</text> <text x="428" y="308">to</text> <text x="464" y="308">Group</text> <text x="408" y="324">Welcome</text> <text x="464" y="324">(Bob)</text> <text x="16" y="356">Get</text> <text x="64" y="356">Charlie</text> <text x="128" y="356">Initial</text> <text x="188" y="356">Keying</text> <text x="252" y="356">Material</text> <text x="264" y="372">Charlie</text> <text x="328" y="372">Initial</text> <text x="388" y="372">Keying</text> <text x="452" y="372">Material</text> <text x="16" y="388">Add</text> <text x="64" y="388">Charlie</text> <text x="108" y="388">to</text> <text x="144" y="388">Group</text> <text x="32" y="404">Welcome</text> <text x="104" y="404">(Charlie)</text> <text x="556" y="404">Step</text> <text x="584" y="404">4</text> <text x="336" y="420">Add</text> <text x="384" y="420">Charlie</text> <text x="428" y="420">to</text> <text x="464" y="420">Group</text> <text x="336" y="436">Add</text> <text x="384" y="436">Charlie</text> <text x="428" y="436">to</text> <text x="464" y="436">Group</text> <text x="376" y="452">Welcome</text> <text x="448" y="452">(Charlie)</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ Alice Bob Charlie AS DS Create account ---------------------------------> | <------------------------------------- Credential | Create account -----------------------> | Step 1 <--------------------------- Credential | Create account -------------> | <----------------- Credential | Initial Keying Material -----------------------------------> | Initial Keying Material -------------------------> | Step 2 Initial Keying Material ---------------> | Get Bob Initial Keying Material ---------------------------> | <------------------------------- Bob Initial Keying Material | Add Bob to Group ------------------------------------------> | Step 3 Welcome(Bob)---------------------------------------------->(Bob) ---------------------------------------------> | <-------------------------------- Add Bob to Group | <----------------------------------- Welcome (Bob) | Get Charlie Initial Keying Material -----------------------> | <--------------------------- Charlie Initial Keying Material | Add Charlie to Group --------------------------------------> | Welcome (Charlie) -----------------------------------------> | Step 4 <---------------------------- Add Charlie to Group | <----------------- Add Charlie to Group | <-------------------- Welcome (Charlie) | ]]></artwork> </artset> </figure> <t>This process proceeds as follows.</t> <section anchor="step-1-account-creation"> <name>Step 1: Account Creation</name> <t>Alice, Bob, and Charlie create accounts with a service provider and obtain credentials from the AS. This is a one-time setup phase.</t> </section> <section anchor="step-2-initial-keying-material"> <name>Step 2: Initial Keying Material</name> <t>Alice, Bob, and Charlie authenticate to the DS and store some initial keying material which can be used to send encrypted messages to them for the first time. This keying material is authenticated with their long-term credentials. Although in principle this keying material can be reused for multiple senders, in order to provide forward secrecy it is better for this material to be regularly refreshed so that each sender can use a new key.</t> </section> <section anchor="step-3-adding-bob-to-the-group"> <name>Step 3: Adding Bob to the Group</name> <t>When Alice wants to create a group including Bob, she first uses the DS to look up his initial keying material. She then generates two messages:</t> <ul spacing="normal"> <li> <t>A message to the entire group (which at this point is just her and Bob) that adds Bob to the group.</t> </li> <li> <t>A <em>Welcome</em> message just to Bob encrypted with his initial keying material that includes the secret keying information necessary to join the group.</t> </li> </ul> <t>She sends both of these messages to the DeliveryServices,Service, which is responsible for sending them to the appropriate people. Note that the security of MLS does not depend on the DS forwarding the Welcome message only to Bob, as it is encrypted for him; it is simply not necessary for other group members to receive it.</t> </section> <section anchor="step-4-adding-charlie-to-the-group"> <name>Step 4: Adding Charlie to the Group</name> <t>If Alice then wants to add Charlie to the group, she follows a similar procedure as with Bob:sheShe first uses the DS to look up his initial keying material and then generates two messages:</t> <ul spacing="normal"> <li> <t>A message to the entire group (consisting of her, Bob, and Charlie) adding Charlie to the group.</t> </li> <li> <t>A <em>Welcome</em> message just to Charlie encrypted with his initial keying material that includes the secret keying information necessary to join the group.</t> </li> </ul> <t>At the completion of this process, we have a group with Alice, Bob, and Charlie, which means that they share a single encryption key that can be used to send messages or to key other protocols. <!-- [rfced] Section 3.4: "or to key other protocols" reads oddly. Are some words missing, or does the text indicate that other protocols are keyed? In other words, is "key" used as a verb here? Original: At the completion of this process, we have a group with Alice, Bob, and Charlie, which means that they share a single encryption key which can be used to send messages or to key otherprotocols.</t>protocols. --> </t> </section> <section anchor="other-group-operations"> <name>Other Group Operations</name> <t>Once the group has been created, clients can perform other actions, such as:</t> <ul spacing="normal"> <li> <t>sending a message to everyone in the group</t> </li> <li> <t>receiving a message from someone in the group</t> </li> <li> <t>adding one or more clients to an existing group</t> </li> <li><t>remove<t>removing one or more members from an existing group</t> </li> <li> <t>updating their own key material</t> </li> <li><t>leave<t>leaving a group (by asking to be removed)</t> </li> </ul> <t>Importantly, MLS does not itself enforce any access control on group operations. For instance, any member of the group can send a message to add a new member or to evict an existing member. This is in contrast to some designs in which there is a single group controller who can modify the group. MLS-using applications are responsible for setting their own access control policies. For instance, if only the group administrator is allowed to change group members, then it is the responsibility of the application to inform members of this policy and who the administrator is.</t> </section> <section anchor="proposals-and-commits"> <name>Proposals and Commits</name> <t>The general pattern for any change in the group state (e.g., to add or remove a user) is that it consists of two messages:</t> <dl><dt>Proposal</dt><dt>Proposal:</dt> <dd> <t>This message describes the change to be made (e.g., add Bob to the group) but does not effect a change.</t> </dd><dt>Commit</dt><dt>Commit:</dt> <dd> <t>This message changes the group state to include the changes described in a set of proposals.</t> </dd> </dl> <t>The simplest pattern is for a client to just send a Commit which contains one or moreProposals,Proposals; forinstanceinstance, Alice could send a Commit with the Proposal Add(Bob) embedded to add Bob to the group. However, there are situations in which one client might send a proposal and another might send the commit. For instance, Bob might wish to remove himself from the group and send a Remove Proposal to do so (see <xref section="12.1.3" sectionFormat="of" target="RFC9420"/>). Because Bob cannot send the Commit, an existing member must do so. Commits can apply to multiple valid Proposals, in which case all the listed changes are applied.</t> <t>It is also possible for a Commit to apply to an empty set ofProposalsProposals, in which case it just updates the cryptographic state of the group without changing its membership.</t> </section> <section anchor="group-members"> <name>Users, Clients, and Groups</name> <t>While it's natural to think of a messaging system as consisting of groups of users, possibly using different devices, in MLS the basic unit of operation is not the user but rather the "client". Formally, a client is a set of cryptographic objects composed of public values such as a name (an identity), a public encryption key, and a public signature key. As usual, a user demonstrates ownership of the client by demonstrating knowledge of the associated secret values.</t> <t>In some messaging systems, clients belonging to the same user must all share the same signature key pair, but MLS does not assume this;insteadinstead, a user may have multiple clients with the same identity and different keys. In this case, each client will have its own cryptographic state, and it is up to the application to determine how to present this situation to users. For instance, it may render messages to and from a given user identically regardless of which client they are associated with, or it may choose to distinguish them.</t> <t>When a client is part of a Group, it is called a Member. A group in MLS is defined as the set of clients that have knowledge of the shared group secret established in the group key establishment phase. Note that until a client has been added to the group and contributed to the group secret in a manner verifiable by other members of the group, other members cannot assume that the client is a member of the group; for instance, the newly added member might not have received the Welcome message or might not have beenunableable to decrypt it for some reason.</t> </section> </section> <section anchor="authentication-service"> <name>Authentication Service</name> <t>The Authentication Service (AS) has to provide three services:</t> <ol spacing="normal" type="1"><li> <t>Issue credentials to clients that attest to bindings between identities and signature keypairs</t>pairs.</t> </li> <li> <t>Enable a client to verify that a credential presented by another client is valid with respect to a referenceidentifier</t>identifier.</t> </li> <li> <t>Enable a group member to verify that a credential represents the same client as anothercredential</t>credential.</t> </li> </ol> <t>A member with a valid credential authenticates its MLS messages by signing them with the private key corresponding to the public key bound by its credential.</t> <t>The AS is considered an abstract layer by the MLSspecification andspecification; part of this service could be, for instance, running on the members' devices, while another part is a separate entity entirely. The following examples illustrate the breadth of this concept:</t> <ul spacing="normal"> <li> <t>A PKI could be used as an AS <xref target="RFC5280"/>. The issuance function would be provided by the certificate authorities in the PKI, and the verification function would correspond to certificate verification by clients.</t> </li> <li> <t>Several current messaging applications rely on users verifying each other's key fingerprints for authentication. In this scenario, the issuance function is simply the generation of a key pair (i.e., a credential is just an identifier and public key, with no information to assist in verification). The verification function is the application function that enables users to verify keys.</t> </li> <li> <t>In a system based on<xref target="CONIKS"/> end userend-user Key Transparency (KT) <xreftarget="KT"/>,target="CONIKS"/> <xref target="I-D.ietf-keytrans-architecture"/>, the issuance function would correspond to the insertion of a key in a KT log under a user's identity. The verification function would correspond to verifying a key's inclusion in the log for a claimed identity, together with the KT log's mechanisms for a user to monitor and control which keys are associated with their identity.</t> </li> </ul> <t>By the nature of its roles in MLS authentication, the AS is invested with a large amount of trust and the compromise of the AS could allow an adversary to, among other things, impersonate group members. We discuss security considerations regarding the compromise of the different AS functions in detail in <xref target="as-compromise"/>.</t> <t>The association between members' identities and their signature keys is fairly flexible in MLS. As noted above, there is no requirement that all clients belonging to a given user have the same signature key (in fact, having duplicate signature keys in a group is forbidden). A member can also rotate the signature key they use within a group. These mechanisms allow clients to use different signature keys in different contexts and at different points in time, providing unlinkability and post-compromise security benefits. Some security trade-offs related to this flexibility are discussed in the securityconsiderations.</t>considerations. <!-- [rfced] Section 4: Should "the security considerations" be "Section 8" or some other section? Original: Some security trade-offs related to this flexibility are discussed in the security considerations. --> </t> <t>In many applications, there are multiple MLS clients that represent a singleentity,entity -- forexampleexample, a human user with a mobile and desktop version of an application.OftenOften, the same set of clients is represented in exactly the same list of groups. In applications where this is the intended situation, other clients can check that a user is consistently represented by the same set of clients. This would make it more difficult for a malicious AS to issue fake credentials for a particular user because clients would expect the credential to appear in all groups of which the user is a member. If a client credential does not appear in all groups after some relatively short period of time, clients have an indication that the credential might have been created without the user's knowledge. Due to the asynchronous nature of MLS, however, there may be transient inconsistencies in a user's client set, so correlating users' clients across groups is more of a detection mechanism than a prevention mechanism.</t> </section> <section anchor="delivery-service"> <name>Delivery Service</name> <t>The Delivery Service (DS) plays two major roles in MLS:</t> <ul spacing="normal"> <li> <t>As a directory service providing the initial keying material for clients to use. This allows a client to establish a shared key and send encrypted messages to other clients even if they're offline.</t> </li> <li> <t>Routing MLS messages among clients.</t> </li> </ul> <t>While MLS depends on correct behavior by the Authentication Service in order to provide endpoint authentication and hence confidentiality of the group key, these properties do not depend on correct behavior by the DS; even a malicious DS cannot add itself to groups or recover the group key. However, depending precisely on how MLS is used, the DS may be able to determine group membership or prevent changes to the group from taking place (e.g., by blocking group change messages).</t> <section anchor="key-storage-and-retrieval"> <name>Key Storage and Retrieval</name> <t>Upon joining the system, each client stores its initial cryptographic key material with the Delivery Service. This key material, called a KeyPackage, advertises the functional abilities of the client such as supported protocol versions, supported extensions, and the following cryptographic information:</t> <ul spacing="normal"> <li> <t>A credential from the Authentication Service attesting to the binding between the identity and the client's signature key.</t> </li> <li> <t>The client's asymmetric encryption public key.</t> </li> </ul> <t>All the parameters in the KeyPackage are signed with the signature private key corresponding to the credential. As noted in <xref target="group-members"/>, users may own multiple clients, each with their own keying material. Each KeyPackage is specific to an MLS version and ciphersuite, but a client may want to offer support for multiple protocol versions and ciphersuites. As such, there may be multiple KeyPackages stored by each user for a mix of protocol versions, ciphersuites, and end-user devices.</t> <t>When a client wishes to establish a group or add clients to a group, it first contacts the Delivery Service to request KeyPackages for each other client, authenticates the KeyPackages using the signature keys, includes the KeyPackages in Add Proposals, and encrypts the information needed to join the group (the <em>GroupInfo</em> object) with an ephemeralkey,key; it then separately encrypts the ephemeral key with the <tt>init_key</tt> from each KeyPackage. When a client requests a KeyPackage in order to add a user to a group, the Delivery Service should provide the minimum number of KeyPackages necessary to satisfy the request. For example, if the request specifies the MLS version, the DS might provide one KeyPackage per supported ciphersuite, even if it has multiple such KeyPackages to enable the corresponding client to be added to multiple groups before needing to upload more freshKeyPackages.</t>KeyPackages. <!-- [rfced] Section 5.1: The only published RFC to date that mentions "init_key" is Normative Reference RFC 9420. May we cite it here for ease of the reader? This question also applies to "epoch_authenticator" and any other parameters mentioned in this document and defined in RFC 9420. Alternatively, we could add this sentence to the end of the Introduction section: It is expected that readers are familiar with the terms used in [RFC9420]. Original: When a client wishes to establish a group or add clients to a group, it first contacts the Delivery Service to request KeyPackages for each other client, authenticates the KeyPackages using the signature keys, includes the KeyPackages in Add Proposals, encrypts the information needed to join the group (the _GroupInfo_ object) with an ephemeral key, then separately encrypts the ephemeral key with the init_key from each KeyPackage. Suggested: When a client wishes to establish a group or add clients to a group, it first contacts the Delivery Service to request KeyPackages for each other client, authenticates the KeyPackages using the signature keys, includes the KeyPackages in Add Proposals, and encrypts the information needed to join the group (the _GroupInfo_ object) with an ephemeral key; it then separately encrypts the ephemeral key with the init_key [RFC9420] from each KeyPackage. --> </t> <t>In order to avoid replay attacks and provide forward secrecy for messages sent using the initial keying material, KeyPackages are intended to be used only once. The Delivery Service is responsible for ensuring that each KeyPackage is only used to add its client to a single group, with the possible exception of a "last resort" KeyPackage that is specially designated by the client to be used multiple times. Clients are responsible for providing new KeyPackages as necessary in order to minimize the chance that the "last resort" KeyPackage will be used.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Ensure that "last resort" KeyPackages don't get used by provisioning enough standard KeyPackages.</t></li> </ul> <ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Rotate "last resort" KeyPackages as soon as possible after being used or if they have been stored for a prolonged period of time. Overall, avoid reusinglast resort"last resort" KeyPackages as much as possible.</t></li> </ul> <ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Ensure that the client for which alast resort"last resort" KeyPackage has been used is updating leaf keys as early as possible.</t></li> </ul><!-- [rfced] Sections 5.1 and subsequent: Do you think other documents may want to refer to specific recommendations in this document? We wonder whether it would be helpful to number the recommendations (e.g., Recommendation 1, or Req 1). In addition, as <strong> is used for RECOMMENDATION, may we change this to Recommendation? The use of capitalization seems unnecessary since it's already bold. --> <t>Overall, it needs to be noted that key packages need to be updated when signature keys are changed.</t> </section> <section anchor="delivery-guarantees"> <name>Delivery of Messages</name> <t>The main responsibility of the Delivery Service is to ensure delivery of messages. Some MLS messages need only be delivered to specific clients (e.g., a Welcome message initializing a new member's state), while others need to be delivered to all the members of a group. The Delivery Service may enable the latter delivery pattern via unicast channels (sometimes known as "client fanout"), broadcast channels ("server fanout"), or a mix of both.</t> <t>For the most part, MLS does not require the Delivery Service to deliver messages in any particular order. Applications can set policies that control their tolerance for out-of-order messages (see <xref target="operational-requirements"/>), and messages that arrive significantlyout-of-orderout of order can be dropped without otherwise affecting the protocol. There are two exceptions to this. First, Proposal messages should all arrive before the Commit that references them. Second, because an MLS group has a linear history of epochs, the members of the group must agree on the order in which changes are applied. Concretely, the group must agree on a single MLS Commit message that ends each epoch and begins the next one.</t> <t>In practice, there's a realistic risk of two members generating Commit messages at the same time, based on the same epoch, and both attempting to send them to the group at the same time. The extent to which this is a problem, and the appropriate solution,dependsdepend on the design of the Delivery Service. Per the CAP theorem <xref target="CAPBR"/>, there are two general classes of distributedsystemsystems that the Delivery Service might fall into:</t> <ul spacing="normal"> <li> <t>Consistent and Partition-tolerant, or Strongly Consistent,systemssystems, which can provide a globally consistent view of data buthashave the inconvenience of clients needing to handle rejectedmessages;</t>messages.</t> </li> <li> <t>Available and Partition-tolerant, or Eventually Consistent,systemssystems, which continue working despite network issues but may return different views of data to different users.</t> </li> </ul> <t>Strategies for sequencing messages in strongly and eventually consistent systems are described in the next two subsections. Most Delivery Services will use the Strongly Consistentparadigmparadigm, but this remains a choice that can be handled in coordination with the client andadvertizedadvertised in the KeyPackages.</t> <t>However, note that a malicious Delivery Service could also reorder messages or provide an inconsistent view to different users. The "generation" counter in MLS messages provides per-sender loss detection and ordering that cannot be manipulated by the DS, but this does not provide complete protection against partitioning. A DS can cause a partition in the group by partitioning key exchange messages; this can be detected only by out-of-band comparison (e.g., confirming that all clients have the same <tt>epoch_authenticator</tt> value). A mechanism for more robust protections is discussed in <xref target="I-D.ietf-mls-extensions"/>.</t> <t>Other forms of Delivery Service misbehavior are still possible that are not easy to detect. For instance, a Delivery Service can simply refuse to relay messages to and from a given client. Without some sort of side information, other clients cannot generally detect this form ofDenial of ServiceDenial-of-Service (DoS) attack.</t> <section anchor="strongly-consistent"> <name>Strongly Consistent</name> <t>With this approach, the Delivery Service ensures that some types of incoming messages have a linear order and all members agree on that order. The Delivery Service is trusted to break ties when two members send a Commit message at the same time.</t> <t>As an example, there could be an "ordering server" Delivery Service that broadcasts all messages received to all users and ensures that all clients see messages in the same order. This would allow clients to only apply the first valid Commit for an epoch and ignore subsequentones.Commits. Clients that send a Commit would then wait to apply it until it is broadcast back to them by the Delivery Service, assuming that they do not receive another Commitfirst.</t>first. <!-- [rfced] Sections 5.2.1 and 8.1.4: As it appears that "ones" in these sentences refers to Commits, we changed "ones" to "Commits". If this is incorrect, please clarify the text. Original: This would allow clients to only apply the first valid Commit for an epoch and ignore subsequent ones. ... As discussed in Section 5, the Delivery Service is trusted to select the single Commit message that is applied in each epoch from among the ones sent by group members. Currently: This would allow clients to only apply the first valid Commit for an epoch and ignore subsequent Commits. ... As discussed in Section 5, the Delivery Service is trusted to select the single Commit message that is applied in each epoch from among the Commits sent by group members. --> </t> <t>Alternatively, the Delivery Service can rely on the <tt>epoch</tt> and <tt>content_type</tt> fields of an MLSMessage to provide an order only to handshake messages, and possibly even filter or reject redundant Commit messages proactively to prevent them from being broadcast. There is some risk associated withfiltering, whichfiltering; this is discussed further in <xref target="invalid-commits"/>.</t> </section> <section anchor="eventually-consistent"> <name>Eventually Consistent</name> <t>With this approach, the Delivery Service is built in a way that may be significantly more available or performant than a strongly consistent system, but offers weaker consistency guarantees. Messages may arrive to different clients in different orders and with varying amounts of latency, which means clients are responsible forreconciliation.</t>reconciliation. <!-- [rfced] Section 5.2.2: Does "offers" refer to the Delivery Service or the way? Original: With this approach, the Delivery Service is built in a way that may be significantly more available or performant than a strongly consistent system, but offers weaker consistency guarantees. Perhaps (the Delivery Service): With this approach, the Delivery Service is built in a way that may be significantly more available or performant than a strongly consistent system, but it offers weaker consistency guarantees. Or possibly (the way): With this approach, the Delivery Service is built in a way that may be significantly more available or performant than a strongly consistent system but that offers weaker consistency guarantees. --> </t> <t>This type of Delivery Service might arise, for example, when group members are sending each message to each other memberindividually,individually or when a distributed peer-to-peer network is used to broadcast messages.</t> <t>Upon receiving a Commit from the Delivery Service, clients caneither:</t>do either of the following:</t> <ol spacing="normal" type="1"><li> <t>Pause sending new messages for a short amount of time to account for a reasonable degree of network latency and see if any other Commits are received for the same epoch. If multiple Commits are received, the clients can use a deterministic tie-breaking policy to decide which to accept, and then resume sending messages as normal.</t> </li> <li> <t>Accept the Commit immediately but keep a copy of the previous group state for a short period of time. If another Commit for a past epoch is received, clients use a deterministic tie-breaking policy to decide if they should continue using the Commit they originally accepted or revert and use the later one. Note that any copies of previous or forked group states must be deleted within a reasonable amount of time to ensure that the protocol providesforward-secrecy.</t>forward secrecy.</t> </li> </ol> <t>If the Commit references an unknown proposal, group members may need to solicit the Delivery Service or other group members individually for the contents of the proposal.</t> </section> <section anchor="welcome-messages"> <name>Welcome Messages</name> <t>Whenever a commit adds new members to a group, MLS requires the committer to send a Welcome message to the new members. Applications should ensure that Welcome messages are coupled with the tie-breaking logic forcommits, discussed in <xref target="strongly-consistent"/>commits (see Sections <xref target="strongly-consistent" format="counter"/> and <xreftarget="eventually-consistent"/>.target="eventually-consistent" format="counter"/>). That is, when multiple commits are sent for the same epoch, applications need to ensure that only Welcome messages corresponding to the commit that "succeeded" are processed by new members.</t> <t>This is particularly important when groups are being reinitialized. When a group is reinitialized, it is restarted with a different protocol version and/or ciphersuite but identical membership. Whenever an authorized member sends and commits a ReInit proposal, this immediately freezes the existing group and triggers the creation of a new group with a new <tt>group_id</tt>.</t> <t>Ideally, the new group would be created by the same member that committed the <tt>ReInit</tt> proposal (including sending Welcome messages for the new group to all of the previous group's members).HoweverHowever, this operation is not always atomic, so it's possible for a member to go offline after committing a ReInit proposal but before creating the new group. If this happens, it's necessary for another member to continue the reinitialization by creating the new group and sending out Welcome messages.</t> <t>This has the potential to create a race condition, where multiple members try to continue the reinitialization at the same time, and members receive multiple Welcome messages for each attempt at reinitializing the same group. Ensuring that all members agree on which reinitialization attempt is "correct" is key to prevent this from causing forks.</t> </section> </section> <section anchor="invalid-commits"> <name>Invalid Commits</name> <t>Situations can arise where a malicious or buggy client sends a Commit that is not accepted by all members of the group, and the DS is not able to detect this and reject the Commit. For example, a buggy client might send an encrypted Commit with an invalid set of proposals, or a malicious client might send a malformed Commit of the form described in <xref section="16.12" sectionFormat="of" target="RFC9420"/>.</t> <t>In situations where the DS is attempting to filter redundant Commits, the DS might update its internal state under the assumption that a Commit has succeeded and thus end up in a state inconsistent with the members of the group. For example, the DS might think that the current epoch is now <tt>n+1</tt> and reject any commits from other epochs, while the members think the epoch is <tt>n</tt>, and as a result, the group is stuck -- no member can send a Commit that the DS will accept.</t> <t>Such“desynchronization”"desynchronization" problems can arise even when the Delivery Service takes no stance on which Commit is "correct" for an epoch. The DS can enable clients to choose between Commits, for example by providing Commits in the order received and allow clients to reject any Commits that violate their view of the group's policies. As such, all honest andcorrectly-implementedcorrectly implemented clients will arrive at the same "first valid Commit" and choose to process it. Malicious or buggy clients that process a different Commit will end up in a forked view of thegroup.</t>group. <!-- [rfced] Section 5.3: This sentence does not parse. If neither suggestion below is correct, please clarify. Original: The DS can enable clients to choose between Commits, for example by providing Commits in the order received and allow clients to reject any Commits that violate their view of the group's policies. Suggestion #1: The DS can enable clients to choose between Commits - for example, by providing Commits in the order received and allowing clients to reject any Commits that violate their view of the group's policies. Suggestion #2: The DS can enable clients to choose between Commits - for example, by providing Commits in the order received - and allow clients to reject any Commits that violate their view of the group's policies. --> </t> <t>When these desynchronizations happen, the application may choose to take action to restore the functionality of the group. These actions themselves can have security implications. For example, a client developer might have a client automatically rejoin a group, using an external join, when it processes an invalid Commit. In this operation, however, the client trusts that the GroupInfo provided by the DS faithfully represents the state of the group, and not, say, an earlier state containing a compromised leaf node. In addition, the DS may be able to trigger this condition by deliberately sending the victim an invalid Commit. In certain scenarios, this trust can enable the DS or a malicious insider to undermine the post-compromise security guarantees provided by MLS.</t> <t>Actions to recover from desynchronization can also have availability and DoS implications. For example, if a recovery mechanism relies on external joins, a malicious member that deliberately posts an invalid Commit could also post a corrupted GroupInfo object in order to prevent victims from rejoining the group. Thus, careful analysis of security implications should be made for any system for recovering from desynchronization.</t> </section> </section> <section anchor="functional-requirements"> <name>Functional Requirements</name> <t>MLS is designed as a large-scale group messaging protocol and hence aims to provide both performance and security(e.g.(e.g., integrity and confidentiality) to its users. Messaging systems that implement MLS provide support for conversations involving two or more members, and they aim to scale to groups with tens of thousands of members, typically including many users using multiple devices.</t> <section anchor="membership-changes"> <name>Membership Changes</name> <t>MLS aims to provide agreement on group membership, meaning that all group members have agreed on the list of current group members.</t> <t>Some applications may wish to enforceACLsAccess Control Lists (ACLs) to limit addition or removal of group members, to privileged clients or users. Others may wish to require authorization from the current group members or a subset thereof. Such policies can be implemented at the application layer, on top of MLS. Regardless, MLS does not allow for or support addition or removal of group members without informing all othermembers.</t>members. <!-- [rfced] Section 6.1: The comma in this sentence makes it difficult to parse. Is the comma necessary? Original: Some applications may wish to enforce ACLs to limit addition or removal of group members, to privileged clients or users. --> </t> <t>Membership of an MLS group is managed at the level of individual clients. In most cases, a client corresponds to a specific device used by a user. If a user has multiple devices, the user will generally be represented in a group by multiple clients (although applications could choose to have devices share keying material). If an application wishes to implement operations at the level of users, it is up to the application to track which clients belong to a given user and ensure that they areadded / removedadded/removed consistently.</t> <t>MLS provides two mechanisms for changing the membership of a group. The primary mechanism is for an authorized member of the group to send a Commit that adds or removes other members. The second mechanism is an "external join": A member of the group publishes certain information about the group, which a new member can use to construct an "external" Commit message that adds the new member to the group. (There is no similarly unilateral way for a member to leave the group; they must be removed by a remainingmember.)</t>member.) <!-- [rfced] Section 6.1: Because "primary" is used instead of "first", should "second" in the next sentence be "secondary"? Original: The primary mechanism is for an authorized member of the group to send a Commit that adds or removes other members. The second mechanism is an "external join": A member of the group publishes certain information about the group, which a new member can use to construct an "external" Commit message that adds the new member to the group. --> </t> <t>With both mechanisms, changes to the membership are initiated from inside the group. When members perform changes directly, this is clearly the case. External joins are authorized indirectly, in the sense that a member publishing a GroupInfo object authorizes anyone to join who has access to the GroupInfo object, subject to whatever access control policies the application applies for external joins.</t> <t>Both types of joins are done via a Commit message, which could be blocked by the DS or rejected by clients if the join is not authorized. The former approach requires that Commits be visible to the DS; the latter approach requires that clients all share a consistent policy. In the unfortunate event that an unauthorized member is able to join, MLS enables any member to remove them.</t> <t>Application setup may also determine other criteria for membership validity. For example, per-device signature keys can be signed by an identity key recognized by other participants. If a certificate chain is used to authenticate device signature keys, then revocation by the owner adds an alternative mechanism to prompt membership removal.</t> <t>An MLS group's secrets change on every change of membership, so each client only has access to the secrets used by the group while they are a member. Messages sent before a client joins or after they are removed are protected with keys that are not accessible to the client. Compromise of a member removed from a group does not affect the security of messages sent after their removal. Messages sent during the client's membership are also secure as long as the client has properly implemented the MLS deletion schedule, which calls for the secrets used to encrypt or decrypt a message to be deleted after use, along with any secrets that could be used to derive them.</t> </section> <section anchor="parallel-groups"> <name>Parallel Groups</name> <t>Any user or client may have membership in several groups simultaneously. The set of members of any group may or may not form a subset of the members of another group. MLS guarantees that the FS and PCS goals within a given group are maintained and not weakened by user membership in multiple groups. However, actions in other groups likewise do not strengthen the FS and PCS guarantees within a given group, e.g., key updates within a given group following a device compromisedoesdo not provide PCS healing in other groups; each group must be updated separately to achieve these security objectives. This also applies to future groups that a member has yet to join, which are likewise unaffected by updates performed in current groups.</t> <t>Applications can strengthen connectivity among parallel groups by requiring periodic key updates from a user across all groups in which they havemembership.</t>membership. <!-- [rfced] Section 6.2: Does "they have" refer to "a user" (in which case "they have" should be "the user has") or something else? Original: Applications can strengthen connectivity among parallel groups by requiring periodic key updates from a user across all groups in which they have membership. --> </t> <t>MLS provides a pre-shared key (PSK) that can be used to link healing properties among parallel groups. For example, suppose a common member M of two groups A and B has performed a key update in group A but not in group B. The key update provides PCS with regard to M in group A. If a PSK is exported from group A and injected into group B, then some of these PCS properties carry over to group B, since the PSK and secrets derived from it are only known to the new, updated version of M, not to the old, possibly compromised version of M.</t> </section> <section anchor="asynchronous-usage"> <name>Asynchronous Usage</name> <t>No operation in MLS requires two distinct clients or members to be online simultaneously. In particular, members participating in conversations protected using MLS can update the group's keys, add or remove new members, and send messages without waiting for another user's reply.</t> <t>Messaging systems that implement MLS have to provide a transport layer for delivering messages asynchronously and reliably.</t> </section> <section anchor="access-control"> <name>Access Control</name> <t>Because all clients within a group (members) have access to the shared cryptographic material, the MLS protocol allows each member of the messaging group to perform operations. However, every service/infrastructure has control over policies applied to its own clients. Applications managing MLS clients can be configured to allow for specific group operations. On the one hand, an application could decide that a group administrator will be the only member to perform add and remove operations. On the other hand, in many settings such as open discussion forums, joining can be allowed foranyone.</t>anyone. <!-- [rfced] Section 6.4: a) We see "add and remove operations" here but "Remove Proposal" in Section 3.6 and "Remove group operation" in Section 8.3.1.3. Should "add and remove operations" be changed to "Add and Remove operations"? Original: On the one hand, an application could decide that a group administrator will be the only member to perform add and remove operations. b) Regarding "Remove Proposal" and "Add Proposal" as used in this document: RFC 9420 uses "Remove proposal" and "Add proposal" in its text. Would you like to use lowercase "proposal" in this document per RFC 9420? --> </t> <t>While MLS Application messages are always encrypted, MLS handshake messages can be sent either encrypted (in an MLS PrivateMessage) or unencrypted (in an MLS PublicMessage). Applications may be designed such that intermediaries need to see handshake messages, for example to enforce policy on which commits are allowed, or to provide MLS ratchet tree data in a central location. If handshake messages are unencrypted, it is especially important that they be sent over a channel with strong transport encryption (see <xref target="security-and-privacy-considerations"/>) in order to prevent external attackers from monitoring the status of the group. Applications that use unencrypted handshake messages may take additional steps to reduce the amount of metadata that is exposed to the intermediary. Everything else being equal, using encrypted handshake messages provides stronger privacy properties than using unencrypted handshake messages, as it prevents intermediaries from learning about the structure of thegroup.</t>group. <!-- [rfced] Section 6.4: It is not clear what "for example" refers to in this sentence. If the suggested text is not correct, please clarify. Original: Applications may be designed such that intermediaries need to see handshake messages, for example to enforce policy on which commits are allowed, or to provide MLS ratchet tree data in a central location. Suggested (removing the comma after "allowed"): Applications may be designed such that intermediaries need to see handshake messages - for example, to enforce policy on which commits are allowed or to provide MLS ratchet tree data in a central location. --> </t> <t>If handshake messages are encrypted, any access control policies must be applied at the client, so the application must ensure that the access control policies are consistent across all clients to make sure that they remain in sync. If two different policies were applied, the clients might not accept or reject a group operation andend-upend up in different cryptographic states, breaking their ability to communicate.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Avoid using inconsistent access 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 ways: External signers can submit proposals for changes to the group, and new joiners can use an external join to add themselves to the group. The <tt>external_senders</tt> extension ensures that all members agree on which signers are allowed to send proposals, but any other policies must be assured to beconsistentconsistent, as noted above.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Have an explicit group policy setting the conditions under which external joins are allowed.</t></li> </ul></section> <section anchor="handling-authentication-failures"> <name>Handling Authentication Failures</name> <t>Within an MLS group, every member is authenticated to every other member by means of credentials issued and verified by the Authentication Service. MLS does not prescribe what actions, if any, an application should take in the event that a group member presents an invalid credential. For example, an application may require such a member to be immediatelyevicted,evicted or may allow some grace period for the problem to be remediated. To avoid operational problems, it is important for all clients in a group to have a consistent view of which credentials in a group are valid, and how to respond to invalid credentials.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Have a uniform credential validation process to ensure that all group members evaluate other members' credentials in the same way.</t></li> </ul> <ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Have a uniform policy for how invalid credentials are handled.</t></li> </ul><t>In some authentication systems, it is possible for apreviously-validpreviously valid credential to become invalid over time. For example, in a system based on X.509 certificates, credentials can expire or be revoked. The MLS update mechanisms allow a client to replace an old credential with a new one. This is best done before the old credential becomes invalid.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Proactively rotate credentials, especially if a credential is about to become invalid.</t></li> </ul></section> <section anchor="state-loss"> <name>Recovery After State Loss</name> <t>Group members whose local MLS state is lost or corrupted can reinitialize their state byre-joiningrejoining the group as a new member and removing the member representing their earlier state. An application can require that a client performing such a reinitialization prove its prior membership with a PSK that was exported from theprevoiusprevious state.</t> <t>There are a few practical challenges to this approach. For example, the application will need to ensure that all members have the required PSK, including any new members that have joined the group since the epoch in which the PSK was issued. And of course, if the PSK is lost or corrupted along with the member's other state, then it cannot be used to recover.</t> <t>Reinitializing in this way does not provide the member with access to group messagesfromexchanged during the state loss window, but it enables proof of prior membership in the group. Applications may choose various configurations for providing lost messages to valid group members that are able to prove prior membership.</t> </section> <section anchor="support-for-multiple-devices"> <name>Support for Multiple Devices</name> <t>It is typically expectedforthat users within a grouptowill own various devices. A new device can be added to a group and be considered as a new client by the protocol. This client will not gain access to the history even if it is owned by someone who owns another member of the group. MLS does not provide direct support for restoring history in this case, but applications can elect to provide such a mechanism outside of MLS. Such mechanisms, if used, may reduce the FS and PCS guarantees provided by MLS.</t> </section> <section anchor="extensibility"> <name>Extensibility</name> <t>The MLS protocol provides several extension points where additional information can be provided. Extensions to KeyPackages allow clients to disclose additional information about their capabilities. Groups can also have extension data associated with them, and the group agreement properties of MLS will confirm that all members of the group agree on the content of these extensions.</t> </section> <section anchor="application-data-framing-and-type-advertisements"> <name>Application Data Framing and Type Advertisements</name> <t>Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data. Each applicationwhichthat uses MLS needs to define the format of its <tt>application_data</tt> and any mechanism necessary to determine the format of that content over the lifetime of an MLS group. In manyapplicationsapplications, this means managing format migrations for groups with multiple members who may each be offline at unpredictable times.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Use the default content mechanism defined in <xref section="3.3" sectionFormat="of" target="I-D.ietf-mls-extensions"/>, unless the specific application defines another mechanism that more appropriately addresses the same requirements for that application of MLS. <!-- [rfced] Section 6.9: We do not see the word "default" or any indication of a default mechanism in Section 3.3 of [I-D.ietf-mls-extensions]. Please confirm that the text and citation are correct and will be clear to readers. Original: *RECOMMENDATION:* Use the default content mechanism defined in Section 3.3 of [I-D.ietf-mls-extensions], unless the specific application defines another mechanism which more appropriately addresses the same requirements for that application ofMLS.</t> </li> </ul>MLS. --> </t> <t>The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted. Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with.</t> </section> <section anchor="federation"> <name>Federation</name> <t>The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can interoperate to form federated systems if they use compatible authentication mechanisms, ciphersuites, application content, and infrastructure functionalities. Federation is described in more detail in <xref target="I-D.ietf-mls-federation"/>.</t> </section> <section anchor="compatibility-with-future-versions-of-mls"> <name>Compatibility with Future Versions of MLS</name> <t>It is important that multiple versions of MLS be able to coexist in the future. Thus, MLS offers a version negotiation mechanism; this mechanism prevents version downgrade attacks where an attacker would actively rewrite messages with a lower protocol version than theonesmessages originally offered by the endpoints. When multiple versions of MLS are available, the negotiation protocol guarantees that the version agreed upon will be the highest version supported in common by the group.</t> <t>In MLS 1.0, the creator of the group is responsible for selecting the best ciphersuite supported across clients. Each client is able to verify availability of protocol version,ciphersuitesciphersuites, and extensions at all times onceheit has at least received the first group operation message.</t> <t>Each member of an MLS group advertises the protocol functionality they support. These capability advertisements can be updated over time, e.g., if client software is updated while the client is a member of a group. Thus, in addition to preventing downgrade attacks, the members of a group can also observe when it is safe to upgrade to a new ciphersuite or protocol version.</t> </section> </section> <section anchor="operational-requirements"> <name>Operational Requirements</name> <t>MLS is a security layer that needs to be integrated with an application. Afully-functionalfully functional deployment of MLS will have to make a number of decisions about how MLS is configured and operated. Deployments that wish to interoperate will need to make compatible decisions. This section lists all of the dependencies of an MLS deployment that are external to the protocol specification, but would still need to be aligned within a given MLS deployment, or for two deployments to potentiallyinteroperate.</t>interoperate. <!-- [rfced] Section 7: This sentence is difficult to parse. To what does ", or for two deployments to potentially interoperate" refer? If the suggested text is not correct, please clarify. Original: This section lists all of the dependencies of an MLS deployment that are external to the protocol specification, but would still need to be aligned within a given MLS deployment, or for two deployments to potentially interoperate. Suggested: This section lists all of the dependencies of an MLS deployment that are external to the protocol specification but would still need to be aligned within a given MLS deployment so that two deployments can potentially interoperate. --> </t> <t>The protocol has a built-in ability to negotiate protocol versions, ciphersuites, extensions, credential types, and additional proposal types. For two deployments to interoperate, they must have overlapping support in each of these categories. The <tt>required_capabilities</tt> extension(Section 7.2 of <xref(<xref section="7.2" sectionFormat="of" target="RFC9420"/>) can promote interoperability with a wider set of clients by ensuring that certain functionality continues to be supported by a group, even if the clients in the group aren't currently relying on it.</t> <t>MLS relies on the following network services,thatwhich need to be compatible in order for two different deployments based on them to interoperate.</t> <ul spacing="normal"> <li> <t>An <strong>Authentication Service</strong>, described fully in <xref target="authentication-service"/>, defines the types of credentialswhichthat may be used in a deployment and provides methods for: </t> <ol spacing="normal" type="1"><li> <t>Issuing new credentials with a relevant credential lifetime,</t> </li> <li> <t>Validating a credential against a reference identifier,</t> </li> <li> <t>Validating whether or not two credentials represent the same client, and</t> </li> <li> <t>Optionally revoking credentialswhichthat are no longer authorized.</t> </li> </ol> </li> <li> <t>A <strong>Delivery Service</strong>, described fully in <xref target="delivery-service"/>, provides methods for: </t> <ol spacing="normal" type="1"><li> <t>Delivering messages for a group to all members in the group.</t> </li> <li> <t>Delivering Welcome messages to new members of a group.</t> </li> <li> <t>Uploading new KeyPackages for a user's own clients.</t> </li> <li> <t>Downloading KeyPackages for specific clients. Typically, KeyPackages are used once and consumed.</t> </li> </ol> </li> <li> <t>Additional services may or may not berequiredrequired, depending on the application design: </t> <ul spacing="normal"> <li> <t>In cases where group operations are not encrypted, the DS has the ability to observe and maintain a copy of the public group state. In particular, this is useful forclients(1) clients that do not have the ability to send the full public state in a Welcome message when inviting auser,user orfor a(2) a client that needs to recover from losing their state. Such public state can containprivacy sensitiveprivacy-sensitive information such as group members' credentials and related publickeys, hencekeys; hence, services need to carefully evaluate the privacy impact of storing this data on the DS.</t> </li> <li> <t>If external joiners are allowed, there must be a methodto publishfor publishing a serialized <tt>GroupInfo</tt> object (with an <tt>external_pub</tt> extension) that corresponds to a specific group and epoch, andkeepfor keeping that object in sync with the state of the group.</t> </li> <li> <t>If an application chooses not to allow external joining, it may instead provide a method for external users to solicit group members (or a designated service) to add them to a group.</t> </li> <li> <t>If the application uses PSKs that members of a group may not have access to (e.g., to control entry into the group or to prove membership in the group in the past, as discussed in <xreftarget="state-loss"/>)target="state-loss"/>), there must be a method for distributing these PSKs to group members who might not havethem,them -- forinstanceinstance, if they joined the group after the PSK was generated.</t> </li> <li> <t>If an application wishes to detect and possibly discipline members that send malformed commits with the intention of corrupting a group's state, there must be a method for reporting and validating malformed commits.</t> </li> </ul> </li> </ul> <t>MLS requires the following parameters to be defined, which must be the same for two implementations to interoperate:</t> <ul spacing="normal"> <li> <t>The maximum total lifetime that is acceptable for a KeyPackage.</t> </li> <li> <t>How long to store the resumption PSK for past epochs of a group.</t> </li> <li> <t>The degree of tolerance that's allowed for out-of-order message delivery: </t> <ul spacing="normal"> <li> <t>How long to keep unused nonce and key pairs for asender</t>sender.</t> </li> <li> <t>A maximum number of unused key pairs to keep.</t> </li> <li> <t>A maximum number of steps that clients will move a secret tree ratchet forward in response to a single message before rejecting it.</t> </li> <li> <t>Whether to buffer messages that aren't yet able to be understoodyetdue to other messages not arrivingfirst, andfirst and, if so, how many and for howlong. Forlong -- for example, Commit messages that arrive before a proposal theyreference,reference or application messages that arrive before the Commit starting an epoch.</t> </li> </ul> </li> </ul> <t>If implementations differ in these parameters, they will interoperate to some extent but may experience unexpected failures in certain situations, such as extensive message reordering.</t> <t>MLS provides the following locations where an application may store arbitrary data. The format and intention of any data in these locations must align for two deployments to interoperate:</t> <ul spacing="normal"> <li> <t>Application data, sent as the payload of an encrypted message.</t> </li> <li> <t>Additional authenticated data, sent unencrypted in an otherwise encrypted message.</t> </li> <li> <t>Group IDs, as decided by group creators and used to uniquely identify a group.</t> </li> <li> <t>Application-level identifiers of public key material(specifically(specifically, the <tt>application_id</tt> extension as defined in <xref section="5.3.3" sectionFormat="of" target="RFC9420"/>).</t> </li> </ul> <t>MLS requires the following policies to be defined, which restrict the set of acceptablebehaviorbehaviors in a group. These policies must be consistent between deployments for them to interoperate:</t> <ul spacing="normal"> <li> <t>A policy on which ciphersuites are acceptable.</t> </li> <li> <t>A policy on any mandatory or forbidden MLS extensions.</t> </li> <li> <t>A policy on when to send proposals and commits in plaintext instead of encrypted.</t> </li> <li> <t>A policy for which proposals are valid to have in a commit, including but not limited to: </t> <ul spacing="normal"> <li> <t>When a member is allowed to add or remove other members of the group.</t> </li> <li> <t>When, and under what circumstances, a reinitialization proposal is allowed.</t> </li> <li> <t>When proposals from external senders are allowed and how to authorize those proposals.</t> </li> <li> <t>When external joiners are allowed and how to authorize those external commits.</t> </li> <li> <t>Which other proposal types are allowed.</t> </li> </ul> </li> <li> <t>A policy of when members should commit pending proposals in a group.</t> </li> <li> <t>A policy of how to protect and share the GroupInfo objects needed for external joins.</t> </li> <li> <t>A policy for when two credentials represent the same client. Note that many credentials may be issued attesting the same identity but for different signature keys, because each credential corresponds to a different client owned by the same application user. However, one device may control multiple signature keys -- for instance, if the device has keys corresponding to multiple overlapping time periods -- but should still only be considered a single client. <!-- [rfced] Section 7: As it appears that "they have" refers to "one device", we changed "they have" to "the device has". If this is incorrect, please clarify the text. Original: However, one device may control multiple signature keys - for instance if they have keys corresponding to multiple overlapping time periods--- but should still only be considered a singleclient.</t>client. Currently: However, one device may control multiple signature keys - for instance, if the device has keys corresponding to multiple overlapping time periods - but should still only be considered a single client. --> </t> </li> <li> <t>A policy on how long to allow a member to stay in a group without updating its leaf keys before removing them.</t> </li> </ul> <t>Finally, there are some additional application-defined behaviors that are partially an individual application's decision but may overlap with interoperability:</t> <ul spacing="normal"> <li> <t>When and how to pad messages.</t> </li> <li> <t>When to send a reinitialization proposal.</t> </li> <li> <t>How often clients should update their leaf keys.</t> </li> <li> <t>Whether to prefer sending full commits or partial/empty commits.</t> </li> <li> <t>Whether there should be a <tt>required_capabilities</tt> extension in groups.</t> </li> </ul> </section> <section anchor="security-and-privacy-considerations"> <name>Security and Privacy Considerations</name> <t>MLS adopts the Internet threat model <xref target="RFC3552"/> and therefore assumes that the attacker has complete control of the network. It is intended to provide the security services described in <xref target="intended-security-guarantees"/> in the face of attackers who can:</t> <ul spacing="normal"> <li> <t>Monitor the entire network.</t> </li> <li> <t>Read unprotected messages.</t> </li> <li><t>Can generate, inject<t>Generate, inject, and delete any message in the unprotected transport layer.</t> </li> </ul> <t>While MLS should be run over a secure transport such as QUIC <xref target="RFC9000"/> or TLS <xref target="RFC8446"/>, the security guarantees of MLS do not depend on the transport. This departs from the usual design practice of trusting the transport because MLS is designed to provide security even in the face of compromised network elements, especially the DS.</t> <t>Generally, MLS is designed under the assumption that the transport layer is present to keep metadata private from network observers, while the MLS protocol provides confidentiality, integrity, and authentication guarantees for the application data (which could pass through multiple systems). Additional properties such as partial anonymity or deniability could also be achieved in specific architecture designs.</t> <t>In addition, these guarantees are intended to degrade gracefully in the presence of compromise of the transport security links as well as of both clients and elements of the messaging system, as described in the remainder of this section.</t> <section anchor="assumptions-on-transport-security-links"> <name>Assumptions on Transport Security Links</name> <t>As discussed above, MLS provides the highest level of security when its messages are delivered over an encrypted transport. The main use of the secure transport layer for MLS is to protect thealready limitedalready-limited amount of metadata. Very little information is contained in the unencrypted header of the MLS protocol message format for group operation messages, and application messages are always encrypted in MLS.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Use transports that provide reliability and metadata confidentiality whenever possible, e.g., by transmitting MLS messages over a protocol such as TLS <xref target="RFC8446"/> or QUIC <xref target="RFC9000"/>.</t></li> </ul><t>MLS avoids needing to send the full list of recipients to the server for dispatching messages because that list could potentially contain tens of thousands of recipients. Header metadata in MLS messages typically consists of an opaque <tt>group_id</tt>, a numerical value to determine the epoch of the group (the number of changes that have been made to the group), and whether the message is an application message, a proposal, or a commit.</t> <t>Even though some of this metadata information does not consist of sensitive information, in correlation with other data a network observer might be able to reconstruct sensitive information. Using a secure channel to transfer this information will prevent a network attacker from accessing this MLS protocol metadata if it cannot compromise the secure channel.</t> <section anchor="integrity-and-authentication-of-custom-metadata"> <name>Integrity and Authentication of Custom Metadata</name> <t>MLS provides an authenticated "Additional Authenticated Data" (AAD) field for applications to make data available outside a PrivateMessage, while cryptographically binding it to the message.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Use the "Additional Authenticated Data" field of the PrivateMessage instead of using other unauthenticated means of sending metadata throughout the infrastructure. If the data should be kept private, the infrastructure should use encrypted Application messages instead.</t></li> </ul></section> <section anchor="metadata-protection-for-unencrypted-group-operations"> <name>Metadata Protection for Unencrypted Group Operations</name> <t>Having no secure channel to exchange MLS messages can have a serious impact on privacy when transmitting unencrypted group operation messages. Observing the contents and signatures of the group operation messages may lead an adversary to extract information about the group membership.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Never use the unencrypted mode for group operations without using a secure channel for the transport layer.</t></li> </ul></section> <section anchor="dos-protection"> <name>DoSprotection</name>Protection</name> <t>Ingeneralgeneral, we do not considerDenial of Service (DoS)DoS resistance to be the responsibility of the protocol. However, it should not be possible for anyone aside from the Delivery Service to perform a trivial DoS attack from which it is hard to recover. This can be achieved through the secure transport layer.</t> <t>In the centralized setting, DoS protection can typically be performed by using tickets or cookies which identify users to a service for a certain number of connections. Such a system helps in preventing anonymous clients from sending arbitrary numbers of group operation messages to the Delivery Service or the MLS clients.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Use credentialsuncorrellateduncorrelated with specific users to help prevent DoS attacks, in aprivacy preserving manner.manner that preserves privacy. Note that the privacy of these mechanisms has to be adjusted in accordance with the privacy expected from secure transport links. (See more discussion in the next section.)</t></li> </ul></section> <section anchor="message-suppression-and-error-correction"> <name>Message Suppression and Error Correction</name> <t>As noted above, MLS is designed to provide some robustness in the face of tampering within the secure transport, i.e., tampering by the Delivery Service. The confidentiality and authenticity properties of MLS prevent the DS from reading or writing messages. MLS also provides a few tools for detecting message suppression, with the caveat that message suppression cannot always be distinguished from transportfailure.</t>failure. <!-- [rfced] Section 8.1.4: Is tampering by the Delivery Service the only type of tampering scenario (in which case "i.e.," is correct), or is it one example of a tampering scenario (in which case "e.g.," would be correct)? Original: As noted above, MLS is designed to provide some robustness in the face of tampering within the secure transport, i.e., tampering by the Delivery Service. --> </t> <t>Each encrypted MLS message carries a "generation" number which is a per-sender incrementing counter. If a group member observes a gap in the generation sequence for a sender, then they know that they have missed a message from that sender. MLS also provides a facility for group members to send authenticated acknowledgments of application messages received within a group.</t> <t>As discussed in <xref target="delivery-service"/>, the Delivery Service is trusted to select the single Commit message that is applied in each epoch from among theonesCommits sent by group members. Since only one Commit per epoch is meaningful, it's not useful for the DS to transmit multiple Commits to clients. The risk remains that the DS will use the ability maliciously.</t> <t>While it is difficult or impossible to prevent a network adversary from suppressing payloads in transit, in certain infrastructures such as banks orgovernmentsgovernment settings, unidirectional transports can be used and be enforced via electronic or physical devices such as diodes. This can lead to payloadcorruptioncorruption, which does not affect the security or privacy properties of the MLS protocol but does affect the reliability of the service. In thatcasecase, specific measures can be taken to ensure the appropriate level of redundancy and quality of service for MLS.</t> </section> </section> <section anchor="intended-security-guarantees"> <name>Intended Security Guarantees</name> <t>MLS aims to provide a number of security guarantees, covering authentication, as well as confidentiality guarantees to different degrees in different scenarios.</t> <section anchor="message-secrecy-authentication"> <name>Message Secrecy and Authentication</name> <t>MLS enforces the encryption of application messages and thus generally guarantees authentication and confidentiality of application messages sent in a group.</t> <t>In particular, this means that only other members of a given group can decrypt the payload of a given application message, which includes information about the sender of the message.</t> <t>Similarly, group members receiving a message from another group member can authenticate that group member as the sender of the message and verify the message's integrity.</t> <t>Message content can be deniable if the signature keys are exchanged over a deniable channel prior to signing messages.</t> <t>Depending on the group settings, handshake messages can be encrypted as well. If that is the case, the same security guarantees apply.</t> <t>MLS optionally allows the addition of padding to messages, mitigating the amount of information leaked about the length of the plaintext to an observer on the network.</t> </section> <section anchor="fs-and-pcs"> <name>Forward and Post-Compromise Security</name> <!-- [rfced] Section 8.2.2: Does "Forward" here refer to Forward Secrecy (FS) or forward security as mentioned in Section 8.4.2? Please note that we only see one instance of "forward security" in this document (Section 8.4.2) and do not see this term used in RFC 9420. Original: 8.2.2. Forward and Post-Compromise Security --> <t>MLS provides additional protection regarding secrecy of past messages and future messages. These cryptographic security properties are Forward Secrecy (FS) and Post-Compromise Security (PCS).</t> <t>FS means that access to all encrypted traffic history combined with access to all current keying material on clients will not defeat the secrecy properties of messages older than the oldest key of the compromised client. Note that this means that clients have to delete the appropriate keys as soon as they have been used with the expectedmessage, otherwisemessage; otherwise, the secrecy of the messages and the securityforof MLSisare considerably weakened.</t> <t>PCS means that if a group member's state is compromised at some time t1 but the group member subsequently performs an update at some time t2, then all MLS guarantees apply to messages sent by the member after timet2,t2 and sent by other members after they have processed the update. For example, if an attacker learns all secrets known to Alice at time t1, including both Alice's long-term secret keys and all shared group keys, but Alice performs a key update at time t2, then the attacker is unable to violate any of the MLS security properties after the updates have been processed.</t> <t>Both of these properties are satisfied even against compromised DSs andASsASes in the case where some other mechanism for verifying keys is in use, such as Key Transparency <xreftarget="KT"/>.</t>target="I-D.ietf-keytrans-architecture"/>.</t> <t>Confidentiality is mainly ensured on the client side. BecauseForward Secrecy (FS)FS andPost-Compromise Security (PCS)PCS rely on the active deletion and replacement of keying material, any clientwhichthat is persistently offline may still be holding old keying material and thus be a threat to both FS and PCS if it is later compromised.</t> <t>MLS partially defends against this problem by active members including freshness. However, not much can be done on the inactive side especially in the case where the client has not processed messages. <!-- [rfced] Section 8.2.2: We had trouble following this sentence. Does "by active members including freshness" mean "by active members ensuring freshness of data" or something else? Original: MLS partially defends against this problem by active members including freshness, however not much can be done on the inactive side especially in the case where the client has not processedmessages.</t> <ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong>messages. --> </t> <t indent="3"><strong>RECOMMENDATION:</strong> Mandate key updates from clients that are not otherwise sending messages and evict clientswhichthat are idle for too long.</t></li> </ul><t>These recommendations will reduce the ability of idle compromised clients to decrypt a potentially long set of messages that might have been sent after the point of compromise. <!-- [rfced] Section 8.2.2: "followed" read oddly in this sentence. We updated the text. If this is incorrect, please clarify the meaning of "followed". Original: These recommendations will reduce the ability of idle compromised clients to decrypt a potentially long set of messages that might have followed the point of thecompromise.</t>compromise. Currently: These recommendations will reduce the ability of idle compromised clients to decrypt a potentially long set of messages that might have been sent after the point of compromise. --> </t> <t>The precise details of such mechanisms are a matter of local policy and beyond the scope of this document.</t> </section> <section anchor="Non-Repudiation-vs-Deniability"> <name>Non-Repudiationvsvs. Deniability</name> <t>MLS provides strong authentication within a group, such that a group member cannot send a message that appears to be from another group member. Additionally, some services require that a recipient be able to prove to the service provider that a message was sent by a given client, in order to report abuse. MLS supports both of these use cases. In some deployments, these services are provided by mechanismswhichthat allow the receiver to prove a message's origin to a third party. This is often called "non-repudiation".</t> <t>Roughly speaking, "deniability" is the opposite of "non-repudiation", i.e., the property that it is impossible to prove to a third party that a message was sent by a given sender. MLS does not make any claims with regard to deniability. It may be possible to operate MLS in ways that provide certain deniability properties, but defining the specific requirements and resulting notions of deniability requires further analysis.</t> </section> <section anchor="associating-a-users-clients"> <name>Associating a User's Clients</name> <t>When a user has multiple devices, the base MLS protocol only describes how to operate each device as a distinct client in the MLS groups that the user is a member of. As a result, the other members of the group will be able to identify which of a user's devices sent eachmessage, and thereforemessage and, therefore, which device the user was using at the time. Group members would also be able to detect when the user adds or removes authorized devices from their account. For some applications, this may be an unacceptable breach of the user's privacy.</t> <t>This risk only arises when the leaf nodes for the clients in question provide data that can be used to correlate the clients.SoSo, one way to mitigate this risk is by only doing client-level authentication within MLS. If user-level authentication is still desirable, the application would have to provide it through some other mechanism.</t> <t>It is also possible to maintain user-level authentication while hiding information about the clients that a user owns. This can be done by having the clients share cryptographic state, so that they appear as a single client within the MLS group. Appearing as a single client has the privacy benefits of no longer leaking which device was used to send a particularmessage,message and no longer leaking the user's authorized devices. However, the application would need to provide a synchronization mechanism so that the clients' state remain consistent across changes to the MLS group. Flaws in this synchronization mechanism may impair the ability of the user to recover from a compromise of one of their devices. In particular, state synchronization may make it easier for an attacker to use one compromised device to establish exclusive control of a user's account, locking them out entirely and preventing them fromrecovering.</t>recovering. <!-- [rfced] Section 8.2.4: Should "the clients' state remain" be "the clients' state remains" or "the clients' states remain"? Original: However, the application would need to provide a synchronization mechanism so that the clients' state remain consistent across changes to the MLS group. --> </t> </section> </section> <section anchor="endpoint-compromise"> <name>Endpoint Compromise</name> <t>The MLS protocol adopts a threat modelwhichthat includes multiple forms of endpoint/client compromise. While adversaries are in a strong position if they have compromised an MLS client, there are still situations where security guarantees can be recovered thanks to the PCS properties achieved by the MLS protocol.</t> <t>In thissectionsection, we will explore the consequences and recommendations regarding the following compromise scenarios:</t> <ul spacing="normal"> <li> <t>The attacker has access to a symmetric encryptionkey</t>key.</t> </li> <li> <t>The attacker has access toaan application ratchetsecret</t>secret.</t> </li> <li> <t>The attacker has access to the group secrets for onegroup</t>group.</t> </li> <li> <t>The attacker has access to a signature oracle for anygroup</t>group.</t> </li> <li> <t>The attacker has access to the signature key for onegroup</t>group.</t> </li> <li> <t>The attacker has access to all secrets of a user for all groups (full statecompromise)</t>compromise).</t> </li> </ul> <section anchor="symmetric-key-compromise"> <name>Compromise of Symmetric Keying Material</name> <t>As described above, each MLS epoch creates a new Group Secret.</t> <t>These group secrets are then used to create a per-sender Ratchet Secret, which in turn is used to create a per-sender with an additional data(AEAD)(Authenticated Encryption with Associated Data (AEAD)) key <xref target="RFC5116"/>keythat is then used to encrypt MLS Plaintext messages. Each time a message is sent, the Ratchet Secret is used to create a new Ratchet Secret and a new corresponding AEAD key. Because of the properties of the key derivation function, it is not possible to compute a Ratchet Secret from its corresponding AEAD key or compute Ratchet Secret n-1 from Ratchet Secretn.</t>n. <!-- [rfced] Section 8.3.1: "a per-sender with" in this sentence is difficult to follow. If the suggested text is not correct, please clarify. Original: These group secrets are then used to create a per-sender Ratchet Secret, which in turn is used to create a per-sender with additional data (AEAD) [RFC5116] key that is then used to encrypt MLS Plaintext messages. Suggested: These group secrets are then used to create a per-sender Ratchet Secret, which in turn is used to create a per-sender key with additional data (Authenticated Encryption with Associated Data (AEAD); see [RFC5116]) that is then used to encrypt MLS Plaintext messages. --> </t> <t>Below, we consider the compromise of each of these pieces of keying material in turn, in ascending order of severity. While this is a limited kind of compromise, it can be realistic in cases of implementation vulnerabilities where only part of the memory leaks to the adversary.</t> <section anchor="compromise-of-aead-keys"> <name>Compromise of AEAD Keys</name> <t>In some circumstances, adversaries may have access to specific AEAD keys and nonceswhichthat protect an Application message or a Group Operation message. Compromise of these keys allows the attacker to decrypt the specific message encrypted with that key but no other; because the AEAD keys are derived from the Ratchet Secret, it cannot generate the next Ratchet Secret and hence not the next AEAD key.</t> <t>In the case of an Application message, an AEAD key compromise means that the encrypted application message will be leaked as well as the signature over that message. This means that the compromise has both confidentiality and privacy implications on the future AEAD encryptions of that chain. In the case of a Group Operation message, only the privacy is affected, as the signature is revealed, because the secrets themselves are protected byHPKE encryption.Hybrid Public Key Encryption (HPKE). Note that under that compromise scenario, authentication is not affected in either of these cases. As every member of the group can compute the AEAD keys for all the chains (they have access to the Group Secrets) in order to send and receive messages, the authentication provided by the AEAD encryption layer of the common framing mechanism is weak. Successful decryption of an AEAD encrypted message only guarantees that some member of the group sent themessage.</t>message. <!-- [rfced] Section 8.3.1.1: For ease of the reader, we expanded "HPKE" as "Hybrid Public Key Encryption". If this is incorrect, please provide the correct definition. Original: In the case of a Group Operation message, only the privacy is affected, as the signature is revealed, because the secrets themselves are protected by HPKE encryption. Currently: In the case of a Group Operation message, only the privacy is affected, as the signature is revealed, because the secrets themselves are protected by Hybrid Public Key Encryption (HPKE). --> </t> <t>Compromise of the AEAD keys allows the attacker to send an encrypted message using that key, but the attacker cannot send a message to a groupwhichthat appears to be from any valid clientsince theybecause the attacker cannot forge the signature. This applies to all the forms of symmetric key compromise described in <xreftarget="symmetric-key-compromise"/>.</t>target="symmetric-key-compromise"/>. <!-- [rfced] Section 8.3.1.1: This sentence as written appeared to say that the compromise cannot forge the signature. We updated it to indicate that the attacker cannot forge the signature. If this is incorrect, please provide clarifying text. Original: Compromise of the AEAD keys allows the attacker to send an encrypted message using that key, but cannot send a message to a group which appears to be from any valid client since they cannot forge the signature. Currently: Compromise of the AEAD keys allows the attacker to send an encrypted message using that key, but the attacker cannot send a message to a group that appears to be from any valid client because the attacker cannot forge the signature. --> </t> </section> <section anchor="compromise-of-ratchet-secret-material"> <name>Compromise of Ratchet Secretmaterial</name>Material</name> <t>When a Ratchet Secret is compromised, the adversary can compute both the current AEAD keys for a given sender as well as any future keys for that sender in this epoch. Thus, it can decrypt current and future messages by the corresponding sender. However, because it does not have previous Ratchet Secrets, it cannot decrypt past messages as long as those secrets and keys have beendeleted.</t>deleted. <!-- [rfced] Section 8.3.1.2: Does "both the current AEAD keys for a given sender as well as any future keys" mean "both of the current AEAD keys for a given sender, as well as any future keys", "both (1) the current AEAD keys for a given sender and (2) any future keys", or something else? Original: When a Ratchet Secret is compromised, the adversary can compute both the current AEAD keys for a given sender as well as any future keys for that sender in this epoch. --> </t> <t>Because of its Forward Secrecy guarantees, MLS will also retain secrecy of all other AEAD keys generated for <em>other</em> MLS clients, outside this dedicated chain of AEAD keys and nonces, even within the epoch of the compromise. MLS provides Post-Compromise Security against an active adaptive attacker across epochs for AEAD encryption, which means that as soon as the epoch is changed, if the attacker does not have access to more secret material they won't be able to access any protected messages from future epochs.</t> </section> <section anchor="compromise-of-the-group-secrets-of-a-single-group-for-one-or-more-group-epochs"> <name>Compromise of the Group Secrets of asingle groupSingle Group foroneOne ormore group epochs</name>More Group Epochs</name> <t>An adversary who gains access to a set of Groupsecrets--assecrets -- for example, when a member of the group iscompromised--iscompromised -- is significantly more powerful. In this section, we consider the case where the signature keys are not compromised, which can occur if the attacker has access to part of the memory containing the group secrets but not to the signature keys which might be stored in a secure enclave.</t> <t>In this scenario, the adversary gains the ability to compute any number of Ratchet Secrets for the epoch and their corresponding AEAD encryption keys and thus can encrypt and decrypt all messages for the compromised epochs.</t> <t>If the adversary is passive, it is expected from the PCS properties of the MLS protocolthat,that as soon as the compromised party remediates the compromise and sends an honest Commit message, the next epochs will provide message secrecy.</t> <t>If the adversary is active, the adversary can engage in the protocol itself and perform updates on behalf of the compromised party with no ability for an honest group to recover message secrecy. However, MLS provides PCS against active adaptive attackers through its Remove group operation. This meansthat,that as long as other members of the group are honest, the protocol will guarantee message secrecy for all messages exchanged in the epochs after the compromised party has been removed.</t> </section> </section> <section anchor="compromise-by-an-active-adversary-with-the-ability-to-sign-messages"> <name>Compromise by anactive adversaryActive Adversary with theabilityAbility tosign messages</name>Sign Messages</name> <t>If an active adversary has compromised an MLS client and can sign messages, two differentsettingsscenarios emerge. In the strongest compromise scenario, the attacker has access to the signing key and can forge authenticated messages. In aweaker, yetweaker but realistic scenario, the attacker has compromised a client but the client signature keys are protected with dedicated hardware featureswhichthat do not allow direct access to the value of the private key and instead provide a signature API.</t> <t>When considering an active adaptive attacker with access to a signature oracle, the compromise scenario implies a significant impact on both the secrecy and authentication guarantees of the protocol, especially if the attacker also has access to the group secrets. In thatcasecase, both secrecy and authentication are broken. The attacker can generate any message, for the current and future epochs, until the compromise is remediated and the formerly compromised client sends an honest update.</t> <t>Note that under this compromise scenario, the attacker can perform all operationswhichthat are available to a legitimate client even without access to the actual value of the signature key.</t> </section> <section anchor="compromise-of-the-authentication-with-access-to-a-signature-key"> <name>Compromise of theauthenticationAuthentication withaccessAccess to asignature key</name>Signature Key</name> <t>The difference between having access to the value of the signature key and only having access to a signing oracle is not about the ability of an active adaptive network attacker to perform different operations during the time of thecompromise,compromise; the attacker can perform every operation available to a legitimate client in both cases.</t> <t>There is a significant difference,howeverhowever, in terms of recovery after a compromise.</t> <t>Because of the PCS guarantees provided by the MLS protocol, when a previously compromised client recovers from compromise and performs an honest Commit, both secrecy and authentication of future messages can be recovered as long as the attacker doesn't otherwise get access to the key. Because the adversary doesn't have the signing key, they cannot authenticate messages on behalf of the compromised party, even if they still have control over some group keys by colluding with other members of the group.</t> <t>This is in contrast with the case where the signature key is leaked. In thatcasecase, the compromised endpoint needs to refresh its credentials and invalidate the old credentials before the attacker will be unable to authenticate messages.</t> <t>Beware that in both oracle and private key access, an active adaptive attacker can follow the protocol and request to update its own credential. This in turn induces a signature key rotation which could provide the attacker with part or the full value of the privatekeykey, depending on the architecture of the service provider.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Signature private keys should be compartmentalized from other secrets and preferably protected by a Hardware Security Module (HSM) or dedicated hardware features to allow recovery of the authentication for future messages after a compromise. <!-- [rfced] Section 8.3.3: Given "dedicated hardware features" in this sentence, we expanded "HSM" as "Hardware Security Module" for ease of the reader. If this is incorrect, please provide the correct definition. Original: *RECOMMENDATION:* Signature private keys should be compartmentalized from other secrets and preferably protected by an HSM or dedicated hardware features to allow recovery of the authentication for future messages after acompromise.</t> </li> </ul> <ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong>compromise. Currently: *RECOMMENDATION:* Signature private keys should be compartmentalized from other secrets and preferably protected by a Hardware Security Module (HSM) or dedicated hardware features to allow recovery of the authentication for future messages after a compromise. --> </t> <t indent="3"><strong>RECOMMENDATION:</strong> When the credential type supports revocation, the users of a group should check for revoked keys.</t></li> </ul></section> <sectionanchor="security-consideration-in-the-context-of-a-full-state-compromise">anchor="security-considerations-in-the-context-of-a-full-state-compromise"> <name>SecurityconsiderationConsiderations in thecontextContext of afull state compromise</name>Full State Compromise</name> <t>In real-world compromise scenarios, it is often the case that adversaries target specific devices to obtain parts of the memory or even the ability to execute arbitrary code in the targeted device.</t> <t>Also, recall that in this setting, the application will often retain the unencrypted messages. If so, the adversary does not have to break encryption at all to access sent and received messages. Messages may also be sent by using the application to instruct the protocol implementation.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> If messages are stored on the device, they should be protected using encryption at rest, and the keys used should be stored securely using dedicated mechanisms on the device.</t></li> </ul> <ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> If the threat model of the system is against an adversarywhichthat can access the messages on the device without even needing to attack MLS, the application should delete plaintext and ciphertext messages as soon as practical after encryption or decryption.</t></li> </ul><t>Note that this document makes a clear distinction between the way signature keys and other group shared secrets must be handled. In particular, a large set of group secrets cannot necessarily be assumed to be protected by an HSM or secure enclave features. This is especially true because these keys are frequently used and changed with each message received by a client.</t> <t>However, the signature private keys are mostly used by clients to send a message. They also provide strong authentication guarantees to otherclients, henceclients; hence, we consider that their protection by additional security mechanisms should be a priority.</t><t>Overall<t>Overall, there is no way to detect or prevent these compromises, as discussed in the previoussections, performingsections: Performing separation of the application secret states can help recovery aftercompromise,compromise; this is the case for signaturekeyskeys, but similarconcern existsconcerns exist for a client's encryption private keys.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> The secret keys used for public key encryption should be stored similarly to the way the signature keys are stored, as keys can be used to decrypt the group operation messages and contain the secret material used to compute all the group secrets.</t></li> </ul><t>Even if secure enclaves are not perfectlysecure,secure or are even completely broken, adopting additional protections for these keys can ease recovery of the secrecy and authentication guarantees after a compromise where, for instance, an attacker can sign messages without having access to the key. In certain contexts, the rotation of credentials might only be triggered by the AS throughACLs,ACLs and hence beoutside ofbeyond the capabilities of the attacker.</t> </section> </section> <section anchor="service-node-compromise"> <name>Service Node Compromise</name> <section anchor="general-considerations"> <name>Generalconsiderations</name>Considerations</name> <section anchor="privacy-of-the-network-connections"> <name>Privacy of thenetwork connections</name>Network Connections</name> <t>There are many scenarios leading to communication between the application on a device and the Delivery Service or the AuthenticationService. In particularService -- in particular, when:</t> <ul spacing="normal"> <li> <t>The application connects to the Authentication Service to generate or validate a new credential before distributing it.</t> </li> <li> <t>The application fetches credentials at the Delivery Service prior to creating a messaging group (one-to-one or more than two clients).</t> </li> <li> <t>The application fetches service provider information or messages on the Delivery Service.</t> </li> <li> <t>The application sends service provider information or messages to the Delivery Service.</t> </li> </ul> <t>In all these cases, the application will often connect to the device via a secure transportwhichthat leaks information about the origin of therequestrequest, such as the IP address and -- depending on the protocol -- theMACMedia Access Control (MAC) address of the device.</t> <t>Similar concerns exist in the peer-to-peer use casesoffor MLS.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> In the case where privacy or anonymity is important, using adequate protection such asMASQUEMultiplexed Application Substrate over QUIC Encryption (MASQUE) <xref target="I-D.schinazi-masque-proxy"/>, Top-of-Rack (ToR) switches, or a VPN can improve metadata protection. <!-- [rfced] Section 8.4.1.1: For ease of the reader, we expanded "MASQUE" and "ToR". If the definition of "ToR" is incorrect, please provide the correct definition. (The definition of "MASQUE" was taken from draft-schinazi-masque-proxy.) Original: *RECOMMENDATION:* In the case where privacy or anonymity is important, using adequate protection such as MASQUE [I-D.schinazi-masque-proxy], ToR, or a VPN can improve metadataprotection.</t> </li> </ul>protection. Currently: *RECOMMENDATION:* In the case where privacy or anonymity is important, using adequate protection such as Multiplexed Application Substrate over QUIC Encryption (MASQUE) [MASQUE-PROXY], Top-of-Rack (ToR) switches, or a VPN can improve metadata protection. --> </t> <t>More generally, using anonymous credentials in anMLS basedMLS-based architecture might not be enough to provide strong privacy or anonymity properties.</t> </section> <sectionanchor="storage-of-metadata-and-ecryption-at-rest-on-the-servers">anchor="storage-of-metadata-and-encryption-at-rest-on-the-servers"> <name>Storage of Metadata andEcryptionEncryption atrestRest on the Servers</name> <t>In the case where private data or metadata has to be persisted on the servers for functionality (mappings between identities and push tokens, groupmetadata...),metadata, etc.), it should be stored encrypted at rest and only decrypted upon need during the execution. Honest Service Providers can rely on suchencryptionan "encryption atrestrest" mechanism to be able to prevent access to the data when not using it.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Store cryptographic material used for server-side decryption of sensitivemeta-datametadata on the clients and only send it when needed. The server can use the secret to open and update encrypted data containers after which they can delete these keys until the next time they need it, in which case those can be provided by the client.</t></li> </ul> <ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Rely on group secrets exported from the MLS session for server-side encryption at rest and update the key after each removal from the group.RotateOtherwise, rotate those keys on a regularbasis otherwise.</t> </li> </ul>basis.</t> </section> </section> <section anchor="delivery-service-compromise"> <name>Delivery Service Compromise</name> <t>MLS is intended to provide strong guarantees in the face of compromise of the DS. Even a totally compromised DS should not be able to read messages or inject messages that will be acceptable to legitimate clients. It should also not be able to undetectably remove,reorderreorder, or replay messages.</t> <t>However, a malicious DS can mount a variety of DoS attacks on the system, including total DoS attacks (where it simply refuses to forward any messages) and partial DoS attacks (where it refuses to forward messages to and from specific clients). As noted in <xref target="delivery-guarantees"/>, these attacks are only partially detectable by clients without an out-of-band channel. Ultimately, failure of the DS to provide reasonable service must be dealt with as a customer service matter, not via technology.</t> <t>Because the DS is responsible for providing the initial keying material to clients, it can provide stale keys. This does not inherently lead to compromise of the message stream, but it does allow it to attack forward security to a limited extent. This threat can be mitigated by having initial keys expire.</t> <t>Initial keying material (KeyPackages) using the <tt>basic</tt> Credential type is more vulnerable to replacement by a malicious or compromised DS, as there is no built-in cryptographic binding between the identity and the public key of the client.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Prefer a Credential type in KeyPackageswhichthat includes a strong cryptographic binding between the identity and its key (forexampleexample, the <tt>x509</tt> Credential type). When using the <tt>basic</tt> Credentialtypetype, take extra care to verify the identity (typicallyout-of-band).</t> </li> </ul>out of band).</t> <section anchor="privacy-of-delivery-and-push-notifications"> <name>Privacy ofdeliveryDelivery andpush notifications</name> <t>AnPush Notifications</name> <t>Push-tokens provide an important mechanism that is often ignored from the standpoint of privacyconsiderations are the push-tokens.considerations. In many modern messaging architectures, applications are using push notification mechanisms typically provided by OS vendors. This is to make sure that when messages are available at the Delivery Service (orbyvia other mechanisms if the DS is not a central server), the recipient application on a device knows about it. Sometimes the push notification can contain the application messageitself whichitself; this saves a round trip with the DS.</t> <t>To "push" this information to the device, the service provider and the OS infrastructures use unique per-device, per-application identifiers called push-tokens. This means that the push notification provider and the service provider have information on which devices receive information and at which point in time. Alternatively, non-mobile applications could use awebsocketWebSocket or persistent connection for notifications directly from the DS.</t> <t>Even though they can't necessarily access the content, which is typically encrypted MLS messages, the service provider and the push notification provider have to be trusted to avoid making correlation on which devices are recipients of the samemessage.</t>message. <!-- [rfced] Section 8.4.2.1: We had trouble parsing this sentence. Are some words missing? If the suggested text is not correct, please clarify "they" and "content, which is typically encrypted MLS messages". Original: Even though they can't necessarily access the content, which is typically encrypted MLS messages, the service provider and the push notification provider have to be trusted to avoid making correlation on which devices are recipients of the same message. Suggested: Even though the service provider and the push notification provider can't necessarily access the content (typically encrypted MLS messages), they have to be trusted to avoid making correlations regarding which devices are recipients of the same message. --> </t> <t>For secure messaging systems, push notifications are often sentreal-timein real time, as it is not acceptable to create artificial delays for message retrieval.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Ifreal timereal-time notifications are not necessary, one can delay notifications randomly across recipient devices using a mixnet or other techniques.</t></li> </ul><t>Note that with a legal request to ask the service provider for the push-token associated with an identifier, it is easy to correlate the token with a second request to the company operating the push-notification system to get information about the device, which is often linked with a real identity via a cloud account, a creditcardcard, or other information.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> If stronger privacy guarantees are needed with regard to the push notification provider, the client can choose to periodically connect to the Delivery Service without the need of a dedicated push notification infrastructure.</t></li> </ul><t>Applications can also consider anonymous systems for server fanout (forexampleexample, <xref target="Loopix"/>).</t> </section> </section> <section anchor="as-compromise"> <name>Authentication Service Compromise</name> <t>The Authentication Service design is left to the infrastructure designers. In most designs, a compromised AS is a serious matter, as the AS can serve incorrect or attacker-provided identities to clients.</t> <ul spacing="normal"> <li> <t>The attacker can link an identity to acredential</t>credential.</t> </li> <li> <t>The attacker can generate newcredentials</t>credentials.</t> </li> <li> <t>The attacker can sign newcredentials</t>credentials.</t> </li> <li> <t>The attacker can publish or distributecredentials</t>credentials.</t> </li> </ul> <t>An attacker that can generate or sign new credentials may or may not have access to the underlying cryptographic material necessary to perform such operations. In that last case, it results in windows of time for which all emitted credentials might be compromised.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Use HSMs to store the root signature keys to limit the ability of an adversary with no physical access to extract the top-level signature private key.</t></li> </ul><t>Note that historically some systems generate signature keys on the Authentication Service and distribute the private keys to clients along with their credential. This is a dangerous practice because it allows the AS or an attacker who has compromised the AS to silently impersonate the client.</t> <section anchor="authentication-compromise-ghost-users-and-impersonations"> <name>Authenticationcompromise:Compromise: GhostusersUsers andimpersonations</name>Impersonations</name> <t>One important property of MLS is that all Members know which other members are in the group at all times. If all Members of the group and the Authentication Service are honest, no parties other than the members of the current group can read and write messages protected by the protocol for that Group.</t> <t>This guarantee applies to the cryptographic identities of the members. Details about how to verify the identity of a client depend on the MLS Credential type used. For example, cryptographic verification of credentials can be largely performed autonomously (e.g., without user interaction) by the clients themselves for the <tt>x509</tt> Credential type.</t> <t>In contrast, when MLS clients use the <tt>basic</tt> Credential type,thensome other mechanism must be used to verify identities. Forinstanceinstance, the Authentication Service could operate some sort of directory server to provide keys, or users could verify keys via an out-of-band mechanism.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Select the MLS Credential type with the strongest securitywhichthat is supported by all target members of an MLS group.</t></li> </ul> <ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Do not use the same signature keypair across groups. Update all keys for all groups on a regular basis. Do not preserve keys in different groups when suspecting a compromise.</t></li> </ul><t>If the AS is compromised, it could validate a signature keypair (or generate anew) signature keypairnew one) for an attacker. The attacker could then use this keypair to join a group as if it were another of the user's clients. Because a user can have many MLS clients running the MLS protocol, it possibly has many signature keypairs for multiple devices. These attacks could be very difficult to detect, especially in large groups where the UI might not reflect all the changes back to the users. If the application participates in a key transparency mechanism in which it is possible to determine every key for a given user, then this would allow for detection of surreptitiously created false credentials.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Make sure that MLS clients reflect all the membership changes to the users as they happen. If a choice has to be made because the number of notifications is too high, the client should provide a log of state of the device so that the user can examine it.</t></li> </ul> <ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Provide a key transparency mechanism for the AuthenticationServicesService to allow public verification of the credentials authenticated by this service.</t></li> </ul><t>While the ways to handle MLS credentials are not defined by the protocol or the architecture documents, the MLS protocol has been designed with a mechanism that can be used to provide out-of-band authentication to users. The "authentication_secret" generated for each user at each epoch of the group is a one-time,per client,per-client authentication secretwhichthat can be exchanged between users to prove theiridentityidentities to each other. This can bedonedone, forinstanceinstance, using a QR code that can be scanned by the otherparties.</t> <ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong>parties. <!-- [rfced] Section 8.4.3.1: In this document's XML file, all other parameters containing underscores are placed in <tt>s except for "authentication_secret". May we place it in <tt>s and remove the quotes? Original: The "authentication_secret" generated for each user at each epoch of the group is a one-time, per client, authentication secret which can be exchanged between users to prove their identity to each other. --> </t> <t indent="3"><strong>RECOMMENDATION:</strong> Provide one or more out-of-band authentication mechanisms to limit the impact of an Authentication Service compromise.</t></li> </ul><t>We note, again, that the Authentication Service may not be a centralizedsystem,system and could be realized by many mechanisms such as establishing prior one-to-one deniable channels, gossiping, or using trust on first use (TOFU) for credentials used by the MLSProtocol.</t>protocol.</t> <t>Another important consideration is the ease of redistributing new keys on client compromise, which helps recovering security faster in various cases.</t> </section> <section anchor="privacy-of-the-group-membership"> <name>Privacy of the Group Membership</name> <t>Group membership is itself sensitiveinformationinformation, and MLS is designed to limit the amount of persistent metadata. However, large groups often require an infrastructurewhichthat provides server fanout. In the case of client fanout, the destination of a message is known by allclients, henceclients; hence, the server usually does not need this information. However, they may learn this information through traffic analysis. Unfortunately, in a server-side fanout model, the Delivery Service can learn that a given client is sending the same message to a set of other clients. In addition, there may be applications of MLS in which the group membership list is stored on some server associated with the DeliveryService.</t>Service. <!-- [rfced] Section 8.4.3.2: It is not clear to us whether "they" in the second sentence refers to "all clients" or "the server" in the first sentence. Please clarify. Original (the run-on sentence has been fixed): In the case of client fanout, the destination of a message is known by all clients, hence the server usually does not need this information. However, they may learn this information through traffic analysis. --> </t> <t>While this knowledge is not a breach of the protocol's authentication or confidentiality guarantees, it is a serious issue for privacy.</t> <t>Someinfrastructureinfrastructures keep a mapping between keys used in the MLS protocol and user identities. An attacker with access to this information due to compromise or regulation can associate unencrypted group messages (e.g., Commits and Proposals) with the corresponding user identity.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Use encrypted group operation messages to limit privacy risks whenever possible.</t></li> </ul><t>In certain cases, the adversary can access specific bindings between public keys and identities. If the signature keys are reused across groups, the adversary can get more information about the targeted user.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Ensure that linking between public keys and identities only happens in expected scenarios.</t></li> </ul></section> </section> </section> <section anchor="considerations-for-attacks-outside-of-the-threat-model"> <name>Considerations forattacks outsideAttacks Outside of thethreat model</name>Threat Model</name> <t>Physical attacks on devices storing and executing MLS principals are not considered in depth in the threat model of the MLS protocol. While non-permanent, non-invasive attacks can sometimes be equivalent to software attacks, physical attacks are considered outside of the MLS threat model.</t> <t>Compromise scenarios typically consist of a software adversary, which can maintain active adaptive compromise and arbitrarily change the behavior of the client or service.</t> <t>On the other hand, security goals consider that honest clients will always run the protocol according to its specification. This relies on implementations of the protocol to securely implement the specification, which remains non-trivial.</t><ul empty="true"> <li> <t><strong>RECOMMENDATION:</strong><t indent="3"><strong>RECOMMENDATION:</strong> Additional steps should be taken to protect the device and the MLS clients from physical compromise. In such settings, HSMs and secure enclaves can be used to protect signature keys.</t></li> </ul></section> <section anchor="cryptographic-analysis-of-the-mls-protocol"> <name>Cryptographic Analysis of the MLS Protocol</name> <t>Various academic works have analyzed MLS and the different security guarantees it aims to provide. The security of large parts of the protocol has been analyzed by <xref target="BBN19"/>(draft(regarding MLS Draft 7), <xref target="ACDT21"/>(draft 11)(regarding MLS Draft 11), and <xref target="AJM20"/>(draft(regarding MLS Draft 12).</t> <t>Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarialmodels, formodels. For example, <xref target="BBR18"/>, <xref target="ACDT19"/>, <xref target="ACCKKMPPWY19"/>, <xref target="AJM20"/>, <xref target="ACJM20"/>, and <xref target="AHKM21"/> analyze the ratcheting tree sub-protocol of MLS that facilitates keyagreement,agreement; <xref target="WPBB22"/> analyzes the sub-protocol of MLS for group state agreement andauthentication, whileauthentication; and <xref target="BCK21"/> analyzes the key derivation paths in the ratchet tree and key schedule. Finally, <xref target="CHK21"/> analyzes the authentication and cross-group healing guarantees provided by MLS.</t> </section> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>This documentmakeshas norequests of IANA.</t>IANA actions.</t> </section> </middle> <back> <displayreference target="I-D.ietf-keytrans-architecture" to="KT"/> <displayreference target="I-D.ietf-mls-extensions" to="EXTENSIONS"/> <displayreference target="I-D.ietf-mls-federation" to="FEDERATION"/> <displayreference target="I-D.schinazi-masque-proxy" to="MASQUE-PROXY"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="I-D.ietf-mls-protocol"> <front> <title>The Messaging Layer Security (MLS) Protocol</title> <author fullname="Richard Barnes" initials="R." surname="Barnes"> <organization>Cisco</organization> </author> <author fullname="Benjamin Beurdouche" initials="B." surname="Beurdouche"> <organization>Inria & Mozilla</organization> </author> <author fullname="Raphael Robert" initials="R." surname="Robert"> <organization>Phoenix R&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-Gordon"> <organization>University of Oxford</organization> </author> <date day="27" month="March" year="2023"/> <abstract> <t>Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. </t> </abstract> </front> <seriesInfo name="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-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands.</t> </abstract> </front> <seriesInfo name="RFC" value="9420"/> <seriesInfo name="DOI" value="10.17487/RFC9420"/> </reference> <reference anchor="RFC5116"> <front> <title>An Interface and Algorithms for Authenticated Encryption</title> <author fullname="D. McGrew" initials="D." surname="McGrew"/> <date month="January" year="2008"/> <abstract> <t>This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5116"/> <seriesInfo name="DOI" value="10.17487/RFC5116"/> </reference><!-- draft-ietf-mls-protocol (RFC 9420; published) --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9420.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="KT"> <front> <title>Key Transparency Architecture</title> <author fullname="Brendan McMillion" initials="B." surname="McMillion"> </author> <date day="4" month="March" year="2024"/> <abstract> <t> This document defines the terminology and interaction patterns involved in the deployment of Key Transparency (KT) in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non-prescriptive guidance on how to securely apply KT to a number of common applications. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-keytrans-architecture-01"/> </reference><!-- draft-ietf-keytrans-architecture (I-D Exists) --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-keytrans-architecture.xml"/> <reference anchor="CONIKS" target="https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-melara.pdf"> <front> <title>CONIKS: Bringing Key Transparency to End Users</title> <authorinitials="M."initials="M. S." surname="Melara" fullname="Marcela S. Melara"> <organization/> </author> <author initials="A." surname="Blankstein" fullname="Aaron Blankstein"> <organization/> </author> <author initials="J." surname="Bonneau" fullname="Joseph Bonneau"> <organization/> </author> <authorinitials="E."initials="E. W." surname="Felten" fullname="Edward W. Felten"> <organization/> </author> <authorinitials="M."initials="M. J." surname="Freedman" fullname="Michael J. Freedman"> <organization/> </author> <date month="August" year="2015"/> </front> <refcontent>Proceedings of the 24th USENIX Security Symposium</refcontent> </reference> <referenceanchor="CAPBR">anchor="CAPBR" target="https://dl.acm.org/doi/10.1145/343477.343502"> <front> <title>Towards robust distributed systems (abstract)</title> <author fullname="Eric A. Brewer"initials="E."initials="E. A." surname="Brewer"> <organization>UC Berkeley and Inktomi</organization> </author> <date month="July" year="2000"/> </front><seriesInfo name="Proceedings<refcontent>Proceedings of the nineteenth annual ACM symposium on Principles ofdistributed" value="computing"/>distributed computing, p. 7</refcontent> <seriesInfo name="DOI" value="10.1145/343477.343502"/><refcontent>ACM</refcontent></reference> <reference anchor="ACCKKMPPWY19" target="https://eprint.iacr.org/2019/1489"> <front> <title>Keep the Dirt: Tainted TreeKEM, Adaptively and Actively Secure Continuous Group Key Agreement</title> <author initials="J." surname="Alwen" fullname="Joel Alwen"> <organization/> </author> <author initials="M." surname="Capretto" fullname="Margarita Capretto"> <organization/> </author> <author initials="M." surname="Cueto" fullname="Miguel Cueto"> <organization/> </author> <author initials="C." surname="Kamath" fullname="Chethan Kamath"> <organization/> </author> <author initials="K." surname="Klein" fullname="Karen Klein"> <organization/> </author> <author initials="I." surname="Markov" fullname="Ilia Markov"> <organization/> </author> <author initials="G." surname="Pascual-Perez" fullname="Guillermo Pascual-Perez"> <organization/> </author> <author initials="K." surname="Pietrzak" fullname="Krzysztof Pietrzak"> <organization/> </author> <author initials="M." surname="Walter" fullname="Michael Walter"> <organization/> </author> <author initials="M." surname="Yeo" fullname="Michelle Yeo"> <organization/> </author> <date year="2019"/> </front> <refcontent>Cryptology ePrint Archive</refcontent> </reference> <reference anchor="ACDT19" target="https://eprint.iacr.org/2019/1189.pdf"> <front> <title>Security Analysis and Improvements for the IETF MLS Standard for Group Messaging</title> <author initials="J." surname="Alwen" fullname="Joel Alwen"> <organization/> </author> <author initials="S." surname="Coretti" fullname="Sandro Coretti"> <organization/> </author> <author initials="Y." surname="Dodis" fullname="Yevgeniy Dodis"> <organization/> </author> <author initials="Y." surname="Tselekounis" fullname="Yiannis Tselekounis"> <organization/> </author> <date year="2019"/> </front> <refcontent>Cryptology ePrint Archive</refcontent> </reference> <reference anchor="ACDT21" target="https://eprint.iacr.org/2021/1083.pdf"> <front> <title>Modular Design of Secure Group Messaging Protocols and the Security of MLS</title> <author initials="J." surname="Alwen" fullname="Joel Alwen"> <organization/> </author> <author initials="S." surname="Coretti" fullname="Sandro Coretti"> <organization/> </author> <author initials="Y." surname="Dodis" fullname="Yevgeniy Dodis"> <organization/> </author> <author initials="Y." surname="Tselekounis" fullname="Yiannis Tselekounis"> <organization/> </author> <date year="2021"/> </front> <refcontent>Cryptology ePrint Archive</refcontent> </reference> <reference anchor="ACJM20" target="https://eprint.iacr.org/2020/752.pdf"> <front> <title>Continuous Group Key Agreement with Active Security</title> <author initials="J." surname="Alwen" fullname="Joel Alwen"> <organization/> </author> <author initials="S." surname="Coretti" fullname="Sandro Coretti"> <organization/> </author> <author initials="D." surname="Jost" fullname="Daniel Jost"> <organization/> </author> <author initials="M." surname="Mularczyk" fullname="Marta Mularczyk"> <organization/> </author> <date year="2020"/> </front> <refcontent>Cryptology ePrint Archive</refcontent> </reference> <reference anchor="AHKM21" target="https://eprint.iacr.org/2021/1456.pdf"> <front> <title>Server-Aided Continuous Group Key Agreement</title> <author initials="J." surname="Alwen" fullname="Joel Alwen"> <organization/> </author> <author initials="D." surname="Hartmann" fullname="Dominik Hartmann"> <organization/> </author> <author initials="E." surname="Kiltz" fullname="Eike Kiltz"> <organization/> </author> <author initials="M." surname="Mularczyk" fullname="Marta Mularczyk"> <organization/> </author> <date year="2021"/> </front> <refcontent>Cryptology ePrint Archive</refcontent> </reference> <reference anchor="AJM20" target="https://eprint.iacr.org/2020/1327.pdf"> <front> <title>On The Insider Security of MLS</title> <author initials="J." surname="Alwen" fullname="Joel Alwen"> <organization/> </author> <author initials="D." surname="Jost" fullname="Daniel Jost"> <organization/> </author> <author initials="M." surname="Mularczyk" fullname="Marta Mularczyk"> <organization/> </author> <date year="2020"/> </front> <refcontent>Cryptology ePrint Archive</refcontent> </reference> <reference anchor="BBN19" target="https://inria.hal.science/hal-02425229/document"> <front> <title>Formal Models and Verified Protocols for Group Messaging: Attacks and Proofs for IETF MLS</title> <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan"> <organization/> </author> <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche"> <organization/> </author> <author initials="P." surname="Naldurg" fullname="Prasad Naldurg"> <organization/> </author> <date year="2019"/> </front> <seriesInfo name="HAL ID" value="hal-02425229"/> </reference> <reference anchor="BBR18" target="https://hal.inria.fr/hal-02425247/file/treekem+%281%29.pdf"> <front> <title>TreeKEM: Asynchronous Decentralized Key Management for Large Dynamic Groups - A protocol proposal for Messaging Layer Security (MLS)</title> <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan"> <organization/> </author> <author initials="R." surname="Barnes" fullname="Richard Barnes"> <organization/> </author> <author initials="E." surname="Rescorla" fullname="Eric Rescorla"> <organization/> </author> <date year="2018"/> </front> <seriesInfo name="HAL ID" value="hal-02425247"/> </reference> <reference anchor="BCK21" target="https://eprint.iacr.org/2021/137.pdf"> <front><title>Cryptographic Security<title>Security Analysis of the MLSRFC, Draft 11</title>Key Distribution</title> <author initials="C." surname="Brzuska" fullname="Chris Brzuska"> <organization/> </author> <author initials="E." surname="Cornelissen" fullname="Eric Cornelissen"> <organization/> </author> <author initials="K." surname="Kohbrok" fullname="Konrad Kohbrok"> <organization/> </author> <date year="2021"/> </front> <refcontent>Cryptology ePrint Archive</refcontent> </reference> <!-- [rfced] [BCK21]: We updated this listing to use the title found on the provided URL, as we found "Cryptographic Security of the MLS RFC, Draft 11" on <https://eprint.iacr.org/2021/137> but again found "Security Analysis of the MLS Key Distribution" when we clicked "PDF" under "Available format(s)". Please let us know any concerns. Original: [BCK21] Brzuska, C., Cornelissen, E., and K. Kohbrok, "Cryptographic Security of the MLS RFC, Draft 11", 2021, <https://eprint.iacr.org/2021/137.pdf>. Currently: [BCK21] Brzuska, C., Cornelissen, E., and K. Kohbrok, "Security Analysis of the MLS Key Distribution", Cryptology ePrint Archive, 2021, <https://eprint.iacr.org/2021/137.pdf>. --> <reference anchor="CHK21" target="https://www.usenix.org/system/files/sec21-cremers.pdf"> <front> <title>The Complexities of Healing in Secure Group Messaging: Why Cross-Group Effects Matter</title> <author initials="C." surname="Cremers" fullname="Cas Cremers"> <organization/> </author> <author initials="B." surname="Hale" fullname="Britta Hale"> <organization/> </author> <author initials="K." surname="Kohbrok" fullname="Konrad Kohbrok"> <organization/> </author> <date month="August" year="2021"/> </front> <refcontent>Proceedings of the 30th USENIX Security Symposium</refcontent> </reference> <reference anchor="WPBB22" target="https://eprint.iacr.org/2022/1732.pdf"> <front> <title>TreeSync: Authenticated Group Management for Messaging Layer Security</title> <author initials="T." surname="Wallez" fullname="Théophile Wallez"> <organization/> </author> <author initials="J." surname="Protzenko" fullname="Jonathan Protzenko"> <organization/> </author> <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche"> <organization/> </author> <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan"> <organization/> </author> <date year="2022"/> </front> <refcontent>Cryptology ePrint Archive</refcontent> </reference> <referenceanchor="Loopix">anchor="Loopix" target=""> <front> <title>The Loopix Anonymity System</title> <author initials="A. M." surname="Piotrowska" fullname="Ania M. Piotrowska"> <organization/> </author> <author initials="J." surname="Hayes" fullname="Jamie Hayes"> <organization/> </author> <author initials="T." surname="Elahi" fullname="Tariq Elahi"> <organization/> </author> <author initials="S." surname="Meiser" fullname="Sebastian Meiser"> <organization/> </author> <author initials="G." surname="Danezis" fullname="George Danezis"> <organization/> </author> <date month="August" year="2017"/> </front></reference> <reference anchor="RFC6120"> <front> <title>Extensible Messaging and Presence Protocol (XMPP): Core</title> <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/> <date month="March" year="2011"/> <abstract> <t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6120"/> <seriesInfo name="DOI" value="10.17487/RFC6120"/> </reference> <reference anchor="RFC5280"> <front> <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title> <author fullname="D. Cooper" initials="D." surname="Cooper"/> <author fullname="S. Santesson" initials="S." surname="Santesson"/> <author fullname="S. Farrell" initials="S." surname="Farrell"/> <author fullname="S. Boeyen" initials="S." surname="Boeyen"/> <author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="W. Polk" initials="W." surname="Polk"/> <date month="May" year="2008"/> <abstract> <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview<refcontent>Proceedings ofthis approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regardingtheformat and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5280"/> <seriesInfo name="DOI" value="10.17487/RFC5280"/> </reference> <reference anchor="I-D.ietf-mls-extensions"> <front> <title>The Messaging Layer Security (MLS) Extensions</title> <author fullname="Raphael Robert" initials="R." surname="Robert"> <organization>Phoenix R&D</organization> </author> <date day="24" month="April" year="2024"/> <abstract> <t> This document describes extensions to the Messaging Layer26th USENIX Security(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> <seriesInfo name="Internet-Draft" value="draft-ietf-mls-extensions-04"/> </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&D</organization> </author> <date day="9" month="September" year="2023"/> <abstract> <t> This document describes how the Messaging Layer Security (MLS) protocol can be used in a federated environment. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mlswg/mls-federation. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-mls-federation-03"/> </reference> <reference anchor="RFC3552"> <front> <title>Guidelines for Writing RFC Text on Security Considerations</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <author fullname="B. Korver" initials="B." surname="Korver"/> <date month="July" year="2003"/> <abstract> <t>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="72"/> <seriesInfo name="RFC" value="3552"/> <seriesInfo name="DOI" value="10.17487/RFC3552"/> </reference> <reference anchor="RFC9000"> <front> <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/> <date month="May" year="2021"/> <abstract> <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t> </abstract> </front> <seriesInfo name="RFC" value="9000"/> <seriesInfo name="DOI" value="10.17487/RFC9000"/> </reference> <reference anchor="RFC8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <date month="August" year="2018"/> <abstract> <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="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 Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document defines the concept of a "MASQUE Proxy", an Internet-accessible node that can relay client traffic in order to provide privacy guarantees. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-schinazi-masque-proxy-02"/>Symposium</refcontent> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6120.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <!-- draft-ietf-mls-extensions (I-D Exists) --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-mls-extensions.xml"/> <!-- draft-ietf-mls-federation (Expired) --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-mls-federation.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <!-- draft-schinazi-masque-proxy (I-D Exists) --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.schinazi-masque-proxy.xml"/> </references> </references> <section anchor="contributors" numbered="false" toc="include" removeInRFC="false"> <name>Contributors</name> <contact initials="R." surname="Barnes" fullname="Richard Barnes"> <organization>Cisco</organization> <address> <email>rlb@ipv.sx</email> </address> </contact> <contact initials="K." surname="Cohn-Gordon" fullname="Katriel Cohn-Gordon"> <organization>Meta Platforms</organization> <address> <email>me@katriel.co.uk</email> </address> </contact> <contact initials="C." surname="Cremers" fullname="Cas Cremers"> <organization>CISPA Helmholtz Center for Information Security</organization> <address> <email>cremers@cispa.de</email> </address> </contact> <contact initials="B." surname="Hale" fullname="Britta Hale"> <organization>Naval Postgraduate School</organization> <address> <email>britta.hale@nps.edu</email> </address> </contact> <contact initials="A." surname="Kwon" fullname="Albert Kwon"> <organization>Badge Inc.</organization> <address> <email>kwonalbert@badgeinc.com</email> </address> </contact> <contact initials="K." surname="Kohbrok" fullname="Konrad Kohbrok"> <organization>Phoenix R&D</organization> <address> <email>konrad.kohbrok@datashrine.de</email> </address> </contact> <contact initials="R." surname="Mahy" fullname="Rohan Mahy"> <organization>Wire</organization> <address> <email>rohan.mahy@wire.com</email> </address> </contact> <contact initials="B." surname="McMillion" fullname="Brendan McMillion"> <organization/> <address> <email>brendanmcmillion@gmail.com</email> </address> </contact> <contact initials="T. van der" surname="Merwe" fullname="Thyla van der Merwe"> <organization/> <address> <email>tjvdmerwe@gmail.com</email> </address> </contact> <contact initials="J." surname="Millican" fullname="Jon Millican"> <organization>Meta Platforms</organization> <address> <email>jmillican@meta.com</email> </address> </contact> <contact initials="R." surname="Robert" fullname="Raphael Robert"> <organization>Phoenix R&D</organization> <address> <email>ietf@raphaelrobert.com</email> </address> </contact> </section> </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==[rfced] Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> <!-- [rfced] Please let us know if any changes are needed for the following: a) The following term was used inconsistently in this document. We chose to use the latter form. Please let us know any objections. last resort (2 instances) / "last resort" (4 instances) (per Normative Reference RFC 9420) b) The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Would you like us to follow usage in Normative Reference RFC 9420 ("The Messaging Layer Security (MLS) Protocol")? Most of the terms listed below are also used in RFC 9420. We have marked them with asterisks ("*"). * Application message (3 instances) / application message (12 instances) (e.g., "an Application message", "an application message") (RFC 9420 uses "application message".) * authentication service (Abstract) / Authentication Service (16 instances) (RFC 9420 uses "Authentication Service".) * commit (>=13 instances) / Commit (>50 instances) (e.g., "the commit", "the Commit", "any commits", "any Commits") (RFC 9420 uses both forms but appears to use lowercase when this term is used generally. Please review usage in this document and advise.) * credential type (1 instance) / Credential type (8 instances) (We also see "credential types" in Section 7.) (RFC 9420 uses "credential type".) * delivery service (2 instances) / Delivery Service (>40 instances) (RFC 9420 uses "Delivery Service".) Eventually Consistent / eventually consistent (1 instance each) (We also see "strongly and eventually consistent systems" in Section 5.2.) * forward secrecy (3 instances) / Forward Secrecy (1 instance other than where defined) (RFC 9420 uses "forward secrecy". We changed "forward-secrecy" in this document to "forward secrecy" for now.) * group / Group (used generally) (e.g., "a group", "a Group", "the group", "that group", "that Group") (RFC 9420 uses "a group", "the group", "that group", etc.) group operation message (7 instances) / Group Operation message (2 instances in Section 8.3.1.1) * group secret (10 instances) / Group Secret (2 instances) / Group secret (1 instance) (RFC 9420 uses "group secret".) * Handshake message (2 instances) / handshake message (9 instances) (RFC 9420 uses "handshake message".) Key Transparency (2 instances) / key transparency (2 instances) (e.g., "Key Transparency [KT]", "key transparency mechanism") * keypair (4 instances) / key pair (5 instances) (RFC 9420 uses "key pair".) * Member (3 instances) / member (>50 instances) (used generally) (e.g., "When a client is part of a Group, it is called a Member", "all Members", "all members") (RFC 9420 uses "member".) * Plaintext (1 instance) / plaintext (3 instances) ("MLS Plaintext messages", "plaintext and ciphertext messages") (RFC 9420 uses "plaintext" in running text.) * post-compromise security / Post-Compromise Security (RFC 9420 uses "post-compromise security".) * proposal (23 instances) / Proposal (5 instances) (used generally, e.g., "the proposal", "the Proposal", "of proposals", "of Proposals") RFC 9420 uses initial capitalization when referring to a Proposal object and lowercase when used generally. We cannot determine general uses versus referring to a Proposal object here. Please review and advise. push notification (adj.) (5 instances) / push-notification (adj.) (1 instance) (e.g., "push notification provider", "push notification infrastructure", "push-notification system") (Usage in post-6000 published RFCs is mixed.) push tokens (1 instance) / push-tokens (3 instances) (No precedent in published RFCs.) * ratchet secret (1 instance) / Ratchet Secret (11 instances) (RFC 9420 uses "ratchet secret".) ReInit proposal (3 instances in Section 5.2.3) / reinitialization proposal (2 instances in Section 7) Service Provider (2 instances) / service provider (10 instances) Strongly Consistent (2 instances) / strongly consistent (1 instance) * x509 / X.509 ("x509 Credential type", "X.509 certificates") (RFC 9420 uses "X509Credential" and "X.509 credential".) c) In the XML file, we see that emphasis ("<em>") for "Welcome message" is applied three times, while all other instances of "<em>" are used only once for a given word or term (where the term is first used). Is "Welcome message" a special case, or should the second and third instances of "<em>" be removed for this term? d) Would you like spacing to be consistent? Welcome (Bob) / Add(Bob) (RFC 9420 does not use spacing between "Welcome" or "Add" and the parenthetical item that follows those terms.) Notes re. the SVG: In the SVG for Figure 2, we found that a closing parenthesis was missing after the first "Bob": <text x="84" y="292">(Bob</text> We added the closing parenthesis. However, as a result, there isn't a space between "(Bob)" and the arrow line. If you want to change "Welcome (Bob)" to "Welcome(Bob)" in line with RFC 9420, we will need you to modify the entries in the SVG. If you want to have a space after the first "Bob" in Figure 2, we will need you to make that update as well. --> </rfc>