Re: [MLS] confirming cipher suites decisions

Richard Barnes <rlb@ipv.sx> Tue, 25 February 2020 18:24 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 684243A125A for <mls@ietfa.amsl.com>; Tue, 25 Feb 2020 10:24:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.382
X-Spam-Level:
X-Spam-Status: No, score=-0.382 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, URIBL_RHS_DOB=1.514] autolearn=no 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 9-JnJwts2HQO for <mls@ietfa.amsl.com>; Tue, 25 Feb 2020 10:24:28 -0800 (PST)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 15B9C3A0FA5 for <mls@ietf.org>; Tue, 25 Feb 2020 10:24:23 -0800 (PST)
Received: by mail-qt1-x82a.google.com with SMTP id l16so354738qtq.1 for <mls@ietf.org>; Tue, 25 Feb 2020 10:24:23 -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=q2SL+VXTIOGXK4P3L0m4NzIk4wFT+y3TZvbLcCxgGfY=; b=X5yVhfcL+tesym3pOtu5KepCn+EbfRoJJPhX51APzlVdSI+pZ1Q/xBSJiRyrKSzFOL 9cIYief/9bN/aDCCsxm0yRFxsrClfQ6BkLstLQkSwxtnAvPyY17D7DKlwdrPttN8JohK 9SkV7N3Gw5wG5lRrzTGgc9j+YSBU7FW4Ikbg66Nxdphf9c4RaU/LgjX4MF+wOyrjc/Rz xbTrN8tV76mmxr5dPdPCFBemCJmUOh2RjDvWyrhem1CbtQwXEABY2jqC5Ru7dwoSq3iq wyyL1g8C8lo4zkUs1I68tjt1fjPWvolo9qttxsYLUvMsOvqnw6OpQt5Y3XQRgREu8iV2 PTKQ==
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=q2SL+VXTIOGXK4P3L0m4NzIk4wFT+y3TZvbLcCxgGfY=; b=LjdkcFlYKxdLhhLGf8NrkZSQ3OQ6S8YxVynStqwiX8lehXhEmrNLxjKkFdXwmaJxIS wEzYLHnui4VpaVN23bxcEXCMtMoIRi1xSZk+ycoAvosXf5NujuEpsudAv/jXZArfsqjS 7MqTyinUQj6sKlUCrHk3ImwM3XjXFXLYFADhb3zUpF6LCa06jD+8zVcCpYyy93EbgWoX s/6zYdM1ProkY7KfRcHALQfU6caQb22QfRWoxCsOdh9y4InqxNlsfcGxkbjX4haCrwrF skAUxaos7dYWvblDliXSWDQplDXcwB5rhC6WNgo25+3aw+BWYcwE5f7uB1Gtp4g34Kmy v5Ow==
X-Gm-Message-State: APjAAAVwvjyQ8oNJB2q+ajbw8LG8SFmRyB4t0GvrKMbkLC9egbXjs5jL RcIeodu+3IFJpTO5y2XkajYY3Zdli2/1QLAmCt7dv2U/fmw=
X-Google-Smtp-Source: APXvYqyYFjplFtnU5EH9QUpuvIDahvCr9K2XFuv2dbyOt8BIWDspqeOgPEKU3zUxGYmQYDHA8Hc9MSNE+ui7FIUuy00=
X-Received: by 2002:ac8:1e90:: with SMTP id c16mr54632746qtm.265.1582655062750; Tue, 25 Feb 2020 10:24:22 -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>
In-Reply-To: <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 25 Feb 2020 13:24:07 -0500
Message-ID: <CAL02cgS813EWDm8g=_P18XHVJJJErgit4OWP7fDCMPzkQcJQQw@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d14c13059f6a9822"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/GVK9OBhG_m6Vh0kXU0RrEe0nJyc>
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: Tue, 25 Feb 2020 18:24:31 -0000

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
>