4.2.1.Strongly Consistent

With this approach, the Delivery Service ensures that some types of incomingmessages have a linear order and all members agree on that order. The DeliveryService is trusted to break ties when two members send a Commit message at thesame time.¶

As an example, there could be an "ordering server" Delivery Service thatbroadcasts all messages received to all users and ensures that all clients seehandshake messages in the same order. Clients that send a Commit would then waitto apply it until it's broadcast back to them by the Delivery Service, assumingthey don't receive another Commit first.¶

The Delivery Service can rely on theepoch andcontent_type fields of anMLSMessage for providing an order only to handshake messages, and possibly evenfilter or reject redundant Commit messages proactively to prevent them frombeing broadcast. Alternatively, the Delivery Service could simply apply an orderto all messages and rely on clients to ignore redundant Commits.¶

4.2.2.Eventually Consistent

With this approach, the Delivery Service is built in a way that may besignificantly more available or performant than a strongly consistent system,but offers weaker consistency guarantees. Messages may arrive to differentclients in different orders and with varying amounts of latency, which meansclients are responsible for reconciliation.¶

This type of Delivery Service might arise, for example, when group members aresending each message to each other member individually, or when a distributedpeer-to-peer network is used to broadcast messages.¶

Upon receiving a Commit from the Delivery Service, clients can either:¶

1. Pause sending new messages for a short amount of time to account for areasonable degree of network latency and see if any other Commits arereceived for the same epoch. If multiple Commits are received, the clientscan use a deterministic tie-breaking policy to decide which to accept, andthen resume sending messages as normal.¶
2. Accept the Commit immediately but keep a copy of the previous group state fora short period of time. If another Commit for a past epoch is received,clients use a deterministic tie-breaking policy to decide if they shouldcontinue using the Commit they originally accepted or revert and use thelater one. Note that any copies of previous or forked group states must bedeleted within a reasonable amount of time to ensure the protocol providesforward-secrecy.¶

In the event of a network partition, a subset of members may be isolated fromthe rest of the group long enough that the mechanisms above no longer work. Thiscan only be solved by sending a ReInit proposal to both groups, possibly with anexternal sender type, and recreating the group to contain all members again.¶

If the Commit references an unknown proposal, group members may need to solicitthe Delivery Service or other group members individually for the contents of theproposal.¶

7.1.1.Integrity and Authentication of Custom Metadata

The MLS protocol provides an authenticated "Additional Authenticated Data" fieldfor applications to make data available outside the MLSCiphertext.¶

• RECOMMENDATION: Use the "Additional Authenticated Data" field of theMLSCiphertext message instead of using other unauthenticated means of sendingmetadata throughout the infrastructure. If the data is private, theinfrastructure should use encrypted Application messages instead.¶

7.1.2.Metadata Protection for Unencrypted Group Operations

Having no secure channel to exchange MLS messages can have a serious impact onprivacy when transmitting unencrypted group operation messages. Observing thecontents and signatures of the group operation messages may lead an adversary toextract information about the group membership.¶

• RECOMMENDATION: Never use the unencrypted mode for group operationswithout using a secure channel for the transport layer.¶

7.1.3.DoS protection

In general we do not consider Denial of Service (DoS) resistance to be theresponsibility of the protocol. However, it should not be possible for anyoneaside from the Delivery Service to perform a trivial DoS attack from which it ishard to recover. This can be achieved through the secure transport layer.¶

In the centralized setting, DoS protection can typically be performed by usingtickets or cookies which identify users to a service for a certain number ofconnections. Such a system helps in preventing anonymous clients from sendingarbitrary numbers of group operation messages to the Delivery Service or the MLSclients.¶

• RECOMMENDATION: Anonymous credentials can be used in order to help DoSattacks prevention, in a privacy preserving manner. Note that the privacy ofthese mechanisms has to be adjusted in accordance with the privacy expectedfrom the secure transport links. (See more discussion further down.)¶

7.1.4.Message Suppression and Error Correction

