Re: [MLS] confirming server assist way forward

Sean Turner <> Tue, 25 February 2020 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60D553A1110 for <>; Tue, 25 Feb 2020 09:28:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.585
X-Spam-Status: No, score=-0.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dhFodhhzu4Um for <>; Tue, 25 Feb 2020 09:28:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87A553A1181 for <>; Tue, 25 Feb 2020 09:28:37 -0800 (PST)
Received: by with SMTP id j23so176104qtr.11 for <>; Tue, 25 Feb 2020 09:28:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=3e68LEk8pBKc34uvGyFKz7N81pa2GSYMi8ZjgQdo4xs=; b=nB9QLNejV8xntE1ckbTV5Mq3yZF74HqfV9xP+URXgj/9ZBZTmhCdEW8DiFWag0i61W 9m4kmLcv9cCq0WmGWYlvDORitlScElXqEqIHPZiT+y5QuXYe64kL6cWtfI2A5pzczZBP 8dFBK2ZiFnNd7CIjUfSfd+ZaiqotI7ch/l35c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=3e68LEk8pBKc34uvGyFKz7N81pa2GSYMi8ZjgQdo4xs=; b=bnGDc3GUbTSIn/y/dPcUuDx5wz9ZBfQiXJEDKyWWNaZ3rh7GKjBgOikZ1bmW4mcbJI U58FgMIe7Ku6eAR6kjcShAJQgs+btg4jP2NS0c3xLshccywWF0yqtpLGJWY9N8IptGCT d3pmtGzHqOpvK8ykmzS59elOp6A2qpKGHMwn4N+QYzy5/RLuho3BrrXDA1/ytP2NLjb1 E8LaDXgzj4rpPtORdvV8/SgXlagaXZX6QmS2eS1LXwAM1bFPngo/KY1pLhk5evDhOaoG Xo6tUVMs6QJtuXT1KIBl8RHI9pm9MqIAPag6NiKCaIATjljvqEvSVOU/3UMblCF+t3VY QX1g==
X-Gm-Message-State: APjAAAX2hzHSeXxlr2lB02VEAj8aivn5UzD5PJXbrezeXejyxWLIrZpL GrIwLW+HJChJ0da4l35zc3s3WnB0V0s=
X-Google-Smtp-Source: APXvYqzg5SDVbHY9HSqhUz8ihy5lQFVXubsKJHQF0d+FyqOB+ybYcByXaHjHR655oXSs/VN+tJRVAQ==
X-Received: by 2002:ac8:83d:: with SMTP id u58mr53417609qth.60.1582651716188; Tue, 25 Feb 2020 09:28:36 -0800 (PST)
Received: from sn3rd.lan ([]) by with ESMTPSA id i5sm7849611qtq.12.2020. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 09:28:35 -0800 (PST)
From: Sean Turner <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 25 Feb 2020 12:28:35 -0500
References: <>
To: Messaging Layer Security WG <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [MLS] confirming server assist way forward
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: Tue, 25 Feb 2020 17:28:39 -0000


I am going to go ahead and confirm that WG’s consensus for the plan outlined below.  I also confirmed with Raphael and Benjamin that they are still willing to start the individual draft (in fact I think they already have a repo). The WG will then consider whether it is a good starting point. Hoping that we can review the draft at IETF 107.

NOTE: 2020-03-09 UTC 23:59 is the submission deadline for IETF 107.



> On Feb 6, 2020, at 11:08, Sean Turner <> 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]
> [1]