Re: [MLS] Async Add

Richard Barnes <rlb@ipv.sx> Tue, 22 September 2020 14:56 UTC

Return-Path: <rlb@ipv.sx>
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 6DA3A3A0F98 for <mls@ietfa.amsl.com>; Tue, 22 Sep 2020 07:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 V5vwKRC6pT_I for <mls@ietfa.amsl.com>; Tue, 22 Sep 2020 07:56:50 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 819953A0F71 for <mls@ietf.org>; Tue, 22 Sep 2020 07:56:50 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id g3so15744784qtq.10 for <mls@ietf.org>; Tue, 22 Sep 2020 07:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; 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; d=1e100.net; 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: <474411EE-C4E8-4D01-B135-2632078C1423@wire.com> <52db4542-ed98-a10b-ac55-e49594504ded@wickr.com>
In-Reply-To: <52db4542-ed98-a10b-ac55-e49594504ded@wickr.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 22 Sep 2020 10:56:14 -0400
Message-ID: <CAL02cgQRrzvFKZrbPpH3b2CGv6FxP5XXtr4V=28CoXYR-bgwOg@mail.gmail.com>
To: Joel Alwen <jalwen@wickr.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000031ddd705afe82d0b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/Tuvucb_LEoX5goaiJ0mwauRpklg>
Subject: Re: [MLS] Async Add
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: 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
available:

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...

--RLB


On Tue, Sep 22, 2020 at 9:24 AM Joel Alwen <jalwen@wickr.com> 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:
> https://github.com/mlswg/mls-protocol/pull/406
> > I will bring this up at the interim tomorrow for discussion.
> >
> > Raphael
> >
> >
> > _______________________________________________
> > 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
>