As noted above, MLS is designed to provide some robustness in the face oftampering within the secure transport, i.e., tampering by the Delivery Service.The confidentiality and authenticity properties of MLS prevent the DS reading orwriting messages. MLS also provides a few tools for detecting messagesuppression, with the caveat that message suppression cannot always bedistinguished from transport failure.¶

Each encrypted MLS message carries a "generation" number which is a per-senderincrementing counter. If a group member observes a gap in the generationsequence for a sender, then they know that they have missed a message from thatsender. MLS also provides a facility for group members to send authenticatedacknowledgments of application messages received within a group.¶

As discussed inSection 4, the Delivery Service is trusted to selectthe single Commit message that is applied in each epoch from among the ones sentby group members. Since only one Commit per epoch is meaningful, it's notuseful for the DS to transmit multiple Commits to clients. The risk remainsthat the DS will use the ability maliciously.¶

While it is difficult or impossible to prevent a network adversary fromsuppressing payloads in transit, in certain infrastructures such as banks orgovernments settings, unidirectional transports can be used and be enforced viaelectronic or physical devices such as diodes. This can lead to payloadcorruption which does not affect the security or privacy properties of the MLSprotocol but does affect the reliability of the service. In that case specificmeasures can be taken to ensure the appropriate level of redundancy and qualityof service for MLS.¶

• RECOMMENDATION: If unidirectional transport is used for the securetransport channel, prefer using a transport protocol which provides ForwardError Correction.¶

7.2.1.Message Secrecy and Authentication

MLS enforces the encryption of application messages and thus generallyguarantees authentication and confidentiality of application messages sent in agroup.¶

In particular, this means that only other members of a given group can decryptthe payload of a given application message, which includes information about thesender of the message.¶

Similarly, group members receiving a message from another group member canauthenticate that group member as the sender of the message and verify themessage's integrity.¶

Message content can be deniable if the signature keys are exchanged over adeniable channel prior to signing messages.¶

Depending on the group settings, handshake messages can be encrypted as well. Ifthat is the case, the same security guarantees apply.¶

MLS optionally allows the addition of padding to messages, mitigating the amountof information leaked about the length of the plaintext to an observer on thenetwork.¶

7.2.2.Forward and Post-Compromise Security

MLS provides additional protection regarding secrecy of past messages and futuremessages. These cryptographic security properties are Forward Secrecy (FS) andPost-Compromise Security (PCS).¶

FS means that access to all encrypted traffic history combined with an access toall current keying material on clients will not defeat the secrecy properties ofmessages older than the oldest key of the compromised client. Note that thismeans that clients have the extremely important role of deleting appropriatekeys as soon as they have been used with the expected message, otherwise thesecrecy of the messages and the security for MLS is considerably weakened.¶

PCS means that if a group member's state is compromised at some time t1 but thegroup member subsequently performs an update at some time t2, then all MLSguarantees apply to messages sent by the member after time t2, and by othermembers after they have processed the update. For example, if an attacker learnsall secrets known to Alice at time t1, including both Alice's long-term secretkeys and all shared group keys, but Alice performs a key update at time t2, thenthe attacker is unable to violate any of the MLS security properties after theupdates have been processed.¶

Both of these properties are satisfied even against compromised DSs and ASs.¶

Confidentiality is mainly ensured on the client side. Because Forward Secrecy(FS) and Post-Compromise Security (PCS) rely on the active deletion andreplacement of keying material, any client which is persistently offline maystill be holding old keying material and thus be a threat to both FS and PCS ifit is later compromised.¶

MLS partially defends against this problem by active members includingfreshness, however not much can be done on the inactive side especially in thecase where the client has not processed messages.¶

• RECOMMENDATION: Mandate key updates from clients that are not otherwisesending messages and evict clients which are idle for too long.¶

These recommendations will reduce the ability of idle compromised clients todecrypt a potentially long set of messages that might have followed the point ofthe compromise.¶

The precise details of such mechanisms are a matter of local policy and beyondthe scope of this document.¶

7.2.3.Non-Repudiation vs Deniability

MLS provides strong authentication within a group, such that a group membercannot send a message that appears to be from another group member.Additionally, some services require that a recipient be able to prove to theservice provider that a message was sent by a given client, in order to reportabuse. MLS supports both of these use cases. In some deployments, these servicesare provided by mechanisms which allow the receiver to prove a message's originto a third party. This is often called "non-repudiation".¶

