[MLS] Follow-up and moving forward on Message Protection

[Benjamin Beurdouche <[e-mail]>]

Dear all,

Message Protection is one of the important parts of MLS that has currently been
left out of the specifications as we were focusing on the establishment of a group secret.

There are a few questions we now need to answer about message protection:

A. What does the Application Key Schedule look like. This the key point of attention as it will influence:
- Strength of the cryptographic security properties we typically get for secrets and messages: FS and PCS;
- Performance and complexity for communication/latency/storage;
- Difficulty to prove the cryptographic security properties we want with the tools that currently exist;
- Difficulty to implement securely.

B. Encryption algorithms and traffic analysis protection
I expect these aspects to be less controversial in the sense that there is nothing new here,
modern protocols use AEAD primitives such as AES-GCM and Chacha20Poly1305.
We also have to deal with nonce-reuse protection.

The idea of this email is not to debate the details now but to make progress on what is missing in the draft.
Overall, I believe that we need to move forward towards MLS being "feature complete",
which is an important step in our process.

---

I have been working on some initial text [0] for message protection, with input from Richard, Karthik and Ekr.
Assumptions in that text are, in my opinion, reasonably conservative and I believe it could be
merged as an initial text.

As I said at the IETF meeting, we believe multiple variants of the Application Key Schedule are possible:
1. a per-participant chaining of the Application Secret (hash forward the secret and derive new keys/nonce per App message)
2. a group chaining of the Application Secret (under the same epoch secret, each sender hash forward the current group Application Secret)
3. no chaining of the Application Secret (each sender update leaf to get a new Epoch Secret, Application Secret and AEAD keys for each message)
each having a different security/async properties.

The PR [0] suggest the use of the classical per-participant chaining with as it is a reasonably well-known
construct. I also didn’t recall any specific opposition to that scheme from the meeting.

The PR also proposes that padding the plaintext of Application messages SHOULD be done to at least
provide some minimal protection of the plaintext length against traffic analysis; one of the two
mandatory-to-implement AEAD constructions MUST be used.

Signatures are the way to authenticate a participant in the existing draft, and I didn’t change that as we can
revisit separately. The signature is included in the plaintext for privacy as there is an implicit weak group
membership property provided by the existing design: only legitimate members of the group can decrypt
the Application message (because only they can compute the current AEAD keys) and look at
the *optionally signed* Application message plaintext.

---

When we have a base design that is good enough, we can then start looking at formal security analysis
of the composition between the Group “Key" Establishment mechanism and the Message Protection
proposed mechanisms.

After speaking with many people offline, it feels like it would be a good solution to merge this PR as
a first step so that we can start working on sub-components separately.
*In no way I feel that the choices for this PR should be the definitive ones for MLS.*
I can make sure to adjust the PR if there are strong opinions on why we shouldn’t merge something.

What do people think and would the mailing list be ok with proceeding this way ? : )

Best,
Benjamin

[0] https://github.com/mlswg/mls-protocol/pull/54 <https://github.com/mlswg/mls-protocol/pull/54>