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

Richard Barnes <rlb@ipv.sx> Fri, 23 August 2019 14:11 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 D08681200E9 for <mls@ietfa.amsl.com>; Fri, 23 Aug 2019 07:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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_NONE=-0.0001, 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 3ZH2-hyQkozr for <mls@ietfa.amsl.com>; Fri, 23 Aug 2019 07:10:59 -0700 (PDT)
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 B630912009C for <mls@ietf.org>; Fri, 23 Aug 2019 07:10:59 -0700 (PDT)
Received: by mail-oi1-x22f.google.com with SMTP id t24so7054151oij.13 for <mls@ietf.org>; Fri, 23 Aug 2019 07:10:59 -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=Gi+FGQD/3F3rbP3T8M/2s/RMobEPCAC3fJRhxHrykhM=; b=f5+X1sCNI3OEY2pjFmeg37Qfyvk9zw52taI/sX4mi9IdgE51cAYXRcpsG3bBBJRLHq INybBb9tuDcO9WCaWNbxyMhl1qx9e/7/Rj4SXc2bwxKZLNsZbhynhKfyULTUE3Btn70p 45kiRl1Jb1oFA+9pFFZ4hUQUNG3H3uepLBNpFU1y4rAtN84p+/BwTdJDH59hU4JBo/kk dxJm/mgPf4RMadi2Y10N/FChOBaT/YhaO4nt6kZGboTQAy+rUHXHtNpAsoSJYC96rRL+ 1092kBQHfg6VrgNPED3A2idyurdwRYyx3WbskJ/mpsgcQXwQ/0XlbPxa2axJ1pgMRTqn Gy9g==
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=Gi+FGQD/3F3rbP3T8M/2s/RMobEPCAC3fJRhxHrykhM=; b=dTaWTkNKTgczHFlUXuZXSfTtfIj5sw/IWAB4XpsaZUeitctrWbDyCul6Af4aTe6i22 wSXL5UpMfutZqrfSUc9P7ABNclXt802NP1fWZrdaiOkhWwu2WBcPP1bkO8+Mw02WToQ6 LpA/Pp4vEw/AClIS8qJ9oD5Cl0rbnsUnTqtgTSQILcdhTeB6mz/9XMlXBBs8PuMtr6KA s+IAYQ+GiAn54eRjAfdg90mdSExH27kJbKDjBPdjpiMsEmIwe1qHg66U6n8U8HCRUKJe QzLQCkYgol4vJ9krXj0jV5THRJl5FfIaMeW2Hp2ztZ9OXvsJcWsqqLFmo62SsBLnverQ 61Aw==
X-Gm-Message-State: APjAAAVkItdNk2tIipXlFV/rnRsNQ50VIpw9CKADVTekzUEFqhq/9CBG jZeY+U4H4HI85DQ5UThWLiTQ9FC33Rr9a+bpyhZucA==
X-Google-Smtp-Source: APXvYqwggzuWOWRf/Ikxz+XhgeY9XM46dE1EZDmMUnze7xKxmvZxMVBD3Dq7pmTkepl6M12rOcWpqCvz1nDw54vnSGE=
X-Received: by 2002:aca:53cf:: with SMTP id h198mr3120695oib.169.1566569458748; Fri, 23 Aug 2019 07:10:58 -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>
In-Reply-To: <a76355f9-52bf-cdc8-5d34-43d7f647188d@cs.tcd.ie>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 23 Aug 2019 10:10:40 -0400
Message-ID: <CAL02cgQ6m72u1ZU+qC2XHkxxMuA6+6+VMqcZfLmvmJYjf3H_8Q@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Raphael Robert <raphael=40wire.com@dmarc.ietf.org>, Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001ae6270590c96075"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/xN9FuNfd9uv9n4HiDtElIF5onAk>
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: Fri, 23 Aug 2019 14:11:02 -0000

On Fri, Aug 23, 2019 at 8:26 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>;
wrote:

