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

[Jon Crowcroft <[e-mail]>]

this sounds very cool....was just reminding myself of what guarantees
http makes (since yr dependent on it) and this article was a quick catchup
(for anyone else not paying enough attention like myself:-)
https://blog.cloudflare.com/stronger-than-a-promise-proving-oblivious-http-privacy-properties
cheers
jon

On Wed, Mar 27, 2024 at 7:51 AM Brendan McMillion <
[e-mail]> wrote:

> 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
>>>>>>>>
>>>>>>>> --
> Mimi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mimi
>