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

Rohan Mahy <rohan.mahy@gmail.com> Tue, 07 May 2024 02:54 UTC

Return-Path: <rohan.mahy@gmail.com>
X-Original-To: mimi@ietfa.amsl.com
Delivered-To: mimi@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 09A0BC14F6BA for <mimi@ietfa.amsl.com>; Mon, 6 May 2024 19:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Status: No, score=-7.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BmRodUUG-tJ6 for <mimi@ietfa.amsl.com>; Mon, 6 May 2024 19:54:41 -0700 (PDT)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09271C14F6B5 for <mimi@ietf.org>; Mon, 6 May 2024 19:54:41 -0700 (PDT)
Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a59c04839caso504759366b.2 for <mimi@ietf.org>; Mon, 06 May 2024 19:54:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715050479; x=1715655279; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Tey0Xd/m0dVJaKa5Mi3Y4SEjKdSZ7Q8y+sHp38gxeHc=; b=Tf2GtgHKMN08jGrpFKXQa16AL3r9xVE5vCKCIBN76TLozzhPYdkgI6/yrux1cWAxtF AgjqfL/sV/5uiQ4Mf9EtpZujK745D2dWHxzVEZm0Ahu7A4SMI25ElRlaC9H7TtUoQ/5h ARrVOzOZlOcUgjuYOColWcwfrC+t44kfzSCZLGvokoRGBDLukxs4dVJW9MzHi4l8DBWw mA/EBD+pCd43hj+5racmWxXNzeDR1aC28KRUwSeMna6MbWaDYhwbkn+4sPOgMSHyDAmy DafWxdJln60NAVXIRIz8mQJqjN8Dphrs8tkFuUtaEm+QSucsls1oYRzf+0hWBDb1hB5u 3ezg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715050479; x=1715655279; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Tey0Xd/m0dVJaKa5Mi3Y4SEjKdSZ7Q8y+sHp38gxeHc=; b=NfVK2SwlQUoI7TjQUqizaJPWR5wP/N53qMIQre0KilAnpwVgPh33vKBiD+PLcX5xed DNxAOSXCnUinMLoK7nvFZbLru8goA3uurQk6LcxBmUu/V+J40m7nhP9zHU1x/zHrulC0 z3zrD2mocXQtwmjk1Wx62nZFB+891mtl0SqbsEDaZ3vex3trmspLC2KHsuM6sle+So/D 49mlfnuT4+cvXe4l0/zp8jPsiDmmRtI0OVYFh9zKaOTz0AEhFhj0u+LNqPjTXg9WpdrF SRpxt5T+XWz8p7M4jAcwlad5M3iOBe+NAGzReveAPaKlld22rl4KEAnGIszINh/DnXjt r6FQ==
X-Forwarded-Encrypted: i=1; AJvYcCUX6RgT/VcMF92IyxUGTf2IyxMu57tCVP5R8sOMMuwmmDvmGCQq20hEkEF0W2M2z2fhsTs1VwxJBYr/f3fm
X-Gm-Message-State: AOJu0Yzus4dM3ApetozJJtEeaC62jr94QELNixz8Pr7bR75rBM+fbq/M vsdSSzwE6f/a4WRXNbiIuLgOm+CajqXiv+llLkYSkFcdffXyo8SA36OwieXnOqvyW/RwIEbTBqT yqKQp8755WVXPIR7s378Upyg0l2mQbQ==
X-Google-Smtp-Source: AGHT+IGtg3ZZNymm0xBi7cc4QNXMtjaeGh5LDlMW9ekIBbeGWmeYdXFwXiabSIBJFakhtE8wrfGq9DbcokjhYyHfFO0=
X-Received: by 2002:a17:907:eab:b0:a59:b6a8:4d7a with SMTP id ho43-20020a1709070eab00b00a59b6a84d7amr4659388ejc.43.1715050478901; Mon, 06 May 2024 19:54:38 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBPoi0Vp=GPaNAwg8YXVfizZLqF2ARnR-PwD1PWzbaaPeA@mail.gmail.com> <CAKoiRubo9OGMzeO_JLoUaiOCUxXY28Ges1Te2yj4mrxYdtijnA@mail.gmail.com> <CABcZeBMqW6UsLSCbDdj4y5LYR_7DgOVXUsrS5rFVNSaZ4Td1XA@mail.gmail.com> <CAKoiRubS1-e-pV0tde=KP5pH65CgVY4ThY4jfWgz0BE44m3V6g@mail.gmail.com> <CABcZeBOG0Hxzz3MNTiMphvTFBtO9xprGUnEZ5J8eGzg83aCw8w@mail.gmail.com> <CAKoiRuZVWyTREfh9nd2OEub_Jwfytmiugq1pGpnvUnfZnz_kVw@mail.gmail.com> <CAKoiRubbS-zDHSX4o=DXABSw08yH=rL9OceF4vS6iNWEMzHz-A@mail.gmail.com> <CAL02cgTo_OHWf-zd2jthU2_Yg3L0OcfedprWsFO+F27AF-sz1w@mail.gmail.com>
In-Reply-To: <CAL02cgTo_OHWf-zd2jthU2_Yg3L0OcfedprWsFO+F27AF-sz1w@mail.gmail.com>
From: Rohan Mahy <rohan.mahy@gmail.com>
Date: Mon, 06 May 2024 19:54:27 -0700
Message-ID: <CAKoiRuY+AuwKEobDX42cJk=Ej=MepxgPTwParXy9gyapnaYH=w@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: multipart/alternative; boundary="0000000000009123240617d44e6a"
X-MailFrom: rohan.mahy@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Eric Rescorla <ekr@rtfm.com>, mimi@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Mimi] Re: Review of draft-ralston-mimi-protocol-02
List-Id: More Instant Messaging Interoperability <mimi.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mimi/Smbvtw4MgB4fLog2zuFC1z7lJ8A>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mimi>
List-Help: <mailto:mimi-request@ietf.org?subject=help>
List-Owner: <mailto:mimi-owner@ietf.org>
List-Post: <mailto:mimi@ietf.org>
List-Subscribe: <mailto:mimi-join@ietf.org>
List-Unsubscribe: <mailto:mimi-leave@ietf.org>

