Original text:
architecture.  In particular, we assume that the following services are provided: <del> A Delivery Service that routes MLS messages among the participants in the protocol.  The following types of delivery are typically required: </del>  Pre-publication of KeyPackage objects for clients Unicast delivery of Welcome messages to new members of a group <del> An Authentication Service that enables group members to </del>  authenticate the credentials presented by other group members.  1.2. RFC EDITOR PLEASE DELETE THIS SECTION. The security goals of MLS are described in I-D.ietf-mls-architecture. We describe here how the protocol achieves its goals at a high level, though a complete security analysis is outside of the scope of this <del> document. </del>  15.1. 15.2.  The first form of authentication we provide is that group members can verify a message originated from one of the members of the group. For encrypted messages, this is guaranteed because messages are that ensures that the legitimate members of the group have the required PSKs. <del> 15.3. </del>  Forward secrecy and post-compromise security are important security notions for long-lived MLS groups.  Forward secrecy means that This way, the key material used to add a member to a new group is more likely to be fresh and less likely to be compromised. <del> 15.4. </del>  KeyPackages are intended to be used only once.  That is, once a KeyPackage has been used to introduce the corresponding client to a KeyPackage publication system SHOULD rate-limit KeyPackage requests, especially if not authenticated. <del> 15.5. </del>  It is possible for a malicious member of a group to "fragment" the group by crafting an invalid UpdatePath.  Recall that an UpdatePath

