Draft: draft-ietf-mls-protocol

Commentary: Depends on 
 Here 's the Weekly Digest for : - - Last week 9 issues were created . Of these , 6 issues have been closed and 3 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : heart : , by : heart : , by : heart : , by : heart : , by : heart : , by : heart : , by : speaker : , by It received 2 comments . - - Last week , 13 pull requests were created , updated or merged . Last week , 3 pull requests were updated . : yellowheart : , by : yellowheart : , by : yellowheart : , by Last week , 10 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 38 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 2 contributors . : bustinsilhouette : : bustin_silhouette : - - 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 . * 
 Long - term inactive users undermine the FS and PCS properties of the protocol . Obviously , users can remove each other if they notice that a participant is inactive . We should consider whether we want to allow the server to do such a removal . 
 Discussion at interim 2019 - 01 : Could do this as " server - instructed " vs. " server done " i.e. , server instructs a client to do a remove But this causes some ambiguity w.r.t . the rest of the group The only difference between  and a server - initiated variant would be signature Other use cases : User deletes account User is no longer authorized to be in group Application would need to set policy about whether / when server - initiated actions would be allowed 
 I 'm assigning this to  under the theory that the signature changes that will come about as a result of will make it straightforward to have an additional key for the server that can be used to sign Adds / Removes . If that does n't turn out to be the case , this might get deferred . 
 After discussion with and There will be a need to signal that a non - member key is being used , e.g. , with some reserved values Do the participants in the group need to agree the set of allowed non - member signers ? If some members accept a signer , others do n't , then you can get partition  will focus on Remove , not Add , and punt on the agreement question ; we assume the application maintains consistency of the view of authorized signers . 
 We should push some of this to the application layer in order to not introduce a new handshake message with problematic authenticity ( agreement on the list of non - members who can sign handshake messages ) . The server could publish an " intent to remove " that will be honored by the first client to come online . The actual Remove HS message will be issued by a member of the group . It can additionally be attached to the server intent to remove , so that clients can convey more contextual information to users . Example : Server issues the intent to remove  from the group .  comes online first after that and send a regular Remove HS message to remove  and links it to the sever intent . Other members of the group can now display "  was removed " instead of "  removed  " to the user . In this example  is the first member to come online , but it could really be any other member . This has the advantage that the protocol remains unaffected as such , while the desired behavior is still achieved . 
 Currently , in order for a new member to join a group , an existing member needs to add them to the group . Certain use cases work more naturally if a new joiner can initiate the add process . I think that broadly speaking we want a process here where someone outside the group can ( 1 ) request to be and ( 2 ) send to the group , but can not receive from the group until . Some things to consider here : Anything that is revealed to a joiner that joins this way is effectively public . Should they be able to see , e.g. , the roster ? How should these interactions relate to the key schedule ? Assuming there 's some message , should it be included into the transcript at Add time ? What happens if there are multiple parallel requests ? 
 At the 2019 - 01 interim , we discussed a " reversed Add " flow , where : Group publishes an InitKey The new joiner sends a UIK to the group and establishes a shared secret with the group This initiates a period where the new joiner can send , but nobody in the group can Before anyone in the group can send , they have to send a Welcome for the new joiner ... which initiates an epoch where they are fully joined 
 In certain use cases , such as enterprise messaging there may / could / might be a problem if " Any member of the group can download an ClientInitKey for a new client and broadcast an Add message " . An enterprise may wish to enforce access restrictions for certain information such as ClientInitKey . Just thinking about security related issues that may be most easily noticed by corp IT types . On the other hand this may be best dealt with outside the protocol scope . 
 I think this is fixed by correct ? A user can propose to Add herself . 
 Partly addressed by . To complete the story , we need a " send - to - group - from - outside " mechanism . Leaving this open until we have that . 
 I do n't think a " send - to - group - from - outside " mechanism will be possible , given that we try quite hard to prevent any key material from inside the group from ever being published . 
 The signing key of external actors will be contained in the leaf in the case it is a CIK .
Paragraph (version B):
Add and Remove proposals can be constructed and sent to the group by
a party that is outside the group.  For example, a Delivery Service
might propose to remove a member of a group has been inactive for a
long time, or propose adding a newly-hired staff member to a group
representing a real-world team.  Proposals originating outside the
group are identified by having a "sender" value in the range
0xFFFFFF00 - 0xFFFFFFFF.
Paragraph (version B):
The specific value 0xFFFFFFFF is reserved for clients proposing that
they themselves be added.  Proposals with types other than Add MUST
NOT be sent with this sender index.  In such cases, the MLSPlaintext
MUST be signed with the private key corresponding to the
ClientInitKey in the Add message.  Recipients MUST verify that the
MLSPlaintext carrying the Proposal message is validly signed with
this key.
Paragraph (version B):
The remaining values 0xFFFFFF00 - 0xFFFFFFFE are reserved for signer
that are pre-provisioned to the clients within a group.  If proposals
with these sender IDs are to be accepted within a group, the members
of the group MUST be provisioned by the application with a mapping
between sender indices in this range and authorized signing keys.  To
ensure consistent handling of external proposals, the application
MUST ensure that the members of a group have the same mapping and
apply the same policies to external proposals.
Paragraph (version B):
An external proposal MUST be sent as an MLSPlaintext object, since
the sender will not have the keys necessary to construct an
MLSCiphertext object.