Re: [MLS] Possible erratum: Re-adding a member

[Raphael Robert <[e-mail]>]

I would also interpret 7.3 in the same way as Richard and Marta. The intermediary group membership state while applying proposals should not be relevant, since applying proposals is fundamentally an atomic operation from the perspective of clients/applications. 
I don’t really see the need for an erratum to clarify that such a Commit is indeed valid. If however the consensus turns out to be that the Commit is invalid, we would need an erratum.

Raphael

> On 8. Sep 2023, at 19:05, Richard Barnes <[e-mail]> wrote:
> 
> This isn't about removing your own node, it's about replacing someone else.  For example:
> 
> - Alice is in a group with Bob (and possibly others)
> - Alice's device loses its state, except for signature key + credential
> - Alice sends Bob a request to re-join with a KeyPackage, that has the same signature key + credential, but is otherwise fresh
> - Bob recognizes that these are both Alice, issues a Commit that removes old-Alice and adds new-Alice
> 
> 
> On Fri, Sep 8, 2023 at 12:28 PM Rohan Mahy <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi Richard,
>> I see a use case for this in the External Commit case. This brings up that maybe we need a clarification that a member can send an External Commit to replace itself (because it has lost its state).
>> 
>> In the case of a regular commit, what is the use case? Surely an UpdatePath would accomplish every possible use case of an in-group Add and Remove. By my read, any Commit containing a Remove of your own leaf node is currently prohibited.  
>> 
>> Thanks,
>> -rohan
>> 
>> Rohan Mahy  l  Vice President Engineering, Architecture
>> 
>> Chat: @rohan_wire on Wire
>> 
>>  
>> 
>> Wire <https://wire.com/en/download/> - Secure team messaging.
>> 
>> Zeta Project Germany GmbH  l  Rosenthaler Straße 40,  <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>10178 Berlin,  <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>Germany <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>
>> 
>> Geschäftsführer/Managing Director: Christian Salza
>> 
>> 
>> HRB 149847 beim Handelsregister Charlottenburg, Berlin
>> 
>> VAT-ID DE288748675
>> 
>> 
>> 
>> On Fri, Sep 8, 2023 at 8:23 AM Richard Barnes <[e-mail] <mailto:[e-mail]>> wrote:
>>> Hi all,
>>> 
>>> I came across a situation where I think the spec might be ambiguous, if not incorrect.  Consider a situation where a member is removed and re-added in the same Commit, using the same signature key for both the old and the new member, but fresh keys otherwise.  Is this a legal commit?
>>> 
>>> (Note that in addition to normal commits of this form, the "resync" external commits that the spec mentions also have this form.)
>>> 
>>> On the one hand: The spec says that a proposal list is invalid if...
>>> - [12.2] It contains an individual proposal that is invalid as specified in Section 12.1 <https://www.rfc-editor.org/rfc/rfc9420.html#proposals>.
>>> - [12.1.1] An Add proposal is invalid if the KeyPackage is invalid according to Section 10.1 <https://www.rfc-editor.org/rfc/rfc9420.html#keypackage-validation>
>>> - [10.1] Verify that the leaf_node of the KeyPackage is valid for a KeyPackage according to Section 7.3 <https://www.rfc-editor.org/rfc/rfc9420.html#leaf-node-validation>.
>>> - [7.3] Verify that the following fields are unique among the members of the group: signature_key 
>>> 
>>> On the other hand: The spec also says (emphasis mine):
>>> - [12.2] It contains an Add proposal with a KeyPackage that represents a client already in the group according to the application, unless there is a Remove proposal in the list removing the matching client from the group.
>>> 
>>> So if you read "members of the group" in the former text as "members of the group before any of the proposals are applied", then my proposed Commit is illegal.  If you read it as "members of the group after any Remove proposals are applied" (as in the latter text), then the proposed Commit is fine.
>>> 
>>> Personally, I think the right answer here is for such a Commit to be valid.  Basically because I don't think a "resync" operation (either externally-driven or within the group) should force a signature key rotation, because signature key rotation is expensive when signature keys are tied to things like transparency or certificates.
>>> 
>>> If we can get agreement on the outcome here, it seems like we should probably file an erratum clarifying the situation.
>>> 
>>> Thanks,
>>> --Richard
>>> _______________________________________________
>>> MLS mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/mls
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls