Hi Benjamin, > Hi Valery, > > Thanks for the review ! > Just a quick note about the inability of a client to remove itself from a group… > > This is expected from the protocol security point of view. As a client you can always > delete your own state, however to ensure to everyone else that you don’t > maliciously retain some secrets, someone honest other than you has to change > those secrets. > > This is why to perform a self remove, a client will have to send a remove proposal > that will be acted upon by someone else… : ) I see. But wearing my ARTART reviewer hat I had to complain about this (I would not have any issues with this if I wore SECDIR reviewer hat) :-) Actually, the issue is not related to the ability of the client to receive messages. As a client you can always delete your own state or just block incoming messages, but you still will be listed as a member of the group for external parties. This is my problem (as ARTART reviewer :-)). Consider the situation when the group constitutes the members of some sect and the user joined it by mistake. Unless other members of the group cooperate (which is unlikely in case of sect) the user is unable to leave the group and will be considered as a member of this sect for external parties even if he/she is in fact not. "You can check out any time But you can never leave" https://youtu.be/09839DpTctU?si=wIDsj6LJRBc_SGCZ Regards, Valery. > Cheers, > Benjamin > > > > On 19 Aug 2024, at 14:59, Valery Smyslov via Datatracker <noreply@xxxxxxxx> > wrote: > > > > Reviewer: Valery Smyslov > > Review result: Ready > > > > I am the assigned ART directorate reviewer for this document. These > > comments were written primarily for the benefit of the ART area > > directors. Document editors and WG chairs should treat these comments > > just like any other last call comments. > > > > I previously reviewed the -09, -10 and -13 versions of the draft and > > now reviewed the diff between the -13 and the -15 versions. The added > > text about the ability to reinitialize the group changing the protocol version and/or > ciphersuite addresses my concerns. > > > > The issue of inability for a client to remove itself from the group by > > its own seems unsolvable in the MLS architecture. While I think this > > issue is important, I'd leave it on ADs' discretion. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
