Change:
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> <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

Discussion:
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.