Draft: draft-ietf-mls-protocol

Commentary: Clarify what client should do when receiving a Commit removing itself update Remove example to show removed client receiving the Commit fix typos in Security Considerations 
 While implementing removals , I came to the conclusion that clients would Currently in the MLS Protocol , when a Commit containing a   is sent to a group , the specification does not provide enough implementation guidance to insure that the removed member is notified of its removal . I can think of three ways a member can determine it has been removed : the DS to forward the Commit message containing the removal to all removed members . an out - of - band protocol convey this information a new MLS message type ( ex : Goodbye ) specifically to convey removal . Forwarding the Commit message would require only one new normative statement in the MLS protocol document , some similar additional text in the MLS architecture document , and a minor change to the remove example flow diagram in the MLS protocol document . This would be a straightforward clarification . The disadvantage is that forwarding the commit to a removed member can leak other membership changes ( ex : the credentials of newly members , and the potential knowledge of which other members were removed at the same time ) . Requiring an out - of - band protocol to convey removal information , while possible , leaves a privacy sensitive decision out of scope , while the analogous action is a first - class part of the MLS protocol ( Welcomes ) . Using a new message type ( ex : Goodbye ) requires new specification work , but allows a message analogous to a Welcome which can inform clients individually they were removed without leaking potentially sensitive information about the new membership of the group they just departed . Note that the architecture document could require that the DS either implement 1 or 2 , but leaving too many choices makes interoperability more complicated . 
 The Commit is the goodbye message . Clients are able to parse it and conclude that they have been removed . I thought that 1 . was always implied , what makes you think otherwise ? 
 I assumed this as well , but it is only implied in the spec , and the example flow showing a remove does n't have an arrow going to the removed client ( which would clearly be wrong if it is required ) . ( For good or bad , a lot of implementers code from examples and then go back and check their assumptions in the body of a spec . That is why it is so important to get examples correct . ) If we decide that it 's an implementation choice ( and say that it is also ok to do it out of band for example ) then we need to explain that in the architecture document . So , we can 1 ) Decide that a client MUST always get the Commit removing them ; make that explicit in the protocol ; fix the example ; explain the privacy leak in the Security Considerations ; possibly summarize this in the architecture document . 2 ) Say that a client MUST be informed about their removal in the protocol spec and leave how to convey removals as one of these policy choices for the DS ( you could even make sending the Commit a SHOULD ) ; explain more extensively in the architecture document . 3 ) Address the privacy issue directly by making an explicit Goodbye message . 
 You introduce the notion of a ' privacy leak ' and a ' privacy issue ' in your last message , what exactly are you referring to ? I think 1 . is currently implied and examples should be adjusted if they do n't reflect that . 
 I think the privacy issue is concerned about is something like : If other changes are made in the same Commit that removes a participant , then the removed participant can see those changes . For example , the identities of people to the group in that commit . It 's not totally clear to me what the security objective here is . It seems like the point of informing a member they have been removed via a group message ( Commit or Goodbye ) would be to prevent the DS from lying to the member about whether they have been removed -- telling them they 'd been removed when they had n't , or vice versa . This honestly is n't something I 'm all that worried about , because ( a ) none of this affects the security of those who remain in the group , and ( b ) even if you had a message , the DS could suppress it ( and thus lie in at least one direction ) . The best argument that occurs to me is that being removed might ( might ! ) trigger deletion of old keys , thus providing better FS for any outstanding messages in prior epochs in the event the removed member was compromised . ( This is unlike the add situation , where we need a protocol message to provide the new joiner with the cryptographic material they need to participate in the group . That can not be delegated to the DS . ) If we had an explicit Goodbye message , we would have a malicious insider risk , in that a group member could generate a Goodbye for someone that was not actually removed . Net of all that , I think something like Rohan 's option ( 2 ) would be my preference . Mostly punt it to OOB , but note that the Commit COULD be used . 
 I suspect as much . I 'd say that this is only a potential privacy issue because the committer can simply avoid it by issuing two commits . The leaked information about other proposals is also not necessarily sensitive . That being said , I think it would be worth mentioning this in the architecture doc . I think either ( 1 ) or ( 2 ) . would work , where ( 2 ) has the benefit of more flexibility . ( 3 ) would indeed be problematic for the reasons you mention . 
 It sounds like there is weak consensus that a client should be informed either by a Commit or out - of - band . I submitted PR which shows a Commit going to the removed user in the example flow , and provides some guidance to a client about processing a Commit that removes itself . I 'll submit a separate PR for the architecture spec that adds this to the list of things you need for a concrete DS / client implementation . 
 Resolved with
Paragraph (version A):
Group secrets are partly derived from the output of a ratchet tree.
Ratchet trees work by assigning each member of the group to a leaf in
the tree and maintaining the following property: the private key of a
node in the tree is known only to members of the group that are
assigned a leaf in the node's subtree.  This is called the _ratchet
tree invariant_ and it makes it possible to encrypt to all group
members except one, with a number of ciphertexts that's logarithmic
in the number of group members.
Paragraph (version B):
Group secrets are partly derived from the output of a ratchet tree.
Ratchet trees work by assigning each member of the group to a leaf in
the tree and maintaining the following property: the private key of a
node in the tree is known only to members of the group that are
assigned a leaf in the node's subtree.  This is called the _ratchet
tree invariant_ and it makes it possible to encrypt to all group
members except one, with a number of ciphertexts that is logarithmic
in the number of group members.
Paragraph (version A):
Applications can mitigate the risks of signature key compromise using
pre-shared keys.  If a group requires joiners to know a PSK in
addition to authenticating with a credential, then in order to mount
an impersonation attack, the attacker would need to compromise the
relevant PSK as well as the victim's signature key.  The cost of this
mitigation is that the application needs some external arrangement
that ensures that the legitimate members of the group to have the
required PSKs.
Paragraph (version B):
Applications can mitigate the risks of signature key compromise using
pre-shared keys.  If a group requires joiners to know a PSK in
addition to authenticating with a credential, then in order to mount
an impersonation attack, the attacker would need to compromise the
relevant PSK as well as the victim's signature key.  The cost of this
mitigation is that the application needs some external arrangement
that ensures that the legitimate members of the group have the
required PSKs.