Subject: [MLS] [Delivery Service]

From: Pascal Junod <[email-masked]>
Date: Thu, 21 Nov 2019 17:51:18 +0100

Hi !

In the architecture document, one expects the Delivery Service "*to route
messages between clients and to act as a message broadcaster, taking in one
message and forwarding it to multiple clients (also known as “server side
fanout”).*" (cf. §2.3)

At the same time, a bit further, one can read that "*Group membership is
itself sensitive information and MLS is designed so that neither the DS nor
the AS need have static knowledge of which clients are in which group.*"

In particular, the ClientInitKey and Welcome messages do not have any
notion about group or node identities, they only have the client_init_key_id
field in common, which means that the DS has no means (through the current
protocol format) to route messages in a proper way.

How is it possible to solve this apparent contradiction ?

Many thanks in advance,

Pascal

---

From: Benjamin Beurdouche <[email-masked]>
Date: Thu, 21 Nov 2019 19:34:02 +0100

Hi Pascal !

Let me try to explain as best as I can the intended meaning and some of the MLS goals...

> On Nov 21, 2019, at 5:51 PM, Pascal Junod <pascalj=[email-masked]> wrote:
> 
> Hi !
> 
> In the architecture document, one expects the Delivery Service "to route messages between clients and to act as a message broadcaster, taking in one message and forwarding it to multiple clients (also known as “server side fanout”).." (cf. §2.3)
> 
> At the same time, a bit further, one can read that "Group membership is itself sensitive information and MLS is designed so that neither the DS nor the AS need have static knowledge of which clients are in which group."
> 
> In particular, the ClientInitKey and Welcome messages do not have any notion about group or node identities, they only have the client_init_key_id field in common, which means that the DS has no means (through the current protocol format) to route messages in a proper way. 
> 

The CIK cannot have a notion of group obviously, but the encrypted GroupInfo of the Welcome message
does contain the GroupID, so on receipt, as a newcomer, you know for which group this new state is.

Now, from the architecture perspective…
In terms of privacy, one of the good scenarios in modern architectures is a DS which does not locally maintain
(“has static knowledge”) the group memberships… In that case, either:
1. the protocol has to expose the receipient(s) in the message and the DS can just look at the message itself
2. the application adds metadata containing a list of recipients which allows the DS to store a copy
of the message in the correct storage location, notify the users and then can “forget” who the recipients where.

There are many alternatives which are left to the provider regarding privacy but MLS is trying to
allow case 2. for providers that want to achieve it. We definitely have more work to do on that side,
especially because of the GID itself, but inherently Privacy will rely on the honesty of the AS and DS,
while Confidentiality and Authentication can rely only on the AS only.

Hope that helps... : )
B.

---

From: Pascal Junod <[email-masked]>
Date: Fri, 22 Nov 2019 14:55:10 +0100

Sure, it helps, thank you Benjamin !

On Thu, Nov 21, 2019 at 7:34 PM Benjamin Beurdouche <
[email-masked]> wrote:

> On Nov 21, 2019, at 5:51 PM, Pascal Junod <
> pascalj=[email-masked]> wrote:
>
> Hi !
>
> fanout”)..*" (cf. §2.3)
> notion about group or node identities, they only have the
> client_init_key_id field in common, which means that the DS has no means
> (through the current protocol format) to route messages in a proper way.
>