Re: [MLS] Proposal: Proposals (was: Laziness)

Richard Barnes <rlb@ipv.sx> Thu, 19 September 2019 14:24 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 BA81D120090 for <mls@ietfa.amsl.com>; Thu, 19 Sep 2019 07:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 2vWCqqlc8oWd for <mls@ietfa.amsl.com>; Thu, 19 Sep 2019 07:24:33 -0700 (PDT)
Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) (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 9483012000F for <mls@ietf.org>; Thu, 19 Sep 2019 07:24:33 -0700 (PDT)
Received: by mail-oi1-x244.google.com with SMTP id t84so2830928oih.10 for <mls@ietf.org>; Thu, 19 Sep 2019 07:24:33 -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=JCGWVUIOVhYsatjKrxPIl1A4dZdxT9Icpiu8ZJTzomo=; b=dklERRT/AVFOn7AVXFa6T31GS1g8ZyJfP7hRCdNwULHUv7jAhWtkuS01NyAoMHN/Ty RYSXAxbFuiW4t4jQ+JuG4D0Y9Nud3D8xf5VxcjfIbNcr88IPuM5ZOuBWir1c//hn6OV9 iuce/enfha7xb022ooYG3DOU+FPuq9zx9nwKKS5PoUeiYLi34Ix1mbMjqY/WVep0IXkH IRGcQhrxICK7zUJyd7+RrkIIua6oX0/1lxm9xbuNSWK4CK3Oc/DswXKpiPO88SHEtpX8 Hi0v4hhEkPx85fum+wJ+p6jcmBP74ItfYvHEQz3bI5e/+JfVAU3qjOPV9rIDrenyIg9h a1+w==
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=JCGWVUIOVhYsatjKrxPIl1A4dZdxT9Icpiu8ZJTzomo=; b=ERZbO/mbSWp407HVJjEAhDYPsowxaGtDMi18Dii3dYaZogwzljdfeDV9Pe1YKaSCov qA23KLbduRKaAzLXubqn4b62V/gwE02JaILveFRaOzRa75UD56TrDGDu3nIP2rgtu+Fv OTtMbzpnVsY9aH7moCVU+6MUeOMQJ7IP5p/uMUMFBVeE6bYEszzKTNr10EUWDECQlm4C 7+kv+Lf/Hq7h6+TsSrI5y69wAF0+ondkdF9CFGd4/zX0EqFWos8cwip0p0FGmYk5oaes LiXmuMYHFkMuzXnRmRQX195SG6XCel5KyRLl2ITfVeJ0HPHFGIMzwbRJb5o/Gd1Mf4NO fM+g==
X-Gm-Message-State: APjAAAWEck8f9Mf6WU3T21kl0M+lq0dAxa1EVGxHIBDBY6Rzu2mdjnEy NDfBnLm67O8uyRjC6OGBFaUEwWRsNpWHj5L0zzwdOQ==
X-Google-Smtp-Source: APXvYqxf2ZCiXAJ7PHDqXiwbNeiR2cmhQzZVa68rj2rqxL2zeRdp/y2EDtlKkHNk4NAELFHY6UNZ1xTqeCzMO/9ndec=
X-Received: by 2002:aca:4e12:: with SMTP id c18mr2258507oib.135.1568903072661; Thu, 19 Sep 2019 07:24:32 -0700 (PDT)
MIME-Version: 1.0
References: <CAL02cgSbgkYyMcm=w8+oF+R5GBKaaofV3_x_VF0rMc0jWhs+Kg@mail.gmail.com> <f9634330-93bb-df46-a37c-bdf19359c2e0@cs.tcd.ie> <AE4D69D4-F7BA-490C-887E-A557BAC656FC@wire.com> <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> <a76355f9-52bf-cdc8-5d34-43d7f647188d@cs.tcd.ie> <CAL02cgQ6m72u1ZU+qC2XHkxxMuA6+6+VMqcZfLmvmJYjf3H_8Q@mail.gmail.com> <f212ba04-87cd-c954-3072-9f4bf676d4d7@cs.tcd.ie> <CAL02cgSF_CWHkXY4dNjw53kzpHyL-5uBJxxHo1MtyAKcOYxjaA@mail.gmail.com> <752B7C91-19CF-45CF-8774-DED73A908A23@inria.fr> <CAL02cgQF42KDrXH8F0qt1_J0jhu0Cd18PNkN3+PsP1zW9uTLrg@mail.gmail.com> <9756C849-1248-4E2B-9509-07EAF59A0FC4@inria.fr> <6119dac1-2822-4756-b514-4bb500bbaf04@www.fastmail.com> <46673A73-0D73-4206-9DBE-009CA8B4F9B5@fb.com>
In-Reply-To: <46673A73-0D73-4206-9DBE-009CA8B4F9B5@fb.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 19 Sep 2019 10:24:19 -0400
Message-ID: <CAL02cgQzSUpVdc4-ALAo4MnA5OMeiZG00t0T20u7LmE7UgDCEQ@mail.gmail.com>
To: Jon Millican <jmillican@fb.com>
Cc: "mls@ietf.org" <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000557cf60592e8b667"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/prJJUbgc97JGPLjGydDV41PvFq4>
Subject: Re: [MLS] Proposal: Proposals (was: Laziness)
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, 19 Sep 2019 14:24:37 -0000

I think the current PR is pretty good w.r.t. these comments.

W.r.t. Updates: "An Update proposal requests that the sender's leaf node in
the tree be updated with a new HPKE public key."  No affordance for Updates
other than by the leaf holder.

W.r.t. Server-initiated: That's not in this PR, but I think it lays the
groundwork.  In the sense that once Proposals are split out, the
constraints on who can make a proposal can be looser than who can make a
Commit.  So for example, you could configure the application to accept
Proposals from the server and include them in the next Commit.  That takes
care of server-initiated Remove completely.  For server-initiated Add, you
would also need a way for someone external to the group to send to the
group, for the interim period in between Proposal/Add and  Commit.  But
that seems like it can be handled in a future iteration.

--Richard


On Thu, Sep 19, 2019 at 10:00 AM Jon Millican <jmillican@fb.com>; wrote:

> Sorry for jumping onto this thread quite late, but just a couple comments
> to add:
>
>
>
> >  Can Update Proposals be issued by anyone but the member itself? If we
> say yes, the analysis will be more straight forward, but it is also more
> limited. If we say no, the question remains who can issue them. They could
> be issued by the server or another member. Right now I don’t see why
> another member should be allowed to do so, but I could think of reasons why
> the server should be allowed to do so (multi-device context). We should
> again be very careful w.r.t the ghost user scenario in order to avoid the
> possibility that the server can sneak in a malicious participant that way.
>
>
>
> I don't see a good reason for anyone other than a leaf-owner to ever issue
> an update to that leaf. If we treat multi-device as a special case of
> group, then the server would also not need to do this – it could instead
> just issue adds and removes as devices change.
>
>
>
>
>
> > Server add/remove is important in many practical use cases: you buy a
> new phone and log in; the server wants to remove your old phone from all
> groups it's in, and add the new phone.
>
>
>
> To stress this point, server-controlled group membership is a practical
> necessity in many cases. I can’t think of any significant messaging service
> that does not allow account resets, and I believe the majority will allow
> multi-device/group threads to continue when this happens. For example,
> membership of a thread in Messenger is based on user account rather than
> device – if a device is attached to a given user account, then it is
> inherently in any threads that this user account is also in. Logging into
> an account is not a cryptographic process attached to some other device,
> but authenticating to an online service (e.g. username + password). I
> believe Wire follows the same model. In this world, a device which logs
> into an account needs to be able to not only receive future messages to
> that account’s threads (which could be achieved at the application level
> without server-add), but also to send messages to any of these threads
> (potentially before any other device in the thread has come online) – which
> would be more challenging to implement at the application level. For this
> reason, I’d strongly favour server add in the protocol.
>
>
>
> Jon
>
>
>
>
>
> *From: *MLS <mls-bounces@ietf.org>; on behalf of Katriel Cohn-Gordon <
> me@katriel.co.uk>;
> *Date: *Friday, 30 August 2019 at 17:41
> *To: *"mls@ietf.org"; <mls@ietf.org>;
> *Cc: *Messaging Layer Security WG <mls@ietf.org>;
> *Subject: *Re: [MLS] Proposal: Proposals (was: Laziness)
>
>
>
> This abstraction seems sensible. Server add/remove is important in many
> practical use cases: you buy a new phone and log in; the server wants to
> remove your old phone from all groups it's in, and add the new phone. Since
> we of course don't want to give the server the ability to actually effect
> this change, only to propose it, it seems to me that we already need a way
> to disconnect proposals and commits anyway. Once that's the case, it
> doesn't seem too big a leap to cleanly factor all operations into that
> structure.
>
>
>
> My main worry would be complicating the analysis. However, it seems like
> if the separation is clean enough then it might not actually make the
> analysis too bad, because there is a clean property (that Karthik
> described) for each epoch change. So, on balance, I think I'm in favour of
> this proposal.
>
>
>
> --katriel
>
>
>
> On Tue, 27 Aug 2019, at 6:23 PM, Karthik Bhargavan wrote:
>
>
>
> Hi Richard,
>
>
>
> On 23 Aug 2019, at 18:48, Richard Barnes <rlb@ipv.sx>; wrote:
>
>
>
> Just to confirm I understand, the key exchange protocol in this conception
> would be something like, at each epoch:
>
>
>
> 1. KEM a secret to some set of people whom you believe to be the current
> members of the group
>
> 2. Send that KEM'ed value out to the group together with a description of
> the current membership
>
> 3. KDF the KEM'ed secret together with the prior epoch secret to get the
> new epoch secret
>
> 4. Use the new epoch secret to generate a confirmation over the current
> state of the group
>
> Where the KEM in (1) would be something like TreeKEM or just "encrypt to a
> list of public keys".  Then the proposals would just be a way for people to
> sync up on who the current members of the group are (by leaf key).
>
>
>
> This is essentially correct, of course with a bunch of details to
> guarantee that everyone gets the same keys.
>
> It remains mostly unchanged from what we have currently.
>
>
>
> The major thing I would be worried about in such a split is how it would
> deal with authority over changes, which affect the authentication
> properties of the protocol.  The current Proposals proposal maintains the
> property that everyone agrees on the proposals and can verify that they
> were proper, e.g., only the holder of a leaf can update that leaf.  If we
> sever the connection between the proposals and the top-level transcript
> entirely, then I'm not sure how you would continue to assure that, say, the
> sender of a Commit didn't just swap out Joe's leaf key for the NSA.
>
>
>
> The changes would be signed by the sender, as usual. The only question is
> whether this signature is enough, without binding the signature to the key
> exchange transcript or current epoch secret.
>
> Note that the tree synchronization protocol has its own transcript on how
> the tree has changed over time, and certainly we could require each update
> to sign this “state history” transcript.
>
> We should of course impose the requirement that only the "holder of the
> signature key corresponding to a leaf” can update that leaf.
>
> In fact, the tree update protocol can ensure that only members of a
> subtree can change the root of that subtree.
>
> This is what we guarantee now anyway. I don’t see that substantially
> changing in the decoupled design.
>
>
>
>
>
> I agree that there is degree of separation here (since, e.g., it's easy to
> imagine swapping in a "list of keys" KEM for TreeKEM).  But it seems like a
> fairly high degree of coupling is necessary to maintain authentication.
>
>
>
> So, what would be the authentication property you would want for a tree
> change?
>
> The tree changing sender must know the signature key for a member *and
> must also know the current epoch secret*?
>
>
>
> Perhaps what you are pointing out is that we cannot remove signatures from
> the key exchange protocol, and so we’d end up needing two signatures; one
> for tree synchronization and the other for authenticating the key exchange.
>
> Actually, we also need a third signature for the message protection. How
> and when we can share these signatures is an optimization problem, but they
> serve different purposes.
>
>
>
> -Karthik
>
>
>
>
>
> --Richard
>
>
>
>
>
>
>
> On Fri, Aug 23, 2019 at 1:22 PM Karthik Bhargavan <
> karthikeyan.bhargavan@inria.fr>; wrote:
>
> Hello All,
>
>
>
> It seems to me that one way to think about “laziness” would be to cleanly
> separate the MLS key exchange into two different protocols.
>
> The first is a “classic” authenticated synchronization protocol where
> members of a group can create and modify a shared data structure (in this
> case, the group membership tree).
>
> The second is a novel key establishment protocol where some member of the
> group generates a fresh group secret that will be delivered only to the
> current members computed from the (current) group state.
>
> Currently the first and second protocols are tightly interleaved: every
> time the group data structure is modified by some member (or admin), that
> member must also generate and distribute the fresh group secret.
>
> The laziness proposal can be thought of as detaching the two protocols:
> the key establishment protocol can follow group modifications with some
> delay.
>
>
>
> So rather than trying to add “laziness” to the existing protocol, should
> we try to do this detachment in a principled way by defining two
> independent sub-protocols?
>
> It would have the advantage that we may be able to consider other designs
> for synchronization and key establishment, which may well be orthogonal
> concerns.
>
>
>
> In our model of MLS, we can already factor out the protocol in this way,
> but it makes the security invariants a bit harder to express in a
> user-friendly way.
>
> Still, I would prefer to compose proofs for simpler sub-protocols rather
> than try to prove security for a single complex protocol with lots of
> options.
>
>
>
> Best,
>
> -Karthik
>
>
>
>
>
> On 23 Aug 2019, at 10:48, Richard Barnes <rlb@ipv.sx <rlb@ipv..sx>> wrote:
>
>
>
>
>
>
>
> On Fri, Aug 23, 2019 at 10:21 AM Stephen Farrell <
> stephen.farrell@cs.tcd.ie>; wrote:
>
>
>
> Hiya,
>
>
>
> On 23/08/2019 15:10, Richard Barnes wrote:
>
> >
>
> > I'm not clear on what you mean by "meaningfully handled by members".
>
> >
>
>
>
> I'm assuming that MLS protocol data will likely be
>
> handled by a library. ISTM more likely that such a
>
> library might default to, or be carelessly used to,
>
> honor anything the server proposes if this is an MLS
>
> protocol feature rather than an application layer
>
> feature. That'd be an example of not meaningfully
>
> handling this:-) We have seen similar kinds of
>
> failure with applications and TLS libraries in the
>
> past where certs aren't checked etc.
>
>
>
> Oh I see.  That would actually be a pretty difficult policy to implement,
> at least without turning off authentication altogether, at least in the
> envisioned protocol.  By which I mean:
>
>
>
> - Right now, clients are expected to maintain a list of members' signing
> keys
>
> - So signers are just indicated by their index in that list
>
> - The obvious way to add non-member signers is to reserve a block of
> indices (say 0xFFFFFFxx) that can correspond to application-specific
> entities
>
> - Then clients need to get configured with which server keys go with which
> reserved indices
>
>
>
> Assuming we go in that direction, the natural, "I don't care about
> server-initiated stuff" library design would be to just not implement any
> special handling for those reserved indices, in which case you'll reject
> anything from the server.  I would expect a library that does anything else
> to have an API for the configuration required in the last point.
>
>
>
> The obvious screw-up case would be, "Treat a signature from the reserved
> block as trusted".  But that's actually a little hard to implement; because
> the public keys aren't provided, you would have to also not do any
> signature verification at all, which means you're now totally open to the
> world.  Hopefully that would raise some red flags for developers.
>
>
>
> So it's not impossible to screw up, but not trivial either.  At least if
> you want to maintain authentication for group members.  If you turn that
> off too, I don't think we can save you.
>
>
>
> --Richard
>
>
>
>
>
>
>
> I do accept the argument that it can happen at the
>
> application layer if not defined in the MLS protocol,
>
> but doing this kind of thing at the application layer
>
> seems safer to me.
>
>
>
> It's also not clear to me that all MLS applications
>
> would need this feature. (That may be true, I just
>
> don't know.) If they don't, then again, it seems to
>
> be more conservative to leave it to applications.
>
>
>
> I agree that there are sharp edges however this kind
>
> of thing is done though.
>
>
>
> Cheers,
>
> S.
>
> _______________________________________________
>
> MLS mailing list
>
> MLS@ietf.org
>
> https://www.ietf.org/mailman/listinfo/mls
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=gabsgG53OsRWJChybmvBPhP4Bww6dRbrbur9MZMqSbA&s=jPen3uhkJSug-XGStQZg7vWn_ys1LeXbX5NwQS0CwCg&e=>
>
> _______________________________________________
>
> 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
>