Re: [MLS] Syntax and mechanics for external commit

[Richard Barnes <[e-mail]>]

OK, how about the following proposal (heh):

- Add ExternalInitSecret proposal
- Add an "inline proposals" field to Commit that lets the committer send
proposals with a commit

Two remaining worries here:

- Validation: You want it to be the case that an ExternalInitSecret is only
present for a Commit signed by a new joiner.  So some that information will
have to be passed from MLSPlaintext validation to Commit processing.  Or
maybe we don't care about that restriction?  It seems like a member sending
ExternalInitSecret should at least be SHOULD NOT, but maybe it's not bad
enough to absolutely forbid / have hard checks against.

- Complexity: MLSPlaintext signature validation has to find a key to verify
the signature.  I guess in this case, it should take the one for the
Committer (Commit.update_path.leaf_key_package.public_key), but it should
also be the case that that key was added to the group with this Commit.  In
any case, this probably calls for a new sender type.

Maybe these can both be solved with a flag passed into Commit processing:

if (external_commit) {
  // verify that there is an Add corresponding to
update_path.leaf_key_package
} else {
  // verify that ExternalInitSecret is not present
}

Even if so, that logic should get specified in the commit processing
section of the spec.

--RLB


On Wed, Oct 7, 2020 at 8:57 AM Raphael Robert <raphael=
[e-mail]> wrote:

> I think that’s exactly the motivation we need for inline proposals, this
> surplus of signatures is not specific to this use case!
>
> Raphael
>
> > On 7 Oct 2020, at 13:27, Joel Alwen <[e-mail]> wrote:
> >
> > On 7 Oct 2020, at 03:20, Richard Barnes <[e-mail]> wrote:
> >> 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.
> > Isn't it a bit redundant to have the External party prepare a full
> > (ExternInitSecret) proposal packet only to then immediately commit to
> it? That
> > means a full extra frame of bandwidth, an extra signature for the
> external party
> > and an extra sig verification for group members.
> >
> > I'm wondering what the motivation is for making this an explicit proposal
> > instead of, say, a second mode for commits. (E.g. a commit uses
> init_secret[n]
> > iff no kem_output field is included in the commit packet. Otherwise it
> uses the
> > "external_init_secret" computed as Richard described.)
> >
> > ATM I can't think of a scenario where we wouldnt want the external
> committer to
> > also be the one creating the ExternalInitSecret proposal and immediatly
> > committing to it...
> >
> > - Joël
> >
> >
> > On 07/10/2020 12:36, Raphael Robert wrote:
> >> Thanks Richard for looking at all aspects in detail!
> >>
> >> I thought about these things as well and will comment inline:
> >>
> >>> On 7 Oct 2020, at 03:20, Richard Barnes <[e-mail]> wrote:
> >>>
> >>> 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
> >>
> >> I think we are better off with re-using the current Commit syntax and
> I’ll
> >> explain why further below.
> >>
> >>> - 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
> >>
> >> From the discussion at the interim, I think there is consensus about
> this
> >> part, we just need to add that to the PR.
> >>
> >>>
> >>>
> >>> # 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.
> >>
> >> While that is not very explicit in the current PR, my approach was the
> >> following:
> >>
> >> All Proposals should be allowed in an external Commit:
> >>
> >> - Adds: The joiner (new member) could right away add more members, or
> Commit
> >> to already existing Add Proposals if those are accessible. - Removes:
> The
> >> joiner can remove prior appearances of itself (like you pointed out) or
> >> Commit to already existing Remove Proposals. - Updates: The joiner
> should of
> >> course not issue own Updates and Commit to them, but that is already
> the case
> >> for internal Commits. The joiner can Commit to already existing Update
> >> Proposals from other members.
> >>
> >> Whether all of the above is allowed should only be governed by the
> policy for
> >> a group, nothing else. As a reminder: all clients MUST have the same
> policy
> >> for a certain group in order ta validate/refute Proposals and Commits.
> >>
> >> This pretty much motivates my idea for fully re-using the existing
> Commit
> >> syntax and only introduce the new ExternalInitSecret Proposal.
> >>
> >>>
> >>>
> >>> # 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;
> >>
> >> This is exactly the Proposal we need.
> >>
> >>>
> >>> Given the requirement for an Add proposal, the joiner now has to send a
> >>> “flight of messages”:
> >>>
> >>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit
> >>
> >> I see some more nuance here. The first Add Proposal does not have to be
> >> issued by the new joiner, it could very well be an external Proposal.
> The
> >> scenario I had in mind here is the following:
> >>
> >> A server issues an external Add Proposal for a group. The following
> things
> >> can happen:
> >>
> >> a) Ideal scenario:
> >>
> >> - A member of the group comes online, validates the Add Proposal
> according to
> >> the policy and references it in an internal Commit (no External Commit
> >> needed) and sends a Welcome message to the new member
> >>
> >> b) Equally ideal scenario:
> >>
> >> - The new joiner comes online before anyone else, has access to the
> public
> >> group data but does not need to communicate with the group. Nothing
> happens.
> >>
> >> c) Emergency scenario:
> >>
> >> - The new joiner comes online before anyone else and needs to urgently
> send a
> >> message to the group. The new joiner creates the ExternalInitSecret
> Proposal
> >> and the Commit and sends both to group.
> >>
> >>>
> >>> 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.
> >>>
> >>
> >> As mentioned above, I’m all for re-using the existing Commit syntax
> because
> >> of clarity, simplicity and flexibility.
> >>
> >> I do agree that the amount of signatures is sub-optimal, and this is
> >> something that also occurs in other situations. For example, when a
> member
> >> wants to add n new members at once to the group, it needs to compute n+1
> >> signatures for that. You mention the idea of inline proposals: Would
> that be
> >> a proposal that doesn’t have a signature, but still all other
> information? If
> >> so, I think it would be worthwhile looking at that separately, because
> as you
> >> say, it could be back-ported to internal Commits as well. I’m all for
> >> exploring that idea further.
> >>
> >>>
> >>> # 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;
> >>
> >> This is what the PR currently says, except that the PR used
> GroupContext and
> >> has the full public tree. I agree that the tree hash should be enough
> and
> >> I’ll change the PR accordingly.
> >>
> >>>
> >>> 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.
> >>
> >> While the two are awfully similar, the signature on GroupInfo is not
> required
> >> here and might have undesired effects w.r.t deniability if this is
> publicly
> >> accessible. The other reason for not wanting the signature is that it
> would
> >> be an additional signature to compute with every Commit, making them
> even
> >> more expensive. I propose to keep the struct as-is.
> >>
> >>>
> >>> In any case, it seems like it would be useful to have some syntax for
> >>> this.
> >>>
> >>> Hope this helps, —RLB
> >>
> >>
> >> TL;DR:
> >>
> >> I propose the following:
> >>
> >> - Keep the current Commit syntax - Allow all kinds of Proposals for
> External
> >> Commits, same as with internal Commits - Do the HPKE-based init secret
> for
> >> External Commits - Introduce the ExternalInitSecret Proposal and make it
> >> mandatory for External Commits - Explore the idea of inline proposals
> >> separately - Do not re-use signed GroupInfo struct and keep the adjusted
> >> ExternalCommitInfo instead
> >>
> >> Raphael
> >>
> >>> _______________________________________________ MLS mailing list
> >>> [e-mail] https://www.ietf.org/mailman/listinfo/mls
> >>
> >> _______________________________________________ MLS mailing list
> >> [e-mail] https://www.ietf.org/mailman/listinfo/mls
> >>
> >
> > _______________________________________________
> > MLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mls
>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>