Re: [MLS] confirming cipher suites decisions

Richard Barnes <rlb@ipv.sx> Wed, 12 February 2020 17:04 UTC

Return-Path: <rlb@ipv.sx>
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 8FC291201DC for <mls@ietfa.amsl.com>; Wed, 12 Feb 2020 09:04:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
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 ZUX8PNfHL2RK for <mls@ietfa.amsl.com>; Wed, 12 Feb 2020 09:04:31 -0800 (PST)
Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A7012080F for <mls@ietf.org>; Wed, 12 Feb 2020 09:04:31 -0800 (PST)
Received: by mail-qv1-xf34.google.com with SMTP id dc14so1237736qvb.9 for <mls@ietf.org>; Wed, 12 Feb 2020 09:04:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sqSnQIeC3cay3Xm2mSZNO4itVvDvzjWfrDdwN84MEnk=; b=zrflGt29PlN0o8FwtXd9yo0XgIZw237NFqWwtpvounlczuzNXpLuOV/fzdlJu0NmCa 7lS9+dWj/N4DgaBZAYhrjZQoztYNKH7G47RHesW7jEYjZzMud0hpwqky5QW/+axLnivB wgVm4Ap+lsW7W/HHCEF9w18iYSKdzjAyCeE4RaPG1JZa3XINKM61GedcDlnYabqt1O00 NA6wl6YQm8tSi6I0027lOWlWKAkDdzVwID18q2sEY/B1Qo2cnW3DiSWB7riIYODcnkEp bZ96rWb8P+xJCPzRYED63B07nQn1B8CBD9E0w3o4m4oVSldY2zn4H3e4CwhOAEBnXkpK csUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sqSnQIeC3cay3Xm2mSZNO4itVvDvzjWfrDdwN84MEnk=; b=Hs5TIOKU2cduzJkjtuh/wFwh8zBQq6LQaFCeLo5X6QPBhgVzVPQdDdCj4Qpriq6RG4 dqtA8h/KotC0NAJNjzlmWjR141WfXTpuNstun2FGZRyzpZO2qqXN7f5C4X89P6Dp1bHS xLmeQJiGWaDwf20B0UEJX/MJlpI+TwEBefhpEa3lAZSl12fm7UjUwqM0eWPL0By0wagx cAZj8WgqiXBmMqATbO/ae8AmhUW8S6iI3kLVbqeTFdspv0GNI1sGq0QoiZhHBt/LlysV aZ7piTgk3T9RDfzZHU9BxQS2lf0uVGuNxG1d6xNITFtTbp1a/GsZUx3wvzfAW20M1BiR GDlA==
X-Gm-Message-State: APjAAAWFXBljabDnqXOE79uj4cGgS1a6FGX1a8ca/55jRaoDPSJblf4O nRgJZ6C7rtdnHGLW0urVN/+J9TyxFcGXRFmv5GzQxg==
X-Google-Smtp-Source: APXvYqwNoE/Gpo+sgGex15BzjBI67k3TxeYjmr0YHk+LK5VPl9gSWKVn7M9xF3fZXIJUbeD1aQLdRGk15Lafs53CisA=
X-Received: by 2002:a05:6214:13ef:: with SMTP id ch15mr20516448qvb.183.1581527070507; Wed, 12 Feb 2020 09:04:30 -0800 (PST)
MIME-Version: 1.0
References: <D107086A-ED6C-48D8-8BC3-B3AE7E424F85@sn3rd.com> <D2B8EAF9-9109-4247-B714-13306724F712@nps.edu>
In-Reply-To: <D2B8EAF9-9109-4247-B714-13306724F712@nps.edu>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 12 Feb 2020 12:04:15 -0500
Message-ID: <CAL02cgTspXEr87fO_bxWtYccH24fk+GBE8mBxR0x7YG91P1GDQ@mail.gmail.com>
To: "Hale, Britta (CIV)" <britta.hale@nps.edu>
Cc: Sean Turner <sean@sn3rd.com>, Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003d9e68059e63f7e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/BjsHw3EQbM17sdVAV0n2iC2GY_4>
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: Wed, 12 Feb 2020 17:04:35 -0000

I agree that these considerations are good to get documented, but at least
given the current state of thinking, it seems fine to proceed with the
strategy in the current PR.

On Wed, Feb 12, 2020 at 11:00 AM Hale, Britta (CIV) <britta.hale@nps.edu>;
wrote:

> Hi,
>
> Concerning the use of a single group signature scheme or individual
> signature schemes, it is probably worthwhile to expand on the consideration
> points and clarify what security implications we are accepting - in either
> case. I have listed out some issues in the following Google doc:
>
>
> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilIdFKw14/edit?usp=sharing
>
> I am not making an argument for either case at this point, but pushing
> this out for discussion and to help us achieve more clarity as to the
> benefits and consequences of either choice. There are certainly more issues
> to consider (e.g. ease of implementation, efficiency, etc. in addition to
> security considerations) and other views - feel free to add them or discuss
> on the mailing list.
>
> All the best,
>
> Britta
>
>
> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" <mls-bounces@ietf.org
> on behalf of 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.
>
>     Cheers,
>
>     Nick and Sean
>     _______________________________________________
>     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
>