Reviewer comments:
Add a paragraph to Operational Context describing additional security services that the DS can provide Add a citation to security analyses via the MLS Architecture Add a section discussing metadata protection
It also feels like the text assumes that the DS is a server as opposed to the abstract layer that we define it as in the architecture document. Maybe we should qualify the considerations accordingly?
NAME NAME - Thanks for sending . I didn't merge it directly, but rewrote the metadata section trying to hit the key points from your proposal. LMK what you think.
Comment by NAME Hmmm :P
Cf. RFC 8446 We could provide some more citations to the analyses that are now in the literature if you think that would help.
CC NAME NAME NAME for citations
They are also in this architecture document PR: URL
Oh good, I'll just add a citation over to mls-architecture.
Comment by NAME That is quite some information that must be publicly available to allow external Add requests. This leaks information, eg same epoch means the group membership did not change, etc etc. I hope this will appear in the Security Considerations later :)
I suppose between this and , we should add a subsection to the Security Considerations on metadata privacy.
I'm not sure actually resolves this?
Oops, that's correct NAME Had it in my notes among the others.
Comment by NAME There seems to be no group "owner", so inviting one member X, could that member than delete members from the group until the group is empty? Apparently, there is ACLs for this, but the document doesn't describe how ACLS would work or how these would be implemented.
You are correct that MLS is "egalitarian" by default, in that any member can perform any action. This capability can be limited by policy, enforced either at the endpoints or at the DS (the latter requiring handshake messages to be unencrypted). This is discussed in the MLS architecture document, e.g., in the section. I would be open to adding some security considerations noting this. But seeing as it's already in the architecture, I would be inclined to close this issue with no action.
Comment by NAME I find the interaction with the application layer not clear. Not much is mentioned in this document. How can a group have an administrator? How is that enforced at the MLS layer? How do ACLs interact with MLS? (How are DoS attacks mitigated (eg spam attempts to join any group). What hooks would be in the authentication service and/or delivery server? How would clients know the properties of these two services? This includes how it is not clear to me how race conditions are handled. What if two members try to expel each other at the same time? What if the group is so large, members always get their epoch wrong for things like Commit messages?
I think the intent was to have these issues mostly dealt with in the architecture document. Broadly speaking, it is the DS's job to solve these problems. For example, the DS we use in Webex chooses which member makes which commit. This is why we have Section 3, . There are also some brief notes in Section 14, ". Unless we need to make this division of labor clearer, I'm inclined to close this issue with no action.
While instant messaging was one of the big motivators for MLS, it is not the only one to be implemented in the same timeframe. In MIMI for example we are planning to have a whole work item that specifies many more constraints on how the DS would be expected to work in an instant messaging context. Whereas we have implementors of MLS who are planning to do things very differently for an IoT communication application.
I'll reread the architecture bit again about the DS, but it still feels to me it could be made more clear.

Revised text:
architecture.  In particular, we assume that the following services are provided:  <ins> A Delivery Service (DS) that routes MLS messages among the participants in the protocol.  The following types of delivery are typically required: </ins> Pre-publication of KeyPackage objects for clients Unicast delivery of Welcome messages to new members of a group  <ins> Sequencing of Commit messages (see sequencing) An Authentication Service (AS) that enables group members to </ins> authenticate the credentials presented by other group members. <ins> The DS and AS may also apply additional policies to MLS operations to obtain additional security properties.  For example, MLS enables any participant to add or remove members of a group; a DS could enforce a policy that only certain members are allowed to perform these operations.  MLS authenticates all members of a group; a DS could help ensure that only clients with certain types of credential are admitted.  MLS provides no inherent protection against denial of service; A DS could also enforce rate limits in order to mitigate these risks. </ins> 1.2. RFC EDITOR PLEASE DELETE THIS SECTION. The security goals of MLS are described in I-D.ietf-mls-architecture. We describe here how the protocol achieves its goals at a high level, though a complete security analysis is outside of the scope of this  <ins> document.  The Security Considerations section of I-D.ietf-mls- architecture provides some citations to detailed security analyses. </ins> 15.1. 15.2. <ins> MLS does not provide confidentiality protection to some messages and fields within messages: KeyPackage messages GroupInfo messages The unencrypted portion of a Welcome message Any Proposal or Commit messages sent as MLSPlaintext messages The unencrypted header fields in MLSCiphertext messages The lengths of encrypted Welcome and MLSCiphertext messages The only mechanism MLS provides for confidentially distributing a group's ratchet tree to new members is to send it in a Welcome message as a "ratchet_tree" extension.  If an application distributes the tree in some other way, its security will depend on that application mechanism. A party observing these fields might be able to infer certain properties of the group: Group ID Current epoch and frequency of epoch changes Frequency of messages within an epoch Group extensions Group membership The amount of metadata exposed to parties outside the group, and thus the ability of these parties to infer the group's properties, depends on several aspects of the DS design, such as: How KeyPackages are distributed How the ratchet tree is distributed How prospective external joiners get a GroupInfo object for the group Whether MLSPlaintext or MLSCiphertext messages are used for Proposal and Commit messages In the remainder of this section, we note the ways that the above properties of the group are reflected in unprotected group messages, as a guide to understanding how they might be exposed or protected in a given application. 15.2.1. MLS provides no mechanism to protect the group ID and epoch of a message from the DS, so the group ID and the frequency of messages and epoch changes are not protected against inspection by the DS. 15.2.2. A group's extensions are first set by the group's creator and then updated by GroupContextExtensions proposals.  A GroupContextExtension proposal sent as MLSPlaintext leaks the groups' extensions. A new member learns the group's extensions via a GroupInfo object. When the new member joins via a Welcome message, the Welcome message's encryption protects the GroupInfo message.  When the new member joins via an external join, they must be provided with a GroupInfo object.  Protection of this GroupInfo object is up to the application - if it is transmitted over a channel that is not confidential to the group and the new joiner, then it will leak the group's extensions. 15.2.3. The group's membership is represented directly by its ratchet tree, since each member's LeafNode contains members' cryptographic keys, a credential that contains information about the member's identity, and possibly other identifiers.  Applications that expose the group's ratchet tree outside the group also leak the group's membership. Changes to the group's membership are made by means of Add and Remove proposals.  If these proposals are sent as MLSPlaintext, then information will be leaked about the corresponding changes to the group's membership.  A party that sees all of these changes can reconstruct the group membership. Welcome messages contain a hash of each KeyPackage for which the Welcome message is encrypted.  If a party has access to a pool of KeyPackages and observes a Welcome message, then they can identify the KeyPackage representing the new member.  If the party can also associate the Welcome with a group, then the party can infer that the identified new member was added to that group. Note that these information leaks reveal the group's membership only to the degree that that membership is revealed by the contents of a member's LeafNode in the ratchet tree.  In some cases, this may be quite direct, e.g., due to credentials attesting to identifiers such as email addresses.  An application could construct a member's leaf node to be less identifying, e.g., by using a pseudonymous credential and frequently rotating encryption and signature keys. 15.3. </ins> The first form of authentication we provide is that group members can verify a message originated from one of the members of the group. For encrypted messages, this is guaranteed because messages are that ensures that the legitimate members of the group have the required PSKs.  <ins> 15.4. </ins> Forward secrecy and post-compromise security are important security notions for long-lived MLS groups.  Forward secrecy means that This way, the key material used to add a member to a new group is more likely to be fresh and less likely to be compromised.  <ins> 15.5. </ins> KeyPackages are intended to be used only once.  That is, once a KeyPackage has been used to introduce the corresponding client to a KeyPackage publication system SHOULD rate-limit KeyPackage requests, especially if not authenticated.  <ins> 15.6. </ins> It is possible for a malicious member of a group to "fragment" the group by crafting an invalid UpdatePath.  Recall that an UpdatePath