IETF Logo Mail Archive

Re: [MLS] -mls-architecture: resolving encrypted group operations

Richard Barnes <rlb@ipv.sx> Thu, 14 March 2024 04:12 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB26C14F748 for <mls@ietfa.amsl.com>; Wed, 13 Mar 2024 21:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=ipv-sx.20230601.gappssmtp.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 TqI7zsBYEqmM for <mls@ietfa.amsl.com>; Wed, 13 Mar 2024 21:12:23 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 902C3C14F6B1 for <mls@ietf.org>; Wed, 13 Mar 2024 21:12:23 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id e9e14a558f8ab-3666ddf3be9so2064205ab.3 for <mls@ietf.org>; Wed, 13 Mar 2024 21:12:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20230601.gappssmtp.com; s=20230601; t=1710389542; x=1710994342; 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=cvqIOWNe/AcwpcpLgR8uu5KPU8O2bR8xT5/Xx1XoIBk=; b=QCrQENPffWOQLAgTdDOzNl+MjBumoIJlNpXtpB42jyejr8EmfjsGtrZx+ckVxHIbfq SDf3Dheg0V13wqBZm/Z3mq60TDxgNcs1IdYTbt/Zqwbn0dC++LAbOkqIBw6cEERBjbb2 aooxuak3pqxtmOlC2ZhRlmDdjc0yfbmKh0UXU+6VTqCbiNNf/pj+/DbxHhmPizBDvDvi dX2BdhfcJg7BREaD82mohlDdciMtk63t+4uKCUQjmWAt4GWNo5C0k0HMi7Z371ZWtCGi jZISE+PW1BfG7E1lX1s+yG0oQ0IivT7alYR5kYEf/vr3Y9B3ociLdwyODE1iC4BDIfel N4RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710389542; x=1710994342; 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=cvqIOWNe/AcwpcpLgR8uu5KPU8O2bR8xT5/Xx1XoIBk=; b=sspYZ6/BcEqnaq0Zcrp0p0dRSAYVUjjNLTzS3/ie3BbfdB8StRIoSQJtlxU65BEvy6 O3trSyKENRVur6QhqQ/yFnG+F8C89vMCectIoEw2xf2iXQYUBrU8q5MZFrLUfi7SzYXB Xpv2N0gGthrXhxtu3h0BADfYH9KxT8mChJUSJARj4544+CRgbpt5Ejx6MPfg55tE9Ttc uvNvryUGjOe1dh0PjOlsMdkLmySwr77sMGikw3MZywBZwFyaUVLHDeQSiw8UzywXKpgn ZHVgOAPzVXo6qL7BTctApyFwEvhzcZ/fDG0WAaIq5ylEfW+RWjl9BvBev+mgWzLD/bH9 O3UQ==
X-Gm-Message-State: AOJu0YzfWaF3IFdUEj8XyPxlaiuTjAXxijoYZmpMAVcNjtJuoQaKOYCR alTD31Xdkc7Fi6wNLyjvFuwt+vCFAHrLNuz9nKynez+h0/rixCw0pnFJ1e3xbh8qZLVtBfJRSbL hn08D8jUy9uZAPB3I3JwjnrPkwRLeRQVUBLdjv6VwTFUG11I+6FKcfw==
X-Google-Smtp-Source: AGHT+IFClQiKJpX+/ZOTC9UHktDMhFg3IJVYq7guWkenkHBJuOxoQ5gqkTEDc8NRfttKfrNehZanRIY0IDrXjeAC5/U=
X-Received: by 2002:a05:6e02:58a:b0:364:4c:8dc4 with SMTP id c10-20020a056e02058a00b00364004c8dc4mr629102ils.6.1710389542315; Wed, 13 Mar 2024 21:12:22 -0700 (PDT)
MIME-Version: 1.0
References: <E88F391B-19CF-4A54-BA4D-743B99599FFC@sn3rd.com>
In-Reply-To: <E88F391B-19CF-4A54-BA4D-743B99599FFC@sn3rd.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 14 Mar 2024 00:12:10 -0400
Message-ID: <CAL02cgSg3jh-86O-kx+MeApnsaq+wL=2t+_H_RK1WwEG80EU9A@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: MLS List <mls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000019068506139719a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/FMwgFpJofvOUgYJpLn4VKXDHigc>
Subject: Re: [MLS] -mls-architecture: resolving encrypted group operations
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2024 04:12:24 -0000

I have a strong preference for #246 over #249.

It is true that using PrivateMessage provides greater confidentiality.  But
in practice, every application so far that has shipped MLS at large scale
is using PublicMessage, and AFAIK all that are currently envisioned (e.g.,
MIMI).  The scaling benefits of having a server track the tree are
substantial if you're doing anything but quite small groups.

The purpose of this document is to guide people toward the strongest
practical solutions, not to guilt them into doing the very most secure
thing.  (And we certainly can't force anyone to be "explicit".)  #246
strikes the right balance between being clear on the one hand ("All other
things being equal...") and being practical on the other hand.

--RLB

On Wed, Mar 13, 2024 at 11:56 PM Sean Turner <sean@sn3rd.com> wrote:

> Hi! Last we met, we talked about how to resolve the issue related to one
> of the encrypted group operation’s recommendations [1]; also, thanks to
> Brendan for starting this thread [2].  This thread is intended to help Nick
> and I call consensus on which of the two PRs to direct the authors to land.
> If it is not clear from this thread, we will discuss at our session at IETF
> 119.  The two PRs follow:
>
> 1. PR #246 [3] rewords the issue description and removes the
> recommendation; this change keeps us (the royal us) from looking silly when
> the first protocol to call out MLS does not follow the recommendation.
>
> 2. PR #249 [4] keeps recommendation but state that applications may use
> unencrypted operations if they have an explicit reason to.
>
> Cheers,
> spt
>
> [1] https://github.com/mlswg/mls-architecture/issues/210
> [2] https://mailarchive.ietf.org/arch/msg/mls/1ohlP2TZr_LBuLyM7rfDKnM9Jo8/
> [3] https://github.com/mlswg/mls-architecture/pull/246
> [4] https://github.com/mlswg/mls-architecture/pull/249
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>

v2.23.0 | Report a Bug | By Email