Draft: draft-ietf-mls-protocol

Commentary: Based on , it should be made explicit that sub - group branching requires a fresh key package for each member . I think there is still a conflict of wording here that I would like feedback on because of this line ( which is what triggered me thinking there was a bug ) 
 Thanks for the PR and thanks for digging into this . I think what the sentence is meant to say is that the receiver MUST check that the members of the new group are a subset of the members of the old group at that specific epoch . Since we 're using new LeafNodes in the new group and we do n't have a fixed notion of identity ( at least not within MLS ) , we have to refer to the application / the AS to ensure that the identity expressed by the credential in each LeafNode in the subgroup has a corresponding identity ( i.e. one that represents the same party ) expressed by a credential in a LeafNode in the original group . Maybe something like : This leaves the possibility of a collision , where the identifiers in a given leaf in the new group would be valid updates to more than one member in the old group . This should probably be forbidden in general , although outside of this case it 's not really a problem , because updates are always specific to one leaf . Alternatively , we could somehow include LeafNodeRefs that specifically indicate which member represents which other member . Or just leave it up to the application to sort this all out . 
 Curious what you think about saying the the credential has to be equal ? We can determine equality of the credential itself just by doing tls serialization . 
 Sure , requiring the credential to be exactly the same would be a simple way to figure out if it 's the same party in both groups . However , I can imagine that some applications will want distinct credentials for each group . If we mandate that credentials are the same , this would force the application to use the same credential in every key package / LeafNode . Since subgroups can potentially be branched at any time and in any group , all key packages that a party publishes then have to have the same credential as all of the groups that party is in , so another party branching a subgroup can get hold of a KeyPackage with the same credential as the group the subgroup is branched off of . Personally , I 'd prefer asking the application to check that the identities of the new group are a subset of the identities of the original group . 
 I can see that being an issue , although I am somewhat worried about us not being opinionated in same way about how to determine equality here , mainly because of interop type things . We punt on how to validate the credentials as well in general so I guess this is in line with prior decisions 
 Hey and check the change I just posted . and I put that together , it 's a bit tough to get a generic definition of equivalency . 
 There is currently a logical flaw in the subgroup branching flow . In order to branch , you need to compose a message . A Welcome message includes which is defined as follows : The problem with this is that the field of type can not be made for existing members of the group because the leaf nodes are now types . is now only used to add new members to the group , so we ca n't reuse this for sub group initialization . 
 I 'm not sure I understand correctly . Are you suggesting when branching a group off of another group , one re - uses the leaves of the old group ? If so , that 's not how it 's meant to work . The new group created in the process of subgroup branching should be independent from the " parent " group safe for the PSK , which all member have to provide upon creation of the group . In fact one should never use the same key material in the leaves of multiple groups except when the supply of key packages that a party provides via the DS is exhausted ( see Section 17.4 ) . 
 That was part of my question . When there were key packages in the leaves , you theoretically could fork the group from a given point in time and reuse the current tree , but I was n't sure if that was a proper solution or not . Sounds like it is n't , but either way , I think there should be clarification in the document about this . Let me write up a quick PR on it . 
 opened Would like your feedback there . We have conflicting wording here as well . What threw me off in the first place was the line indicating that LeafNodes should be the same in the sub - group , and if we are fetching new key packages they will not be the same . 
  , could you safely derive new keys for the members of the subgroup instead ? If so , that would be an enormous increase in efficiency and ( especially in the federated case ) make group creation timing consistent enough to do dynamically . 
 Nice idea ! But it 's tricky , since we 're dealing with public key pairs that the creator of the new group does n't know the private keys for . If we were only using HPKE schemes that support updateable public key encryption , the creator of the new group could indeed update the key in the existing group and send the " delta " encrypted to each corresponding member ( which would still represent an overhead , but we might be able to optimize this somehow ) . This is similar to the RTreeKEM mechanism that et al . proposed at some point . To go all the way here , we 'd have to do the same for the public key material in the credentials as well , which is not something we had considered before . It would be a new primitive , something like an updateable signature scheme ? Probably something to consider for HPKE / MLS 2.0 . We could also allow the re - use of LeadNodes for this particular case . It would be the simpler solution and I do n't think it would be catastrophic , since we have to assume that LeafNode ( or KeyPackage ) key material is re - used in the " last resort " scenario anyway , but this would definitely be something we should discuss on the mailing list , as it would break a pretty basic assumption we 've made until now . 
 Just catching up on this . nice catch here . It seems like we have two options here : new KeyPackages ( as in ) some way to make a new group based on LeafNodes alone I probably agree that we should do ( 1 ) in the short term , but ( 2 ) also has some appeal -- it does n't feel right to require new KeyPackages for folks you 're already in touch with -- despite it probably being more spec text . So here 's a sketch of ( 2 ) in the interest of completeness . Suppose we defined a message of the following form : ... which would pretty closely parallel to Commit . You would send it in MLSMessage and require a in MLSMessageAuth . Where Commit instructs the recipient to create a new epoch from the current one within the same group , Branch would instruct the recipient to create a new epoch that is the first epoch of a new group . In both cases , you would form an epoch / GroupContext as specified , then use the to ratchet into the new epoch . I 'm pretty sure that would work and have the expected security properties , though obviously formal analysis would be appreciated . The main awkardness that occurs to me is that any members joining after the branch would have to provide new key packages . And obviously , it would require a fair bit more spec text . All that said , though , the exercise of working all that out has increased my impression that we should do ( 1 ) for now . If we want something like ( 2 ) later , it can be done pretty cleanly in an extension . 
 Fixed by 
 Well put !
Paragraph (version A):
A new group can be formed from a subset of an existing group's
members, using the same parameters as the old group.  The creator of
the group indicates this situation by including a PreSharedKey of
type "resumption" with usage "branch" in the Welcome message that
creates the branched subgroup.
Paragraph (version B):
A new group can be formed from a subset of an existing group's
members, using the same parameters as the old group.
Paragraph (version B):
Determine a subset of existing members that should be a part of
the sub-group.
Paragraph (version B):
Create a new tree for the sub-group by fetching a new KeyPackage
for each existing member that should be included in the sub-group.
Paragraph (version B):
Create a Welcome message that includes a PreSharedKey of type
"resumption" with usage "branch".
Paragraph (version A):
Each LeafNode in the new group's tree MUST be a leaf in the old
group's tree at the epoch indicated in the PreSharedKey.
Paragraph (version B):
Each LeafNode in a new subgroup MUST match some LeafNode in the
original group.  In this context, a pair of LeafNodes is said to
"match" if the identifiers presented by their respective
credentials are considered equivalent by the application.