Re: [MLS] [Delivery Service]

[Pascal Junod <[e-mail]>]

Sure, it helps, thank you Benjamin !

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

> 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=[e-mail]> 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.
>
> How is it possible to solve this apparent contradiction ?
>
>
> 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.
>