Re: [MLS] confirming cipher suites decisions

Sean Turner <> Thu, 13 February 2020 14:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50F6312011D for <>; Thu, 13 Feb 2020 06:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CebnJovT_eNh for <>; Thu, 13 Feb 2020 06:49:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 277831200E0 for <>; Thu, 13 Feb 2020 06:49:21 -0800 (PST)
Received: by with SMTP id w15so5883432qkf.6 for <>; Thu, 13 Feb 2020 06:49:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=fvq5Zf0hF/2HCX29qbkkzaAdgpwTSH3T7hbkSVKZXOo=; b=DBgfcfYq5/XWcXxna11o2frEm81BmdOw+EDXXEhhci3vlqxsQwbYAEdB0grRU15IIS KKVosx0Df1GGHTsTJEsnS22Mj8tRPeCc47Su1cQxh93Gltw+E3sOPdk0jCvpffb6prgO Dxc4MN+JcLOTg1kCTYak58mwdNCobNWKPOWNQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=fvq5Zf0hF/2HCX29qbkkzaAdgpwTSH3T7hbkSVKZXOo=; b=nmAMEPw8felSJT/TcpSlpasBMo7XAbUFbxFS0zh2vzDmZqB4XmP/u+c1ejxmCroUdF uYM/NoDvPsFimP11/K2piItXnZHNziHeXPXZifTgVt0IypBVFUWhMInVixArkyXA8vXd 1E+dU+RXscd6C33WOLiYhNoH+/E2+Qj7vdySmVD68BYhFVNqQbmd7jaHV0G9MZmanBsO 8kaz7tkurmi9UvcSYKujJcKNwPGGyhGa3jprQIsi4sgwFy5cI+mFCi9vq7Amsur15tWZ hm6S00z6R/o82kWuN6AfaTfQhpHJdDAwnwVIUMzkHd6WBqy3SgH5M53iXP9mMFM8FUgr phfA==
X-Gm-Message-State: APjAAAVsndwe13exROXzyQJoI6OFnQYBPidvAgP/tMNeVKsTii/AcmUU u+aPPQiKQhJQqAOfCq1V8iPJ8wcaPHEfEw==
X-Google-Smtp-Source: APXvYqxbOrocg890tRRxTO+XIxDSz+9fbmr6YIpkiMFD53wS3fjnNBcNrKvbAdrcpRNjQOYXtB+3ZQ==
X-Received: by 2002:a37:a958:: with SMTP id s85mr12171374qke.243.1581605360037; Thu, 13 Feb 2020 06:49:20 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id v10sm1484554qtq.58.2020. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Feb 2020 06:49:19 -0800 (PST)
From: Sean Turner <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 13 Feb 2020 09:49:18 -0500
References: <>
To: Messaging Layer Security WG <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3445.104.11)
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, 13 Feb 2020 14:49:23 -0000

> On Feb 6, 2020, at 11:08, Sean Turner <> wrote:
> Hi!
> tl;dr: confirming MTI suite selections and rationale for avoiding proliferation
> During the F2F Interim in January, the WG discussed cipher suites-related issues. Namely, whether a per-group signature scheme should be driven by the chosen cipher suite, what were the MTI (Mandatory To Implement) cipher suites, and what the actual algorithm should be.
> There was rough agreement that there should be one signature scheme per group and that should be driven by the cipher suite. There are, at least, three things to consider: 1) if a potential group member does not support the algorithm, then they will not become a member or the group will need to downgrade; 2) when the group needs/wants to update, it is a flag day; and, 3) the cipher suites will have a similar combinatorial issues as the TLS cipher suites prior to TLS 1.3. The agreement was “rough” because 1) likely has some important implications.
> The MLS cipher suites defined were as follows: 
> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519
> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256
> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519
> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448
> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521
> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448
> At the interim, the consensus was to make the non-NIST suites the MTI.  The rationale was that those implementation that need to be NIST compliant will do so regardless of the choice made by the WG.
> In looking at the actual cipher suites, it was noted that the 256-bit schemes the SHA should be SHA-512. The rationale agreed was that SHA-384 is SHA-512 cut in half, so just do SHA-512 because it is one less operation.
> To avoid the proliferation of cipher suites, guidance will be provided to be conservative about allocating new code points. The consensus at the interim was that the suites provided were minimal and provided good coverage for the known use cases:
> - (X25519, AES-GCM, Ed25519) - Good for desktop
> - (P-256, AES-GCM, P-256) - Compliance
> - (X25519, ChachaPoly, Ed25519) - Good for mobile
> The chairs need to confirm the interim’s consensus on list, so please let the WG know by 2359 UTC 20 February whether you disagree with these choices and why.
> NOTE: The final text will obviously be reviewed, but is being composed as part of the following PR:
> NOTE: We combined these cipher suite related consensus points, but if we only come to consensus on some of these we can still incorporate what we do agree on.

I finally got around to doing my homework related to PR279. My bit was the more procedural bits that instructs IANA to establish/use a Designated Expert pool: