Re: [MLS] confirming cipher suites decisions

Richard Barnes <rlb@ipv.sx> Thu, 05 March 2020 19:02 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 8F4613A09AC for <mls@ietfa.amsl.com>; Thu, 5 Mar 2020 11:02:13 -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 mccZb6B8GuDP for <mls@ietfa.amsl.com>; Thu, 5 Mar 2020 11:02:10 -0800 (PST)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 DFC3A3A09C5 for <mls@ietf.org>; Thu, 5 Mar 2020 11:02:09 -0800 (PST)
Received: by mail-qt1-x82c.google.com with SMTP id d22so5005520qtn.0 for <mls@ietf.org>; Thu, 05 Mar 2020 11:02:09 -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=PKi8UpX3h+n+bemWTZyVHpydzzicm2zwm/S0u7jScVw=; b=LIJDXA64jVGDEhnunRyGAe3qBGeJAifQY11G/lnjXNbKtFOe4sWubJvzLpTcQnR5ZP D9jdC2rVzuavO/ihaIEOa0p2FlfeZtk0osoa7UmbFLuhe5hWxo+OkPNyfurOiBSUI3jF Uyp+U3+TdXcl1sR5CAKzJ1EUIX2wFZazYGb+IZ+6XSwcQQCXk8nQtOJhY8V5jPZVDN0O Clemki/wFqfL+VbCup/DhMAod4QdLippnyGXUuGCDin86yDXKLjs8SsJ1STrgZAZpeog +JeIjwDMJm218bfWUlmNM6hiCrjftrt8tzHv1Z3hDseIagd/T7sSmgYjjC4r6pwgCx22 VYOQ==
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=PKi8UpX3h+n+bemWTZyVHpydzzicm2zwm/S0u7jScVw=; b=kg4cf2MAO2yml8y/1pt/biGZbxSrwbfltYiLyR0WGJwa0iuMSjlgXRE+CdnkupjZtx zz1XhleU7l0g/lGjH3mJn+zXRZtBu/Yo2S+BuC0SkzLTIqpKhZYRYSGShAG2WdrjlI92 WnsBr2W+i8gBK6yvzIPXWyyJ76Sgx5VW16esDAKY5BsSHvW40oAIZ2cYr6SKKiBKr5FW iOHI2iEKejfJuHoD5bGvlohgvI4xE0dnyDlBcrvp+v0h1JZuIc22v/Wnnn/StZypQ/mP HU3Olfsf95a9Bxi1syfZVIYj2iWGitsY640+yQX2kmUWlvWC3esbg2eSrV2h+l1+Bpiw yHeQ==
X-Gm-Message-State: ANhLgQ0BNMaCLuBkTlvR7jvOMXxc6SsCScXTTXVT4c/QZOlUV2VmUtFF ifNz539m5irUKoiKLDvVIAAK8Vz3aZkmbf2mXahaq5Li9zI=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vuULNJuU/klR5PrKKfgz5xHzqgmnPv2cBy6WOIV?= =?utf-8?q?t9I5ko8kc1Si3mT7A+vZL+6YsZXU7Le83Mfynnp9VdUjnCg=3D?=
X-Received: by 2002:ac8:1e90:: with SMTP id c16mr99348qtm.265.1583434927401; Thu, 05 Mar 2020 11:02:07 -0800 (PST)
MIME-Version: 1.0
References: <D107086A-ED6C-48D8-8BC3-B3AE7E424F85@sn3rd.com> <D2B8EAF9-9109-4247-B714-13306724F712@nps.edu> <B02410C5-F6C3-4580-AA92-C48687731919@nps.edu> <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <CAL02cgS813EWDm8g=_P18XHVJJJErgit4OWP7fDCMPzkQcJQQw@mail.gmail.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <58D2D973-B1D3-45C7-89AA-53689C24B813@sn3rd.com>
In-Reply-To: <58D2D973-B1D3-45C7-89AA-53689C24B813@sn3rd.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 5 Mar 2020 11:01:53 -0800
Message-ID: <CAL02cgTWUQw=DCTiFdN_hJJZSjKNXTC2sXCQELsF0_y-tYunAw@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005f819105a0202ccf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/6_atCtgiBg4In53Fakv878UxujU>
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: Thu, 05 Mar 2020 19:02:14 -0000

Thanks, Sean.  I will proceed to get things merged.  As I think I said
up-thread, changing it later should be straightforward.

On Thu, Mar 5, 2020 at 10:45 AM Sean Turner <sean@sn3rd.com> wrote:

