Re: [MLS] confirming cipher suites decisions

Benjamin Beurdouche <> Thu, 27 February 2020 10:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 532C63A08ED for <>; Thu, 27 Feb 2020 02:47:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id etK0kPSkpZk5 for <>; Thu, 27 Feb 2020 02:47:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16EF53A086F for <>; Thu, 27 Feb 2020 02:47:13 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.70,491,1574118000"; d="scan'208,217";a="340588647"
Received: from (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2020 11:47:10 +0100
From: Benjamin Beurdouche <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FF65B8DD-9134-4D69-90AA-907DC6AF678B"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Thu, 27 Feb 2020 11:47:10 +0100
In-Reply-To: <>
Cc: Cas Cremers <>, Karthikeyan Bhargavan <>, ML Messaging Layer Security <>, Konrad Kohbrok <>
To: Britta Hale <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [MLS] confirming cipher suites decisions
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Feb 2020 10:47:25 -0000

Hi Britta,

> On 27 Feb 2020, at 10:57, Hale, Britta (CIV) <> wrote:
> Benjamin,
> The issues you describe are primarily TLS-type problems, where uncontrolled, large-scale agility and interop issues exist.

Yes exactly, and I think two-party short lived connections for TLS are easier to handle
than will be the long-lived multi-party connections of MLS.

> As has been stated in the working group as a supporting argument to many changes over the different drafts, within the messaging/MLS space we are looking at significantly more client-specific control.

Yes, and we keep being careful that it is the case when writing the drafts,
but this doesn’t mean that we should be willing to risk interoperability.

> It is not unreasonable for a newcomer to support a selection of signature schemes. If the group creator really wants full interop, they can always define the set of available schemes to consist only of the MTI.

I think at reverse, if you are willing to break interop, you should be selecting something
else than the MTI when creating the group. And again, in what I say, nothing prevents
you to pick the NIST ciphersuite for compliance and use only that.
But I don’t see the interest of mixing algs and put at risk implementations and interoperability.

Out of curiosity, where you somehow arguing for multiple MTIs here ?