[Mimi] Re: Privacy Preserving DS

Rohan Mahy <rohan.mahy@gmail.com> Mon, 13 May 2024 21:32 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 44F73C16942E for <mimi@ietfa.amsl.com>; Mon, 13 May 2024 14:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 CAVQ-IOOwwYy for <mimi@ietfa.amsl.com>; Mon, 13 May 2024 14:32:47 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 66A09C169424 for <mimi@ietf.org>; Mon, 13 May 2024 14:32:27 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-51f99f9e0faso5456039e87.2 for <mimi@ietf.org>; Mon, 13 May 2024 14:32:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715635945; x=1716240745; 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=ZkxwbELMdSfRqElL22wxAqU1v2gPQc0xfzO3bVHT7O0=; b=EKDRLqSaNxlimVqWz4fFdfLcUo6SZrTTgi5yCgbYHwqmrRgQFZMvrx0Jv3hlKV/lF0 ndqrFUaB5MCcpP2610KrGIabk69IgoLdcG9gQN+OFPPMe/+OU/DB89BK+8F+Y45byC86 0a+A8+ktdZGHHTH5jRVFsT0Uw5FbDCekLiDVRLRIsdaf7b9qCe9Tq5KXv7HuGoGYBEer aDOFZN0yR7h9dP5m/Ur1DMsUmahTYybxHUmVVO/DyKJfwbNnj14yMgOe/R+gfg2joI3e cO6hSD04pT1umpSojKfj7k1QOrlDkBSN0aiLroFRHv7nMCBdeVBQ2aEbK2ReYmPXQa5t J+Bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715635945; x=1716240745; 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=ZkxwbELMdSfRqElL22wxAqU1v2gPQc0xfzO3bVHT7O0=; b=lJry9XyhHSe+IdO/1VuN9PKCrxyxOqym20+FdAL/RhRkhCgVXLz21+Wrl3jw7g0s/D LKu+cXSHTacHtECac2gjWc9MZ3k5vNJNv667h3AKzRTAVmT2vPyc93Oh+85iPhu2/xPt t+LN/8xKOv+sBzufI9RN92Q9pWKmkXUg4JSg/w0V7L6pamb6QY4bs1jxURg8bgiOBetF CnCO0IZC7YBoshhjbBb/3H35Aiu2zx7IxB3NniYGMt0XiWPpUzDufVF0AGiEzKd3AmXu Hckwr4yzn6nIxmd1vrZBcv+Vq85XMAXGaqEF66uZ+AdYOV+HafmEuFM+IDd3562C4r6U YUZw==
X-Gm-Message-State: AOJu0Yz7xcG0vc1IBss5Rcs6aeBJ3fWo/c/Sa0XE1L7Kn3ciAZ9DPY+E EH/tl7TnwXzJUjIatHrJMzFqbmktjuJukjii+OdBa+Rb8TumAzV2YRJxjd4KCAa+cTyPUjDico8 cklEb136Q0botvX9bkYCmSaGdEAw=
X-Google-Smtp-Source: AGHT+IH8W0vy5tUbL1BH/WiRp8yAmo6h2sfeyiZczEV08ZIG47obglakT+PW7J3g90kRcdDGN3Fda2FFoy++6KNQLWk=
X-Received: by 2002:ac2:5603:0:b0:51a:f2eb:b4c9 with SMTP id 2adb3069b0e04-5220ff71dcamr6962612e87.1.1715635944991; Mon, 13 May 2024 14:32:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAJTd26LOoC_uiPbyiCdh-kR50KdC_J10uxzA1javwgQH99FazQ@mail.gmail.com> <CAKoiRubgZ72nm4=Xd2roq-Xasa5qY30knxMPcsjjHeECxPBUuQ@mail.gmail.com> <CAJTd26J_BOoY9pSP98Jfu3ycmGTz=C0wznmtoaXEe=31S7+0=g@mail.gmail.com>
In-Reply-To: <CAJTd26J_BOoY9pSP98Jfu3ycmGTz=C0wznmtoaXEe=31S7+0=g@mail.gmail.com>
From: Rohan Mahy <rohan.mahy@gmail.com>
Date: Mon, 13 May 2024 17:32:12 -0400
Message-ID: <CAKoiRubaavNUA68VCdgytpAHbEjjiXVdhWfJcm4X003NTLwKFw@mail.gmail.com>
To: Brendan McMillion <brendanmcmillion@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000010b51306185c9f5e"
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: mimi@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Mimi] Re: Privacy Preserving DS
List-Id: More Instant Messaging Interoperability <mimi.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mimi/TKV0O56pw1MAosOJ0FT4e4uO-qg>
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>

