Draft: draft-ietf-mls-protocol

Commentary: 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 do n't support 
 Just for context : This PR addresses the second part of . 
 Agreed . Looks good . 
 Discussed at 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 can not 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 do n'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 . 
 and I discussed real - time , propose to do the following : out the GroupContext extensions as above a new proposal type to update the group 's extensions : 
 Looks good to me !
Paragraph (version A):
The "capabilities" extension indicates what protocol versions,
ciphersuites, and protocol extensions are supported by a client.
Paragraph (version B):
The "capabilities" extension indicates what protocol versions,
ciphersuites, protocol extensions, and non-default proposal types are
supported by a client.  Proposal types defined in this document are
considered "default" and thus need not be listed.
Paragraph (version A):
The sender of a Commit MUST include all valid proposals that it has
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
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.
Paragraph (version B):
The sender of a Commit MUST include all valid proposals that it has
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
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).
Paragraph (version B):
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.
Paragraph (version B):
This registry lists identifiers for types of proposals that can be
made for changes to an MLS group.  The extension type field is two
bytes wide, so valid extension type values are in the range 0x0000 to
0xffff.
Paragraph (version B):
Recommended: Whether support for this extension is recommended by
the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended"
column is assigned a value of "N" unless explicitly requested, and
adding a value with a "Recommended" value of "Y" requires
Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N
transition.