Roughly speaking, "deniability" is the opposite of "non-repudiation", i.e., theproperty that it is impossible to prove to a third party that a message was sentby a given sender. MLS does not make any claims with regard to deniability. Itmay be possible to operate MLS in ways that provide certain deniabilityproperties, but defining the specific requirements and resulting notions ofdeniability requires further analysis.¶

7.2.4.Associating a User's Clients

When the same user uses multiple clients, it may be possible for other membersof a group to recognize all of those clients as belonging to the same user. Forexample, all of a user's clients might present credentials authenticating theuser's identity. This association among devices might be considered a leak ofprivate information. The remainder of this section describes several approachesfor addressing this.¶

This risk only arises when the leaf nodes for the clients in question providedata that can be used to correlate the clients. So one way to mitigate thisrisk is by only doing client-level authentication within MLS. If user-levelauthentication is still desirable, the application would have to be provide itthrough some other mechanism.¶

It is also possible to maintain user-level authentication while hidinginformation about the clients that a user owns. This can be done by having theclients share cryptographic state, so that they appear as a single client withinthe MLS group. The application would need to provide a synchronizationmechanism so that the clients' state remained consistent across changes to theMLS group.¶

• RECOMMENDATION: Avoid sharing cryptographic state between clients toimprove resilience against compromises. An attacker could use one compromiseddevice to establish ownership of a state across other devices and reduce theability of the user to recover.¶

7.3.1.Compromise of AEAD key material

In some circumstances, adversaries may have access to specific AEAD keys andnonces which protect an Application or a Group Operation message. While this isa very weak kind of compromise, it can be realistic in cases of implementationvulnerabilities where only part of the memory leaks to the adversary.¶

When an AEAD key is compromised, the adversary has access to a set of AEAD keysfor the same chain and the same epoch, hence can decrypt messages sent usingkeys of this chain. An adversary cannot send a message to a group which appearsto be from any valid client since they cannot forge the signature.¶

The MLS protocol will ensure that an adversary cannot compute any previous AEADkeys for the same epoch, or any other epochs. Because of its Forward Secrecyguarantees, MLS will also retain secrecy of all other AEAD keys generated forother MLS clients, outside this dedicated chain of AEAD keys and nonces, evenwithin the epoch of the compromise. However the MLS protocol does not providePost Compromise Secrecy for AEAD encryption within an epoch. This means that ifthe AEAD key of a chain is compromised, the adversary can compute an arbitrarynumber of subsequent AEAD keys for that chain.¶

These guarantees are ensured by the structure of the MLS key schedule whichprovides Forward Secrecy for these AEAD encryptions, across the messages withinthe epoch and also across previous epochs. Those chains are completely disjointand compromising keys across the chains would mean that some Group Secrets havebeen compromised, which is not the case in this attack scenario (we explorestronger compromise scenarios as part of the following sections).¶

MLS provides Post-Compromise Secrecy against an active adaptive attacker acrossepochs for AEAD encryption, which means that as soon as the epoch is changed, ifthe attacker does not have access to more secret material they won't be able toaccess any protected messages from future epochs.¶

In the case of an Application message, an AEAD key compromise means that theencrypted application message will be leaked as well as the signature over thatmessage. This means that the compromise has both confidentiality and privacyimplications on the future AEAD encryptions of that chain. In the case of aGroup Operation message, only the privacy is affected, as the signature isrevealed, because the secrets themselves are protected by HPKE encryption.¶

Note that under that compromise scenario, authentication is not affected ineither of these cases. As every member of the group can compute the AEAD keysfor all the chains (they have access to the Group Secrets) in order to send andreceive messages, the authentication provided by the AEAD encryption layer ofthe common framing mechanism is very weak. Successful decryption of an AEADencrypted message only guarantees that a member of the group sent the message.¶

7.3.2.Compromise of the Group Secrets of a single group for one or more group epochs

