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

[Rohan Mahy <[e-mail]>]

On Fri, Apr 12, 2024 at 10:00 AM Eric Rescorla <[e-mail]> wrote:

>
> On Fri, Apr 12, 2024 at 9:17 AM Rohan Mahy <[e-mail]> wrote:
>
>>
>> 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.
>
If you are saying that we need to define the exact syntax of some data
which is signed by the client and needs to get distributed to the other
clients that conveys room state changes, then I agree.


> 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.
>
Let's say we have data structure D that says that Alice added Bob to the
room "clubhouse", and some data structure D' that includes D and a
signature over D.

So you would be OK with Alice sending:

- D' stapled to an MLS Commit with an embedded AppSync Proposal (or its
moral equivalent) with the hash of the resulting participation list after D
is applied

but not ok with Alice sending:

- an MLS Commit which includes D in an AppSync proposal directly?

If I understood you correctly, please explain why the latter is so
objectionable. If I didn't, please explain how the contents of D gets to
each of the clients and how/when the clients verify their participation
lists.

I will also point out that the former approach requires a lot of additional
protocol complexity and interaction with key material in the MLS domain or
derived from key material in the MLS domain in order to generate and verify
the signature on D'.

thanks,
-rohan