Re: [Mimi] Confirming adoption calls for draft-barnes-mimi-arch and draft-ralston-mimi-protocol

[Rohan Mahy <[e-mail]>]

Hi Brendan,
Thanks very much for sharing this. This is generally the right level of
detail and helps a lot for understanding where you are coming from.

A few questions and reactions:
- Could you please elaborate on the construction of the bearer tokens? If
not done correctly, this can easily leak as much metadata as the design
team proposal.
- How does the hub know when to stop sending messages to an RSP?
- What happens if a hub forwards an invalid/unacceptable commit (not
related to an unwanted Welcome) and all the other clients are offline? How
does "rollback" work? (Note the current proposal will also need to address
a subset of this same problem)
- Are partition keys shared with any of the providers? If so, how do they
use them? If not, what benefit do they provide?
- In the self Remove case, an external commit can ignore the proposal,
leaving the client in the MLS group, unless it a) uses SelfRemove, b)
continues to monitor the group for a Commit showing its removal, or c) uses
an extension to insist that external commits include queued proposals.
- Do you envision that handshakes on the hub are always either always
private or always public for a single MLS group/MIMI room, or could they be
a mix?

Thanks,
-rohan



On Tue, Mar 26, 2024 at 12:14 PM Brendan McMillion <
[e-mail]> wrote:

> Hi Rohan
>
> Sure, here's a general approach that I think would meet mimi's goals
> better: https://gist.github.com/Bren2010/d009ba8d702ae3428b31981295455f02
>
> It's hard for me to see how the pseudonyms approach could possibly be
> fruitful. If the reason for requiring PublicMessage is performance (i.e.
> having clients upload a linear amount of encrypted data is too expensive
> for them), how could a pseudonym scheme possibly authenticate a linear
> number of members with sublinear data? Say that it is possible -- why
> couldn't this same encryption scheme just be applied directly to the
> ratchet tree, instead of adding a layer of indirection that risks voiding
> the security of all of MLS?
>
> If the reason for requiring PublicMessage is to support policy
> enforcement, then obviously we don't trust clients to do this themselves.
> But if we don't trust clients, the approach of inspecting handshake
> messages and trying to actively track the group state actually makes the
> protocol more brittle and vulnerable to abuse. The hub server can't verify
> group state, so a single malformed message can brick the group in
> innumerable different ways and there's nothing that can be done to recover.
> If the hub server was out of the way, instead of enforcing it's own idea of
> who's in the group and which epoch is most recent, honest clients can
> recover from malicious behavior in a straightforward way.
>
>
> On Sun, Mar 24, 2024 at 3:11 PM Rohan Mahy <[e-mail]> wrote:
>
>> Hi Brendan,
>>
>> You characterized the state of the current draft as "freely" sharing a
>> lot of metadata with all the providers. I'd like to examine that a bit more.
>>
>> Assuming each client follows the recommendation in the draft to use a
>> unique pseudonym per group (this implies only joining via join/invitation
>> links or knocks), the non-local providers know the following:
>> - the authorization policy of the group (broadly),
>> - how many MLS clients from each provider are in each group,
>> - how often each client sends messages,
>> - the authorization role(s) assigned to their anonymized users, and
>> - (if they reveal it) if there are multiple devices under the same
>> pseudonym.
>>
>> While a user's local provider (which the user has chosen) is sort of
>> outside of the scope of MIMI, when it is a hub provider it will at least
>> need to disclose machine-readable privacy information for each of its
>> rooms. Each client gets to examine the room policy before they join and
>> before they accept any change to that policy. This is already way better
>> than the status quo. The metadata privacy extensions that Konrad and
>> Raphael are working on further improve the privacy situation.
>>
>> If you think this is setting the privacy bar too low, I think it would be
>> reasonable to provide an outline of how you think MIMI could provide
>> similar functionality with even less metadata. IMO this doesn't need to be
>> an I-D, but at least a page-long email with bullet points.
>>
>> Thanks,
>> -rohan
>>
>> On Sat, Mar 23, 2024 at 3:45 PM Brendan McMillion <
>> [e-mail]> wrote:
>>
>>> Providing the same privacy properties as Signal is incredibly difficult.
>>> Nobody is asking mimi to do that. However, the mimi protocol could be a
>>> neutral way for service providers to synchronize messages related to a
>>> given group. Whether a service provider chooses to receive messages in some
>>> exceptionally private way or not, would be the service provider's choice.
>>> But instead the drafts require duplicating state between the encryption
>>> layer and mimi layer, and this presupposes a certain inescapable amount of
>>> metadata leakage.
>>>
>>> On Sun, Mar 24, 2024 at 1:49 AM Rohan Mahy <[e-mail]> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Mar 23, 2024, 02:38 Stephen Farrell <[e-mail]>
>>>> wrote:
>>>>
>>>>> Sounds like a classic loss for privacy.
>>>>>
>>>>
>>>> I argue it is the opposite. Today if you want to join a group chat on
>>>> any system other than Signal, the participants surrender much more metadata
>>>> than would be revealed to other providers under the proposed MIMI approach
>>>> with pseudonyms. In addition, the low metadata approaches (using techniques
>>>> such as privacy pass) that Konrad and Raphael are nurturing offer
>>>> substantial improvements to privacy.
>>>> If we publish a specification that requires all providers to provide at
>>>> least Signal-level metadata privacy, it is likely that we will end up with
>>>> neither interoperability nor privacy for the vast majority of users.
>>>> Thanks,
>>>> -rohan
>>>>
>>>>