The attack scenario considering an adversary gaining access to a set of Groupsecrets is significantly stronger. This can typically be the case when a memberof the group is compromised. For this scenario, we consider that the signaturekeys are not compromised. This can be the case for instance if the adversary hasaccess to part of the memory containing the group secrets but not to thesignature keys which might be stored in a secure enclave.¶

In this scenario, the adversary gains the ability to compute any number of AEADencryption keys for any AEAD chains and can encrypt and decrypt all messages forthe compromised epochs.¶

If the adversary is passive, it is expected from the PCS properties of the MLSprotocol that, as soon as the compromised party remediates the compromise andsends an honest Commit message, the next epochs will provide message secrecy.¶

If the adversary is active, the adversary can follow the protocol and performupdates on behalf of the compromised party with no ability for an honest groupto recover message secrecy. However, MLS provides PCS against active adaptiveattackers through its Remove group operation. This means that, as long as othermembers of the group are honest, the protocol will guarantee message secrecy forall messages exchanged in the epochs after the compromised party has beenremoved.¶

7.3.3.Compromise by an active adversary with the ability to sign messages

Under such a scenario, where an active adversary has compromised an MLS client,two different settings emerge. In the strongest compromise scenario, theattacker has access to the signing key and can forge authenticated messages. Ina weaker, yet realistic scenario, the attacker has compromised a client but theclient signature keys are protected with dedicated hardware features which donot allow direct access to the value of the private key and instead provide asignature API.¶

When considering an active adaptive attacker with access to a signature oracle,the compromise scenario implies a significant impact on both the secrecy andauthentication guarantees of the protocol, especially if the attacker also hasaccess to the group secrets. In that case both secrecy and authentication arebroken. The attacker can generate any message, for the current and futureepochs, until the compromise is remediated and the formerly compromised clientsends an honest update.¶

Note that under this compromise scenario, the attacker can perform alloperations which are available to a legitimate client even without access to theactual value of the signature key.¶

Without access to the group secrets, the adversary will not have the ability togenerate messages which look valid to other members of the group and to theinfrastructure as they need to have access to group secrets to compute theencryption keys or the membership tag.¶

7.3.4.Compromise of the authentication with access to a signature key

The difference between having access to the value of the signature key and onlyhaving access to a signing oracle is not about the ability of an active adaptivenetwork attacker to perform different operations during the time of thecompromise, the attacker can perform every operation available to a legitimateclient in both cases.¶

There is a significant difference, however in terms of recovery after acompromise.¶

Because of the PCS guarantees provided by the MLS protocol, when a previouslycompromised client performs an honest Commit which is not under the control ofthe adversary, both secrecy and authentication of messages can be recovered inthe case where the attacker didn't get access to the key. Because the adversarydoesn't have the key and has lost the ability to sign messages, they cannotauthenticate messages on behalf of the compromised party, even if they stillhave control over some group keys by colluding with other members of the group.¶

This is in contrast with the case where the signature key is leaked. In thatcase PCS of the MLS protocol will eventually allow recovery of theauthentication of messages for future epochs but only after compromised partiesrefresh their credentials securely.¶

Beware that in both oracle and private key access, an active adaptive attackercan follow the protocol and request to update its own credential. This in turninduces a signature key rotation which could provide the attacker with part orthe full value of the private key depending on the architecture of the serviceprovider.¶

• RECOMMENDATION: Signature private keys should be compartmentalized fromother secrets and preferably protected by an HSM or dedicated hardwarefeatures to allow recovery of the authentication for future messages after acompromise.¶

7.3.5.Security consideration in the context of a full state compromise

In real-world compromise scenarios, it is often the case that adversaries targetspecific devices to obtain parts of the memory or even the ability to executearbitrary code in the targeted device.¶

Also, recall that in this setting, the application will often retain theunencrypted messages. If so, the adversary does not have to break encryption atall to access sent and received messages. Messages may also be sent by using theapplication to instruct the protocol implementation.¶

• RECOMMENDATION: If messages are stored on the device, they should beprotected using encryption at rest, and the keys used should be storedsecurely using dedicated mechanisms on the device.¶

