Subject: [MLS] Message Order

From: "Andrikopoulos Konstantinos" <[email-masked]>
Date: Thu, 12 Dec 2019 20:01:29 +0000

Hello,

I am a computer science master's student, focusing on cryptography and security. As a part of a small research project, supervised by Kenneth Paterson, I am looking into the MLS protocol. In particular, we have been paying attention the message reordering problems that are mentioned in the current draft of the protocol.

The purpose I am writing this email is that, before we continue further with the project, we would like to see if you have already decided on the direction that you would like the solution to follow. Would you be able to point us to any texts that you may have compiled or past discussions on the subject?

Thank you,

Konstantinos

---

From: Richard Barnes <[email-masked]>
Date: Mon, 16 Dec 2019 14:32:19 -0500

Hi Konstantinos,

Thanks for reaching out.  I think the current thinking is described in the
"Sequencing of State Changes" section of the current document [1].  (It
probably needs a rewrite, thought, to use more current terminology.)  In
brief:

* The protocol allows each state/epoch to have a single successor [2],
* So the members of the group need to agree on which Commit message causes
this epoch change.
* In some deployment cases, a straightforward way to achieve such agreement
is to ensure that all members receive Commits in the same order, so they
can just take the first one
* You could also envision applying other techniques to agree on which
Commit is applied, e.g., running a consensus protocol
* These requirements apply only to Commits; Proposals and application
messages are uncontentious, and can be arbitrarily reordered in any case

The requirement for strict ordering of states is something the group has
accepted for a while, since in the primary use case, with a centralized
Delivery Service, it seems reasonably achievable.  However, it is
problematic for more decentralized cases, Matrix [3] being the
most-discussed example.  To make those scenarios work better, you would
need (a) non-linear epoch IDs so that you could tolerate forks in the state
history, and (b) a "merge" algorithm so that you could coalesce two forks.
Both of those are areas where some additional thinking could be helpful.

Hope that helps!
--Richard

[1]
https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#sequencing-of-state-changes-sequencing
[2] ... because epochs are identified with a counter, cf.
https://github.com/mlswg/mls-protocol/pull/245
[3] https://matrix.org

On Mon, Dec 16, 2019 at 1:46 PM Andrikopoulos Konstantinos <
[email-masked]> wrote:

> Hello,
>
>
> I am a computer science master's student, focusing on cryptography and
> security. As a part of a small research project, supervised by Kenneth
> Paterson, I am looking into the MLS protocol. In particular, we have been
> paying attention the message reordering problems that are mentioned in the
> current draft of the protocol.
>
>
> The purpose I am writing this email is that, before we continue further
> with the project, we would like to see if you have already decided on the
> direction that you would like the solution to follow. Would you be able to
> point us to any texts that you may have compiled or past discussions on the
> subject?
>
>
> Thank you,
>
> Konstantinos
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>