Re: [MLS] confirming merge for PRs

Richard Barnes <rlb@ipv.sx> Wed, 26 February 2020 17:36 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 0188E3A0E52 for <mls@ietfa.amsl.com>; Wed, 26 Feb 2020 09:36:19 -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 bN859HP5lI23 for <mls@ietfa.amsl.com>; Wed, 26 Feb 2020 09:36:17 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 EF4533A0E57 for <mls@ietf.org>; Wed, 26 Feb 2020 09:36:16 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id u124so165640qkh.13 for <mls@ietf.org>; Wed, 26 Feb 2020 09:36:16 -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=bANw9Q10UXtd0pVeoGuTF349gtsBLyz3gyNjxi3RDtk=; b=lOHYC7Lb2HKNwvsSgMnqovE7nCUzHI4qT08r39IN0mzOpAtCeUftfNtxu+StBJPcB1 jxTR863dwmZ1cBnU5z9TSXJaqp8hI0whMD6HnSIBFhaeuyQVn7hVsyaR5+gV2oYYgjd8 6uT7HrP/aPelwJUP+TiCJesQNcLBGY0eV2Z6rg66AOW93FyyP1Xfso2ZpW3g+/Uw6mgB MoVmL6HLrAjaJw4AirGpC/lnrFVjys5QKeKeYHuX0gyTeBRqxaPmIBG1hGUlGbFknHXb bh2vyDRDbCsNWpO5OuBrD0DqxhU0nYD8twqBeAVLoMasLyS4m0IiAgGT1I1cWhLsn78q b4SQ==
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=bANw9Q10UXtd0pVeoGuTF349gtsBLyz3gyNjxi3RDtk=; b=eXdBIL7a+ybC3NsdBiR5fnyxqPEqUWlYlv98a1mLAAq4zf3XfUln9dso0Pe8fGzdQN hSQ83iAFuYkh9F2c9WpnHslEHYVv4pC3gTLxcwekKu1tbomztYO+Ep0DuBEEXYvC4kr+ jESu34imG2J9dnFMSeLeOqRrIuXPWn8mKqXW52IWEfcyjOmph6ZsqHqaH1+vr1SOkHr5 WJ3I2clM8Sx76WPO2MMyZEd/K2sJWmlEViKzqqE2mLyh+GxTU7ImJC5OWRlRHMF5ROcc /DDwvY1VB2CplP+w3X0NyAtGTBGLUZxULZnsY7Hi3uhEyJvAB0sBBI6JeAV4AF+YAuFX XVYA==
X-Gm-Message-State: APjAAAVLplGveyNMWIiTDzTcz3zS/753E2Qf9nDRNAEVm0NTdzTp5DvU GUhwtZsJWmZPXtAs9oPKWUrze3i8DbgObg6oFHnesw==
X-Google-Smtp-Source: APXvYqzRKH66dtQ4hXdbDESzrKNUNkcQkK6TXCwKqMD082twsUrhTLo9BboSEXHly0XzC94mbhszFahPkOSyT5iJ6V8=
X-Received: by 2002:a05:620a:989:: with SMTP id x9mr187980qkx.371.1582738575767; Wed, 26 Feb 2020 09:36:15 -0800 (PST)
MIME-Version: 1.0
References: <101134CD-4B65-4172-9F82-C9466AE0B021@sn3rd.com> <AC1A2733-DC9A-4BA0-B127-F635BB183A88@sn3rd.com> <F05465C7-A102-44C5-8549-27B91160F3D1@cloudflare.com>
In-Reply-To: <F05465C7-A102-44C5-8549-27B91160F3D1@cloudflare.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 26 Feb 2020 12:35:59 -0500
Message-ID: <CAL02cgTPJGeX=JmSnsd-VM3cyz4daRO2GpfW1=C0iKxAfEhUVg@mail.gmail.com>
To: Brendan McMillion <brendan=40cloudflare.com@dmarc.ietf.org>
Cc: Sean Turner <sean@sn3rd.com>, Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000094cd40059f7e0afe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/q2ViSj3sOu9amhXxk6kQm07iyaQ>
Subject: Re: [MLS] confirming merge for PRs
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: Wed, 26 Feb 2020 17:36:19 -0000

Minor note: The usual terminology here is "critical" / "non-critical", cf.
X.509, JWE/JWS.

You observation here is correct -- much like in TLS, the server's selection
of extensions governs for the session, the group creator's selection of
extensions governs here.  As a corollary, the group extensions MUST be a
subset of the CIK extensions (just like server extensions are a subset of
client extensions).  I thought I had elaborated this, but I'm happy to make
it clearer.

I'm not sure that your examples really make the case for non-critical
extensions:

- If extensions change processing, even if they don't change the wire
image, everyone needs to do them.  See, e.g., RTreeKEM.
- GREASE extensions should be ignored, but only if the client *knows*
they're to be ignored, in which case the client supports them.  Note that
even in TLS (where the need is more acute), GREASE doesn't change who
offers and who chooses.

Not sure what you're envisioning for OOB; maybe there's a case there.

In any case, if you have an all-critical extension mechanism, you could use
it to opt into an optional-criticality extension mechanism, since everyone
would need to support the concept of non-critical extensions.  Or if it was
really important, adding support is just a matter of adding a criticality
flag.

I'm not finding a compelling reason for non-critical extensions at this
point, though, so I'm inclined to land the PR as it is (possibly with some
clarifications), and pivot later if we really need non-critical extensions.

--RLB

On Wed, Feb 26, 2020 at 11:40 AM Brendan McMillion <brendan=
40cloudflare.com@dmarc.ietf.org> wrote:

> Hi all
>
> My comment on the current PR is just pointing out that, if an extension is
> used in a group’s config, then it seems like it's mandatory for all clients
> to understand that extension. There are some cases where it might be
> desirable for a group to “have” an extension without call clients needing
> to understand it, including:
>
> - Extensions that improve efficiency without wire changes
> - Extensions that create out-of-band channels
> - GREASE extensions
>
> So, this is an argument for distinguishing between mandatory and optional
> extensions.
>
> > On Feb 26, 2020, at 8:28 AM, Sean Turner <sean@sn3rd.com> wrote:
> >
> > Hi!
> >
> > Brendan noted on the call that he thought that we needed some more
> discussion on #296. I see that he’s submitted a comment on the PR. If we
> cannot come to closure on this on list, then we can discuss it next week.
> >
> > spt
> >
> >> On Feb 25, 2020, at 12:29, Sean Turner <sean@sn3rd.com> wrote:
> >>
> >> All,
> >>
> >> The following PRs were 1st discussed at the 5-Feb virtual interim. The
> WG discussed them again on the 1-Feb call and the editors believe these are
> ready to merge. If have any objections to merging these please provide your
> input by 2359 UTC 28-Feb otherwise we will declare consensus and the will
> ask the editors to merge the PRs.
> >>
> >> #283 Use the same ratchet for Handshake and Application keys
> >> https://github.com/mlswg/mls-protocol/pull/283
> >>
> >> #296 Flesh out the extensions story
> >> https://github.com/mlswg/mls-protocol/pull/296
> >>
> >> #304 Use HKDF to derive key pairs
> >> https://github.com/mlswg/mls-protocol/pull/304
> >>
> >> Cheers,
> >>
> >> spt
> >>
> >
> > _______________________________________________
> > 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
>