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 >
- [MLS] confirming cipher suites decisions Sean Turner
- Re: [MLS] confirming cipher suites decisions Hale, Britta (CIV)
- Re: [MLS] confirming cipher suites decisions Richard Barnes
- Re: [MLS] confirming cipher suites decisions Hale, Britta (CIV)
- Re: [MLS] confirming cipher suites decisions Sean Turner
- Re: [MLS] confirming cipher suites decisions Paul Grubbs
- Re: [MLS] confirming cipher suites decisions Benjamin Beurdouche
- Re: [MLS] confirming cipher suites decisions Dennis Jackson
- Re: [MLS] confirming cipher suites decisions Hale, Britta (CIV)
- Re: [MLS] confirming cipher suites decisions Konrad Kohbrok
- Re: [MLS] confirming cipher suites decisions Sean Turner
- Re: [MLS] confirming cipher suites decisions Richard Barnes
- Re: [MLS] confirming cipher suites decisions Sean Turner
- Re: [MLS] confirming cipher suites decisions Benjamin Beurdouche
- Re: [MLS] confirming cipher suites decisions Cas Cremers
- Re: [MLS] confirming cipher suites decisions Hale, Britta (CIV)
- Re: [MLS] confirming cipher suites decisions Benjamin Beurdouche
- Re: [MLS] confirming cipher suites decisions Karthik Bhargavan
- Re: [MLS] confirming cipher suites decisions Cas Cremers
- Re: [MLS] confirming cipher suites decisions Benjamin Beurdouche
- Re: [MLS] confirming cipher suites decisions Cas Cremers
- Re: [MLS] confirming cipher suites decisions Hale, Britta (CIV)
- Re: [MLS] confirming cipher suites decisions Konrad Kohbrok
- Re: [MLS] confirming cipher suites decisions Benjamin Beurdouche
- Re: [MLS] confirming cipher suites decisions Hale, Britta (CIV)
- Re: [MLS] confirming cipher suites decisions Benjamin Beurdouche
- Re: [MLS] confirming cipher suites decisions Benjamin Beurdouche
- Re: [MLS] confirming cipher suites decisions Hale, Britta (CIV)
- Re: [MLS] confirming cipher suites decisions Raphael Robert
- Re: [MLS] confirming cipher suites decisions Karthik Bhargavan
- Re: [MLS] confirming cipher suites decisions Hale, Britta (CIV)
- Re: [MLS] confirming cipher suites decisions Hale, Britta (CIV)
- Re: [MLS] confirming cipher suites decisions Raphael Robert
- Re: [MLS] confirming cipher suites decisions Hale, Britta (CIV)
- Re: [MLS] confirming cipher suites decisions Raphael Robert
- Re: [MLS] confirming cipher suites decisions Jon Millican
- Re: [MLS] confirming cipher suites decisions Sean Turner
- Re: [MLS] confirming cipher suites decisions Richard Barnes