Re: [Mimi] Review of draft-ralston-mimi-protocol-02

[Eric Rescorla <[e-mail]>]

On Fri, Apr 12, 2024 at 9:17 AM Rohan Mahy <[e-mail]> wrote:

> Hi Eric,
> Sorry for the late reply. This message was stuck in my Outbox.
>
> Questions about your hash proposal inline:
>
> On Wed, Mar 20, 2024 at 3:56 PM Eric Rescorla <[e-mail]> wrote:
>
>>
>> On Wed, Mar 20, 2024 at 3:34 PM Rohan Mahy <[e-mail]> wrote:
>>
>>
>>> If you get a message adding 3 new clients belonging to Cathy, how long
>>> do you wait for the MIMI message which adds her to the participant list so
>>> you can compare the hash you received?
>>>
>>
>> You don't compare the hash. The purpose of the hash is merely to ensure
>> that everyone has the same MIMI state, but the MIMI layer is responsible
>> for looking into the MIMI state and the MLS layer is responsible for
>> looking into the MLS state.
>>
>
> The MIMI protocol is among providers. How would clients Alice, Bob, and
> Cathy get the hash of a MIMI message sent between Alice's provider and
> Bob's provider to add Bob as an authorized participant of a room in order
> (to incorporate it into the MLS state or corroborate it)? How would that
> hash be meaningful to clients Alice, Bob, and Cathy?
>

I think we're both agreed that there has to be some PDU that specifies the
new state of the room that ends up at the endpoints. This is what allows
them to decide whether a given MLS operation is permissible. MIMI will have
to define that PDU and the endpoints will need to understand it. Please let
me know if you disagree with that.

The disagreement we seem to be having is if that PDU should be carried
outside MLS (most likely wrapping an MLS message) or inside MLS (in this
draft as an MLS extension). I don't think there's anything in our charter
which precludes the former design.

-Ekr


-Ekr