Re: [MLS] confirming cipher suites decisions

Paul Grubbs <pag225@cornell.edu> Fri, 14 February 2020 20:48 UTC

Return-Path: <pag225@cornell.edu>
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 B09041201E3 for <mls@ietfa.amsl.com>; Fri, 14 Feb 2020 12:48:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=cornell.edu
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 yKBnsUovqYxv for <mls@ietfa.amsl.com>; Fri, 14 Feb 2020 12:48:11 -0800 (PST)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 DE3141201DC for <mls@ietf.org>; Fri, 14 Feb 2020 12:48:10 -0800 (PST)
Received: by mail-qt1-x82e.google.com with SMTP id r5so7865510qtt.9 for <mls@ietf.org>; Fri, 14 Feb 2020 12:48:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cornell.edu; s=g.20171207; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RvOybXE87jaEdl5s0dwFWbURUIy5+OLhlgeNnCZ84DE=; b=Yj4T6jrNEDGMcG1kZHoNJ3tSoj3N+96yjTm/b0l+wEIchUS3kf27k8mutoqJKlA1vx S/94IwxMEpBoBJYG+XENIvGV3phbKiruD6klF48pTbd6hWTKX52CgeERxjdyACh/6zmb yOABtRSXb80AAw1PH1h/FIvT0Hl7MhNIlB5nYBw6B3eDwlQ26Vfn0RbxMbqKiilyA6aR l2M0p+CIHYV6Sl33EgxxNR0NAJIJMhZeIZFUVO3RVwpCr5gq9QleDxD4UaU78CyCyH8J xr6zEJDTe3Q6h9eGFAtx7iNDg6AF/wq7IURzoZLFtOde9+TSxQMn3BBkw5hOfu49TRhc t93g==
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=RvOybXE87jaEdl5s0dwFWbURUIy5+OLhlgeNnCZ84DE=; b=cPFDOOqtB8CituR5V0ytvZfOlgo+3c+yao6UO8Xf98mr8aOQvcVrMQbpwDwEsOJADx 5u/JD/hS2k10XIIaV5lJ3oPcohYyt9wc609C/6AzttiyqXJvtIQvKIONrb6eNP+Afy2j vcF2eG/3fnHcgrNqeOzShBap10JYcsq1bLpITNqvs8cmPUaMnwykAkkMkFmxaXxmFurF CXTFJKBG5fH+AmdBdavjK6ocLJ6bO1NNYID3BDo3dPh5ncfzE5/KAnsvuqQXuO6FGhkc EzQ+jchmHXfJ452HVgMrJioJ/zKbea+lHfKUjby3TwTx+LD9ncbdFJ9xSDsOYfb8G4wL myQw==
X-Gm-Message-State: APjAAAXUj3i7NqcTq8+b1M/7+V5BXlNUlFhkedOi1YgFRlXGZJKN3tYz ya6UxVDd0CsLAb2RIhFgHmEZizs1ZOY1wE3Du0UuJw==
X-Google-Smtp-Source: APXvYqydUenQocoutKgi5sLAi7iBV2rvXB8V9V4nL7rcCAJi4KAaSGxIcdeZsWFgIv2VusE/O1NIyKmpBpRRWKwouEQ=
X-Received: by 2002:ac8:4419:: with SMTP id j25mr4121674qtn.378.1581713289371; Fri, 14 Feb 2020 12:48:09 -0800 (PST)
MIME-Version: 1.0
References: <D107086A-ED6C-48D8-8BC3-B3AE7E424F85@sn3rd.com> <9DE50F4A-DDBD-400E-8EA4-2D40A75CE028@sn3rd.com>
In-Reply-To: <9DE50F4A-DDBD-400E-8EA4-2D40A75CE028@sn3rd.com>
From: Paul Grubbs <pag225@cornell.edu>
Date: Fri, 14 Feb 2020 15:47:58 -0500
Message-ID: <CAKDPBw8OC74H7zAkk9e1mkm6UtB6L76Lh5qmjv-DNjep1LmApA@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bffca0059e8f52f7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/TyIsZsa8Fa38EzlmSdFTndeRHTE>
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: Fri, 14 Feb 2020 20:48:14 -0000

Hey all, quick question - all the AE schemes used in these cipher suites
are non-committing (meaning they misbehave in weird ways when keys may be
adversarially known or chosen). Not including a cipher suite which uses a
committing AE (cAE) scheme may make reasoning about the protocol's behavior
difficult in some settings. Since the latency increase of committing AE
would not be terribly high (one such scheme is AES128-CTR-then-HMAC-SHA384
with HKDF-derived encryption and authentication keys, which is reasonably
close to what Signal uses), might the inclusion of a cAE cipher suite be
worth discussing?

On Thu, Feb 13, 2020 at 9:49 AM Sean Turner <sean@sn3rd.com> wrote:

>
>
> > On Feb 6, 2020, at 11:08, Sean Turner <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.
>
> I finally got around to doing my homework related to PR279. My bit was the
> more procedural bits that instructs IANA to establish/use a Designated
> Expert pool:
> https://github.com/mlswg/mls-protocol/pull/307
>
> spt
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>