Re: [MLS] Recommendation for encrypted group operations

[Brendan McMillion <[e-mail]>]

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