Re: [Mimi] Confirming adoption calls for draft-barnes-mimi-arch and draft-ralston-mimi-protocol

Rohan Mahy <rohan.mahy@gmail.com> Sun, 24 March 2024 22:11 UTC

Return-Path: <rohan.mahy@gmail.com>
X-Original-To: mimi@ietfa.amsl.com
Delivered-To: mimi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAABBC14F616 for <mimi@ietfa.amsl.com>; Sun, 24 Mar 2024 15:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Qdsu7ed9Ocv for <mimi@ietfa.amsl.com>; Sun, 24 Mar 2024 15:11:16 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 28B02C14F5E7 for <mimi@ietf.org>; Sun, 24 Mar 2024 15:11:16 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-513dc99b709so4695308e87.1 for <mimi@ietf.org>; Sun, 24 Mar 2024 15:11:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711318274; x=1711923074; 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=XxrKKfVv4hT7fioGoey0Y3Jhsf6jzA7YNYoRl9FfGDQ=; b=SEydKR0ovJySaZQeox5fTrgE1We5WJ8ZR2/joHoF6ANjHqlQOPFSBa8KFT+Q6ppsrs Jwe+Cr59n0y164u0zVi8YmfKtn9lHKiQRITr0AJv7ALmgzjfrng9ZHwX3nYvjUX2quAV m4/EEeWYMUtWF7Xtrjv08VjoUe32pjA1UnuurF5Y35MFwTYKKkKtc36oUqN5Gs3kbaYp M3BqbAU85m/tc/ihvYiNqvRKqJLNxKoJb4bOCFpdweSXWMzw+bHU6r31YOBirF0AWAZ6 LY+q6wAaXFWwEhS3zchToje1H1l0CkNfcTUQSVrnVwweVvyGAxc7U0rM/CQaa/GzRDHv pHtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711318274; x=1711923074; 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=XxrKKfVv4hT7fioGoey0Y3Jhsf6jzA7YNYoRl9FfGDQ=; b=nASk3mFPHp1fRijv+v0BdIZRhmLesMsk0rKFfl9+MeIrdg0802YrVxSZv6f1wp3lRp 89Bn2v1EyNlg3XlpJ7KGIcCwwfgp7QpioXuwiAjiAGwLhNP06Me2H+DKVAjkjH/q6ZEt N7Ax86WPbV6arEOHNnn9zgb+DCi8dggHDkEhpNQhPuafBnZ66kIlpl4XNHT+svlbLf+y YTRb7W5X7y8YszpRrh4fv5QhbtXbr7Z9sd4XzAj2+l5u3EsHaLh703OvQLvEqvA0VG3Y As+MsfUu6LE72IQCvehvfiuKEKAouwa0LF03kq+8VAnhzMk8OhSN2o7Vg5IF5JxUZfSU iS1A==
X-Forwarded-Encrypted: i=1; AJvYcCVexHUjXrQHmiWIrTo/YVwyl8KYDC30A5EKoX8wMgf2Ug2VHJ06DXuZTz5vqT0rIK+36EqA5NY7w9VJzWf8
X-Gm-Message-State: AOJu0YxFb6eh2aCIIFFE5pAaLP9ny3hlazQi3lPlIL6oA4gRj6OO0bki 7OdKlRkh9h+gJUEInsiCXOXMYuGUW9mWg3R8Zef42r9uDMXxJsEf3WnHqNAWYLpDETFAwm8dzJk Jk0xCgphIHvDHXHanDxkqcu6HySic5eQN8t4=
X-Google-Smtp-Source: AGHT+IEnxF1fOasUExwADVW/QtUGOakrWNSUuFlryUucYgswaMUQV9PrrruWj8tg8nw2x6o3WGjhzQoS6NtrgmkbXpY=
X-Received: by 2002:a19:5f11:0:b0:513:def:9c8a with SMTP id t17-20020a195f11000000b005130def9c8amr2664896lfb.69.1711318273986; Sun, 24 Mar 2024 15:11:13 -0700 (PDT)
MIME-Version: 1.0
References: <8C305FF1-41E2-4E60-94CF-B15A5EEBFC03@cooperw.in> <CAKoiRuYse46M5TiCoCgMhuW=MZrAmfJf0KUkZGX20PJVUmM66Q@mail.gmail.com> <CANd9WG55weUzkDA5MjKxS8cEg=dAaqVOyEsVxEO7p0wA7J7yNw@mail.gmail.com> <CAMRcRGT_hqdO_AEg4oHgmN_sFrpQoPyxuU20Snt1S1Y5ym0qHA@mail.gmail.com> <CAJTd26JOvqpuakznGK5dqUEX2wW1FhvS==Zk+oZKvWgtq+cPFg@mail.gmail.com> <CAL02cgTd=5GCcLpKqB5=XgFq-geUuFrFW-2Cu84F7=3QLdTdLA@mail.gmail.com> <54e875bb-6a35-4879-b7f7-2a33da96b4b4@cs.tcd.ie> <CAKoiRubSCrRrAxDDmpLC8xUdzk3eNUOxBSz0ra6vi_qf95Jvcg@mail.gmail.com> <CAJTd26+pSCwjbQLAQyjMG73tDMPSwFTVt-ZaSOvDtokNXxZazw@mail.gmail.com>
In-Reply-To: <CAJTd26+pSCwjbQLAQyjMG73tDMPSwFTVt-ZaSOvDtokNXxZazw@mail.gmail.com>
From: Rohan Mahy <rohan.mahy@gmail.com>
Date: Sun, 24 Mar 2024 15:11:02 -0700
Message-ID: <CAKoiRuZ73o7aK8aX8WTArHujy_6EYaGoQqnWfzO_a1-ihrb0rw@mail.gmail.com>
To: Brendan McMillion <brendanmcmillion@gmail.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Richard Barnes <rlb@ipv.sx>, Suhas Nandakumar <suhasietf@gmail.com>, Travis Ralston <travisr=40matrix.org@dmarc.ietf.org>, Alissa Cooper <alissa@cooperw.in>, mimi@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d19bc406146f55af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mimi/YxGAoxBttqtcl3aUpzLlGCfpSmU>
Subject: Re: [Mimi] Confirming adoption calls for draft-barnes-mimi-arch and draft-ralston-mimi-protocol
X-BeenThere: mimi@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: More Instant Messaging Interoperability <mimi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mimi>, <mailto:mimi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mimi/>
List-Post: <mailto:mimi@ietf.org>
List-Help: <mailto:mimi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mimi>, <mailto:mimi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Mar 2024 22:11:17 -0000