>
> Hiya,
>
> On 23/08/2019 13:17, Raphael Robert wrote:
> > The ghost user scenario is precisely what we want to avoid. In
> > Richard’s Proposals draft, every Proposal has to be validated by a
> > Commit message, and the latter can only be issued by an existing
> > member of the group. Therefore the server still cannot control the
> > group membership, it can rather only make proposals on how the
> > membership list should be modified. Naturally we need to make sure
> > that everything works as intended.
>
> Sure, I get that. My concern is that I'm not clear how
> such proposals could meaningfully be handled by members
> in general - it seems like it could be quite a footgun.
>

It was pointed out in the discussion at IETF 105 that given that vendors
seem to want server-initiated Add/Remove, they will do it somehow, either
using a mechanism in the protocol, or as you say, using something at the
application layer.

It seems to me that between those two options, having it in the protocol is
the better one.  It at least provides clear accountability for who is in
the group and how they were added: The records of who made the proposal and
who committed the proposal are both in the transcript, and thus have to be
revealed to everyone.  In the application-layer alternative, you'd still
have the commiter in the transcript, but the server could just whisper to
one participant, and nobody else would need to know that the server had
anything to do with the transaction.

I'm not clear on what you mean by "meaningfully handled by members".  Even
in the Proposal / server-initiated-in-the-protocol case, messages from the
server are authenticated, and endpoints should be expected to apply
authorization policy to them.  (The presumption would be that the clients
in a given environment would be configured to trust their servers.)  In
addition, like current Add messages, Add proposals would have the full
ClientInitKey for the proposed member, which means that members can see
their credential and possibly make a decision based on that.  So there are
two authenticated identities to use for authorization decisions, (1) the
server / proposer's identity, and (2) the new member's identity.

There are some sharp edges here, but that will be true with any
server-initiated case (whether or not in this document), and I think the
proposal here provides good guard rails to guide people to better solutions.

--Richard




>
> Cheers,
> S.
>
> >
> >> On 23 Aug 2019, at 13:26, Stephen Farrell
> >> <stephen.farrell@cs.tcd.ie>; wrote:
> >>
> >>
> >> Hiya,
> >>
> >> On 23/08/2019 11:24, Raphael Robert wrote:
> >>> Right now, Add and Remove handshake messages have to be signed by
> >>> an existing member of the group. There is no way for the server
> >>> to make any changes to the group membership.
> >>
> >> Thanks. As you note in your other mail, that seems a bit
> >> concerning, from a potentially ghostly point of view. My initial
> >> reaction (again with the "benefit" of not having kept up to date
> >> with the drafts:-) is that a service using MLS could put itself in
> >> a position to do the same thing within the application layer if
> >> necessary, so it'd seem better for it not to be a feature of the
> >> MLS protocol.
> >>
> >> I've no opinion on the general idea of proposals, my concern is
> >> only really about a non-member of the group (the server or anyone
> >> else) being able to control group membership like that, for what I
> >> guess would effectively be all applications using MLS.
> >>
> >> Cheers, S.
> >>
> >>>
> >>>> On 23 Aug 2019, at 11:08, Stephen Farrell
> >>>> <stephen.farrell@cs.tcd.ie>; wrote:
> >>>>
> >>>> Signed PGP part
> >>>>
> >>>> Sorry for not following mls in detail but can you explain how:
> >>>>
> >>>> On 22/08/2019 23:16, Richard Barnes wrote:
> >>>>> 2. Allow some flavor of server-initiated Add and Remove
> >>>>
> >>>> ...compares to the status quo ante?
> >>>>
> >>>> Thanks, S. <0x5AB2FAF17B172BEA.asc>
> >>>>
> >>>>
> >>>
> >>>
> >> <0x5AB2FAF17B172BEA.asc>
> >
> >
> >
> > _______________________________________________ MLS mailing list
> > MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls
> >
>