Re: [MLS] Recommendation for encrypted group operations

[Richard Barnes <[e-mail]>]

#1 is an "only" issue in those cases, but real apps care about those
situations.  Uploading the ratchet tree was a primary constraint on Webex's
scaling of MLS to support real meeting sizes.

#2 is certainly an issue in enterprise settings, but more generally, it
applies in any case where it's not acceptable to wait to enforce policy
decisions until a member empowered to enforce those decisions comes
online.  If you have a messaging space where a room moderator has set a
policy that "nobody with a Gmail address can join", do you rely on everyone
in the room to generously not add a forbidden user?  Do you rely on
reactive removals?  Or do you have the server help by quashing forbidden
joins.  You basically can't have a public room *and* usable abuse
mitigation without server assistance.

So yes, these are real concerns.

--Richard

On Tue, Jan 30, 2024 at 11:10 AM Brendan McMillion <
[e-mail]> wrote:

> #1 is only an issue if you are supporting very very large groups, or maybe
> if you have very inefficient credentials. #2 does not immediately resonate
> with me, as it sounds more like a concern that you would have in corporate
> environments?
>
> I personally have not followed the mimi wg very closely and I can not say
> why they made this decision.
>
> On Tue, Jan 30, 2024 at 12:58 PM Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>> On Tue, Jan 30, 2024 at 12:41 PM Brendan McMillion <
>> [e-mail]> wrote:
>>
>>> I appreciate the point about the current text seeming like an RFC 6919
>>> "should (but won't)" which is why my proposed resolution was to state the
>>> specific common reason why the recommendation wouldn't be followed. You're
>>> claiming without evidence that the recommendation should be removed because
>>> encrypted group operations have a "real cost" that is "clearly
>>> prohibitive". This sort of thinking becoming common is what I think we
>>> should try to avoid, and why the recommendation should stay. I'm working on
>>> such an MLS deployment <https://xmtp.org/roadmap>. The cost is minimal
>>> and it actually simplifies things quite a bit to assume nothing of the DS.
>>>
>>
>> Richard in fact did state evidence in his original message, specifically
>> that:
>>
>> 1. "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."
>> 2. "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)."
>>
>> Those certainly seem like "real costs". Do you think either of those
>> statements is untrue?
>>
>> Perhaps your argument is with "clearly prohibitive", but the relevant
>> evidence for that is that when the relevant IETF WG (MIMI) considered this
>> matter, they concluded that it was impractical to have encrypted group
>> operations. Of course, MIMI could be wrong about that, but then what you
>> should be doing is trying to convince them, and perhaps providing text
>> about why that analysis is incorrect, to go into this document. Absent
>> that, having a naked recommendation doesn't do anything meaningful to
>> impact people's behavior and, as I said, mostly makes the IETF look like it
>> doesn't have a consistent view.
>>
>> -Ekr
>>
>>
>>
>>
>>> On Tue, Jan 30, 2024 at 10:51 AM Richard Barnes <[e-mail]> wrote:
>>>
>>>> This brings us back to EKR's point about RFC 6919.  MLS supports those
>>>> things, but at real cost.  So yes, some applications might choose to take
>>>> on that cost, but to date, nobody has.  This document should be providing
>>>> guidance to implementors about how to make good engineering decisions, not
>>>> exhorting them to do the most confidentiality-preserving thing at all costs.
>>>>
>>>> BTW MIMI is making this decision intentionally -- it has already been
>>>> discussed pretty extensively, and the costs are clearly prohibitive.  The
>>>> considerations are documented in mailing list posts and minutes, and I'm
>>>> sure they will make it into the documents.  And nothing we write in this
>>>> document can compel that WG to do anything anyway, it's an informative
>>>> document.
>>>>
>>>> --RLB
>>>>
>>>> On Tue, Jan 30, 2024 at 8:19 AM Brendan McMillion <
>>>> [e-mail]> wrote:
>>>>
>>>>> 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
>>>>>>>
>>>>>>