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 <del> has properly implemented the MLS deletion schedule. </del>  5.2. There are a few practical challenges to this approach.  For example, the application will need to ensure that all members have the required PSK, including any new members that have joined the group <del> since the epoch in which the PSK was issued. </del>  Reinitializing in this way does not provide the member with access to group messages from during the state loss window, but enables proof 7.1. <del> Any secure channel can be used as a transport layer to protect MLS messages such as QUIC, TLS, WireGuard or TOR.  However, the MLS protocol is designed to consider the following threat-model: </del>  The attacker can read, write, and delete arbitrary messages inside the secure transport channel. and quality of service for MLS. *RECOMMENDATION:* If unidirectional transport is used for the <del> secure transport channel, prefer using a protocol which provides Forward Error Correction. </del>  7.2. The attacker has access to all secrets of a user for all groups (full state compromise) <del> Recall that the MLS protocol provides chains of AEAD keys, per sender that are generated from Group Secrets.  These keys are used to protect MLS Plaintext messages which can be Group Operation or Application messages.  The Group Operation messages offer an additional protection as the secret exchanged within the TreeKEM group key agreement are public-key encrypted to subgroups with HPKE. </del>  7.3.1. and decrypt all messages for the compromised epochs. If the adversary is passive, it is expected from the PCS properties <del> of the MLS protocol that, as soon as an honest Commit message is sent by the compromised party, the next epochs will provide message secrecy. </del>  If the adversary is active, the adversary can follow the protocol and perform updates on behalf of the compromised party with no ability protocol, especially if the attacker also has access to the group secrets.  In that case both secrecy and authentication are broken. The attacker can generate any message, for the current and future <del> epochs until an honest update from the compromised client happens. </del>  Note that under this compromise scenario, the attacker can perform all operations which are available to a legitimate client even The attacker can publish or distribute credentials <del> Infrastructures that provide cryptographic material or credentials in place of the MLS client (which is under the control of the user) often have the ability to use the associated secrets to perform operations on behalf of the user, which is unacceptable in many situations.  Other mechanisms can be used to prevent this issue, such as the service blessing cryptographic material used by an MLS client. </del>  *RECOMMENDATION:* Make clients submit signature public keys to the AS, this is usually better than the AS generating public key pairs decrypted during the execution.  Applications should also consider anonymous systems for server fanout (for example Loopix). <del> Often, expectation from users is that the infrastructure will not retain the ability to constantly map the user identity to signature public keys of the MLS protocol.  Some infrastructures will keep a mapping between signature public keys of clients and user identities. This can enable an adversary that has compromised the AS (or required access according to regulation) to monitor unencrypted traffic and correlate the messages exchanged within the same group. </del>  *RECOMMENDATION:* Always use encrypted group operation messages to limit privacy risks.

Comment by NAME Again I am confused there are users with expectations of the MLS protocol, which is still in a draft form only? Is this mixing MLS and non-MLS?
Comment by NAME Is this the equivalent of proprietary IM clients "auto delete" or "view once" type messaging? "MLS deletation schedule" has not been defined before it is mentioned here. What is this?
It is not the equivalent of "expiring messages" features. It's a forward security provision.
The is defined in the protocol document. Perhaps a pointer would be useful.
Comment by NAME This seems a bit of gloating about the MLS protocol/client. Why not just state why the attack is impossible and require that MLS clients do this? I don't see other features being compared to other/older/worse solutions?
Comment by NAME It feels a bit odd to think of a compromised user sending an honest Commit message. If the user doesn't know they are compromised, they will still be compromised and this new Commit message won't help. If the user did know they were compromised and undid that, then sure this honest Commit message helps. I think perhaps "honest Commit" should be expanded and say something about de-compromised client sending a Commit message. My issue with "honest" is that compromised user with a passive attacker is still "honest". Similarly confusing is:
I think these cases mean "formerly compromised".
Comment by NAME This "recall" is misplaced. It is not mentioned before until this point.
Comment by NAME Is this saying a protocol within MLS, eg some application protocol? Or is this saying in this case, do not use MLS but another protocol at the messaging layer?
I understand "a protocol" as "a transport protocol". Because MLS does not provide FEC, and its integrity checks will fail if the packet is corrupted.
Comment by NAME It states any "secure channel" can be used, but it is kinda says any insecure channel can be used too. It also feels a little odd to describe these properties of MLS in the Security Considerations section, and not like in the introduction.
This is no different from how you can run TLS over a bare TCP/IP connection or you can run it over IPsec, and you get better security properties in the latter case.
Comment by NAME Wouldn't this PSK that is the result of a membership be part of the "state lost or corrupted" ? What is the exact kind of failure mode one would address with this? Also, how often would such a PSK get updated as it needs to be known to add group members (and doing this too often would I assume lead to long dormant group members from losing access?) If one could remove once's old self without the PSK, than everyone could delete any member?

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  <ins> 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. </ins> 5.2. There are a few practical challenges to this approach.  For example, the application will need to ensure that all members have the required PSK, including any new members that have joined the group  <ins> 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. </ins> Reinitializing in this way does not provide the member with access to group messages from during the state loss window, but enables proof 7.1.  <ins> As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure channel can be used as a transport layer to protect MLS messages, such as QUIC, TLS, WireGuard or TOR.  However, the MLS protocol is designed to consider the following threat-model: </ins> The attacker can read, write, and delete arbitrary messages inside the secure transport channel. and quality of service for MLS. *RECOMMENDATION:* If unidirectional transport is used for the  <ins> secure transport channel, prefer using a transport protocol which provides Forward Error Correction. </ins> 7.2. The attacker has access to all secrets of a user for all groups (full state compromise)  <ins> The MLS protocol provides per-sender chains of AEAD keys that are generated from Group Secrets.  These keys are used to protect MLS Plaintext messages which can be Group Operation or Application messages.  The Group Operation messages offer an additional protection as the secret exchanged within the TreeKEM group key agreement are public-key encrypted to subgroups with HPKE. </ins> 7.3.1. and decrypt all messages for the compromised epochs. If the adversary is passive, it is expected from the PCS properties  <ins> of the MLS protocol that, as soon as the compromised party remediates the compromise and sends an honest Commit message, the next epochs will provide message secrecy. </ins> If the adversary is active, the adversary can follow the protocol and perform updates on behalf of the compromised party with no ability protocol, especially if the attacker also has access to the group secrets.  In that case both secrecy and authentication are broken. The attacker can generate any message, for the current and future  <ins> epochs, until the compromise is remediated and the formerly compromised client sends an honest update. </ins> Note that under this compromise scenario, the attacker can perform all operations which are available to a legitimate client even The attacker can publish or distribute credentials  <ins> In the past, some systems have had a centralized server generate signature key pairs and distribute them to clients.  In such cases, the centralized server is a point of compromise, since it stores signature private keys that can be used to impersonate clients.  A better approach is instead to generate signature key pairs in clients and have them "blessed" by the centralized service, e.g., by having the service issue a credential binding the key pair to the client's identity.  In this approach, there is still a risk that the centralized service will authorize additional key pairs, but it will not be able to use existing, client-generated private keys. </ins> *RECOMMENDATION:* Make clients submit signature public keys to the AS, this is usually better than the AS generating public key pairs decrypted during the execution.  Applications should also consider anonymous systems for server fanout (for example Loopix).  <ins> Some infrastructure keeps 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. </ins> *RECOMMENDATION:* Always use encrypted group operation messages to limit privacy risks.


