Re: [MLS] Recommendation for encrypted group operations

[Brendan McMillion <[e-mail]>]

You can workshop the exact text of my email, but the same point still
stands. We could instead say we're discussing applications that "accept
leaking group membership to a central server" and "need to use that central
server to provide certain features". All 3 of these criteria /must/ be met
to justify using unencrypted group operations. However, MLS was
painstakingly designed to make meeting any of these 3 criteria /optional/:
- MLS was designed to be secure without transport encryption
- MLS was designed to be able to support Sealed Sender-type operation
- MLS was designed to work on relatively simple Delivery Services that are
agnostic to the protocol

Keeping the recommendation to use encrypted group operations is not passing
judgement on applications that use unencrypted group operations. If mimi
(or any other application) is unable to encrypt group operations despite
this being a first-class feature of mls, I would just like them to make
that decision intentionally and document it.

On Tue, Jan 30, 2024 at 9:48 AM Richard Barnes <[e-mail]> wrote:

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