• RECOMMENDATION: If the threat model of the system is against an adversarywhich can access the messages on the device without even needing to attackMLS, the application should delete plaintext messages and ciphertextsimmediately after encryption or decryption.¶

Even though, from the strict point of view of the security formalization, aciphertext is always public and will forever be, there is no loss in trying toerase ciphertexts as much as possible.¶

Note that this document makes a clear distinction between the way signature keysand other group shared secrets must be handled. In particular, a large set ofgroup secrets cannot necessarily be assumed to be protected by an HSM or secureenclave features. This is especially true because these keys are extremelyfrequently used and changed with each message received by a client.¶

However, the signature private keys are mostly used by clients to send amessage. They also provide strong authentication guarantees to other clients,hence we consider that their protection by additional security mechanisms shouldbe a priority.¶

Overall there is no way to detect or prevent these compromises, as discussed inthe previous sections, performing separation of the application secret statescan help recovery after compromise, this is the case for signature keys butsimilar concern exists for the encryption private key used in the TreeKEM GroupKey Agreement.¶

• RECOMMENDATION: The secret keys used for public key encryption should bestored similarly to the way the signature keys are stored, as keys can be usedto decrypt the group operation messages and contain the secret material usedto compute all the group secrets.¶

Even if secure enclaves are not perfectly secure, or even completely broken,adopting additional protections for these keys can ease recovery of the secrecyand authentication guarantees after a compromise where, for instance, anattacker can sign messages without having access to the key. In certaincontexts, the rotation of credentials might only be triggered by the AS throughACLs, hence be outside of the capabilities of the attacker.¶

7.4.1.General considerations

7.4.2.Delivery Service Compromise

MLS is intended to provide strong guarantees in the face of compromise of theDS. Even a totally compromised DS should not be able to read messages or injectmessages that will be acceptable to legitimate clients. It should also not beable to undetectably remove, reorder or replay messages.¶

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 fromspecific clients). As noted inSection 4.2, these attacks are onlypartially detectable by clients without an out-of-band channel. Ultimately,failure of the DS to provide reasonable service must be dealt with as a customerservice matter, not via technology.¶

Because the DS is responsible for providing the initial keying material toclients, it can provide stale keys. This does not inherently lead to compromiseof the message stream, but does allow it to attack forward security to a limitedextent. This threat can be mitigated by having initial keys expire.¶

Initial keying material (KeyPackages) using thebasic Credential type is morevulnerable to replacement by a malicious or compromised DS, as there is nobuilt-in cryptographic binding between the identity and the public key of theclient.¶

• RECOMMENDATION: Prefer a Credential type in KeyPackages which includes astrong cryptographic binding between the identity and its key (for example thex509 Credential type). When using thebasic Credential type take extracare to verify the identity (typically out-of-band).¶

7.4.3.Authentication Service Compromise

The Authentication Service design is left to the infrastructure designers. Inmost designs, a compromised AS is a serious matter, as the AS can serveincorrect or attacker-provided identities to clients.¶

• The attacker can link an identity to a credential¶
• The attacker can generate new credentials¶
• The attacker can sign new credentials¶
• The attacker can publish or distribute credentials¶

In the past, some systems have had a centralized server generate signature keypairs and distribute them to clients. In such cases, the centralized server isa point of compromise, since it stores signature private keys that can be usedto impersonate clients. A better approach is instead to generate signature keypairs in clients and have them "blessed" by the centralized service, e.g., byhaving the service issue a credential binding the key pair to the client'sidentity. In this approach, there is still a risk that the centralized servicewill authorize additional key pairs, but it will not be able to use existing,client-generated private keys.¶

• RECOMMENDATION: Make clients submit signature public keys to the AS, thisis usually better than the AS generating public key pairs because the AScannot sign on behalf of the client. This is a benefit of a Public KeyInfrastructure in the style of the Internet PKI.¶

An attacker that can generate or sign new credentials may or may not have accessto the underlying cryptographic material necessary to perform suchoperations. In that last case, it results in windows of time for which allemitted credentials might be compromised.¶

• RECOMMENDATION: Use HSMs to store the root signature keys to limit theability of an adversary with no physical access to extract the top-levelsignature private key.¶