7.3.3.1. One important feature of MLS is that all Members know which other <del> clients are in the group at all times.  If all Members of the group </del>  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. <del> Beware though, the link between the cryptographic identity of the client and the real identity of the End User is important.  Details about how to verify the identity of a client depend on the MLS Credential type used.  For example, cryptographic verification of </del>  credentials can be largely performed autonomously on the clients for the "x509" Credential type.  In contrast, when MLS clients use the "basic" Credential type, a larger degree of trust must be placed in a *RECOMMENDATION:* Select the strongest MLS Credential type available among the target members of an MLS group. <del> While the Authentication Service is often very well protected from external attackers, it might be the case that this service is compromised.  In such infrastructure, the AS could validate a (or generate a new) signature keypair for an identity which is not the expected one.  Because a user can have many MLS clients running the MLS protocol, it possibly has many signature keypairs for multiple devices.  Note that when a "basic" Credential is used, the Authentication Service also needs an out-of-band mechanism to verify the identity asserted in the Credential. With some Authentication Service designs, a private or centralized authority is trusted to validate signature keypairs used in the MLS protocol.  This is typically the case in some of the biggest messaging infrastructures. </del>  In the case where an adversarial keypair is generated for a specific identity, an infrastructure without any transparency mechanism or

The Section has three recommendations, but the discussion rambles. The proposed text places topics related to each recommendation before that recommendation.
Thanks!
Comment by NAME Why allow this in the MLS protocol? How can this "typically" be the case of some of the biggest messaging infrastructures? Clearly those don't run the MLS protocol? Perhaps you meant to compare a similar function to the AS in other messaging protocols? That is, I would clarify what is the issue, what is possible in MLS and how it compares to non-MLS existing deployments.
At a high level, MLS was designed to be agnostic about the authentication design, so I don't think there's much normative for MLS to say here. With that said, it seems to me that there are two practices here: A centralized/private authority. As the text says, this is very common and seems like a fairly natural design, whether we like it or not. That authority generating keys rather than signing them. That seems bad, and I guess we could discourage it, but it can't be enforceably prohibited
That was probably meant to be a comparison, yes, but this entire block has been removed through the multiple changes already made anyway. The important part was to describe things as ekr suggested which is already the case and there is already a recommendation to not design a system which generates the keys in the section about the AS.

7.3.3.1. One important feature of MLS is that all Members know which other  <ins> members are in the group at all times.  If all Members of the group </ins> 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.  <ins> Details about how to verify the identity of a client depend on the MLS Credential type used.  For example, cryptographic verification of </ins> credentials can be largely performed autonomously on the clients for the "x509" Credential type.  In contrast, when MLS clients use the "basic" Credential type, a larger degree of trust must be placed in a *RECOMMENDATION:* Select the strongest MLS Credential type available among the target members of an MLS group.  <ins> If the AS is compromised, it could validate a (or generate a new) signature keypair for an attacker.  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. *RECOMMENDATION:* Provide a key transparency mechanism for the Authentication Services to allow public verification of the credentials authenticated by this service. Note that when a "basic" Credential is used, the Authentication Service also needs an out-of-band mechanism to verify the identity asserted in the Credential. </ins> In the case where an adversarial keypair is generated for a specific identity, an infrastructure without any transparency mechanism or


As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure <del> channel can be used as a transport layer to protect MLS messages, such as QUIC RFC9000, TLS RFC8446, IPsec RFC6071, WireGuard WireGuard, or TOR TOR.  However, the MLS protocol is designed to consider the following threat-model: </del>  The attacker can read, write, and delete arbitrary messages inside the secure transport channel.

There have been a lot of comments about the inclusion of WireGuard and Tor as potential secure transports, but I actually think it's confusing to cite IPsec as well for layering issues. We don't have a real praxis for using things that aren't application-layer style protocols for protecting this kind of traffic, so I don't think we should encourage these. I've trimmed it to just QUIC and TLS.

As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure  <ins> channel, such as QUIC RFC9000, TLS RFC8446, can be used to transport MLS messages.  However, the MLS protocol is designed to consider the following threat-model: </ins> The attacker can read, write, and delete arbitrary messages inside the secure transport channel.


document) and an abstract protocol MLSPROTO 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 a <del> concrete protocol such as XMPP RFC3920.  In addition, it does not </del>  specify a complete wire encoding, but rather a set of abstract data structures which can then be mapped onto a variety of concrete encodings, such as TLS I-D.ietf-tls-tls13, CBOR RFC7049, and JSON

Change reference to XMPP to the current RFC. Change heading of "Deniability" section, which also discusses non-repudiation, to "Non-Repudiation and Deniability". I wondered if that latter section should note that a third-party (ie, non-Member) cannot identify a sender from a given encrypted message, but then I wondered if that was the case or not.
Thanks NAME !

document) and an abstract protocol MLSPROTO 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 a  <ins> concrete protocol such as XMPP RFC6120.  In addition, it does not </ins> specify a complete wire encoding, but rather a set of abstract data structures which can then be mapped onto a variety of concrete encodings, such as TLS I-D.ietf-tls-tls13, CBOR RFC7049, and JSON


Upon joining the system, each Client stores its initial cryptographic key material with the DS.  This key material represents the initial contribution from each member that will be used in the establishment <del> of the shared group key.  This initial keying material MUST be </del>  authenticated using the Client's identity key.  Thus, the Client stores:

Removing 2119 "MUST" as agreed in Paris. Note that this is the minimal change and in another PR I will suggest removing as many lower case instances of must, should, etc. as possible.

Upon joining the system, each Client stores its initial cryptographic key material with the DS.  This key material represents the initial contribution from each member that will be used in the establishment  <ins> of the shared group key.  This initial keying material is </ins> authenticated using the Client's identity key.  Thus, the Client stores:


A model system is shown in [TODO: Figure]. <del> The messaging service presents as two abstract services: </del>  <del> An Authentication Server (AS) which is responsible for maintaining user identities, issuing credentials which allow them to authenticate to each other, and potentially distributing user </del>  keying material. <del> A Message Switch (MS) which is responsible for delivering messages between users.  In the case of group messaging, the message switch may also be responsible for acting as an "exploder" where the sender sends a single message to a group and the switch then forwards it to each recipient. </del>  <del> In many systems, the AS and the MS are actually operated by the same </del>  entity and may even be the same server.  However, they are logically distinct and, in other systems, may be operated by different entities so we show them as separate here.  Other partitions are also Alice, Bob, and Charlie create accounts with the messaging service and obtain credentials from the AS. <del> Alice, Bob, and Charlie authenticate to the MS and store some </del>  keying material which can be used to encrypt to them for the first time. When Alice wants to send a message to Bob and Charlie, she <del> contacts the MS and looks up their keying material.  She uses </del>  those keys to establish a set of keys which she can use to send to Bob and Charlie.  She then sends the encrypted message(s) to the <del> MS, which forwards them to the ultimate recipients. </del>  Bob and/or Charlie respond to Alice's message.  Their messages might include new keys which allow the joint keys to be updated,

The current naming is confusing: MS stands for "Message Switch" and "Messaging Server" but not for "Messaging Service" AS stands for "Authentication Server" and "Authentication Service". The proposed change gives: MS as "Messaging Service" (AS* + DS) AS as "Authentication Service" DS as "Delivery Service" the "Server"s being the endpoints and not the functionality

