[MLS] Syntax and mechanics for external commit

[Richard Barnes <[e-mail]>]

Hey all,

I wanted to send some thoughts on how to implement external commit, as a
prelude to a PR.  This is a little bit of an essay, so tl;dr, the proposal
is:

- Rather than re-using Proposal/Commit, we should make a new ExternalCommit
message, parallel to Proposal/Commit
- We should also define a syntax for telling the joiner the requisite
information about the group

# HPKE-based init secret

The concept here is as follows:

- An HPKE/KEM key pair `(skG, pkG)` is derived off of the key schedule for
each epoch
- The public key `pkG` of that key pair is published along with with other
group metadata
- The joiner calls SetupBaseS(pkG, some_public_group_context) to get an
encapsulated key `enc` and an HPKE context `ctx`
- The joiner sends the encapsulated key to the group with their external
commit
- The members of the group call SetupBaseS(enc, skG,
some_public_group_context) to get an equivalent HPKE context `ctx`
- Everyone calls `ctx.export(MLS_export_label, init_secret_size)` to derive
the init secret

So there are two syntactic requirements:

1. Publishing the group’s public key `pkG`
2. Sending the encapsulated key `enc` to the group


# What Proposals?

The current PR correctly requires that the external Commit MUST cover an
Add proposal for the new member.   It does not forbid the Commit covering
*other* proposals.  It seems like it might be useful in a couple of cases
to keep that option open:
* Including PSK proposals for additional authentication when joining
* Including a Remove proposal for your prior appearance when re-joining

The only current proposal that would be nonsensical is an Update.

Whether we do this has some impact on the syntax, as discussed below.


# External commit syntax: Separate or Together

Assume for the moment that we are not going to do the above asymmetric
calculation for every commit.  Then we need some extra, optional syntax  to
carry `enc`, either as an optional field on Commit or as a new Proposal,
which is the agreed mechanism for extending Commits.  (If we do it every
time, we can just make this part of Commit.)  In the below, I’ll assume a
new Proposal, say ExternalInitSecret.

struct {
  opaque kem_output<0..2^16-1>;
} ExternalInitSecret;

Given the requirement for an Add proposal, the joiner now has to send a
“flight of messages”:

- Proposal(Add)
- Proposal(ExternalInitSecret)
- Commit

Let’s call this the Separate Option.  It’s a bit heavyweight, since each of
these is signed separately.  It’s duplicative, since the KeyPackage in the
Add is immediately overwritten by the (necessarily different) KP in the
Commit.  And you have potential fate-sharing issues, since all three need
to succeed or fail.

You could also envision a Together Option, where we define another
top-level content type (parallel to Proposal and Commit) for this purpose:

struct {
  opaque kem_output<0..2^16-1>;
  UpdatePath path;
} ExternalCommit;

That would avoid all of the challenges above, but it optimizes out all of
the flexibility to include other proposals.  So maybe it’s worth
considering an Extensible Together Option, where we can put extra proposals
into an ExternalCommit

struct {
  Proposal proposals<0..2^32-1>;
  opaque kem_output<0..2^16-1>;
  UpdatePath path;
} ExternalCommit;

Personally, I kind of like the Flexible Together Option, since it provides
simplicity and extensibility.  And to be honest, I’ve been wondering if we
should allow inline proposals in Commit for a while, along just these
lines.  If we do this option, we should probably back-port it to Commit as
well.


# Syntax for what the Joiner Needs

The PR notes that the joiner needs to know a bunch of information about the
group in order to make a well-formed ExternalCommit.  In earlier iterations
of this style of join, we had a GroupInitKey that carried the right
information. Following that pattern here, we get something like the
following:

struct {
  CipherSuite cipher_suite;
  opaque group_id<0..255>;
  uint64 epoch;
  opaque tree_hash<0..255>;
  opaque confirmed_transcript_hash<0..255>;
  Extension extensions<0..2^32-1>;
} GroupKeyPackage;

Note that this object is essentially the same as a GroupInfo object.  The
only things it is missing are interim_transcript_hash and signature, both
of which might be useful.  So maybe all we need to do here is say that
clients can publish GroupInfo unencrypted if they want to enable self-adds,
in addition to distributing it in encrypted form in Welcome.

In any case, it seems like it would be useful to have some syntax for this.

Hope this helps,
—RLB