Re: [MLS] Key Schedule, ProposalOrRef objects, Group splitting attack

Here’s a partial answer:

> On 8. Jun 2021, at 11:16, Tijana Klimovic <tijana.klimovic97@gmail.com> wrote:
> 
> Hello,
> 
> I had a few questions about different parts of the specification.
> 
> Firstly, I wanted to ask about the motivation behind the Key Schedule being what it is, namely a sequence alternating between KDF.Extract and KDF.Expand. Why couldn't it be just a single KDF.Extract followed by a single KDF.Expand, to form an actual key derivation function, and then derive the different keys by providing the appropriate context? 
> 
> Furthermore I am not sure why the KDF.Expand is used at all here since the length parameter provided is KDF.Nh which from the specification is supposed to be: "The value KDF.Nh is the size of an output from KDF.Extract, in bytes". Therefore, the KDF Expands used by the scheme don't really expand the pseudorandom key given by the KDF.Extract to have a bigger length.

I’ll let someone else comment on the above.

> 
> I am not sure why we use a ProposalOrRef type. And why only proposals sent by the commiter are included by value and all others are hashes of the MLSPlaintext containing proposals sent by members different from the commiter. 

Proposals are handshake messages in their own right and are distributed between members within an epoch. At the end of an epoch someone sends a Commit that references the proposals with a commit hash. 
To make things easier for members who immediately want to commit to a proposal, inline proposals are also supported so that members can do all of it in one message. That’s all there is to it.

In earlier versions of MLS, handshake messages were always committing. Introducing the proposal-commit scheme brought some more flexibility in general. Now there can be proposals from externals as well, or you can propose to remove yourself from the group (which impossible before, someone else had to remove you).

> 
> Lastly, I haven't managed to find where the specification tackles the problem of the group splitting attack. Namely, if we for example have a group of 5 clients, the attacker can split the group state into two group states, by making sure that any message (proposal, commit, application) originating from client 1,2,3 is delivered to only client 1,2,3 only and that similarily any message originating from clients 4,5 are only delivered to clients 4,5. 

If the Delivery Service decides to route messages this way, there is not much you can do about it as a client. The AppAck extension helps to detect some of the dropped messages, but at the end of the day you have to trust the DS to not do a DoS attack on clients. The protocol cannot fix that problem.
Of course you could try to mitigate this out-of-band, for example you could have a mechanism where members can regularly compare the authentication secrets or some other value exported from the exporter.

Raphael

> 
> Many thanks.
> Tijana Klimovic
> 
> 
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls