Re: [Mimi] Metadata Minimal MIMI (MIMIMI)

>
> 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 <ietf@raphaelrobert.com>
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 <
> konrad.kohbrok@datashrine.de> 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
>> Mimi@ietf.org
>> https://www.ietf.org/mailman/listinfo/mimi
>>
> --
> Mimi mailing list
> Mimi@ietf.org
> https://www.ietf.org/mailman/listinfo/mimi
>
>
>