Re: [MLS] Async Add

Richard Barnes <> Tue, 22 September 2020 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DA3A3A0F98 for <>; Tue, 22 Sep 2020 07:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V5vwKRC6pT_I for <>; Tue, 22 Sep 2020 07:56:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 819953A0F71 for <>; Tue, 22 Sep 2020 07:56:50 -0700 (PDT)
Received: by with SMTP id g3so15744784qtq.10 for <>; Tue, 22 Sep 2020 07:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IUKwP8BA0zlQif5l0HBDdyebq449pv2lh9p/khKcBOk=; b=f5Qy/RrZbAlVU3JvcMXABinVjHMAMnyQFYOwdwjCjRivmosdave9GMJM6/mSICXpmK gVIGE4nt6fgUBxKb1cV5YRtQ59eb9GzBKUI48bN2QsFalbeljMdVjo0bTnRFjJ8RkZOI xaaR7GDGgiwtJUhbxhiDGGgyV3tE3bmTPDsTJdZhd4QIWm+PJxS7DcQxs8AUfbP9Cj+V 37xefdZkV6uIG+L9Dk0kYq8Dw5UQI1Wvaq0j6HtVv/CO/zQY5cvVytagNGSFFr6YphS9 j8HHFtu8noUwqe4pVebgx8Vvd+9TxEcIMadItYQ0aIoVzj9yD7EJy0+n+Kl8xLQoC+Pz iOpA==
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=IUKwP8BA0zlQif5l0HBDdyebq449pv2lh9p/khKcBOk=; b=fVXbgY0aDXXPNufdaldPCLU4zqi1zcT/nPBNJGSN/WrPhatffT+PPPBUTcjKAED6K7 s37mD/cSeoNqir278EyGJuoCksLCL9HGRVzxLuaCj6POsYB5W3gstHb36aihDHzfLzP7 d45fDABgzm4undlX6f1XXjdAJX7h5f9U+HSJSPIJfSgOtstq806/LTi3RoFD42m+Nbbm 9KVn7qg/kW1qW/l+CsEFS1ft9gRDFhxNy3IQY1x3u72UqD138S8+4sHmxLwOuFaoHop3 U1EOetyzFxfp8i2Fuj8KOdylnFqWu8vtuqXH4iUr3IGkC6NqmhF3YkScN5j0rms8Kdm/ rKYA==
X-Gm-Message-State: AOAM530ipnRIUwv/IwB3tI9OMkyFfJ7cASgDFsXP0wJ4clRj3VIszhbO DAe3GqIz4mt3v4XajPkxfuAOG3fH2VEaXSINKdtkQQ==
X-Google-Smtp-Source: ABdhPJxLDk/uoYqRgT8GopDvIYDIjJSAA5FgFx68XSFd4bdZ5kpcVpMm20QvxChOdDhWglPTTskwneF2rKmtNhgz3IU=
X-Received: by 2002:ac8:1b92:: with SMTP id z18mr4867580qtj.265.1600786609063; Tue, 22 Sep 2020 07:56:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Tue, 22 Sep 2020 10:56:14 -0400
Message-ID: <>
To: Joel Alwen <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="00000000000031ddd705afe82d0b"
Archived-At: <>
Subject: Re: [MLS] Async Add
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, 22 Sep 2020 14:56:52 -0000

Thanks for posting this, Raphael.  I agree with Joël that this is a feature
that is likely to get some use.  And the PR is pleasantly short (though I
think it might need a bit more elaboration).

On the topic of entropy from the last epoch, I'm wary of the current
all-zero approach.  It seems like there are at least two other approaches

a. "Public init secret" - Alongside the regular init secret, derive a
"public init secret" from the key schedule.  Then use this as the init
secret for external commits.

b. "Init with KEM" - You could generate a key pair off of the key schedule,
use some KEM-based operations to derive the next init secret.  In the early
days of MLS, we used DH for this.  Nowadays, we're KEM-only, but I think
the HPKE exporter might be pressed into serving a similar purpose.

Looking forward to the discussion...


On Tue, Sep 22, 2020 at 9:24 AM Joel Alwen <> wrote:

> My initial 2 cents: this is not just a corner case. MLS should specify how
> to
> support such functionality but as an optional mode and making explicit the
> price
> in security it entails.
> I believe such a feature would be used quite a bit if it where available.
> E.g.
> My phone is the only device on my account. It breaks. I get a new one and
> log
> back in to my account. Now I want my re-join my old groups. In most
> deployments
> I'd expect that to be permitted by group policies. But how can I re-join
> w/o the
> help of someone else in the group actively "pulling" me in? If I'm not
> mistaken
> then this PR provides an answer.
> The solution does come with a price though. Some things that come to mind:
>  - It seems to require storing public group state on the DS (or some other
> server) which isn't great for E2E metadata protection.
>  - An external commit provides weaker security guarantees than a normal
> commit.
> It throws out the old init_secret. Ergo, if ever an HPKE sk to which one
> of the
> UpdatePath secrets was encrypted to leaks then the entire application key
> schedule of the new epoch is compromised. (Not to mention that further
> epochs
> may also be compromised depending on the particulars of the execution.) For
> normal commits that's not the case because the adv. also needs the old
> epoch's
> init_secret.
> - Joël
> On 21/09/2020 20:15, Raphael Robert wrote:
> > Hi all,
> >
> > Over the course of the past weeks when assessing how well MLS would fit
> into existing messengers, it became obvious that adding new members is
> still problematic. The operation – while technically asynchronous – still
> requires two parties to be online in many cases.
> >
> > Rather than writing a lot of prose here, I attached a presentation that
> explains the problem and offers a potential solution.
> >
> > I also created the following PR:
> > I will bring this up at the interim tomorrow for discussion.
> >
> > Raphael
> >
> >
> > _______________________________________________
> > MLS mailing list
> >
> >
> >
> _______________________________________________
> MLS mailing list