Hi Brendan,

You characterized the state of the current draft as "freely" sharing a lot
of metadata with all the providers. I'd like to examine that a bit more.

Assuming each client follows the recommendation in the draft to use a
unique pseudonym per group (this implies only joining via join/invitation
links or knocks), the non-local providers know the following:
- the authorization policy of the group (broadly),
- how many MLS clients from each provider are in each group,
- how often each client sends messages,
- the authorization role(s) assigned to their anonymized users, and
- (if they reveal it) if there are multiple devices under the same
pseudonym.

While a user's local provider (which the user has chosen) is sort of
outside of the scope of MIMI, when it is a hub provider it will at least
need to disclose machine-readable privacy information for each of its
rooms. Each client gets to examine the room policy before they join and
before they accept any change to that policy. This is already way better
than the status quo. The metadata privacy extensions that Konrad and
Raphael are working on further improve the privacy situation.

If you think this is setting the privacy bar too low, I think it would be
reasonable to provide an outline of how you think MIMI could provide
similar functionality with even less metadata. IMO this doesn't need to be
an I-D, but at least a page-long email with bullet points.

Thanks,
-rohan

On Sat, Mar 23, 2024 at 3:45 PM Brendan McMillion <
brendanmcmillion@gmail.com> wrote:

> Providing the same privacy properties as Signal is incredibly difficult.
> Nobody is asking mimi to do that. However, the mimi protocol could be a
> neutral way for service providers to synchronize messages related to a
> given group. Whether a service provider chooses to receive messages in some
> exceptionally private way or not, would be the service provider's choice.
> But instead the drafts require duplicating state between the encryption
> layer and mimi layer, and this presupposes a certain inescapable amount of
> metadata leakage.
>
> On Sun, Mar 24, 2024 at 1:49 AM Rohan Mahy <rohan.mahy@gmail.com> wrote:
>
>>
>>
>> On Sat, Mar 23, 2024, 02:38 Stephen Farrell <stephen.farrell@cs.tcd.ie>
>> wrote:
>>
>>> Sounds like a classic loss for privacy.
>>>
>>
>> I argue it is the opposite. Today if you want to join a group chat on any
>> system other than Signal, the participants surrender much more metadata
>> than would be revealed to other providers under the proposed MIMI approach
>> with pseudonyms. In addition, the low metadata approaches (using techniques
>> such as privacy pass) that Konrad and Raphael are nurturing offer
>> substantial improvements to privacy.
>> If we publish a specification that requires all providers to provide at
>> least Signal-level metadata privacy, it is likely that we will end up with
>> neither interoperability nor privacy for the vast majority of users.
>> Thanks,
>> -rohan
>>
>>