Re: [MLS] [Delivery Service]

Pascal Junod <> Fri, 22 November 2019 13:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E347C120147 for <>; Fri, 22 Nov 2019 05:55:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 089lWCyQhmTI for <>; Fri, 22 Nov 2019 05:55:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D1A951200B9 for <>; Fri, 22 Nov 2019 05:55:21 -0800 (PST)
Received: by with SMTP id x21so8095414ior.2 for <>; Fri, 22 Nov 2019 05:55:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XHkEFCaUYNnk+ZHESNo0HOFzw+vZ87KUoF/zQzCp/Lg=; b=MiocPm3OUwrbHF56KIgvH+oH5SGIlj8AFDO3S6SnDrZd4Dy+BcMWCsUbFBW4KujvvN UZcibeRg8oplcPqShJwG/W0xOOe4b6Y8aW9qMGnFBq58rsNlbvjrOUmwQKOt59tZckZZ CHD3UEiLtTuDcMYp2NShJTfkbQ4OZXWuh7kLo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XHkEFCaUYNnk+ZHESNo0HOFzw+vZ87KUoF/zQzCp/Lg=; b=gczUX+Qd52V5qHa39kJRUa9qtVdV82bUhTMieGh3f1s2VNbH1RSNqqgFSN09AZc3GF MJIsl0nPHqHPWZ6ztVKqHWT7m44Z7Sikwl+MX5S876+lkq2ucPqXwPLmARywe9FvtGmM x0UTw3UwfVDv12cHJ18j7ddEQN+GDP8iFZyao9DOKMgBW8KfkPAKIW4b86fNMGmuyG10 R/s1d1MpMAqxPOJQIp/J6ITUIzKs3S7yBAFXmI131SFAmUp0TZSBksi+K5l2GEt01J56 Ub/R3Zq8llqhKrKjrZyn6XoJ9PQ+s4K7ap9WyhJOS12oFWk/Kj4vYAGpJCZ7ZcIkgkEQ DzhQ==
X-Gm-Message-State: APjAAAXIOC3zTmDnaH7Eeu36+V/KVI76TelCzcmJ5uppF4xVPKY5e3k+ ViTGBM+lGDhh/meVhQDy7faqEvF//z943nkCowwAPf1Rxrg=
X-Google-Smtp-Source: APXvYqyCwN0IOj5Wel1UZjcJSQsgmWNUWols26DFh5S0AbLuhMoKoc+Z2/a3sl4VS3HiswEAQb5tFVAYg0UmGB71nJE=
X-Received: by 2002:a02:234b:: with SMTP id u72mr14157874jau.44.1574430920987; Fri, 22 Nov 2019 05:55:20 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Pascal Junod <>
Date: Fri, 22 Nov 2019 14:55:10 +0100
Message-ID: <>
To: Benjamin Beurdouche <>
Cc: ML Messaging Layer Security <>
Content-Type: multipart/alternative; boundary="000000000000c52f7c0597efc3c1"
Archived-At: <>
Subject: Re: [MLS] [Delivery Service]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Nov 2019 13:55:23 -0000

Sure, it helps, thank you Benjamin !

On Thu, Nov 21, 2019 at 7:34 PM Benjamin Beurdouche <> 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 <
>> 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.