Re: [MLS] [Delivery Service]

Pascal Junod <pascalj@snap.com> Fri, 22 November 2019 13:55 UTC

Return-Path: <pjunod@snapchat.com>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E347C120147 for <mls@ietfa.amsl.com>; Fri, 22 Nov 2019 05:55:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=snap.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 089lWCyQhmTI for <mls@ietfa.amsl.com>; Fri, 22 Nov 2019 05:55:21 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A951200B9 for <mls@ietf.org>; Fri, 22 Nov 2019 05:55:21 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id x21so8095414ior.2 for <mls@ietf.org>; Fri, 22 Nov 2019 05:55:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snap.com; 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; d=1e100.net; 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: <CAPOUjt69249PznZzpLdZ81XtCTR=5nDWtmA6rTu9nABSf=KJ7A@mail.gmail.com> <75433909-13FF-4D0E-B6E5-9300DEFBC041@inria.fr>
In-Reply-To: <75433909-13FF-4D0E-B6E5-9300DEFBC041@inria.fr>
From: Pascal Junod <pascalj@snap.com>
Date: Fri, 22 Nov 2019 14:55:10 +0100
Message-ID: <CAPOUjt5A2haCG0Yiu-3rDryrGVptsiqWXmBVw4kPPL6xO-7r2w@mail.gmail.com>
To: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Cc: ML Messaging Layer Security <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c52f7c0597efc3c1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/YsCD1iL_cgFCApNMqqnK99ZCKHA>
Subject: Re: [MLS] [Delivery Service]
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=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 <
benjamin.beurdouche@inria.fr>; 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=40snap.com@dmarc.ietf.org>; 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.
>