Draft: draft-ietf-mls-protocol

Commentary: r ? 
 Discussed at interim , remove resynch with a single op ( external join + remove in one op ) . research why resynch was dropped . 
 A good point was raised by Jonathon Hoyland during the MLS IETF 109 meeting regarding possible concerns in using external commits for resync , particularly in the case of  adding / removing herself .  noted that this is a feature in the case that  is no longer synchronized with the group and therefore can use an external commit to add herself back in , removing the previous version . As opposed to any newcomer joining with an external commit , the case of  re - joining presents a potential security issue . Namely , as currently specified ( in my reading of the draft ) , an existing group member ,  , has no means to distinguish between the following cases : 1 ) Alice needs to resync and therefore performs an external commit and removes her prior version . 2 )  ’s signature keys are compromised ( it is not necessary for the adversary to compromise any group state ) . The adversary performs an external commit in  ’s name , and then removes her prior version and impersonates her to the group . One might hope that  notices that she is removed and communicates this to the group members OOB , but it is also possible that that she assumes some other reason for the removal , is offline , or simply is not active enough to take action for a fairly long compromise window . Even if she tries to use an external commit to get back into the group and then removes the adversary - as - Alice , there is no means for other group members distinguish the real Alice from the adversary - as - Alice and the process could be circular ( until new valid identity keys are issued ) . While a newcomer is a fresh source to be trusted or not ,  has been “ healing ” along with the group and the above option ( 2 ) allows the adversary to bypass all of that . The source of the problem is that when     , she is not providing any validation of being the same / previous identity , so it is easy for other group members to accept that nothing more than a resync has taken place . Thus , a fairly straightforward solution is to require PSK use in cases where an external commit is used for resync . By enabling a PSK derived from a previous epoch during which  was part of the group to be injected with the external commit ,  provides some proof of prior group membership and we avoid the total reset . This is not quite PCS in that the attacker is active following compromise , but it is a linked case . As such it is important that a conscious decision is made regarding this ( either as a slight change before the feature - freeze in line with the other changes that the editors have proposed , or as a working group decision to close the issue as out - of - scope ) . 
 Just to think this with what has been discussed on the mailing list : will give members a way to do the distinction mentioned above . 
 - I do n't think that 's actually the case ; it would only allow the members a way to recognize that  is replacing herself . I think the right answer here is what  suggests , plus a little : We should enumerate a few specific constraints on the proposals that can be carried inline in an external Commit : There MUST be an Add proposal for the signer There MUST be an ExternalInit proposal There MUST NOT be any Update proposals If a Remove proposal is present , then : The identity of the removed node MUST be the same as the identity in the Add KeyPackage There MUST be a PSK proposal of type , referencing an earlier epoch of this group In other words , you can commit things that existing members sent ( by reference ) , but the joiner - initiated proposals must only ( a ) add the joiner , and ( b ) optionally remove the old instance of the joiner , with the PSK assurance suggests . 
 Coming back to this after a few weeks , I 'm actually not sure this is a problem worth solving . The attack scenario ( 2 ) exists whether or not a member can resync without proving prior membership . As long as ( a ) the group allows external Commits , and ( b ) the group does not require a new appearance of an existing identity to present a PSK from an earlier epoch , then the attacker can still do the attack by first joining , and then removing the old  . The only difference in the case where the external commit also does the resync is that the two happen together . It also does n't seem unreasonable to regard the ability to resync from loss of all state except the signature key as a feature , not a bug . Of course , that position would entail accepting that compromise of signature keys would be sufficient to impersonate the user , but that does n't seem all that surprising , at least to me . So this seems like a question of group policy to me . Either the group requires ReInit PSKs on resync ( and you ca n't recover from all - but - signature - key state loss ) , or it does n't ( and signature keys are the last resort ) . This can be documented in the Security Considerations , in a new PR . As far as , I think it 's probably still worth adding the precision , but I would change the PSK part to MAY if not remove it entirely . 
 There is also a practical issue with using PSKs to prove past membership , in that if there have been joins since  lost state , the new joiners wo n't have the PSK . This is of course a general issue with the proof - of - past - membership PSK , but it is particularly salient here .
Paragraph (version B):
If a Remove proposal is present, then the "credential" and
"endpoint_id" of the removed leaf MUST be the same as the
corresponding values in the Add KeyPackage.
Paragraph (version A):
An external commit MUST reference no more than one ExternalInit
proposal, and the ExternalInit proposal MUST be supplied by value,
not by reference.  When processing a Commit, both existing and new
members MUST use the external init secret as described in
external-initialization.
Paragraph (version B):
When processing a Commit, both existing and new members MUST use
the external init secret as described in external-initialization.
Paragraph (version B):
In other words, External Commits come in two "flavors" - a "join"
commit that adds the sender to the group or a "resync" commit that
replaces a member's prior appearance with a new one.
Paragraph (version B):
Note that the "resync" operation allows an attacker that has
compromised a member's signature private key to introduce themselves
into the group and remove the prior, legitimate member in a single
Commit.  Without resync, this can still be done, but requires two
operations, the external Commit to join and a second Commit to remove
the old appearance.  Applications for whom this distinction is
salient can choose to disallow external commits that contain a
Remove, or to allow such resync commits only if they contain a
"reinit" PSK proposal that demonstrates the joining member's presence
in a prior epoch of the group.  With the latter approach, the attacke
would need to compromise the PSK as well as the signing key, but the
application will need to ensure that continuing, non-resync'ing
members have the required PSK.
Paragraph (version B):
The signature keys held by group members are critical to the security
of MLS against active attacks.  If a member's signature key is
compromised, then an attacker can create KeyPackages impersonating
the member; depending on the application, this can then allow the
attacker to join the group with the compromised member's identity.
For example, if a group has enabled external parties to join via
external commits, then an attacker that has compromised a member's
signature key could use an external commit to insert themselves into
the group - even using a "resync"-style external commit to replace
the compromised member in the group.
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 to have the
required PSKs.