IETF Logo Mail Archive

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

Benjamin Beurdouche <ietf@beurdouche.com> Thu, 14 March 2024 10:08 UTC

Return-Path: <ietf@beurdouche.com>
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 7E0ABC151985 for <mls@ietfa.amsl.com>; Thu, 14 Mar 2024 03:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.24
X-Spam-Level:
X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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=beurdouche-com.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 rLM5yLddujRo for <mls@ietfa.amsl.com>; Thu, 14 Mar 2024 03:08:14 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 AE3B3C151983 for <mls@ietf.org>; Thu, 14 Mar 2024 03:08:14 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-513cfd48224so689863e87.2 for <mls@ietf.org>; Thu, 14 Mar 2024 03:08:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beurdouche-com.20230601.gappssmtp.com; s=20230601; t=1710410891; x=1711015691; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=E4KSwobPh9q20zOLbElFoyhhkRTe3OvX/C1lARVw0n0=; b=JNStwC1SpInzTNsP7ppXDMWryq+cqyOeWMsWyaIhZIPfs/48+dK+ZeipGbxqFpmSMz FQ7yY8DHNOvWY+3tRma4TMvJVQu9Z+9eu/r6oCn9huEKnH9FiZ5FQz6ATymUJrx+FGAE SiQUFySB5HFvE58EKAu3gzfQpZ/EYKf9pwcU0R9Den6gNKMv/DkWfxa0jQtGIuBK2+iw 26ycnRvFlrIXd5p3L2cEIlEblaxuljXV6HByLsY+qiDJY8SH85kuVOH+vfpH4bokmmCY n2SkWVZWph3HuOlqtI8CFSNwqpaz8LMqmk29cjT7AUOOWKDQCJjQTMgAg0n+1L3fn+8p kbPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710410891; x=1711015691; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=E4KSwobPh9q20zOLbElFoyhhkRTe3OvX/C1lARVw0n0=; b=V+0Q8rgQ6EU8ovIrI7tZFdUosdM+CCmMsHNcmOlf/G2vh18FwvkIfktnk6JJU+qYJY +WFYYGS/2EJMSU4ohztHUnvc1LN+8n/neF9rUE4UKSKxj788Bf3m4R7jFJIibNgetfKg AjcTaa6Oj+GyqyBUX37Tf+eZLNatnmk3foeF2bJdtS2CiuTpmpoyppG1kpLjsfv8bFhi 8WZ7A8W58q0xsJfk1RVHQZyoaKUB/GSzC9DJSV8846c45f06kpxFECYpYai5xoGVWrpo svSBGjD/Z43jM1MbU34+hbtkzpfmYCaiCtxckMAJiGmunEsF9Nqmj4JFjwvBRQczA2Mj UDdg==
X-Gm-Message-State: AOJu0YwtdBV/PRoQ0YLAudtB/A3QAE3VgjKFReR8nCjA6VaqqvfwU7Tm cfnjT5V7MDbSsnZ2CHIw5QCQ2WCWdpey35JPCCgHWj7NLtBgsj7zpBBY8ouyl/YipiUqqeyVfyu v
X-Google-Smtp-Source: AGHT+IH269lYrgySRTHl9pk+Px4ebbQ6oFOvbiE4SkyEknw5UzLqkbjoNR3NSdCD7YrefKD0is/5sg==
X-Received: by 2002:a19:ca0e:0:b0:513:cff2:967f with SMTP id a14-20020a19ca0e000000b00513cff2967fmr761219lfg.18.1710410891286; Thu, 14 Mar 2024 03:08:11 -0700 (PDT)
Received: from smtpclient.apple ([2a01:e0a:50e:a4a0:7c0b:9028:2314:4dac]) by smtp.gmail.com with ESMTPSA id je2-20020a05600c1f8200b004133072017csm5209213wmb.42.2024.03.14.03.08.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2024 03:08:10 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: Benjamin Beurdouche <ietf@beurdouche.com>
In-Reply-To: <E88F391B-19CF-4A54-BA4D-743B99599FFC@sn3rd.com>
Date: Thu, 14 Mar 2024 11:08:00 +0100
Cc: ML IETF Messaging Layer Security <mls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7FAB2EC-5B46-478C-92FB-E7559010EAF8@beurdouche.com>
References: <E88F391B-19CF-4A54-BA4D-743B99599FFC@sn3rd.com>
To: Sean Turner <sean@sn3rd.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/Aj5KYUH9tgKvfb9fhjCBReOxPG4>
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 10:08:18 -0000

Hi,

I have a preference for the other #249 which keeps the recommendation but I would be fine with either. 

My main reason is that, in the rest of the architecture document, the idea is to have the strongest 
security target possible as a recommandation and take explicit action to relax properties when needed.

In that spirit I don’t see an issue with encrypting group operations even in the case you need server assist,
the tradeoff being an additional ciphertext explicitly providing the information to the expected server 
and only that server…

Ben


> On 14 Mar 2024, at 04:56, 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