Re: [Mimi] Brendan's Partition Keys (was Re: Confirming adoption calls for draft-barnes-mimi-arch and draft-ralston-mimi-protocol)

[Brendan McMillion <[e-mail]>]

That's a great point! In terms of abuse mitigation, the value of the
partition key is that it prevents unwanted writes to the /most recent/
epoch. You can still try to write junk to previous epochs where you were in
the group and you knew the partition key. If clients have been offline in
the intervening time, they might still need to process the epochs that
you're filling with junk. But /past/ epochs end with a Commit, and honest
clients can stop reading once they get to the Commit.

So the guidance then would be that pushing a non-leaf epoch, either
hub->RSP or RSP->user, is always fine. (Remembering that without the hub
enforcing a linear sequence of epochs, you have a digraph of epochs
instead, so maybe multiple leafs.) Pushing leaf epochs from hub->RSP risks
opening yourself up to spam from a malicious provider, but maybe that's not
a realistic danger


On Thu, Mar 28, 2024 at 11:21 PM Rohan Mahy <[e-mail]> wrote:

> Sorry, I typed "privacy keys" instead of "partition keys" in a few places
> in my message.
>
> Brendan's gist uses partition keys between the RSP and the hub. I think
> this is a bad idea because of the extra rountrips needed when an offline
> client comes back online and the potential privacy leakage. That doesn't
> mean it wouldn't be potentially useful between the RSP and its client, or
> as an internal filtering mechanism among messages on the client.
> Thanks,
> -rohan
>
>
>
> On Thu, Mar 28, 2024, 22:14 Rohan Mahy <[e-mail]> wrote:
>
>> Hi Brendan,
>> I realized that the privacy keys in your gist have some negative
>> implications for offline use and also leak private timing information.
>>
>> A partition key is a short secret exported from the MLS key schedule.
>>> Whenever users send or receive group messages, they provide the partition
>>> key for the current epoch. Messages sent with a given partition key are
>>> only provided to users who request to receive messages with the same
>>> partition key. (Exceptions may be selectively made for external commits /
>>> proposals, given that the sender isn't in the group yet.)
>>
>>
>> So if a user is offline and was "subscribed" to the privacy key for group
>> "clubhouse" in epoch 13, its RSP will receive app messages in that group
>> and the Commit that moves it to epoch 14, however the RSP won't request
>> anything for subsequent epochs while its client is offline. The hub has to
>> keep messages as long as the longest period that an individual client on
>> any of the providers can be offline. It also means a client will need
>> several round trips to subscribe for messages as a busy group transitions
>> from epoch to epoch. This is not great for the user experience, especially
>> if the client is on a high-latency connection.
>>
>> If the RSP has relatively few users, this also leaks a lot of timing
>> information about when clients of the RSP are online and offline.
>>
>> 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
>>>>>>
>>>>>> --
>> Mimi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mimi
>>
>