Subject: [MLS] Notes from today's working call

From: Richard Barnes <[email-masked]>
Date: Thu, 27 Jan 2022 13:29:32 -0500

Hi all,

We had a very productive call today, and covered pretty much all the
outstanding issues and PRs!  I put some notes in the PRs as we went along,
but a consolidated summary is below.

In addition to the below details, the overall plan the editors have for the
next few steps is:

1. Merge what can be merged from the current list of proposals
2. Make a PR to rearrange sections, without modifying the text of the
sections
3. Continue work on remaining issues

The need for (2) has been around for a while and is becoming increasingly
urgent.  So we're basically imposing a blackout period so that people don't
have to do tough rebases.  Round (1) will include everything that is
basically ready to go now.  Round (3) will cover the few substantive things
we have outstanding.

Thanks again to everyone who participated today,
--RLB

#556 - Fix some typos.
#555 - Add clarifying note about _resolution_ in the most common case.
#554 - Use common-sense definition of _descendant_
#553 - Make definition of _group_ match the Introduction definition
#552 - fetching KeyPackages SHOULD be rate limited.
#551 - Rename InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState

* Editors will handle these, didn't look like they needed WG discussion

#509 - Be explicit that Credentials can attest to multiple identities

* Core thing to assure is that we have the same validation logic across
Add, Update, and Commit
* TODO(Richard) Update and propose merging

#546 - Downgrade MUST to SHOULD for commit senders including all valid
commits
#542 - Conflicting proposal / commit behavior

* Agreement on the resolution in the PR: Clarify that receivers need not
generate an error if they see a Commit that they don't believe covers all
valid proposals.
* TODO(Tom) Update PR, then editors will review + merge

#523 - Move wire_format to a separate tagged-union structure MLSMessage

* Agreement that this is a good idea; some specifics noted in PR
* On hold until after move-sections-around PR

#527 - Stronger parent hashes for authenticated identities

* Théophile reviewed the state of the discussions and current options
* Karthik elaborated on the motivations for covering the credentials in the
leaves
* Agreement that covering the leaves as a list would provide the desired
security property, possibly with lower efficiency
* Richard raised the possibility of eliminating unmerged_leaves **only when
the tree is extended**, which should avoid the issues blocking the use of
the tree hash.
* In general, we have the following decision tree among the various parent
hash options:
  * Do we want to authenticate credentials in parent hash?
    * No => resolution hash
    * Yes => Are we OK with efficiency of leaf hash?
      * Yes => leaf hash
      * No => Do we need unmerged_leaves?
        * No => tree hash
        * Yes => tree hash + one of:
          * Always tree hash over full tree
          * Store number of leaves at tree parent hash alongside parent hash
* TODO(Richard) Describe partial removal of unmerged leaves on PR
* On hold until after move-sections-around PR

#540 - Proposals by reference in external commit

* Agreement to forbid proposals by reference in external commits
* ... since the external joiner can't verify their validity
* TODO(Richard) File a PR to implement this

#537 - Clarity around extensions and RequiredCapabilities

* Agreement on the "everything in the spec is MTI" approach
* TODO(Richard) File a PR to implement, or close if it doesn't look like
one is necessary

#538 - KeyPackage lifetime handling

* TODO(Richard) Close in favor of #539

#539 - Separation between pre-published key packages and leaf node content

* General agreement that the basic idea of the separation is good
* Broad support for signing ciphersuite, group_id in leaves
  * Some details to be worked out with regard to how to represent this
  * Storing information in the leaves vs. just inserting into the signature
* Need to consider whether extensions are needed at both levels
* On hold until after move-sections-around PR