Subject: [MLS] confirming merge for PRs

From: Sean Turner <[email-masked]>
Date: Tue, 25 Feb 2020 12:29:06 -0500

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

---

From: Sean Turner <[email-masked]>
Date: Wed, 26 Feb 2020 11:28:27 -0500

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 <[email-masked]> wrote:
> 
> All,
>

---

From: Brendan McMillion <[email-masked]>
Date: Wed, 26 Feb 2020 08:40:21 -0800

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 <[email-masked]> wrote:
> 
> Hi!
> 
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls

---

From: Richard Barnes <[email-masked]>
Date: Wed, 26 Feb 2020 12:35:59 -0500

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=
[email-masked]> 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:
>
> > 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
> >
> >> 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.
> >>