Re: [MLS] Recommendation for encrypted group operations

[Eric Rescorla <[e-mail]>]

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