A model system is shown in [TODO: Figure].  <ins> The Messaging Service (MS) presents as two abstract services: </ins>  <ins> An Authentication Service (AS) which is responsible for maintaining user identities, issuing credentials which allow them to authenticate to each other, and potentially distributing user </ins> keying material.  <ins> A Delivery Service (DS) which is responsible for delivering messages between users.  In the case of group messaging, the delivery service may also be responsible for acting as an "exploder" where the sender sends a single message to a group and the switch then forwards it to each recipient. </ins>  <ins> In many systems, the AS and the DS are actually operated by the same </ins> entity and may even be the same server.  However, they are logically distinct and, in other systems, may be operated by different entities so we show them as separate here.  Other partitions are also Alice, Bob, and Charlie create accounts with the messaging service and obtain credentials from the AS.  <ins> Alice, Bob, and Charlie authenticate to the DS and store some </ins> keying material which can be used to encrypt to them for the first time. When Alice wants to send a message to Bob and Charlie, she  <ins> contacts the DS and looks up their keying material.  She uses </ins> those keys to establish a set of keys which she can use to send to Bob and Charlie.  She then sends the encrypted message(s) to the  <ins> DS, which forwards them to the ultimate recipients. </ins> Bob and/or Charlie respond to Alice's message.  Their messages might include new keys which allow the joint keys to be updated,


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 <del> interoperate and to form federated systems. </del>  3.1.7. We assume that all transport connections are secured via some transport layer security mechanism such as TLS I-D.ietf-tls-tls13. However, as noted above, the security of MLS will generally survive <del> compromise of the transport layer. </del>  3.2.2. A corollary to this statement is that the AS and the DS cannot read the content of messages sent between Members as they are not Members <del> of the Group.  MLS optionally provide additional protections </del>  regarding traffic analysis so as to reduce the ability of adversaries, or a compromised member of the messaging system, to deduce the content of the messages depending on (for example) their In general we do not consider Denial of Service (DoS) resistance to be the responsibility of the protocol.  However, it should not be <del> possible for anyone to perform a trivial DoS attack from which it is hard to recover. </del>  3.2.2.5. 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 delivery- <del> guarantees, these attacks are only partially detectable by clients. Ultimately, failure of the DS to provide reasonable service must be dealt with as a customer service matter, not via technology. </del>  Because the DS is responsible for providing the initial keying material to Clients, it can provide stale keys.  This does not

Remove "join an existing group" from architecture doc, based on UserAdd having been removed from the protocol doc. Remove statement that message delivery cannot be correlated between AS identities and DS delivery channels. This seems generally very difficult to achieve. It may be possible at times, but does not seem to be grounded in discussions that we have had at the working group meetings. Note that federation requires compatible wire encodings. Note that communication with the AS requires TLS or alternative authentication. Note that out-of-band channels may facilitate detection of misbehaviour. Some grammar fixes.

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  <ins> interoperate and to form federated systems if they use compatible wire encodings. </ins> 3.1.7. We assume that all transport connections are secured via some transport layer security mechanism such as TLS I-D.ietf-tls-tls13. However, as noted above, the security of MLS will generally survive  <ins> compromise of the transport layer, so long as identities provided by the AS are authenticated at a minimum. </ins> 3.2.2. A corollary to this statement is that the AS and the DS cannot read the content of messages sent between Members as they are not Members  <ins> of the Group.  MLS optionally provides additional protections </ins> regarding traffic analysis so as to reduce the ability of adversaries, or a compromised member of the messaging system, to deduce the content of the messages depending on (for example) their In general we do not consider Denial of Service (DoS) resistance to be the responsibility of the protocol.  However, it should not be  <ins> possible for anyone aside from the DS to perform a trivial DoS attack from which it is hard to recover. </ins> 3.2.2.5. 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 delivery-  <ins> 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. </ins> Because the DS is responsible for providing the initial keying material to Clients, it can provide stale keys.  This does not


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 <del> actively rewrite messages messages with a lower protocol version than the ones 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. </del>  3.2.

In the section 3.1.7. Compatibility with future versions of MLS, the word "messages" is duplicated.
Thanks

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  <ins> actively rewrite messages with a lower protocol version than the ones 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. </ins> 3.2.


3.1.3. <del> It is typically expected for users within Group to own different </del>  devices. <del> A new device can be added to a group by sharing of an existing client secrets or 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.  Restoring history is typically not allowed at the protocol level but applications can </del>  elect to provide such a mechanism outside of MLS. 3.1.4. MLS adopts the Internet threat model RFC3552 and therefore assumes that the attacker has complete control of the network.  It is <del> intended to provide the security services described in in the face of </del>  such attackers.  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

There were some odd formulations in section 3.1.3. I hope I addressed those issues without changing the intended meaning.

3.1.3.  <ins> It is typically expected for users within a Group to own different </ins> devices.  <ins> A new device can either be added to a group by sharing secrets of an existing client or 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.  Restoring history is typically not allowed at the protocol level but applications can </ins> elect to provide such a mechanism outside of MLS. 3.1.4. MLS adopts the Internet threat model RFC3552 and therefore assumes that the attacker has complete control of the network.  It is  <ins> intended to provide the security services described in the face of </ins> such attackers.  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


This document describes the reference architecture, functional and security requirements for the Messaging Layer Security (MLS) protocol.  MLS provides a security layer for group messaging <del> applications with from two to a large number of clients.  It is meant to protect against eavesdropping, tampering, and message forgery. </del>  1. services at their disposal to establish the necessary values and credentials required for encryption and authentication. <del> The Messaging Service (MS) presents as two abstract services that allow clients to prepare for sending and receiving messages securely: </del>  An Authentication Service (AS) which is responsible for maintaining user long term identities, issuing credentials which allow them to authenticate each other, and potentially allowing <del> users to discover each others long-term identity keys. </del>  A Delivery Service (DS) which is responsible for receiving and redistributing messages between group members.  In the case of The protocol is designed in a way that limits the server-side (AS and DS) metadata footprint.  The DS only persists data required for the <del> delivery of messages and avoid Personally Identifiable Information </del>  (PII) or other sensitive metadata wherever possible.  A Messaging Service provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with

This PR aims to fix some odd formulations, whilst maintaining the intended meaning of the sentences.
Thanks NAME !

This document describes the reference architecture, functional and security requirements for the Messaging Layer Security (MLS) protocol.  MLS provides a security layer for group messaging  <ins> applications, where the number of clients ranges from two to many. It is meant to protect against eavesdropping, tampering, and message forgery. </ins> 1. services at their disposal to establish the necessary values and credentials required for encryption and authentication.  <ins> The Messaging Service (MS) presents two abstract services that allow clients to prepare for sending and receiving messages securely: </ins> An Authentication Service (AS) which is responsible for maintaining user long term identities, issuing credentials which allow them to authenticate each other, and potentially allowing  <ins> users to discover each other's long-term identity keys. </ins> A Delivery Service (DS) which is responsible for receiving and redistributing messages between group members.  In the case of The protocol is designed in a way that limits the server-side (AS and DS) metadata footprint.  The DS only persists data required for the  <ins> delivery of messages and avoids Personally Identifiable Information </ins> (PII) or other sensitive metadata wherever possible.  A Messaging Service provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with


