Re: [MLS] confirming cipher suites decisions

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Sat, 15 February 2020 08:20 UTC

Return-Path: <benjamin.beurdouche@inria.fr>
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 13D47120044 for <mls@ietfa.amsl.com>; Sat, 15 Feb 2020 00:20:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9U1rLOL7mid for <mls@ietfa.amsl.com>; Sat, 15 Feb 2020 00:19:58 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A07712001B for <mls@ietf.org>; Sat, 15 Feb 2020 00:19:45 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.70,443,1574118000"; d="scan'208,217";a="436135529"
Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.49]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 15 Feb 2020 09:19:43 +0100
Content-Type: multipart/alternative; boundary=Apple-Mail-C49FB91F-C4A1-455C-A164-B9474F216911
Content-Transfer-Encoding: 7bit
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Mime-Version: 1.0 (1.0)
Date: Sat, 15 Feb 2020 09:19:43 +0100
Message-Id: <4AA9B7B2-60EC-4AB4-85CA-FA5EA9F64D3F@inria.fr>
References: <CAKDPBw8OC74H7zAkk9e1mkm6UtB6L76Lh5qmjv-DNjep1LmApA@mail.gmail.com>
Cc: Sean Turner <sean@sn3rd.com>, Messaging Layer Security WG <mls@ietf.org>
In-Reply-To: <CAKDPBw8OC74H7zAkk9e1mkm6UtB6L76Lh5qmjv-DNjep1LmApA@mail.gmail.com>
To: Paul Grubbs <pag225@cornell.edu>
X-Mailer: iPhone Mail (17D50)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/Rxya3jVpklILVkkQwmmb2MFWWug>
Subject: Re: [MLS] confirming cipher suites decisions
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 15 Feb 2020 08:20:01 -0000

Hi Paul,

Yes, thanks for reminding us of this. This is something we need to think about seriously indeed...

My intuition is that since we also have signatures we should be safe. But I agree that we have to evaluate carefully the differences between the committing and non-committing modes.

B.


> On Feb 14, 2020, at 9:48 PM, Paul Grubbs <pag225@cornell.edu> wrote:
> 
> 
> Hey all, quick question - all the AE schemes used in these cipher suites are non-committing (meaning they misbehave in weird ways when keys may be adversarially known or chosen). Not including a cipher suite which uses a committing AE (cAE) scheme may make reasoning about the protocol's behavior difficult in some settings. Since the latency increase of committing AE would not be terribly high (one such scheme is AES128-CTR-then-HMAC-SHA384 with HKDF-derived encryption and authentication keys, which is reasonably close to what Signal uses), might the inclusion of a cAE cipher suite be worth discussing?
> 
>> On Thu, Feb 13, 2020 at 9:49 AM Sean Turner <sean@sn3rd.com> wrote:
>> 
>> 
>> > On Feb 6, 2020, at 11:08, Sean Turner <sean@sn3rd.com> 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:
>> > https://github.com/mlswg/mls-protocol/pull/279
>> > 
>> > 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:
>> https://github.com/mlswg/mls-protocol/pull/307
>> 
>> spt
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls