Change:
received during the current epoch.  Invalid proposals include, for example, proposals with an invalid signature or proposals that are semantically invalid, such as an Add when the sender does not have <del> the application-level permission to add new users.  If there are multiple proposals that apply to the same leaf, the committer chooses one and includes only that one in the Commit, considering the rest invalid.  The committer MUST prefer any Remove received, or the most recent Update for the leaf if there are no Removes.  If there are multiple Add proposals containing KeyPackages with the same tuple "(credential.identity, endpoint_id)" the committer again chooses one to include and considers the rest invalid.  Add proposals that contain KeyPackages with an "(credential.identity, endpoint_id)" tuple that matches that of an existing KeyPackage in the group MUST be considered invalid.  The comitter MUST consider invalid any Add or Update proposal if the Credential in the contained KeyPackage shares the same signature key with a Credential in any leaf of the group, or indeed if the KeyPackage shares the same "hpke_init_key" with another KeyPackage in the group. </del> <ins> the application-level permission to add new users.  Proposals with a non-default proposal type MUST NOT be included in a commit unless the proposal type is supported by all the members of the group that will process the Commit (i.e., not including any members being added or removed by the Commit). If there are multiple proposals that apply to the same leaf, the committer chooses one and includes only that one in the Commit, considering the rest invalid.  The committer MUST prefer any Remove received, or the most recent Update for the leaf if there are no Removes.  If there are multiple Add proposals containing KeyPackages with the same tuple "(credential.identity, endpoint_id)" the committer again chooses one to include and considers the rest invalid.  Add proposals that contain KeyPackages with an "(credential.identity, endpoint_id)" tuple that matches that of an existing KeyPackage in the group MUST be considered invalid.  The comitter MUST consider invalid any Add or Update proposal if the Credential in the contained KeyPackage shares the same signature key with a Credential in any leaf of the group, or indeed if the KeyPackage shares the same "hpke_init_key" with another KeyPackage in the group. </ins> The Commit MUST NOT combine proposals sent within different epochs. In the event that a valid proposal is omitted from the next Commit,

Discussion:
NAME pointed out to me some improvements that could be made in the extensibility of proposals. This PR makes a few changes to smooth out deployment of new proposals: Extends to two bytes, creates an IANA registry, and reserves some space for private use Extends the extension so that clients can indicate which proposal types they support Forbids committers from including proposals that some people don't support
Just for context: This PR addresses the second part of .
Agreed. Looks good.
Discussed at 20211004 interim, merge.
The "Sequencing of State Changes" and "Application Messages" sections date to very early in the document's life, and probably need some updates to reflect current thinking.
Closing for now, might reopen based on WGLC review.
After a thorough review of the current MLS extension system, there are a few questions and we also have a few suggestions for changes. The total set of extensions is fixed and cannot be changed during the lifetime of a group. The set of extensions that is associated with a group is decided by the group creator. All extension types from the set have to be supported by all clients and must therefore be advertised in their capabilities extension. The implementation needs to validate the support in 4 instances: When creating a new group, when joining a group, when creating an add proposal, when parsing someone else's add proposal as part of a Commit. Key package extensions are simple and well-understood, in that they never leave the KeyPackage and there is group consensus through the tree hash. The other kind of extension seems to be called a Group Info Extension (GIE). GIEs can come in two flavours: a) they must be included in the group context, b) they must not be included in the group context. The ratchet tree extensions is an example of type b). GIEs of type a) are essentially just passed from the Adder to the New Joiner, using Welcome messages as an E2EE pipe.The spec does not explicitly introduce the notion of a GIE, it is only mentioned in 16.2. Should the spec be more explicit here? Should the flavour of a GIE (as described above) be reflected in the struct in the spec? E.g. a message type that indicates whether a GIE should be included in the GroupContext (see proposal below).

Can the content of a GIE be dynamic (i.e. it can change during the lifetime of a group)? The ratchet tree extension seems to validate that assumption, it is a bit unclear if this is true for all kinds of GIE. We should be more explicit in the spec. If the content of GIEs is indeed dynamic, should those GIEs always be excluded from the GroupContext? Or optionally? If they are to be included in the GroupContext, how do clients agree on the changes? (See proposal below) We need more guidance regarding extensions in order to keep implementations aligned and capable of interop. A first suggestion would be to allow for the creation of extensions that have dynamic content. This would allow them to use MLS to agree on arbitrary data. The requirement would be to make GIEs with dynamic content more robust by introducing a new proposal type to update the content of extensions: Another improvement to the current extension system would be to be more clear about the kinds of extensions by introducing a dedicated field for every extension: This would allow generic extensions, which in turn allow committers of Add proposals to communicate arbitrary data to new group members in a robust fashion.
Thanks for the analysis here. To your point about “dynamic GIEs” — My initial concept here was that the GIEs included in the GroupContext would be fixed for all time. The ratchet tree extension would not be included in the GroupContext; as you say, it just uses the Welcome for E2E tunneling. Boiling this down a bit, it seems like there are a few problems to solve here: Clarifying which extensions in the GroupInfo go into the GroupContext and which are just used for tunneling E2E Allowing for updates to the group’s extensions For the former, there's a pretty simple solution available: Just have separate fields in the GroupContext for permanent and ephemeral extensions. The joiner processing would then place the into the MLS state / GroupContext, and use/discard the . We could also then update the IANA considerations to reflect these additional categories for where an extension can appear. For the latter problem, I think your ExtensionUpdate is about the right approach. It might be simpler just to have the update proposal provide wholesale replacement to the extensions, so that we don't have to design a merge algorithm.

I'm not totally sure this is worth doing right now, since it seems easy to do as an extension. But especially if we keep it simple, I'm not strongly opposed.
NAME NAME and I discussed real-time, propose to do the following: Split out the GroupContext extensions as above Define a new proposal type to update the group's extensions:
Looks good to me!