As I said in scattered other threads, I think the invalid Commit problem is
actually easier to handle centrally (via the hub) than in a decentralized
fashion. If the hub is tricked into accepting a commit that is not valid,
or accidentally accepts a commit that is not valid, any member that
recognizes this can fetch the GroupInfo, rejoin the group and immediately
undo anything harmful which was done in the invalid commit. This is not
only possible but has been implemented in real IM systems.

Trying to solve the invalid Commit problem only with member clients
requires a consensus threshold and a bunch of not-yet-defined mechanism
that is neither in the core competence of neither the MIMI WG nor the MLS

While I certainly agree we need to give guidance about how to recover from
invalid Commits, we know how to react to this problem under the current
MIMI proposal. We can come up with a different way to do it (which might be
better), but I don't see why that should be linked to privacy metadata

On Mon, May 13, 2024 at 10:10 AM Brendan McMillion <
brendanmcmillion@gmail.com> wrote:

> Yes that's too low in my opinion, but I think it makes sense to approach
> this problem from a different angle -- how do we handle invalid Commits?
> There is more obvious consensus here. Mimi is a federated protocol, so
> there's a requirement to interoperate with unknown codebases. This code
> could be bad / buggy / malicious, so there's also a requirement to be
> robust to bad inputs. The DS is genuinely not able to verify
> Commits/Proposals, but we have the DS trying to verify and enforce policy
> on the handshake messages of a group that it's not a member of. This is
> going to be a source of a lot of bugs that we don't have a reliable way to
> deal with.
> If instead the DS was hands-off, it's a small ask to enable handshake
> encryption and get very strong privacy protections.
> On Mon, May 13, 2024 at 2:45 AM Rohan Mahy <rohan.mahy@gmail.com> wrote:
>> Hi Brendan,
>> I think we are still fuzzy on which metadata privacy problems we care
>> about, so we can analyze the solutions.
>> Many people spoke out that follower providers knowing how many
>> participants are from other providers is an undesirable leakage. That is a
>> relatively easy problem to solve.
>> During the interim, Richard asked if it is acceptable for the hub to have
>> a list of ephemeral public keys and ephemeral pseudonyms for each member of
>> the MLS group. Effectively the hub knowing the number of participants from
>> each non-local provider plus whatever it knows about its local
>> participants. In your opinion is this too low a bar?
>> Thanks,
>> -rohan
>> On Sun, May 12, 2024, 14:33 Brendan McMillion <brendanmcmillion@gmail.com>
>> wrote:
>>> Hi mimi@
>>> At the last interim, I presented the privacy-preserving DS proposal [1]
>>> I sent to the list a while back. The current mimi protocol has the problem
>>> that it requires all handshake messages to be public, so full membership is
>>> visible to all providers. It also has no way to gracefully handle invalid
>>> Commits, meaning the group can be easily bricked by malicious members. (The
>>> point about invalid Commits has become an equally, if not more, compelling
>>> reason to me to rework the protocol.)
>>> In the interim meeting, I talked through the functional aspects of my
>>> proposal:
>>> - Reading and writing messages to a group
>>> - Enforcing access control such that members who aren't in a group can't
>>> read/write messages
>>> - How invalid Commits are detected and handled
>>> - How to manage the number of roundtrips
>>> - How external Commits are handled
>>> We discussed the main architecture changes that are implied:
>>> - Group-level policy enforcement would need to be done largely by
>>> clients rather than the hub. As such, clients would need to take care to
>>> ensure they all have identical policies for which proposals are acceptable.
>>> - Generally in [1], service providers only ever have visibility into
>>> what their own users are doing, and visibility into the /aggregate/
>>> behavior of other service providers. That is, I wouldn't be able to
>>> correlate the behavior of a third-party user between several groups. Things
>>> like removing a user from all groups they're a member of, or identifying
>>> which user was responsible for an abusive message, can only be done by the
>>> user's local service provider.
>>> So my questions for the group are:
>>> - Do we feel that the architecture changes listed above are necessary
>>> and justified?
>>> - Is there anything that people consider a necessary feature of the DS
>>> that they're not sure how to implement in the framework of [1]?
>>> 1. https://gist.github.com/Bren2010/d009ba8d702ae3428b31981295455f02
>>> --
>>> Mimi mailing list -- mimi@ietf.org
>>> To unsubscribe send an email to mimi-leave@ietf.org