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

[Brendan McMillion <[e-mail]>]

>
> To be clear, under this approach the LSP knows Alice wants to talk to Bob,
> and the RSP might know or require that it knows. It sounds like the salient
> difference is that the *hub* does not know Alice wants to talk to Bob.
>

The LSP should only be able to see "Alice wants to talk to one of
RSP's users" because of the masking provided by OHTTP. The privacy property
I generally want is that no service provider should need visibility into
another provider's users

Maybe I need to step back a bit. You said the hub is responsible for
> message ordering. If the hub gets a series of commits moving to epoch 13,
> then to epoch 14, then to 13, then to 15, then to 14, does the hub send
> these in the order it received them, or does it assume a particular epoch
> is current until told otherwise?


Note that the partition key changes each epoch. A user starting at epoch 13
would process the commit at epoch 13, compute the new partition key, then
share that with its LSP. The LSP would get the commit for epoch 14 with the
same partition key, the user would process it, compute the new partition
key, share that with its LSP. And so on. This is how users would
navigate forks in the group state. It requires one roundtrip per epoch, but
the server could always do an http/2 push if it's confident what the next
request will be.

If there are several commits in the same epoch, that's obviously easier.
The hub just provides them in the order received and the first valid one is
the winner.

Is there no authentication required by the hub then? It sounds like the
> only DoS prevention from a compromised but previously honest LSP is rate
> limiting.


Yes, such a service provider could push junk data to the hub. Assuming none
of the service provider's users are members of the group anymore, then none
of the spam would be seen by group members, as the correct partition key
wouldn't be known. You would trigger the abuse mitigation, as you would be
sending a bunch of data to partition keys that nobody seems to be reading.

On Tue, Mar 26, 2024 at 10:12 PM Rohan Mahy <[e-mail]> wrote:

> Thanks, this helped. Three more comments inline.
>
> In the current draft, KeyPackage requests contain both the requesting
>> user's and the target user's identity, and the request is proxied plaintext
>> through several providers. Everyone in the system can see "Alice wants to
>> talk to Bob." By making KeyPackage requests over OHTTP, only the RSP can
>> see "Someone wants to talk to Bob." The RSP might assign bearer tokens so
>> that it knows "Someone" is "Alice", but it also could not. The point is the
>> RSP has control over the anonymity set, and can define it in a way that
>> protects privacy + works with their abuse mitigation.
>
> To be clear, under this approach the LSP knows Alice wants to talk to Bob,
> and the RSP might know or require that it knows. It sounds like the salient
> difference is that the *hub* does not know Alice wants to talk to Bob.
>
> - 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)
>>
> When honest clients come online, they will ignore the invalid commit. The
>> user that sent the invalid commit will either a.) keep sending messages to
>> the old epoch, or b.) start sending messages to a new epoch with a new
>> partition key. Because the honest clients ignored the commit, they will
>> never see/request the messages that went to the new partition key.
>> Repeatedly messaging an epoch after sending a Commit, or sending messages
>> to a partition key that nobody ever reads, should signal abuse to the
>> service provider.
>
> Maybe I need to step back a bit. You said the hub is responsible for
> message ordering. If the hub gets a series of commits moving to epoch 13,
> then to epoch 14, then to 13, then to 15, then to 14, does the hub send
> these in the order it received them, or does it assume a particular epoch
> is current until told otherwise?
>
> A hub will accept group messages from any RSP that knows the group ID.
>
>
> Is there no authentication required by the hub then? It sounds like the
> only DoS prevention from a compromised but previously honest LSP is rate
> limiting.
>
> Cheers,
> -rohan
>
>
> On Tue, Mar 26, 2024 at 6:58 PM Brendan McMillion <
> [e-mail]> wrote:
>
>> Responses inline,
>>
>> On Tue, Mar 26, 2024 at 1:32 PM Rohan Mahy <[e-mail]> wrote:
>>
>>> 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.
>>>
>>
>> In the current draft, KeyPackage requests contain both the requesting
>> user's and the target user's identity, and the request is proxied plaintext
>> through several providers. Everyone in the system can see "Alice wants to
>> talk to Bob." By making KeyPackage requests over OHTTP, only the RSP can
>> see "Someone wants to talk to Bob." The RSP might assign bearer tokens so
>> that it knows "Someone" is "Alice", but it also could not. The point is the
>> RSP has control over the anonymity set, and can define it in a way that
>> protects privacy + works with their abuse mitigation.
>>
>> The idea of authing with a bearer token that corresponds to an anonymity
>> set is a core part of how Sealed Sender works. Allowing users to /verify/
>> that they're in an anonymity set isn't required
>>
>>
>>> - How does the hub know when to stop sending messages to an RSP?
>>>
>>
>> If an RSP doesn't have any users that are asking for the messages for a
>> group, the RSP will simply stop pulling messages / revoke consent for push
>> requests. This is independent of the MLS state.
>>
>>
>>> - 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)
>>>
>>
>> When honest clients come online, they will ignore the invalid commit. The
>> user that sent the invalid commit will either a.) keep sending messages to
>> the old epoch, or b.) start sending messages to a new epoch with a new
>> partition key. Because the honest clients ignored the commit, they will
>> never see/request the messages that went to the new partition key.
>> Repeatedly messaging an epoch after sending a Commit, or sending messages
>> to a partition key that nobody ever reads, should signal abuse to the
>> service provider.
>>
>>
>>> - Are partition keys shared with any of the providers? If so, how do
>>> they use them? If not, what benefit do they provide?
>>>
>>
>> Users share a (group id, epoch, partition key) triplet with their LSP;
>> the LSP sends/requests messages from the hub based on this triplet. The
>> flow is unidirectional -- users only ever provide partition keys to their
>> LSP, the LSP only ever provides them to the hub. The hub uses the provided
>> partition key to gate which messages it provides back to the LSP, and the
>> LSP uses the partition key to gate which messages it provides back to the
>> user.
>>
>>
>>> - 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.
>>>
>>
>> Yes, these are all valid approaches imo. You would just need an extension
>> point to make (a) or (c) implementable
>>
>>
>>> - 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?
>>>
>>
>> My initial idea is that maybe clients could negotiate public/private
>> based on preferences expressed in a LeafNode extension. But the protocol
>> between service providers is neutral to this -- an unencrypted Commit +
>> GroupInfo is shuffled around the same as an encrypted Commit. Maybe you
>> would have some special compression for transmitting the ratchet tree
>>
>>
>>>
>>> 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
>>>>>>>
>>>>>>>