> All,
>
> We have confirmed the rough consensus that the protocol will support one
> signature scheme for the lifetime of the group.
>
> Richard - This means you can merge #279, #304, and #307 (I believe these
> are the right PRs).
>
> Note that we recognize the consensus is rough and if we got it wrong we
> can change it later.
>
> Nick and Sean
>
> > On Feb 26, 2020, at 11:28, Sean Turner <sean@sn3rd.com> wrote:
> >
> > There seems to be rough consensus (stressing the rough) to go with one
> scheme per group. By rough consensus, I mean there seems to be a
> willingness by the group to live with this decision and nobody is super
> bent out of shape about it. Technically, that’s all we need to move
> forward, but there are some concerns concerns that since it’s such a small
> group and there are so few strong voices for the choice that we should give
> it just a bit more time. So, I am extending this call until 2359 UTC 2
> March (i.e., Monday night).
> >
> > Also, there are really three ciphersuite-related decisions being made,
> as noted in the email below.
> >
> > spt
> >
> >> On Feb 25, 2020, at 13:24, Richard Barnes <rlb@ipv.sx> wrote:
> >>
> >> I will not be able to make the call tomorrow, so to summarize my
> opinion on this:
> >>
> >> * I am OK with merging the current PR
> >>  * I have a slight preference for *not* including the sig alg in the
> ciphersuite
> >>  * The simplicity case for including it seems reasonable, but not
> dispositive
> >>  * In any case, I don't care strongly one way or another; I care more
> about progress
> >> * This is an easy change to revert if we change our minds later
> >>  * Credentials are going to indicate the signature algorithm anyway
> >>  * So the only difference in spec is whether endpoints check
> Credential.SigAlgorithm == CipherSuite.SigAlgorithm
> >>
> >>
> >> On Tue, Feb 25, 2020 at 12:43 PM Sean Turner <sean@sn3rd.com> wrote:
> >> Note that the main point of the telecon tomorrow is to address the
> cipher suite issue.  Please take the time to review:
> >> - the related PRs:
> >> https://github.com/mlswg/mls-protocol/pull/279
> >> https://github.com/mlswg/mls-protocol/pull/307
> >> - the messages in this thread
> >> - the issues Britta outlined:
> >>
> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilIdFKw14/edit?usp=sharing
> >>
> >> We would like to close this issue out tomorrow.
> >>
> >> Cheers,
> >>
> >> spt
> >>
> >>> On Feb 19, 2020, at 01:09, Konrad Kohbrok <
> konrad.kohbrok@datashrine.de> wrote:
> >>>
> >>> Hi Britta,
> >>>
> >>> I think you sum it up very nicely. There is one (albeit somewhat
> speculative)
> >>> argument why a single ciphersuite per group might actually be
> beneficial in a
> >>> federation context. In the event that there is "global concensus" that
> a
> >>> ciphersuite needs to be deprecated, my expectation would be that a
> majority of
> >>> the federation nodes/application providers would move to ban those
> ciphersuits,
> >>> excluding anyone who would use _exclusively_ that ciphersuite. That
> would in
> >>> turn be a motivation for all other nodes/application providers to
> catch up as
> >>> well. This also means that nodes can't be made (by whatever authority)
> to use
> >>> weak ciphersuites exclusively and still expect to federate with other
> nodes that
> >>> have more sensible policies.
> >>>
> >>> That's mostly my guess of how the dynamics in such a federated
> environment
> >>> _could_ work, though. Anyone here with some actual
> experience/expertise they can
> >>> share of what the dynamics could be?
> >>>
> >>> Overall, I think I'm in favor of one-ciphersuite-per-group. It just
> seems a lot
> >>> simpler and even in the context of federation, I think that most
> >>> nodes/application providers would allow several ciphersuites to begin
> with,
> >>> where not all of them are weak, meaning no one would really be
> excluded too quickly.
> >>>
> >>> Cheers,
> >>> Konrad
> >>>
> >>>
> >>> On 18.02.20 21:00, Hale, Britta (CIV) wrote:
> >>>> Under the topic of individual/single signature schemes there is the
> final issue of federation. In a federated context, groups are no longer
> under the control of a single application, meaning that we would lose some
> control in forcing good ciphersuite choices. This could lead to two issues:
> >>>>
> >>>> 1) MLS would move closer to facing the TLS problem of having old
> suites supported by edge cases, which in turn weaken the entire group's
> security. There is always the argument that groups would simply refuse
> joiners that do not support the current group cipher, but this is not very
> practical from a usability view. E.g. if everyone using application X
> refused group members who were using application Y, then the point of
> federation would be largely defeated. So, either some form of renegotiation
> is allowed (e.g. export psk) and downgrade becomes more likely, or
> federation does not work reliably.
> >>>>
> >>>> 2) Healing would take longer. Since no one application has a master
> view and control over ciphersuites, upgrading long-lived groups using
> questionable ciphers could take a significant amount of time (all
> applications would need to do so in order for the group to upgrade) or
> alternatively result in kicking group members out of the group (again,
> possible, but questionable for usability except in extreme cases). Under an
> individual cipher choice, any one member can choose/upgrade their scheme,
> allowing for faster adaptability and potential benefits to PCS.
> >>>>
> >>>> From the above, it seems that a single group cipher makes federation
> harder/slower/less secure, but I may not have a clear view on how
> federation would work in this context. Does anyone know whether the above
> are really concerns or not relevant due to other reasons?
> >>>>
> >>>> (Note that this is thinking in the long-term context. Obviously we do
> not want to standardize any cipher choice that is sub-optimal; however any
> number of things may happen with protocol versioning and cipher breaks over
> the span of several years.)
> >>>>
> >>>> Under all the considerations that I have seen so far, the pros and
> cons on both sides place the individual signature cipher option in the
> lead. However that lead is small, hence why I have not been arguing for it.
> The issue of federation could be a deciding factor. If we want federation
> in the future it is of course better not to build inhibiting factors into
> MLS now that could undermine either usability or security in such contexts.
> To make a case to proceed with the single group cipher option, it would be
> great if someone could provide a convincing argument as to why it would be
> the best option for usability and security in the federated environment (or
> preclude a federated use-case altogether).
> >>>>
> >>>> ---
> >>>>
> >>>> Britta
> >>>>
> >>>>
> >>>> On 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)" <
> mls-bounces@ietf.org on behalf of 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
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>
> >> _______________________________________________
> >> 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
>