and is commonly deployed in many such systems.  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 <del> design - even when the messaging service they are using performs </del>  unsatisfactorily. Messaging Layer Security (MLS) specifies an architecture (this 2. Informally, a group is a set of users who possibly use multiple <del> endpoint devices to interact with the Messaging Service (MS).  A group may be as small as two members (the simple case of person to person messaging) or as large as thousands. </del>  In order to communicate securely, users initially interact with services at their disposal to establish the necessary values and credentials required for encryption and authentication. <del> The Messaging Service (MS) presents two abstract services that allow </del>  clients to prepare for sending and receiving messages securely: An Authentication Service (AS) which is responsible for A typical group messaging scenario might look like this: <del> Alice, Bob and Charlie create accounts with a messaging service and obtain credentials from the AS. </del>  Alice, Bob and Charlie authenticate to the DS and store some initial keying material which can be used to send encrypted 2.1. While informally, a group can be considered to be a set of users <del> possibly using multiple endpoint devices to interact with the Messaging Service, this definition is too simplistic. </del>  Formally, a Client is a set of cryptographic objects composed by public values such as a name (an identity), a public encryption key 2.3. The Delivery Service (DS) is expected to play multiple roles in the <del> Messaging Service architecture: </del>  To act as a directory service providing the initial keying material for clients to use.  This allows a client to establish a The protocol is designed in a way that limits the server-side (AS and DS) metadata footprint.  The DS only persists data required for the delivery of messages and avoids Personally Identifiable Information <del> (PII) or other sensitive metadata wherever possible.  A Messaging Service provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with the initial public keys signed by the AS. </del>  [[OPEN ISSUE: These privacy statements seem very strong.  BB.  I would be willing to keep them as requirements since we have example of these protections includes padding messages in order to produce ciphertexts of standard length.  While this protection is highly recommended it is not mandatory as it can be costly in terms of <del> performance for clients and the MS. </del>  Message content can be deniable if the signature keys are exchanged over a deniable channel prior to signing messages. As described in client-compromise, 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 <del> require that a recipient be able to prove to the messaging service </del>  that a message was sent by a given client, in order to report abuse. MLS supports both of these use cases.  In some deployments, these services are provided by mechanisms which allow the receiver to prove

This PR addresses URL
Thanks!
In the context of this document, the meaning of the term Messaging Service (MS) seems a little unclear to me. The document states that the protocol is intended to be embedded in a concrete protocol such as XMPP. However, is a MS meant to be a messaging service such as SMS or MMS? Or a service on the application layer, such as FB or WhatsApp? Essentially who provides / controls the AS and DS? I would be grateful for some clarification on this. Thanks.
It is meant to mean application layer, would changing that to "service provider" work better for you?
Thank you. I do think that the term service provider is less ambiguous.
Ack, will fix soon.
I can make a PR, if you want?
Sure, please go for it.
Fixed by

and is commonly deployed in many such systems.  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  <ins> design - even when the service provider they are using performs </ins> unsatisfactorily. Messaging Layer Security (MLS) specifies an architecture (this 2. Informally, a group is a set of users who possibly use multiple  <ins> endpoint devices to interact with the Service Provider (SP).  A group may be as small as two members (the simple case of person to person messaging) or as large as thousands. </ins> In order to communicate securely, users initially interact with services at their disposal to establish the necessary values and credentials required for encryption and authentication.  <ins> The Service Provider presents two abstract services that allow </ins> clients to prepare for sending and receiving messages securely: An Authentication Service (AS) which is responsible for A typical group messaging scenario might look like this:  <ins> Alice, Bob and Charlie create accounts with a service provider and obtain credentials from the AS. </ins> Alice, Bob and Charlie authenticate to the DS and store some initial keying material which can be used to send encrypted 2.1. While informally, a group can be considered to be a set of users  <ins> possibly using multiple endpoint devices to interact with the Service Provider, this definition is too simplistic. </ins> Formally, a Client is a set of cryptographic objects composed by public values such as a name (an identity), a public encryption key 2.3. The Delivery Service (DS) is expected to play multiple roles in the  <ins> Service Provider architecture: </ins> To act as a directory service providing the initial keying material for clients to use.  This allows a client to establish a The protocol is designed in a way that limits the server-side (AS and DS) metadata footprint.  The DS only persists data required for the delivery of messages and avoids Personally Identifiable Information  <ins> (PII) or other sensitive metadata wherever possible.  A Service Provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with the initial public keys signed by the AS. </ins> [[OPEN ISSUE: These privacy statements seem very strong.  BB.  I would be willing to keep them as requirements since we have example of these protections includes padding messages in order to produce ciphertexts of standard length.  While this protection is highly recommended it is not mandatory as it can be costly in terms of  <ins> performance for clients and the SP. </ins> Message content can be deniable if the signature keys are exchanged over a deniable channel prior to signing messages. As described in client-compromise, 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  <ins> require that a recipient be able to prove to the service provider </ins> that a message was sent by a given client, in order to report abuse. MLS supports both of these use cases.  In some deployments, these services are provided by mechanisms which allow the receiver to prove


2.2. <del> The basic function of the Authentication Service (AS) is to provide a trusted mapping from user identities (usernames, phone numbers, etc.), to long-term identity keys, which may either be one per Client or may be shared amongst the clients attached to a user. The Authentication Service (AS) is expected to play multiple roles in the architecture: A certification authority or similar service which signs some sort of portable credential binding an identity to a signature key. A directory server which provides the key for a given identity (presumably this connection is secured via some form of transport security such as TLS). The MLS protocol assumes a signature keypair for authentication of messages.  It is important to note that this signature keypair might be the identity keypair itself, or a different signature keypair for which the public key has been, for example, signed by the identity private key.  This flexibility allows for multiple infrastructure considerations and has the benefit of providing ways to use different signature keys across different groups by using hierarchical authentication keys.  This flexibility also comes at the price of a security tradeoff, described in the security considerations, between potential unlinkability of the signature keys across groups and the amount of time required to reinstate authentication and secrecy of messages after the compromise of a device. Ultimately, the only requirement is for the applications to be able to check the credential containing the protocol signing key and the identity against the Authentication Service at any time. By definition, the Authentication Service is invested with a large amount of trust.  A malicious AS can impersonate - or allow an attacker to impersonate - any user of the system.  As a corollary, by impersonating identities authorized to be members of a group, an AS can break confidentiality. This risk can be mitigated by publishing the binding between identities and keys in a public log such as Key Transparency (KT) KeyTransparency.  It is possible to build a functional MLS system without any kind of public key logging, but such a system will necessarily be somewhat vulnerable to attack by a malicious or untrusted AS. </del>  2.3.

In the current definition, the AS is portrayed as a distinct service that could, for example run on a server separate from other MLS participants. However, in the MLS spec, it's more of an abstract layer that fulfills certain functionalities, some of which are likely to run on client devices. For example, an identity key that signs individual group-level signature keys could live in the secure element of a device. From the standpoint of the spec, that key would be part of the AS. This PR changes the definition of the AS to reflect this, although there are of course multiple ways to tackle this. The MLS spec is not explicit about the fact that it's the AS that's potentially responsible for message authentication, i.e. to bridge a potential gap between the key used to sign a message and the key in a member's leaf. However, it makes sense that this would be part of an abstract AS layer. If not, I believe it would still make sense to address this in the architecture doc somewhere. The plan is to add more details on compromise of parts of the abstract AS to the security section in a future PR. Let us know what you think! This is joint work with NAME and NAME
Thanks !

2.2.  <ins> The Authentication Service (AS) has to provide two functionalities: authenticate the Credentials (i.e. the identity/signature keypair) used in a group authenticate messages sent in groups given the signature over the message and the sending member's Credential The AS is considered an abstract layer by the MLS specification. Although the name suggests that it is a separate "service", part of this service could be running on the members' devices, while another part is a separate entity entirely. 2.2.1. In most cases, the first functionality will be provided by a distinct entity, which fulfills a role similar to that of an certification authority in the WebPKI: It provides a binding of an identity (e.g., a user name, phone number, email address, etc) to a signature key. The identity/signature key pair can then either be used directly in a group, or as an intermediate, which in turn authenticates the Credential used in the group. The flexibility afforded by the latter option allows for multiple infrastructure considerations and has the benefit of providing ways to use different signature keys across different groups by using hierarchical authentication keys.  This flexibility also comes at the price of a security tradeoff, described in the security considerations, between potential unlinkability of the signature keys across groups and the amount of time required to reinstate authentication and secrecy of messages after the compromise of a device. 2.2.2. MLS messages are authenticated by a signature conforming to the signature scheme of the group's ciphersuite.  To allow for deniability (see Section Non-Repudiation-vs-Deniability), messages do not necessarily have to be signed by the private key corresponding to a member's Credential, but can instead be signed by a different key, which is authenticated by the key in the Credential in some way. While Credential authentication can be performed by a separate entity, message authentication will likely be performed individually by each member.  As a consequence, the message authentication part of the AS would have to run on the members' devices. 2.2.3. By the nature of its roles in MLS authentication, the AS is invested with a large amount of trust and the compromise of one of its functionalities could allow an adversary to, among other things, impersonate group members. We will discuss security considerations regarding the compromise of the different AS functionalities in detail in Section as-compromise. </ins> 2.3.


The formal definition of a Group in MLS is the set of clients that have knowledge of the shared group secret established in the group key establishment phase of the protocol and have contributed to it. <del> Until a Member has contributed to the group secret, other members cannot assume they are a member of the group. </del>  2.2.

Minor corrections throughout from joint edits by NAME NAME and NAME Some description text added.
In the section "Groups, Members, and Clients", the definition of a group in MLS is the set of clients that have knowledge of the shared group key, which is established in the group key exchange. The spec then goes on to say that "Until a Member has contributed to the group secret, other members cannot assume she is a member of the group." This phrasing of what constitutes a group member is quite weak and does not actually reflect the security properties of the underlying group key exchange. If a member has not contributed to the shared group secret, she cannot be considered a member of the group, as 1) she should not be able to learn the group key (without acting adversarially outside of the protocol), and 2) other members cannot verify her membership Instead, I would rephrase this description of a member/non-member to say something stronger, like "Until a Member has been added to the group by another member---thereby requiring that she contributes to the group secret in this process in such a way that is verifiable to other group members--she will not be able to participate as a member of the group."
Good idea. An edit on this has been added to PR .
I might be missing something here: Can't a party be added to a group (thus learning the group secret) and from that point never contribute to the shared group secret? That party would still be able to encrypt and decrypt application messages.
Hi NAME could you please check the current document and propose a new phrasing if needed? Thanks : )
NAME confirmed to me offline that this issue was addressed in
Modulo a few nits that can be fixed post-merge, this looks quite good Thanks to you three for the PR!

The formal definition of a Group in MLS is the set of clients that have knowledge of the shared group secret established in the group key establishment phase of the protocol and have contributed to it.  <ins> Until a Member 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 Member is a member of the group. </ins> 2.2.


and a public signature key.  Ownership of a client by a user is determined by the fact that the user has knowledge of the associated secret values.  When a client is part of a Group, it is called a <del> Member and its signature key pair uniquely identifies it to other clients or members in the Group.  In some messaging systems, clients belonging to the same user must all share the same signature key pair, but MLS does not assume this. Users will often use multiple clients, potentially one or more per device (phones, web clients or other devices...), and may choose to authenticate using the same signature key across devices, using one signature key per device or even one signature key per group. </del>  The formal definition of a Group in MLS is the set of clients that have knowledge of the shared group secret established in the group

Mainly focused on cleaning up grammar, but also fixing some things that have gone stale, like the idea that the MLS protocol is "abstract".
This looks good ! Thank you !
Looks good! Just two comments on client identity.

and a public signature key.  Ownership of a client by a user is determined by the fact that the user has knowledge of the associated secret values.  When a client is part of a Group, it is called a  <ins> Member.  In some messaging systems, clients belonging to the same user must all share the same signature key pair, but MLS does not assume this. Users will often use multiple devices, e.g., a phone as well as a laptop.  Different devices may be represented as different clients, with independent cryptographic state, or they may share cryptographic state, relying on some application-provided mechanism to sync across devices. </ins> The formal definition of a Group in MLS is the set of clients that have knowledge of the shared group secret established in the group


message per epoch. Much like the Authentication Service, the Delivery Service can be <del> split between server and client components.  Acheiving required </del>  uniqueness property will typically require a combination of client and server behaviors.  For example, all of the following examples provide a unique Commit per epoch:

This edit got a little invasive, largely around the "ordering" requirements. As was already pointed out the epoch numbering provides ordering to first order. What is really needed is for the DS to select a single Commit per epoch.
Thanks for the PR! Left a few comments, but otherwise looks good!

message per epoch. Much like the Authentication Service, the Delivery Service can be  <ins> split between server and client components.  Achieving the required </ins> uniqueness property will typically require a combination of client and server behaviors.  For example, all of the following examples provide a unique Commit per epoch:


agreement properties of MLS will confirm that all members of the group agree on the content of these extensions. <del> Application messages carried by MLS are opaque; they can contain arbitrary data.  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. </del> 5.8.  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 authentication mechanisms, ciphersuites, and infrastructure functionalities. <del> 5.9. </del>  It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this

I added a short section after discussing architectural issues for content framing and negotiation. It suggests [1] if the application doesn't have a more specific proposal. [1] URL
URL
Interim 2022-06-09: Informational refence from RFC to a draft is allowed Agreement to just un-revert / re-land
Fixed in

agreement properties of MLS will confirm that all members of the group agree on the content of these extensions.  5.8. <ins> Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism necessary to negotiate the format of that content over the lifetime of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I- D.mahy-mls-content-neg, unless the specific application defines another mechanism which more appropriately addresses the same requirements for that application of MLS. 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. 5.9. </ins> 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 authentication mechanisms, ciphersuites, and infrastructure functionalities.  <ins> 5.10. </ins> It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this


This document describes how the Messaging Layer Security (MLS) can be used in a federated environment where different MLS implementations <del> can interoperate by defining the message format for user key </del>  retrieval.  The document also describes some use cases where federation could be useful. among a user's devices so that each user appears as a single client. <del> A short-lived HPKE key pair used to introduce a new client to a group.  Initialization keys are published for each client (UserInitKey). </del>  A long-lived signing key pair used to authenticate the sender of a message. 3.1. Different applications operated by different entities can use MLS to <del> exchange E2EE messages.  For example in email applications, clients of email1.com can encrypt and decrypt E2EE email messages from email2.com. </del>  3.2. Different client applications operated by the same server can use MLS <del> to exchange E2EE handshake and application messages.  For example different browsers can implement the MLS protocol, and web developers write web applications that use the MLS implementation in the browser to encrypt and decrypt the messages.  This will require a new standard Web API to allow the client applications to set the address of the delivery service in the browser.  A more concrete example is using MLS in the browser to exchange SRTP keys for multi-party conference call. </del>  4. 4.1. <del> In MLS environment the messages can either be delivered using client fanout or server fanout, each will have different requirements. </del>  <del> In a federated environment the client may communicate with one or more delivery services.  Discovering the delivery service and syncing between different delivery services are out of scope of this document. 4.1.1. In this mode, the client SHOULD support communicating with multiple delivery services.  Discovering the delivery service is out of scope </del>  of this document. <del> In this mode, the delivery service SHPULD be stateless, and it the clients responsibility to maintain the group state.  OPEN QUESTION: How ordering could be enforced in this mode? 4.1.2. Multiple delivery services can be avoided, with server side fan out, and all keys requests can be proxied through a single delivery service.  The protocol between different delivery services is out of the scope of this document. </del> OPEN QUESTION: How server assist could be used with multiple servers? how the server state is shared and synced ? 4.2. <del> There is no change needed for the authentication service, however the </del>  authentication in a federated environment becomes more important. The ideal solution would be using a shared transparency log like KeyTransparency. The encrypted message payload is defined in the MLS protocol document MLSPROTO, in order to get federation between different systems, the <del> identity key and user init key retrieval MUST be defined as well. The identity key can always be included in the user init key </del>  response. <del> The delivery service will return one or more user init key bundles, </del>  one for each member. OPEN QUESTION: What if different clients have different cipher In a federated environment, version negotiation is more critical, to avoid forcing a downgrade attack by malicious 3rd party delivery services.  The negotiation could either be done in the <del> UserInitKeyBundle or in a separate handshake message. </del>  7.

Addressed SV's comments Remove the client fanout concept (because of TreeKEM's handshake ordering requirements) Rename UserInitKeys to ClientInitKeys Minor editorial edits
drop client fanout specify why (policy enforcement, metadata protection) incorporated comments from SV check if it is necessary to define server-to-server message formats only one domain is responsible for a group
I'm very interested in the details of this, but was unable to attend the interim meeting. Does this mean that we are explicitly ruling out client fanout entirely? What metadata are we trying to protect here? You could in theory protect all the metadata with client fanout over Tor for example. Does domain here mean domain name? Why is that relevant? (I'd expect MLS to be independent of DNS) The kind of federated delivery service I'm hoping to be able to use with MLS is logically an append only list of messages published by each member. Where each member can read any other members queue and pull messages they don't have into their own queue (they push their own messages to their own queue only). This allows for diverse P2P topologies, and bandwidth efficient routing. This would be compatible with both and .
TreeKEM has the requirement of total ordering of handshake messages which doesn't work with client fanout. Therefore we drop the idea of client fanout until we have a better proposal on how to solve this. is more conceptual, it doesn't have to be an actual domain name.
Addressed in .

This document describes how the Messaging Layer Security (MLS) can be used in a federated environment where different MLS implementations  <ins> can interoperate by defining the message format for client key </ins> retrieval.  The document also describes some use cases where federation could be useful. among a user's devices so that each user appears as a single client.  <ins> A short-lived HPKE I-D.irtf-cfrg-hpke key pair used to introduce a new client to a group.  Initialization keys are published for each client (ClientInitKey). </ins> A long-lived signing key pair used to authenticate the sender of a message. 3.1. Different applications operated by different entities can use MLS to  <ins> exchange end-to-end encrypted messages.  For example in email applications, clients of email1.com can encrypt and decrypt end-to- end encrypted email messages from email2.com. </ins> 3.2. Different client applications operated by the same server can use MLS  <ins> to exchange end-to-end encrypted handshake and application messages. For example different browsers can implement the MLS protocol, and web developers write web applications that use the MLS implementation in the browser to encrypt and decrypt the messages.  This will require a new standard Web API to allow the client applications to set the address of the delivery service in the browser.  A more concrete example is using MLS in the browser to negotiate SRTP keys for multi-party conference calls. </ins> 4. 4.1.  <ins> In a federated environment, the different members of a group might use different Delivery Services.  Each client SHOULD only connect to its respective Deliver Service, which in turn will connect to other Delivery Services to relay messages. </ins>  <ins> One Delivery Service MUST be responsible for handshake message ordering at any given point in time, since TreeKEM requires handshake messages to have a total order.  It MUST be clear to all clients and Delivery Services of the group which Delivery Service is responsible. The protocol between different delivery services is out of the scope </ins> of this document.  OPEN QUESTION: How server assist could be used with multiple servers? how the server state is shared and synced ? 4.2.  <ins> There is no change needed for the Authentication Service, however </ins> authentication in a federated environment becomes more important. The ideal solution would be using a shared transparency log like KeyTransparency. The encrypted message payload is defined in the MLS protocol document MLSPROTO, in order to get federation between different systems, the  <ins> identity key and client init key retrieval MUST be defined as well. The identity key can always be included in the client init key </ins> response.  <ins> The delivery service will return one or more client init key bundles, </ins> one for each member. OPEN QUESTION: What if different clients have different cipher In a federated environment, version negotiation is more critical, to avoid forcing a downgrade attack by malicious 3rd party delivery services.  The negotiation could either be done in the  <ins> ClientInitKeyBundle or in a separate handshake message. </ins> 7.


The delivery service will return one or more client init key bundles, one for each member. <del> OPEN QUESTION: What if different clients have different cipher suites? </del> 6. 6.1.

This should give you the same GitHub pages website as mls-protocol. One this is merged, someone with push access to the repo will need to run: It doesn't look like Pages it on. You can try turning it off and back on in the Settings tab and that will trigger a new deploy. Leave the domain for Pages as the default, not "URL" or something similar
NAME Do you mind reviewing?
NAME Can you follow the instructions in the PR description please

The delivery service will return one or more client init key bundles, one for each member.  6. 6.1.


The goal of the reinit proposal is to trigger a tear down / restart of a group with the same members but different parameters such as a version upgrade, or a cipher suite change. Changing version - version is a field within key package, and this locks a key package to a specific version, even if capabilities allow for multiple versions. Should that field be removed, and instead you just look at capabilities? It seems that this would change with since leaf nodes will not be pinned to a specific version, just a cipher suite. After 575 gets merged one could upgrade versions using a new tree that copies the current non-empty leaves so long as each leaf has the upgraded version in their capabilities set. That specific tree building process is not mentioned, it is just sort of assumed in context. Changing cipher suite - In the case you want to change cipher suite, complexity somewhat increases. You will need to create a new tree by grabbing new key packages for each participant, and because the cipher suite has changed, all of the credentials have also changed. It is mentioned that "A group may be reinitialized by creating a new group with the same membership and different parameters", but this does not have a statement that has a SHOULD or MUST associated with it. For example, in my 5000 member group 1 member does not support the cipher suite that we are migrating away from. As the committer, I'm assuming that I should keep everyone in the group as best effort, but have the option to filter out problematic members that are blocking a migration due to them being offline for long periods of time or having outdated software. Due to the credential change, enforcing a MUST might be difficult since equality between two x509 credentials is not straight forward for example. To summarize, I propose some changes Remove version from key package, and rely on capabilities instead, this may now be irrelevant due to , but the version and capabilities.versions values seem duplicative Add some language in reinitialization that clarifies the flow for upgrading just version vs changing cipher suite, where changing cipher suite explicitly requires you acquire new key packages for each member. Clarify that a person issuing the welcome based on a reinit proposal SHOULD include all existing members
IMO those fields have quite separate purposes. Keep in mind that a different version could have a different KeyPackage format. So says "this KeyPackage is formatted according to this version", while the capabilities says what other versions I support. With that in mind, you need to grab new KeyPackages for everyone regardless of whether you're changing version, ciphersuite, or both. If this isn't clear, we should certainly clarify it. If you're worried about people not supporting the new stuff, you could maintain the hard semantic just by Removing those participants that don't support the new stuff before you ReInit.
Fair enough that seems reasonableI don't think it's necessarily clear right now, it's more of an assumption based on an understanding of the protocol overall. I'll try to come up with something there to give more of a step by step explanation of the flow.If this is a hard requirement should the doc say MUST here? If so, I'm trying to think through what equality means in terms of membership when in the event the cipher suite changes, all the credentials will also change.
On (3) -- I would be OK with saying that the new members MUST be the same as the old members. The notion of "same" is a little squishy, given ambiguities around identifiers, but it seems like it will probably be clear in practice. W.r.t. removing people to make an upgrade possible, when the application decides to upgrade and how the application it meets the same-member criterion is up to the application.
Discussion on virtual interim: Maybe put "remove before upgrade" in implementation considerations document.
NAME I meant to make this call to discuss, seem to not have the invite anymore, can you forward it to me? In terms of where this ticket is at, I was mostly raising the concerns to clarify for myself that what I think is the process is actually the process. I am willing to just close this one out

Abstract  <ins> Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, not any servers involved in delivering messages.  Establishing keys to provide such protections is challenging for group chat settings, in which more than two participants need to agree on a key.  In this document, we specify a group key establishment protocol that provides efficient group key establishment with forward secrecy and post-compromise security. 1. [[ TODO - Group keying is necessary, but hard.  State of the art is sender keys, which have bad FS / PCS and bad rekey efficiency ]] 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. 3. 3.1. 3.2. 3.3. 3.4. 4. [[ Session comprised of (1) ART (2) pre-stage key (3) message key chains ]] [[ Each node caches... ]] 5. 5.1. 5.2. 5.2.1. 5.2.2. 5.2.3. 5.2.4. 6. [[ What trust is placed in the server? ]] 7. </ins>


(respectively _right subtree_). All trees used in this protocol are left-balanced binary trees.  A <del> binary tree is _full_ (and _balanced_) if it its size is a power of two and for any parent node in the tree, its left and right subtrees have the same size.  If a subtree is full and it is not a subset of any other full subtree, then it is _maximal_. </del>  A binary tree is _left-balanced_ if for every parent, either the parent is balanced, or the left subtree of that parent is the largest In order to update the state of the group such as adding and removing participants, MLS messages are used to make changes to the group's ratchet tree.  The participant proposing an update to the tree <del> transmits a representation of a set of tree nodes along the direct path from a leaf to the root.  Other participants in the group can use these nodes to update their view of the tree, aligning their copy of the tree to the sender's. </del>  To perform an update for a leaf, the sender transmits the following <del> information for each node in the direct path from the leaf to the root: </del>  The public key for the node <del> Zero or more encrypted copies of the node's secret value </del>  The secret value is encrypted for the subtree corresponding to the <del> node's non-updated child, i.e., the child not on the direct path. There is one encrypted secret for each public key in the resolution of the non-updated child.  In particular, for the leaf node, there are no encrypted secrets, since a leaf node has no children. </del>  The recipient of an update processes it with the following steps: Compute the updated secret values * Identify a node in the direct path for which the local participant is in the subtree of the non- <del> updated child * Identify a node in the resolution of the non- updated child for which this node has a private key * Decrypt the secret value for the direct path node using the private key from </del>  the resolution node * Compute secret values for ancestors of that node by hashing the decrypted secret This ciphersuite uses the following primitives: <del> Hash function: P-256 </del>  Diffie-Hellman group: secp256r1 (NIST P-256) 5.8. As described in ratchet-tree-updates, each MLS message needs to <del> transmit node values along the direct path from a leaf to the root. The path contains a public key for the leaf node, and a public key and encrypted secret value for intermediate nodes in the path.  In both cases, the path is ordered from the leaf to the root; each node MUST be the parent of its predecessor. </del>  The length of the "node_secrets" vector MUST be zero for the first node in the path.  For the remaining elements in the vector, the the removed leaf using the information in the Remove message Update the ratchet tree by setting to blank all nodes in the <del> direct path from the removed leaf to the root </del>  The update secret resulting from this change is the secret for the root node of the ratchet tree after the second step (after the third

The very first commit from PR (6ba86ff561484a9eb96012e3b55b49f23cb8f9e9) was removed and a separate Issue is filled for unifying the use of "`" and "_".
We inconsistently use the backtick, the underscore or nothing for messages fields or specific operations in the draft. This needs a fix, currently the opinion is to use the TLS style (aka remove everything)

(respectively _right subtree_). All trees used in this protocol are left-balanced binary trees.  A  <ins> binary tree is _full_ (and _balanced_) if its size is a power of two and for any parent node in the tree, its left and right subtrees have the same size.  If a subtree is full and it is not a subset of any other full subtree, then it is _maximal_. </ins> A binary tree is _left-balanced_ if for every parent, either the parent is balanced, or the left subtree of that parent is the largest In order to update the state of the group such as adding and removing participants, MLS messages are used to make changes to the group's ratchet tree.  The participant proposing an update to the tree  <ins> transmits a set of values for intermediate nodes in the direct path of a leaf.  Other participants in the group can use these nodes to update their view of the tree, aligning their copy of the tree to the sender's. </ins> To perform an update for a leaf, the sender transmits the following  <ins> information for each node in the direct path of the leaf: </ins> The public key for the node  <ins> Zero or more encrypted copies of the node's parent secret value </ins> The secret value is encrypted for the subtree corresponding to the  <ins> parent's non-updated child, i.e., the child on the copath of the leaf node.  There is one encrypted secret for each public key in the resolution of the non-updated child.  In particular, for the leaf node, there are no encrypted secrets, since a leaf node has no children. </ins> The recipient of an update processes it with the following steps: Compute the updated secret values * Identify a node in the direct path for which the local participant is in the subtree of the non-  <ins> updated child * Identify a node in the resolution of the copath node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from </ins> the resolution node * Compute secret values for ancestors of that node by hashing the decrypted secret This ciphersuite uses the following primitives:  <ins> Hash function: SHA-256 </ins> Diffie-Hellman group: secp256r1 (NIST P-256) 5.8. As described in ratchet-tree-updates, each MLS message needs to  <ins> transmit node values along the direct path of a leaf.  The path contains a public key for the leaf node, and a public key and encrypted secret value for intermediate nodes in the path.  In both cases, the path is ordered from the leaf to the root; each node MUST be the parent of its predecessor. </ins> The length of the "node_secrets" vector MUST be zero for the first node in the path.  For the remaining elements in the vector, the the removed leaf using the information in the Remove message Update the ratchet tree by setting to blank all nodes in the  <ins> direct path of the removed leaf </ins> The update secret resulting from this change is the secret for the root node of the ratchet tree after the second step (after the third


A Diffie-Hellman finite-field group or elliptic curve <del> A Derive-Key-Pair function that produces a key pair from an octet string </del>  <del> A hash function </del>  A ratchet tree is a left-balanced binary tree, in which each node contains up to three values: An asymmetric public key <del> The private key and public key for a node are derived from its secret value using the Derive-Key-Pair operation. </del>  The contents of a parent node are computed from one of its children as follows: updated child * Identify a node in the resolution of the copath node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from <del> the resolution node * Compute secret values for ancestors of that node by hashing the decrypted secret </del>  Merge the updated secrets into the tree * Replace the public keys for nodes on the direct path with the received public keys * For

For now, I've only touched the sections until the "Cryptographic Objects" section, which seems to be outdated anyway. Once those are updated at some point, I'm happy to help moving from hashing to KDF-derivation there as well.
Thanks Konrad ! : )

A Diffie-Hellman finite-field group or elliptic curve  <ins> A Key Derivation Function (KDF) </ins>  <ins> A Derive-Public-Key function that produces a public key from a private key </ins> A ratchet tree is a left-balanced binary tree, in which each node contains up to three values: An asymmetric public key  <ins> The private key for a node is derived from its secret value using the KDF.  The public key is then derived from the private key using the Derive-Public-Key function. </ins> The contents of a parent node are computed from one of its children as follows: updated child * Identify a node in the resolution of the copath node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from  <ins> the resolution node * Derive secret values for ancestors of that node using the KDF keyed with the decrypted secret </ins> Merge the updated secrets into the tree * Replace the public keys for nodes on the direct path with the received public keys * For


which includes both public and private data.  An initial state, including an initial set of participants, is set up by a group creator using the _Init_ algorithm and based on information pre- <del> published by the initial members.  The creator sends the _GroupInit_ </del>  message to the participants, who can then set up their own group state and derive the same shared secret.  Participants then exchange messages to produce new shared states which are causally linked to roster, since this is the number of nodes in a tree with "size" leaves, according to the structure described in ratchet-trees. <del> The "transcript" field contains the list of "GroupOperation" </del>  messages that led to this state. When a new member is added to the group, an existing member of the When a new one-member group is created (which requires no GroupOperation), the "transcript_hash" field is set to an all-zero <del> vector of length Hash.length. </del>  5.8. object and consider the Handshake message invalid. Use the "confirmation_key" for the new group state to compute the <del> finished MAC for this message, as described below, and verify that it is the same as the "finished_mac" field. </del>  If the the above checks are successful, consider the updated GroupState object as the current state of the group. transcript of group operations, using the transcript hash from the provisional GroupState object:  HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use. Sign uses the signature algorithm indicated by the signer's credential in the roster. the removed leaf An existing participant receiving a Remove message first verifies the <del> signature on the message, then verifies its identity proof against the identity tree held by the participant.  The participant then updates its state as follows: </del>  Update the roster by setting the credential in the removed slot to the null optional value

Fixes for points 1, 2, 4, 7 in .
I think a bunch of these are probably relics of previous versions. For reference, the page numbers listed are from the PDF version of draft 3 of the protocol: [x] 1 - p6: is mentioned, but it is not defined anywhere in the specification. Perhaps is intended.[x] 2 - p19: A field is mentioned, but only is present. Also it's unclear which function is supposed to be used here. It can't be ciphersuite-dependent, since it has to be the same for every Participant.[x] 3 - p22: is used in a diagram, but never defined. I think this is important, and it's mentioned elsewhere.[x] 4 - p24: is mentioned, but never defined. Is it supposed to say ?[ ] 5 - p25: The underlying Hash that HMAC uses can't be defined by anyone's ciphersuite. This is group state, and everyone has to agree on this.[x] 6 - p28: Mentioned "update secret" again without explanation.[x] 7 - p29: "identity tree" is mentioned, but I can't tell what that's referring to. Also "update secret" is here.[x] 8 - p35: is mentioned, but never defined. Perhaps is intended.
Thanks a lot for the review, this is very useful. I have a pass planned for this week and will fix these issues :)
NAME A PR was opened with fixes for points 1, 2, 4, 7. Point 8 was already solved. An issue has been opened to solve points 3 and 6 related to the update secret definition. I tried to figure out your point 5 but I didn't understand it, can you give details ?
Sorry for the delay. I think point 5 was a misunderstanding over when a common ciphersuite is established in the protocol. I'm still not 100% clear on it, but I think I'm just missing something simple. Consider it withdrawn.
Ok, then these issues are fixed by and . Thanks

which includes both public and private data.  An initial state, including an initial set of participants, is set up by a group creator using the _Init_ algorithm and based on information pre-  <ins> published by the initial members.  The creator sends the _Init_ </ins> message to the participants, who can then set up their own group state and derive the same shared secret.  Participants then exchange messages to produce new shared states which are causally linked to roster, since this is the number of nodes in a tree with "size" leaves, according to the structure described in ratchet-trees.  <ins> The "transcript_hash" field contains the list of "GroupOperation" </ins> messages that led to this state. When a new member is added to the group, an existing member of the When a new one-member group is created (which requires no GroupOperation), the "transcript_hash" field is set to an all-zero  <ins> vector of length Hash.length, where the Hash algorithm is defined by the ciphersuite. </ins> 5.8. object and consider the Handshake message invalid. Use the "confirmation_key" for the new group state to compute the  <ins> "confirmation" MAC for this message, as described below, and verify that it is the same as the "confirmation" field. </ins> If the the above checks are successful, consider the updated GroupState object as the current state of the group. transcript of group operations, using the transcript hash from the provisional GroupState object: <ins> [[ OPEN ISSUE: The confirmation data and signature data should probably cover the same data as the one we cover with the GroupState. ]] </ins> HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use. Sign uses the signature algorithm indicated by the signer's credential in the roster. the removed leaf An existing participant receiving a Remove message first verifies the  <ins> signature on the message.  The participant then updates its state as follows: </ins> Update the roster by setting the credential in the removed slot to the null optional value


Since the new member is expected to process the Add message for itself, the Welcome message should reflect the state of the group before the new user is added.  The sender of the Welcome message can <del> simply copy all fields except the "leaf_secret" from its GroupState object. </del>  [[ OPEN ISSUE: The Welcome message needs to be synchronized in the same way as the Add.  That is, the Welcome should be sent only if the

There is no "leaf_secret" field in GroupState. While there might be one in the group state struct that the implementation maintains locally, I think it's safe to recommend copying everything from the GroupState object as it's defined earlier in the document.

Since the new member is expected to process the Add message for itself, the Welcome message should reflect the state of the group before the new user is added.  The sender of the Welcome message can  <ins> simply copy all fields from their GroupState object. </ins> [[ OPEN ISSUE: The Welcome message needs to be synchronized in the same way as the Add.  That is, the Welcome should be sent only if the


A participant that is included in the shared state of a group, and has access to the group's secrets. <del> A short-lived Diffie-Hellman key pair used to introduce a new member to a group.  Initialization keys are published for individual participants (UserInitKey). </del>  <del> A short-lived Diffie-Hellman key pair that represents a group member's contribution to the group secret, so called because the </del>  participants leaf keys are the leaves in the group's ratchet tree. A long-lived signing key pair used to authenticate the sender of a The "tree" field contains the public keys corresponding to the nodes of the ratchet tree for this group.  The length of this <del> vector MUST be "2*size + 1", where "size" is the length of the </del>  roster, since this is the number of nodes in a tree with "size" leaves, according to the structure described in ratchet-trees. the resolution. The HPKECiphertext values are computed according to the Encrypt <del> function defined in HPKE. </del>  Decryption is performed in the corresponding way, using the private key of the resolution node and the ephemeral public key transmitted The Hash function used by HKDF is the ciphersuite hash algorithm. Hash.length is its output length in bytes.  In the below diagram: <del> HKDF-Extract takes its Salt argument from the top and its IKM </del>  argument from the left Derive-Secret takes its Secret argument from the incoming arrow The init_keys array MUST have the same length as the cipher_suites array, and each entry in the init_keys array MUST be a public key for <del> the DH group defined by the corresponding entry in the cipher_suites array. </del>  The whole structure is signed using the client's identity key.  A UserInitKey object with an invalid signature field MUST be considered

I'm approving these changes given the current state of the document, but I filed because the KDF stuff is broken. Please make HPKE a normative reference (since it's required to implement). Since it's an Internet-Draft, you don't need to add it to the references section, you can just reference it directly as and the Markdown processor will add the reference. (Change the to for an informative reference.)

A participant that is included in the shared state of a group, and has access to the group's secrets.  <ins> A short-lived HPKE key pair used to introduce a new member to a group.  Initialization keys are published for individual participants (UserInitKey). </ins>  <ins> A short-lived HPKE key pair that represents a group member's contribution to the group secret, so called because the </ins> participants leaf keys are the leaves in the group's ratchet tree. A long-lived signing key pair used to authenticate the sender of a The "tree" field contains the public keys corresponding to the nodes of the ratchet tree for this group.  The length of this  <ins> vector MUST be "2*size - 1", where "size" is the length of the </ins> roster, since this is the number of nodes in a tree with "size" leaves, according to the structure described in ratchet-trees. the resolution. The HPKECiphertext values are computed according to the Encrypt  <ins> function defined in I-D.barnes-cfrg-hpke. </ins> Decryption is performed in the corresponding way, using the private key of the resolution node and the ephemeral public key transmitted The Hash function used by HKDF is the ciphersuite hash algorithm. Hash.length is its output length in bytes.  In the below diagram:  <ins> HKDF-Extract takes its salt argument from the top and its IKM </ins> argument from the left Derive-Secret takes its Secret argument from the incoming arrow The init_keys array MUST have the same length as the cipher_suites array, and each entry in the init_keys array MUST be a public key for  <ins> the asymmetric encryption scheme defined in the cipher_suites array and used in the HPKE construction for TreeKEM. </ins> The whole structure is signed using the client's identity key.  A UserInitKey object with an invalid signature field MUST be considered


8.4. A Remove message is sent by a group member to remove one or more <del> members from the group. </del>  The sender of a Remove message generates it as as follows: Update the ratchet tree by replacing nodes in the direct path from the removed leaf using the information in the Remove message <del> Reduce the size of the roster and the tree until the rightmost element roster element and leaf node are non-null </del> Update the ratchet tree by setting to blank all nodes in the <del> direct path of the removed leaf </del>  The update secret resulting from this change is the path secret computed for the root node of the ratchet tree in the first step.

This clears up the wording around how to prune the ratchet tree on a Remove operation. Previously, it could be interpreted as "remove nodes from the tree until the rightmost node is not null", but this is not what is intended by the authors, and it also has the ability to produce invalid trees (i.e., trees with an even number of elements). The second change is to do the truncation after doing the Blank propogation up the direct path of the removed leaf. Note that the order of these steps doesn't matter in that they produce the same resulting tree. However, if we blank after pruning, an implementor would have to take care to not to try to blank out previously-removed nodes. Prune-then-blank is a little easier to reason about. The third change is a semantic fix. It is clear from the last paragraph in this section that the root node should be blanked, but the text only said to blank the direct path of the leaf, which does not include the root node. I just added that part in.
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 1 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 4 comments. - - Last week, 9 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .

8.4. A Remove message is sent by a group member to remove one or more  <ins> other members from the group.  A member MUST NOT use a Remove message to remove themselves from the group.  If a member of a group receives a Remove message where the removed index is equal to the signer index, the recipient MUST reject the message as malformed. </ins> The sender of a Remove message generates it as as follows: Update the ratchet tree by replacing nodes in the direct path from the removed leaf using the information in the Remove message  Update the ratchet tree by setting to blank all nodes in the  <ins> direct path of the removed leaf, and also setting the root node to blank Truncate the roster such that the last roster element is non-null Truncate the tree such that the rightmost non-blank leaf is the last node of the tree Note that, in step 4, there must be at least one non-null element in the roster, since any valid GroupState must have the current member in the roster and self-removal is prohibited.  The same reasoning justifies the existence of a non-blank leaf in the ratchet tree in step 5. </ins> The update secret resulting from this change is the path secret computed for the root node of the ratchet tree in the first step.