Thank you Valery,
FYI: The MLS extensions document has the SelfRemove proposal (https://www.ietf.org/archive/id/draft-ietf-mls-extensions-04.html#name-selfremove-proposal), which is a minor improvement on the current behavior since pending SelfRemove proposals are valid in an External Commit. As Benjamin noted, MLS still requires someone who remains in the group to update the cryptographic state. It is also forbidden to send an application message while there are pending proposals. This means it is unlikely a removed client will continue to get messages (which it can decrypt) after it tries to leave.
Cheers,
-rohan
On Mon, Aug 19, 2024, 06:02 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.
_______________________________________________
MLS mailing list -- mls@xxxxxxxx
To unsubscribe send an email to mls-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