Thanks for writing your thoughts down Richard. Two quick comments below:

I think there is a missing requirement from the list that we discussed in
the design team. Both Wire and Wickr experienced substantial implementation
pain dealing with signaling and MLS messages arriving non-simultaneously. I
think it is a requirement that both messages can arrive at the same time
(either in the same message or stapled).

One thing that did not seem particularly clear to me from your analysis is
which providers get to see the room metadata in practice with any of these
approaches (except A or D). Since the MIMI interface is only a
provider-to-provider interface, what do the clients need to do other than
generate MLS messages consistent with the room policy? How does the client
get keys with which to encrypt traffic to the hub? How are the local and
follower providers excluded from these interactions when they are
gatewaying to a likely proprietary protocol?


On Mon, May 6, 2024 at 6:31 PM Richard Barnes <rlb@ipv.sx> wrote:

> I sat down this afternoon and thought through this a little.  Here is a
> small essay...
> # Recap
> Before I get into analysis on this, let me try to recap the requirements
> and the proposals that are on the table:
> Requirements:
> 1. We need a message that changes the state of the room
> 2. It needs to be readable by the hub, so that it can enforce policy and
> update its representation of the room state.
> 3. It needs to be readable by endpoints, so that they can update their
> representation of the room state.
> 4. It needs to be signed by the sender, so that the hub and endpoints can
> verify its authenticity and policy compliance.
> 5. Any endpoint or server involved in the room needs to be able to
> generate a state-change message.
> 6. The state of the room after the update needs to be confirmed in the MLS
> key schedule.
> Proposal A [what's in the document now]:
> * The state change is encoded as an AppSync proposal, wrapped in an MLS
> PublicMessage struct
> * By virtue of being PublicMessage:
>   * (2,3) It is readable by the hub and endpoints
>   * (4) It is signed by its sender
>   * (5) Servers can sign messages using the MLS "external signer"
> functionality
> * (6) The MLS stack maintains a state representation, updates it in
> response to the proposal, and includes it in the key schedule
> Proposal B [what EKR seems to be proposing]:
> * The state change is encoded in an encapsulation to be designed, but not
> as an MLS handshake message (Proposal or Commit)
> * That encapsulation would have the following features:
>   * (2,3) It is encrypted so that it is only readable by the hub and
> endpoints
>   * (4) It is signed by the sender
>   * (5) Somehow endpoints and servers are configured to trust servers
> * (6) The new state of the room is fed into the key schedule via a
> mechanism to be designed
>   * e.g., making a PSK that is a hash of the room state
> Note that RFC 9420 forbids sending application data as PublicMessage.
> Together with requirement (2), that means that in Proposal B, we can't
> simply use PublicMessage as the encapsulation.
> # Analysis
> Both of these have some appealing properties to me:
> * Proposal A requires the least amount of invention.
>   * PublicMessage provides a suitable set of cryptographic mechanisms and
> we just use them.
>   * Whatever encapsulation we design for Proposal B would basically
> reinvent these mechanisms.
> * Proposal B puts the application state handling in the right place.
>   * Making the MLS stack aware of the structure of the application state
> (as now) is pretty gross.
>   * Making the application state opaque to MLS, while still using a
> proposal, requires more interaction between the MLS and application logic.
>   * Better to have the application do its thing, and then shove thing into
> the MLS stack at the end.
> Overall, my preference would be to keep the state changes opaque to MLS
> (so either not a Proposal or a Proposal passing opaque data), but also to
> avoid reinventing a bunch of new mechanism.
> # Some Other Alternatives
> Here are a few other alternatives that seem to split the difference here:
> Proposal C: Allow PublicMessage application data in MLS, and define a
> mechanism for importing a commitment to the state into the group.  Allowing
> PublicMessage would be a simple extension to write, just a flag that says
> "PublicMessage application data is OK".  Importing the state could be as
> simple as synthesizing a PSK.
> Proposal D: Continue to use a Proposal, but make the contents opaque to
> the MLS stack.  The flow would be basically the same as with an application
> message, except that instead of asking for an application message, the
> application logic would ask for an AppSync proposal carrying its opaque
> data.  I would note that the `mls-rs` stack actually already supports this
> pattern [1].
> Proposal E: A more radical proposal would be to have the endpoints
> maintain a second MLS group, **which also includes the hub**.  In this
> group, application data that needs to be visible to the hub could be sent
> as PrivateMessage, since the hub would have the keys.  This group could
> also be a helpful tool for designing more private operations, since it
> could be used to deny non-hub servers access to information they don't need.
> I think the ordering here more or less matches my preference ordering (C >
> D > E).  Proposal E could be more compelling if folks thought there were
> other privacy benefits to having that extra group around.
> [1]
> https://docs.rs/mls-rs/latest/mls_rs/group/proposal/struct.CustomProposal.html
> On Mon, May 6, 2024 at 1:38 PM Rohan Mahy <rohan.mahy@gmail.com> wrote:
>> Hi Ekr,
>> Any response to my question below?
>> Thanks,
>> -rohan
>> On Fri, Apr 12, 2024 at 11:10 AM Rohan Mahy <rohan.mahy@gmail.com> wrote:
>>> On Fri, Apr 12, 2024 at 10:00 AM Eric Rescorla <ekr@rtfm.com> wrote:
>>>> On Fri, Apr 12, 2024 at 9:17 AM Rohan Mahy <rohan.mahy@gmail.com>
>>>> wrote:
>>>>> On Wed, Mar 20, 2024 at 3:56 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>>>>> On Wed, Mar 20, 2024 at 3:34 PM Rohan Mahy <rohan.mahy@gmail.com>
>>>>>> 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
>> --
>> Mimi mailing list -- mimi@ietf.org
>> To unsubscribe send an email to mimi-leave@ietf.org