Re: [MLS] [Delivery Service]

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Thu, 21 November 2019 18:34 UTC

Return-Path: <benjamin.beurdouche@inria.fr>
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 A5C99120108 for <mls@ietfa.amsl.com>; Thu, 21 Nov 2019 10:34:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Q7YhrDw7Vy-W for <mls@ietfa.amsl.com>; Thu, 21 Nov 2019 10:34:05 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B0D1200FA for <mls@ietf.org>; Thu, 21 Nov 2019 10:34:05 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.69,226,1571695200"; d="scan'208,217";a="412925697"
Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.20]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Nov 2019 19:34:03 +0100
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Message-Id: <75433909-13FF-4D0E-B6E5-9300DEFBC041@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D4B55078-44FD-47F1-8C17-2E4EFDEDEED5"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Thu, 21 Nov 2019 19:34:02 +0100
In-Reply-To: <CAPOUjt69249PznZzpLdZ81XtCTR=5nDWtmA6rTu9nABSf=KJ7A@mail.gmail.com>
Cc: ML Messaging Layer Security <mls@ietf.org>
To: Pascal Junod <pascalj=40snap.com@dmarc.ietf.org>
References: <CAPOUjt69249PznZzpLdZ81XtCTR=5nDWtmA6rTu9nABSf=KJ7A@mail.gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/zZ_DTYtF6dVlsXm5i-2zRH_UV6M>
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: Thu, 21 Nov 2019 18:34:07 -0000

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.