Re: [MLS] confirming server assist way forward

Raphael Robert <raphael@wire.com> Fri, 07 February 2020 16:17 UTC

Return-Path: <raphael@wire.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 E9038120965 for <mls@ietfa.amsl.com>; Fri, 7 Feb 2020 08:17:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.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 VUBlDX6421Hf for <mls@ietfa.amsl.com>; Fri, 7 Feb 2020 08:17:16 -0800 (PST)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 4EF0B120939 for <mls@ietf.org>; Fri, 7 Feb 2020 08:17:16 -0800 (PST)
Received: by mail-wm1-x333.google.com with SMTP id t14so3375528wmi.5 for <mls@ietf.org>; Fri, 07 Feb 2020 08:17:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ados+WSy1uts/7zycOaTtAt3xJlpgcZiHqIASbkSDGg=; b=ewe7SrfS7GoUS/H+20yjjAYTmGazNUvHhapKuq8I0KF+x3Eavq9HpRVdLBA5/vMX9y cIoRj7KWEu3of478j/Y4Ro3ueMAn1a3+ea0+9kBtX7KuNXOKAEldxA4qqQDFAC8S057s 9w9NRvYIBdfYSBF14jNQxzleYSIRx10KM3rc4N605BpXamETPBaw25e8q7eleogqstDc VU+X9d04EdFKh1eDs9SGViULGF23qQJjoFEDUA8r/JigX77dSdqHk5UphtGKM31/DosY QpcyHcsDZpKqIQLoNYGyDmrUHW5yDpoht5WwE7VBzmBf1vOATd9DbSNrpPqn3Br++F1c K/mQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ados+WSy1uts/7zycOaTtAt3xJlpgcZiHqIASbkSDGg=; b=k88WWzGyHvdI4kWl/M1oT7v3c5G7/3p3jp5vW30LfgQmkEjzYYwgqWYDB0SDiFP1Tn 4O5mP7KmlIfzxsRIyJ7ogTpMWf0pk/Dyz7CqJYuQfOCAOzjdpnTinGfCwXs02JBAYvxL 8W1TlvYS1mJWvWS68C0vOhkGohenWf7Itfjy6C70cFhPynlWh2ZEKZCAWsratbTzePgs FO4B9RQqDayvPkZHWBeQjDDbX7fZZhjBBbHZVuXsq5PmCaPV8e0PdZiLVqjfni+eg6Aw vNFXF3njm/YEfZHwHNiGtR+9mCF3xMgv0ujvnT6Ln4wAIPAcz4skpdmbriYChuMo7zJa CQ6g==
X-Gm-Message-State: APjAAAWbI9lRZJ7kr9ruerB2ZInmT2cNhnBFPI+Db7bBy+mFBUJs/wbB K1pYXZ0PjDZQmsTwgYVQnBLjPANNrzo43w==
X-Google-Smtp-Source: APXvYqzQsy2M6LkUTjWkxSf71ScxPpsbPopfWA2YsFHy9gGgJTNbev0AKjjxzpAa8tThxTvRKcJo/g==
X-Received: by 2002:a1c:4d03:: with SMTP id o3mr4923659wmh.164.1581092234665; Fri, 07 Feb 2020 08:17:14 -0800 (PST)
Received: from [10.54.170.200] ([88.128.88.49]) by smtp.gmail.com with ESMTPSA id f14sm3927611wrt.7.2020.02.07.08.17.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Feb 2020 08:17:14 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Raphael Robert <raphael@wire.com>
In-Reply-To: <7518041D-619D-47CC-8A17-DEBC1C5B9F02@inria.fr>
Date: Fri, 7 Feb 2020 17:17:13 +0100
Cc: Sean Turner <sean@sn3rd.com>, ML Messaging Layer Security <mls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EA53147E-4DE9-48AC-B57A-BEBBDF47916F@wire.com>
References: <D167460F-FA34-402E-A06E-809130A70132@sn3rd.com> <7518041D-619D-47CC-8A17-DEBC1C5B9F02@inria.fr>
To: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/7pFU7h1GCmnfb-3a74-jeikLSdk>
Subject: Re: [MLS] confirming server assist way forward
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, 07 Feb 2020 16:17:19 -0000

I also support this effort. Like Benjamin said, the goal is not to propose a mandatory concept but rather work o something that could be useful in a number of scenarios and that can be extended if need be.

Raphael

> On 7 Feb 2020, at 15:04, Benjamin Beurdouche <benjamin.beurdouche@inria.fr>; wrote:
> 
> Obviously I support this effort.
> 
> I just want to remind the WG that the intent of that document is to describe
> what we think are the main constraints and establish where the
> places where not only security but also privacy can be affected by a 
> server-assist feature. We will illustrate these places and recommend
> possible solutions. Again, the goal is not to mandate solutions.
> 
> If all goes well, this effort will confort the fact that the server-assist features
> do not affect the core security guarantees we expect from the protocol.
> 
> B.
> 
>> On 6 Feb 2020, at 17:08, Sean Turner <sean@sn3rd.com>; wrote:
>> 
>> Hi!
>> 
>> tl;dr: confirming new individual draft to describe server assist.
>> 
>> During the F2F Interim in January, the WG had a lengthy discussion about server assist. We wrestled with the tussle between privacy and the desire to support very large groups, which just about everybody, if not everybody, believes requires some type of server assist because adding a new member to a large group requires sending megabytes of data in the Welcome message and this can be too much for some devices. Normally, the AS and DS is split and maybe these functions are collapsed in IRL, but Benjamin suggested that we split the functionality up a bit more to talk more fine-grained about the guarantees we want. The functional split suggested was as follows [0]:
>> 
>> - AS: Authentication Service (Signature Keys)
>> - DS: Delivery Service
>> -- CS: Credential Retrieval Service (CIKs)
>> -- IDS: Message Reception Service (Input)
>> --- IDS is responsible for message ordering.
>> -- ODS: Message Delivery Service (Output)
>> --- IDS and ODS may be combined.
>> - SDS: Storage Delivery Service (Welcome+Backup)
>> -- SDS is optional.
>> 
>> Likewise, they suggested that we switch from a model where there is one queue per group, to one queue per recipient.
>> 
>> The consensus at the interim was that it is important to support server assist and that it was equally important to provide truth in advertising, i.e., those that implement the functionality need to understand the security guarantees that are available.
>> 
>> There was also consensus to produce an individual draft that describes server assist. After this draft is published, the WG can review it and decide whether it should be accepted as a workable starting point and potential WG item.
>> 
>> The chairs need to confirm the interim’s consensus on list, so please let the WG know by 2359 UTC 20 February whether you disagree with the way forward and why.
>> 
>> FYI: Benjamin and Raphael volunteered to write this draft.
>> 
>> Cheers,
>> 
>> Nick and Sean
>> 
>> [0] https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/04-architecture.pdf
>> [1] https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/minutes.md
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls