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

["Hale, Britta (CIV)" <[e-mail]>]

Metadata risk to users is certainly a consideration that we should be cognizant of. I also agree that MIMI should take an active role in minimizing it. Without having surveyed potential providers, especially beyond those which have already adopted/deployed MLS, it is not possible to make concrete conjectures about the boundary line where metadata minimization will discourage MIMI use and interoperability. What we do know is that security and privacy awareness and support has increased over the years, and consequently assuming an unnecessary low bar among providers may be doing everyone – especially end users – a disservice. Regulating metadata protections to select, “privacy aware” applications brings to mind the stereotypical argument for encryption only being necessary for paranoid users and select high-assurance applications, an argument we all recognize risks from.

That said, the MIMI efforts so far in pseudonyms, etc., are quite positive steps towards metadata minimization and I hope that we can continue to work on decreasing metadata risk / increasing protections to the greatest degree that can be widely supported, as well as identifying exactly what that is. Identifying that ‘level’ will take further conversations. Still, that that does not conflict with adopting this draft – adoption does not mean that work is finished, i.e.,  we are not at last-call. Moreover, during IETF-118 several arguments were made for moving forward with adoption of a base document in a timely manner given the DMA timeline motivation. Consequently, I support adoption.

Britta


From: Mimi <[e-mail]> on behalf of Brendan McMillion <[e-mail]>
Date: Saturday, March 23, 2024 at 6:45 PM
To: Rohan Mahy <[e-mail]>
Cc: Stephen Farrell <[e-mail]>, Richard Barnes <[e-mail]>, Suhas Nandakumar <[e-mail]>, Travis Ralston <travisr=[e-mail]>, Alissa Cooper <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Mimi] Confirming adoption calls for draft-barnes-mimi-arch and draft-ralston-mimi-protocol

NPS WARNING: *external sender* verify before acting.

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]<mailto:[e-mail]>> wrote:

On Sat, Mar 23, 2024, 02:38 Stephen Farrell <[e-mail]<mailto:[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