[MLS] High-level Questions and Clarifications

[Michael Rosenberg <[e-mail]>]

Hey all, I'm just getting involved with MLS and everyone has been super helpful with onboarding and reviewing stuff, and I'm really grateful for it. I've been trying to do a close reading of protocol spec and these are the last of the questions that didn't fall under a previous PR or Github issue. Some of these questions, if nontrivial, might be better if split out into threads of their own. And of course, feel free to answer whichever subset of these questions you wish. Also, I hope to use what I do understand so far to begin building out a new Rust implementation of the protocol soon.

The following page numbers are from the PDF version of protocol draft #3.

Page 8
======
The sample exchange depicted here shows Add being sent before Welcome. But section 7.2 seems to indicate that Welcome messages have to come first. Does the order matter? I though it did, since Welcome messages are necessary to set the new participant up with the current GroupState so everyone's on the same page after the subsequent Add.

Pages 11,15
===========
The wording "A Diffie-Hellman finite-field group or elliptic curve" that appears twice feels awkward (specifically, I think it should say "finite-field multiplicative group") but more importantly, it's unclear if implementations MUST, SHOULD or, MAY use these mathematical objects for DHE. Further, [clicks in chinstrap on tinfoil hat] could this reasonably be loosened to allow for ciphersuites with quantum-resistant DH-like algorithms such as SIDH?

Page 12
=======
This may not be a well-founded concern, but it might be desirable that the Hash that's used iteratively to derive node secrets on the ratchet tree be keyed (or salted) with tree-specific information. One could imagine if participant D had poor enough entropy and an attacker had done a good amount of precomputation of Hash, the attacker could derive D from Hash(D). Then the attacker could go and do the same thing in another group with another participant with poor entropy without having to do any more precomputation.

Page 20
=======
Which AEAD and DH algorithms are supposed to be used for sending a node's secret to a leaf in the resolution of the copath? Suppose A and B are siblings and that they have different ciphersuite preferences. How does B compute the shared secret AB in order to encrypt new entropy for A?

Another related general question: There are cases when only a single party fails an operation, and it's not immediately clear what the procedure is to handle these. For example, a DirectPath in an Update operation could be filled with all correct ECIESCiphertexts except one, whose contents is random garbage. Then only a Participant with knowledge of the corresponding node secret would be able to tell that there was an invalid ciphertext in the bunch. The rest would be unable to see this, and furthermore, it's unclear how the affected Participant would even prove that it was invalid without having to reveal the node secret to the rest of the Group. How should the protocol handle this?

Page 21
=======
Derive-Secret is a function of HkdfLabel, which in turn contains a GroupState. But the serialization format of the GroupState is not specified anywhere. Am I missing something? This probably should not be implementation-defined, since it is fundamental to agreeing on internal state.

Page 26
=======
Why is cipher_suite in Welcome? Each init key corresponds to a unique cipher suite, so the sender and recipient already know the cipher suite they need to use.

Page 27
=======
What happens when you get two Welcomes? Could you arbitrarily send a Welcome to a person and DoS them from the group by forcing them to update their state to something wrong?

Page 35
=======
How exactly are the message signatures calculated? Does it mean the 16-byte tag at the end of the AES-GCM ciphertext? How does this generalize for AEADs with non-detachable signatures like AES-CCM (which is a mac-then-encrypt construction)?