Re: [Mimi] Metadata Minimal MIMI (MIMIMI)

[Konrad Kohbrok <[e-mail]>]

Good point. We’ve been a bit vague on how the key material is transported and what it actually looks like.

Both to avoid the linear upload-overhead for inviters that you describe and to enable an easier way for new members to join externally, we will want the server to assist in a similar way that it does with the group state. At the same time, we want FS and PCS s.t. new members can’t de-pseudonymize members who had left the group previously and members that are no longer in the group can’t de-pseudonymize members that join after they are gone.

We can do this (in true MLS-fashion) via a tree-shaped key-wrapping scheme (TreeWrap?), where each parent is a symmetric key which is used to encrypt (wrap) its children. In the leaves we have the keys that wrap the keys used to decrypt the leaf credentials. The tree consisting of wrapped keys (but none of the actual keys) is uploaded to the server. Only the key wrapping the root key is required to decrypt the whole tree and thus all leaf credentials. If a member leaves the group, its direct path in the tree is replaced by newly generated and wrapped keys. The wrappers around co-path keys also have to be re-created. If a member joins the group, the tree is expanded (potentially by creating a new root key by wrapping the previous root wrapper key), or they are inserted into a previously blank spot.

To summarize: On membership changes (in particular for removes), log(n) new wrapper ciphertexts have to be uploaded. New members have to download 2n-1 wrapper ciphertexts. Adders have to include the root wrapper key in the GroupInfo. External joiners need the root wrapper key to properly authenticate all group members.

I should note that we have not tested this yet. In our implementation we have some additional key management that is a bit more lax in terms of its FS/PCS guarantees.

Cheers,
Konrad

> Am 07.04.2024 um 21:47 schrieb Brendan McMillion <[e-mail]>:
> 
> On the contrary, the proposal is to use public messages so that the DS can do what it would normally do without pseudonyms: Parse the public messages and keep a copy of the GroupInfo/ Public tree on the server to maximise efficiency. In other words, adding a new member to a groups only requires the sender to send a Commit and a Welcome. The invited member can then fetch the ratchet tree from the server. Conversely, when using External Commits, new joiners can fetch the ratchet tree from the server.
> 
>  The document says, "For the new user(s), the key material can be transported along with the Welcome, e.g. via a GroupInfo extension." I understood this to mean that the connection key for each member of the group must be shared with joining users, encrypted in the GroupInfo. There is one connection key per member, so the encrypted portion of the Welcome scales linearly with the number of members. What am I missing here?
> 
> 
> On Sun, Apr 7, 2024 at 10:37 AM Raphael Robert <[e-mail]> wrote:
> Hi Brendan,
> 
> Thanks for the feedback, I’ll address your points inline:
> 
>> At first glance, it seems this approach has the same efficiency as using encrypted handshake messages. That is, when I add a user to a group, I need to upload an encrypted blob whose size scales linearly with the number of members in the group. Is that right?
> 
> 
> On the contrary, the proposal is to use public messages so that the DS can do what it would normally do without pseudonyms: Parse the public messages and keep a copy of the GroupInfo/ Public tree on the server to maximise efficiency. In other words, adding a new member to a groups only requires the sender to send a Commit and a Welcome. The invited member can then fetch the ratchet tree from the server. Conversely, when using External Commits, new joiners can fetch the ratchet tree from the server.
> 
>> I'm also concerned about the property that, if I'm ever added to even one group with a user, then I learn their connection key. Then I can use their connection key to de-anonymize them in any other group, regardless of whether I've been in that group or not.
> 
> 
> It's a valid concern, just ending up in a group with another member shouldn’t give that member access to you beyond that group. That’s why connection keys must only be shared in 1:1 connections and not in other groups. Obviously the draft is not specific enough in that regard at this point. We need to flesh this out some more.
> 
> Raphael
>  
>> 
>> On Fri, Apr 5, 2024 at 5:34 AM Konrad Kohbrok <[e-mail]> wrote:
>> Hi folks,
>> 
>> Raphael and I just uploaded an I-D with a proposal that sketches a pseudonym-based MIMI variant that aims to reduce MIMI’s metadata footprint. You can find it here: https://datatracker.ietf.org/doc/draft-kohbrok-mimi-metadata-minimalization/
>> 
>> We have been working on this approach for a while now and have already implemented and run a variant of what’s described in the I-D.
>> 
>> The I-D is quite high-level for now to make the concepts easier to grasp. If people are interested we can fill in gaps and add details in the next iterations.
>> 
>> Looking forward to continuing the discussion around metadata in the context of MIMI and any questions regarding our I-D!
>> 
>> Cheers,
>> Konrad
>> 
>> -- 
>> Mimi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mimi
>> -- 
>> Mimi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mimi
> 
> -- 
> Mimi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mimi