Re: [MLS] Recommendation for encrypted group operations

[Richard Barnes <[e-mail]>]

My take here is broadly in line with EKR here.  I have a couple of problems
with Brendan's analysis here:

First: #3 on Brendan's list says "want to" like it's a personal desire, but
it's actually an important objective engineering consideration: Operating
MLS is dramatically more efficient in large groups if a server caches the
tree, to the point where groups of any size are basically unworkable
without this optimization.  (Without this optimization, commits impose
linear cost in units of data sent by the committer to new joiners, and with
large constants because of credentials.)

Second: #2 "don't care about leaking" similarly discounts a legitimate
engineering trade-off.  It's not that the apps exposing membership to the
server are just being lackadaisical; there are legitimate reasons to have a
server act as a policy enforcement point as a secondary check on clients
(e.g., in cases where clients might be adversarial to the interests of the
policy controller).

Calling a set of apps that collectively cover billions of users "quite a
specific subset" is certainly a take, but not one I can agree with.

If I were writing this myself, the outline would be:
* In principle, encrypting MLS handshake messages provides the highest
level of confidentiality
* In practice, this imposes heavy performance costs
* Here are some guidelines that apps can use to decide where they want to
land on this trade-off

EKR's PR is quite close to this, so I would propose we workshop that text a
little and then adopt it.

--Richard


On Tue, Jan 30, 2024 at 7:11 AM Eric Rescorla <[e-mail]> wrote:

>
>
> On Tue, Jan 30, 2024 at 8:57 AM Brendan McMillion <
> [e-mail]> wrote:
>
>> Hi mls@
>>
>> One of the first topics of discussion at our last interim was on whether
>> or not to keep the recommendation in the architecture draft to use
>> encrypted group operations whenever possible. This is issue #210 on the
>> repo [1].
>>
>> The desire to remove this recommendation comes from the fact that many
>> mls deployments and the mimi wg do not follow it. It doesn't seem that the
>> minutes have been uploaded yet, but my memory of the conversation at the
>> interim is that:
>> - We generally agree that encrypted group operations would, in an ideal
>> world, be preferred. I recall several people saying it's the "moral thing
>> to do."
>> - Acknowledging that most deployed applications don't encrypt group
>> operations. We listed the deployments we knew of to prove this.
>>
>> The after-the-fact answer I came up with for why most applications don't
>> encrypt group operations is that they can 1.) guarantee strong
>> transport-layer security, 2.) don't care about leaking group membership to
>> a central server, and 3.) want to use that central server to provide
>> certain features. Despite being well-represented in the mls wg,
>> applications that meet criteria 1, 2 and 3 is actually quite a specific
>> subset within the space of what MLS was designed to support. Any
>> decentralized application would not meet these criteria (no transport-layer
>> encryption). Signal doesn't either (doesn't leak membership).
>>
>> Given this, my proposal is to keep the recommendation but state that
>> applications may use unencrypted operations if they have an explicit
>> reason. I've opened a PR to that effect here:
>> https://github.com/mlswg/mls-architecture/pull/247
>>
>> This is in contrast with a PR from Eric that removes the recommendation
>> and describes the tradeoffs between encrypted and unencrypted group
>> operations on relatively equal footing:
>> https://github.com/mlswg/mls-architecture/pull/246
>>
>> Please say on the list if you have a preference between the PRs. Thank
>> you!
>>
>
> Just to clarify the process here: this is the start of a discussion, not a
> consensus call, though I suppose the chairs might do a consensus call later
> if that's necessary.
>
> With that said, while I agree that it would be better if people encrypted
> the group messages, the objective of IETF documents is not to talk about
> the ideal world but to actually document protocol specifications for people
> to implement.
>
> Here in the IETF, we are specifying precisely one such protocol that uses
> MLS, which is to say MIMI, and as Brendan notes, that protocol uses
> unencrypted group operations. Text like what appears in PR #246 that
> suggests that people ought not to do what we in IETF are in fact doing
> serves mostly to confuse people and make us look uncoordinated [0].
>
> -Ekr
>
> [0] See also RFC 6919 "MUST (BUT WE KNOW YOU WON'T)" and  "OUGHT TO".
>
>
>
>
>
>
>
>
>> 1. https://github.com/mlswg/mls-architecture/issues/210
>> _______________________________________________
>> MLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mls
>>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>