Re: [MLS] Two question regarding use of “reinit” in the RFC

[Brendan McMillion <[e-mail]>]

Hi Vera
>
> Hence my question: Does the “reinit” PSK proposal actually refer to a
> *reinit* PSK or would an *application* PSK be more appropriate for the
> described mechanism?
>
Yes, I believe a resumption PSK with usage=application would be the
appropriate thing to use here. Calling it reinit is maybe a misstatement in
the RFC.

> This sentence also refers to members stuck in an old epoch. If these
> members propose a reinitialization in the old group, the members that have
> already advance to other epochs should equally not be able to process such
> a reinitialization.
>
Practically speaking, I think ReInit proposals are solely for handling
changes to the protocol version / ciphersuite, not fragmentation. This
section (16.12) was maybe written referring to some application-level
mechanism for starting a group over.

On Fri, Feb 23, 2024 at 1:40 AM Vera Wesselkamp <[e-mail]>
wrote:

> Hello,
>
> I have two instances in the RFC where I struggle to understand whether the
> word reinit/reinitialization refers to the reinitialization operation
> defined in section 11.2.
>
> The first is the following use in Section 12.4.3.2:
>
> *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.*
>
> I read this as a resumption PSK of type *resumption* and of usage *reinit*
> as specified in section 7. However that is direct contradiction to the
> following sentence:
>
> *A PreSharedKey proposal with type resumption and usage reinit MUST BE be
> considered invalid.*
>
> Hence my question: Does the “reinit” PSK proposal actually refer to a
> *reinit* PSK or would an *application* PSK be more appropriate for the
> described mechanism?
>
> The second question refers to two appearances of the term in section 16.12
> of the RFC and concerns group splitting:
>
> *Applications provide mechanisms for failed commits to be reported, so
> that group members who were not able to recognize the error themselves can
> reinitialize the group if necessary.*
>
> I do not understand how to use the reinitialization operation defined in
> the RFC in this context. My understanding is that the paragraph describes a
> situation in which some members processed a commit correctly, but a few
> members members cannot and are hence stuck in an older epoch.
> Reinitialization would send an reinit proposal to the current epoch of the
> group for the members that could process the commit. I believe that the
> “stuck” members, however, would not be able to parse the reinit proposal
> and following commit, and can hence not process the reinitialization.
>
> Similarly a few paragraphs later:
>
> *These members will need to either add themselves back with an external
> Commit or reinitialize the group from scratch.*
>
> This sentence also refers to members stuck in an old epoch. If these
> members propose a reinitialization in the old group, the members that have
> already advance to other epochs should equally not be able to process such
> a reinitialization.
>
> I also described a similar situation for a paragraph in the architecture
> file in this issue <https://github.com/mlswg/mls-architecture/issues/234>
> before.
>
> My question is if the use of reinitialization in this sentence refers to
> the operation defined in section 11.2, or just another mechanism, i.e.
> re-joining the group at the “stuck” epoch using external commits. If it
> does refer to the operation, how could the process of reinitializing look
> like and how does it resolve the split group?
>
> Thanks for your help!
>
> Vera
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>