Draft: draft-ietf-mls-protocol

Commentary: Extensions in the CIK were only half of the story . To do things like RTreeKEM or fork / merge as extensions , we need the ability to ( 1 ) tell new members that the group is doing something different , and ( 2 ) confirm that all group members have the same view of the rules of the road . This PR adds extensions to the GroupInfo object for the first case , and to the Welcome object for the second , and a bunch of explanatory text to make it all work . One thing this PR does not do is define a way to change extensions in a running group . You could in principle do this by sending new extensions in Commit that could overwrite or add to extensions . But that entails some messy questions ( how do you delete an extension in use ? ) , so it is currently left to an extension ( heh ) , or to a group restart . Depends on to avoid conflicts in GroupInfo changes . 
 I think this could also be useful for deniability . 
 I imagine we also need to define an IANA registry of extensions , designated experts , a private space ? 
 Filed for the IANA stuff 
 Now that we have a more robust extension mechanism , we need to have an IANA registry to manage extensions , including : Registry structure Registry policy and ( probably ) designated experts Reserved vendor space 
 Certain things about a group are fixed , for example , its ciphersuite and version of MLS , and with , its extensions . It could be desirable to have the ability to change these parameters , e.g. , to use a new ciphersuite when all members support it . Defining a way to change these values " in place " seems tricky , though . Instead , we could define a " restart " mechanism that initializes a new group with the same membership and different parameters . At one level this is trivially possible , just by creating a new group over the same members . But it could be useful to explicitly hand - over from one to the other , so that clients understand that they are the same . You could also tie them together cryptographically , e.g. , by exporting a secret from the old group 's key schedule , and importing it as a PSK into the new group . 
 Replaced by 
 Here 's the Weekly Digest for : - - Last week 5 issues were created . Of these , 1 issues have been closed and 4 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : heart : , by - - Last week , 9 pull requests were created , updated or merged . Last week , 3 pull requests were opened . : greenheart : , by : greenheart : , by : greenheart : , by Last week , 1 pull request was updated . : yellowheart : , by Last week , 5 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 8 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 2 contributors . : bustinsilhouette : : 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 < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also .
Paragraph (version B):
In other words, clients advertise their capabilities in ClientInitKey
extensions, the creator of the group expresses its choices for the
group in Welcome extensions, and the GroupContext confirms that all
members of the group have the same view of the group's extensions.
Paragraph (version B):
A client that posts a ClientInitKey MUST support all parameters
advertised in it.  Otherwise, another client might fail to
interoperate by selecting one of those parameters.
Paragraph (version B):
A client initiating a group MUST ignore all unrecognized
ciphersuites, extensions, and other parameters.  Otherwise, it may
fail to interoperate with newer clients.
Paragraph (version B):
A client adding a new member to a group MUST verify that the
ClientInitKey for the new member contains extensions that are
consistent with the group's extensions.  For each extension in the
GroupContext, the ClientInitKey MUST have an extension of the same
type, and the contents of the extension MUST be consistent with
the value of the extension in the GroupContext, according to the
semantics of the specific extension.
Paragraph (version B):
A client joining a group MUST populate the GroupContext extensions
with exactly the contents of the extensions field in the Welcome
message.  If any extension is unrecognized (i.e., not contained in
the corresponding ClientInitKey), then the client MUST reject the
Welcome message and not join the group.
Paragraph (version B):
Note that the latter two requirements mean that all MLS extensions
are mandatory, in the sense that an extension in use by the group
MUST be supported by all members of the group.
Paragraph (version B):
This document does not define any way for the parameters of the group
to change once it has been created; such a behavior could be
implemented as an extension.