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

[Richard Barnes <[e-mail]>]

On Fri, Aug 23, 2019 at 8:26 AM Stephen Farrell <[e-mail]>
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
> >> <[e-mail]> 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
> >>>> <[e-mail]> 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
> > [e-mail] https://www.ietf.org/mailman/listinfo/mls
> >
>