[km-fs-pcs] Re: Relation to "MLS Targeted Messages"

Konrad Kohbrok <konrad.kohbrok@datashrine.de> Sat, 20 June 2026 04:42 UTC

Return-Path: <konrad.kohbrok@datashrine.de>
X-Original-To: km-fs-pcs@mail2.ietf.org
Delivered-To: km-fs-pcs@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id E32CE10455991 for <km-fs-pcs@mail2.ietf.org>; Fri, 19 Jun 2026 21:42:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1781930563; bh=AwK8gJOOOQB9jS5DT5ddIAh7vJZ2f/QQ+4w2VXen69k=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=AuYMxsxs+nmNBSU/GDJzUNVt3VilkCEWBRZ3zr3XMylH9G+huSpSE3Bm9xTS7LIfB 1bGGsk7hvrlLT/R0Z8F486abFPgLNmIk4GHmUJIJGSScYurfQWu1VXwv1Fh0TSeP7c C52boEN3Gffkgaf0Snk/Y/LmjA2HLrTxUT3HiH10=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=datashrine.de
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcuHjMoHg4Ds for <km-fs-pcs@mail2.ietf.org>; Fri, 19 Jun 2026 21:42:41 -0700 (PDT)
Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [IPv6:2001:67c:2050:0:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 20BEA1045587D for <km-fs-pcs@ietf.org>; Fri, 19 Jun 2026 21:41:09 -0700 (PDT)
Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4gj1xR5TPzz9tvv; Sat, 20 Jun 2026 06:40:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datashrine.de; s=MBO0001; t=1781930459; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q5S5oLrs4PxEMguYuMqHRh7bupCTxCZmssW7XVrZNkk=; b=tcA3mAzjpzr6rKYbHVBekb/JfDwBrbf81Z/l700rZ52KrYnsOYloF0H2pih4KZ1sl99GdC bSE5UA5FH0If5f0BXhxODdkGBdV66qNYkHogENoTgc+XONHh9qOu+HnwWI4QtOgHP/WEba 36Fag7WdaS1exoaNcAzV6Gcf1YbsrbT16d2R7bCdSK5NwXkZxeeKlY1XbYLmueJP2fMz3c tq1XXPKDCodJjW0xZIW5YS3tTYtszhDUhnZuR3SqvOOSVBRd5pVNLkV0j8aqvJFAzK+Plx Y654eH7YnINthw53UbnnJexUzbH3JP9o2Jj9Aj/Yz1XJtWf69QVlN3061rbTtA==
Authentication-Results: outgoing_mbo_mout; dkim=none; spf=pass (outgoing_mbo_mout: domain of konrad.kohbrok@datashrine.de designates 2001:67c:2050:b231:465::1 as permitted sender) smtp.mailfrom=konrad.kohbrok@datashrine.de
Content-Type: multipart/alternative; boundary="Apple-Mail-8046EE11-E0FB-4A9F-8285-0522E0210042"
Content-Transfer-Encoding: 7bit
From: Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Mime-Version: 1.0 (1.0)
Date: Sat, 20 Jun 2026 06:40:47 +0200
Message-Id: <ADF7B962-1F55-4837-87B1-7E5DD719DC04@datashrine.de>
References: <vfikzblyKHOOo-w4eUNkFgZWjdhCwLIi5kvUugwM1RBbhTQEX54pNtkHr4_T_CW6cTJVGwLir9o77ClykU-yUT_LMhu03zUJCnrCdSCMIW4=@proton.me>
In-Reply-To: <vfikzblyKHOOo-w4eUNkFgZWjdhCwLIi5kvUugwM1RBbhTQEX54pNtkHr4_T_CW6cTJVGwLir9o77ClykU-yUT_LMhu03zUJCnrCdSCMIW4=@proton.me>
To: Gaëtan Wattiau <gaetan.wattiau=40proton.me@dmarc.ietf.org>
X-Rspamd-Queue-Id: 4gj1xR5TPzz9tvv
Message-ID-Hash: QC3OGXAYZWXJRZBQ5ZZKD7FLL43TKDTO
X-Message-ID-Hash: QC3OGXAYZWXJRZBQ5ZZKD7FLL43TKDTO
X-MailFrom: konrad.kohbrok@datashrine.de
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: Raphael Robert <ietf=40raphaelrobert.com@dmarc.ietf.org>, km-fs-pcs@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [km-fs-pcs] Re: Relation to "MLS Targeted Messages"
List-Id: Key management that provides forward security and post compromise security <km-fs-pcs.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/km-fs-pcs/8VmU7Hj2QGXREhUCFsYIBcSjMXk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/km-fs-pcs>
List-Help: <mailto:km-fs-pcs-request@ietf.org?subject=help>
List-Owner: <mailto:km-fs-pcs-owner@ietf.org>
List-Post: <mailto:km-fs-pcs@ietf.org>
List-Subscribe: <mailto:km-fs-pcs-join@ietf.org>
List-Unsubscribe: <mailto:km-fs-pcs-leave@ietf.org>

Hi Gaëtan,

Good question. The reason it’s specified for two parties is mostly simplicity and that it matches or requirements. We could certainly adapt MLS-TLS to work with more than two clients. Two immediate consequences would be that you’d need a corresponding profile that ensures that all parties agree on the order of commits and that you would lose sender authentication, because authentication of messages in the TLS stream is symmetric. 

Sticking with two parties keeps it simple for now. If there is interest in a solution for more parties I’d be happy to discuss what that could look like. 

Konrad

Am 19.06.2026 um 21:38 schrieb Gaëtan Wattiau <gaetan.wattiau=40proton.me@dmarc.ietf.org>:


Ok! Thanks for the quick reply. 

I think what I don't understand is why this RFC is so specifically bound to the two-party profile, instead of a more generic: "this is how we generate and roll TLS session keys with MLS". Explaining the rationale for this scope in the introduction would be helpful to newcomers like me.

Gaëtan

On Friday, June 19th, 2026 at 7:08 PM, Raphael Robert <ietf=40raphaelrobert.com@dmarc.ietf.org> wrote:
MLS targeted messages are not a replacement for the MLS 2 party profile, they are really different things.

MLS targeted messages wouldn’t make much sense in a 2 party setting, they were designed for groups with more than two members, because their purpose is to encrypt messages between exactly two members so that the other n-2 members cannot decrypt it.

In other words, there’s no relationship to MLS targeted messages whatsoever. Thank you for the question though, this shows that the text in the current draft could maybe be improved.

Raphael

On 19. Jun 2026, at 19:28, Gaëtan Wattiau <gaetan.wattiau=40proton.me@dmarc.ietf.org> wrote:

I just read the MLS-TLS draft, and my understanding is that it is currently centered on a two-party with a two-party profile.

Have you considered a direction where this stays conceptually 1:1 at the messaging layer, but within an MLS group, using something like targeted messages [1] rather than MLS two-party profile?

Best, 

Gaëtan Wattiau

_______________________________________________
km-fs-pcs mailing list -- km-fs-pcs@ietf.org
To unsubscribe send an email to km-fs-pcs-leave@ietf.org


_______________________________________________
km-fs-pcs mailing list -- km-fs-pcs@ietf.org
To unsubscribe send an email to km-fs-pcs-leave@ietf.org