Re: [Mimi] Metadata Minimal MIMI (MIMIMI)

Raphael Robert <ietf@raphaelrobert.com> Sun, 07 April 2024 17:37 UTC

Return-Path: <ietf@raphaelrobert.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 346F1C14F5F1 for <mimi@ietfa.amsl.com>; Sun, 7 Apr 2024 10:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, 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 (1024-bit key) header.d=raphaelrobert.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 jPRJyB-h2R-n for <mimi@ietfa.amsl.com>; Sun, 7 Apr 2024 10:37:13 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 DCB24C14F6AC for <mimi@ietf.org>; Sun, 7 Apr 2024 10:37:13 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2d80baf621eso41497941fa.1 for <mimi@ietf.org>; Sun, 07 Apr 2024 10:37:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; t=1712511431; x=1713116231; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=fab4kAD55XdBIB1+pU0/t3jXfzXUqHyxbLNNqmmtYV4=; b=zDCuCpnYrwsadHy9vnL2vbUBmNN5LB9n1N9OkNhusJ2vIKYxGrdIOtDDye+zH7SgoO OE4MeYlGbset2/hqkI2Xt9bwyUhPdcGinKKOV55Fh4fOEuQZZuav8dvczBmN1Acz+3Ka VnkkaMmC0XP4Lz35d9asLAOOj+t/eloE+a48Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712511431; x=1713116231; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fab4kAD55XdBIB1+pU0/t3jXfzXUqHyxbLNNqmmtYV4=; b=vw9T9ivPOrY79xpc+EubMJDPSizo3dj0uH8bsnSbLUhvvfP5t9MHLU+fQAn5ma8Q/n KG1oCdxrEoIV94S6qBy6aj+QQ5xay2LyItbGPNR7S+n63wiCmzoN7luz6ild/5SSIOim ppaCIppihByDr9sNAVw3kVCyIpw2B8FGZ3zvzqfqXIiBFNV2TPJ443PHn3jv7HYYdOEA J2RElloCxod9aMuLrOjQ+L20nO3O1wpvfKP3cKhx9mqh24kpHXAAONvvxJPKAYK/E8PF z2lm/KjqdUhnlNkGeX+agllpdukdQkBbRVzJ43HhgW4dBDiSup4TuKuo8YenGHsyxgj3 qQyw==
X-Forwarded-Encrypted: i=1; AJvYcCVwCjTCET+mVH3LJjbclU6EhnhzVkI1bchUQIXAnFZFvMdEsTvssjv8fgQRcs0K3nAfI9akjMrTdEgi260m
X-Gm-Message-State: AOJu0YwX8tNFmKO4Cbt/eMD6migBzZRvvm5YeJdFAduBQLqnp0BOhwNy fu83D5juAWbu8qT92l9vaS8wY6FZCpm+aFP8ij0WH6+HekY8kRxioxoE9ZIex9w=
X-Google-Smtp-Source: AGHT+IGXJtTdRPUjkH+mu9dpNar6bXfy4SttnVexRmolsjsKlh3cHTUk5/ERlgxAQOwlc12zKsj0tA==
X-Received: by 2002:a2e:a417:0:b0:2d6:f16a:857f with SMTP id p23-20020a2ea417000000b002d6f16a857fmr3734949ljn.0.1712511431142; Sun, 07 Apr 2024 10:37:11 -0700 (PDT)
Received: from smtpclient.apple (dynamic-2a01-0c22-b10a-3c00-44ba-aba7-9805-a0fd.c22.pool.telefonica.de. [2a01:c22:b10a:3c00:44ba:aba7:9805:a0fd]) by smtp.gmail.com with ESMTPSA id o19-20020a05600c4fd300b0041567ce9f10sm10581719wmq.0.2024.04.07.10.37.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Apr 2024 10:37:10 -0700 (PDT)
From: Raphael Robert <ietf@raphaelrobert.com>
Message-Id: <0E12AA02-1656-4C49-8473-3A85DC51E9C3@raphaelrobert.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8A453D5C-4C42-440A-A386-EEF192DCE852"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Date: Sun, 07 Apr 2024 19:36:59 +0200
In-Reply-To: <CAJTd26KqjV1BKq9Vtar4QQ4KnPhm=dF7WbysuR-MRsM4mNOkVA@mail.gmail.com>
Cc: Konrad Kohbrok <konrad.kohbrok@datashrine.de>, mimi@ietf.org
To: Brendan McMillion <brendanmcmillion@gmail.com>
References: <8381F4BA-4E8E-4CE0-9FEF-20CEDD30A2CC@datashrine.de> <CAJTd26KqjV1BKq9Vtar4QQ4KnPhm=dF7WbysuR-MRsM4mNOkVA@mail.gmail.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mimi/YHr9GDKlFTdKaxYnMB8qC-j0e18>
Subject: Re: [Mimi] Metadata Minimal MIMI (MIMIMI)
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, 07 Apr 2024 17:37:18 -0000

Hi Brendan,

Thanks for the feedback, I’ll address your points inline:

> At first glance, it seems this approach has the same efficiency as using encrypted handshake messages. That is, when I add a user to a group, I need to upload an encrypted blob whose size scales linearly with the number of members in the group. Is that right?

On the contrary, the proposal is to use public messages so that the DS can do what it would normally do without pseudonyms: Parse the public messages and keep a copy of the GroupInfo/ Public tree on the server to maximise efficiency. In other words, adding a new member to a groups only requires the sender to send a Commit and a Welcome. The invited member can then fetch the ratchet tree from the server. Conversely, when using External Commits, new joiners can fetch the ratchet tree from the server.

> I'm also concerned about the property that, if I'm ever added to even one group with a user, then I learn their connection key. Then I can use their connection key to de-anonymize them in any other group, regardless of whether I've been in that group or not.

It's a valid concern, just ending up in a group with another member shouldn’t give that member access to you beyond that group. That’s why connection keys must only be shared in 1:1 connections and not in other groups. Obviously the draft is not specific enough in that regard at this point. We need to flesh this out some more.

Raphael
 
> 
> On Fri, Apr 5, 2024 at 5:34 AM Konrad Kohbrok <konrad.kohbrok@datashrine.de <mailto:konrad.kohbrok@datashrine.de>> wrote:
>> Hi folks,
>> 
>> Raphael and I just uploaded an I-D with a proposal that sketches a pseudonym-based MIMI variant that aims to reduce MIMI’s metadata footprint. You can find it here: https://datatracker.ietf.org/doc/draft-kohbrok-mimi-metadata-minimalization/
>> 
>> We have been working on this approach for a while now and have already implemented and run a variant of what’s described in the I-D.
>> 
>> The I-D is quite high-level for now to make the concepts easier to grasp. If people are interested we can fill in gaps and add details in the next iterations.
>> 
>> Looking forward to continuing the discussion around metadata in the context of MIMI and any questions regarding our I-D!
>> 
>> Cheers,
>> Konrad
>> 
>> -- 
>> Mimi mailing list
>> Mimi@ietf.org <mailto:Mimi@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mimi
> -- 
> Mimi mailing list
> Mimi@ietf.org
> https://www.ietf.org/mailman/listinfo/mimi