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: ADFU+vuULNJuU/klR5PrKKfgz5xHzqgmnPv2cBy6WOIVt9I5ko8kc1Si3mT7A+vZL+6YsZXU7Le83Mfynnp9VdUjnCg=
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, 05 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 >
- [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