# MLS Meeting 2020-05-19 Notes

(Scribe: Konrad)

# Attendees

Sean Turner, sn3rd
Nick Sullivan, Cloudflare
Britta Hale, NPS
Konrad Kohbrok, Aalto University
Raphael Robert, Wire
Richard Barnes, Cisco
Hubert Chathi, matrix.org
Watson Ladd, Cloudflare
Brendan McMillion, Cloudflare
Chris Brzuska, Aalto University
Nalini Elkins, Inside Products

# Notes

- Today's Agenda: Issues and PRs regarding the Key Schedule

- PR #336 PSK Injection
  - Handles various use cases for PSK injection (re-initialization, branching, external PSKs)
  - no "targeted messages" for now
  - Richard: The PR is underspecified in terms of how it should be used.
  - Britta: The security benefits we get from using PSKs should go into the architecture document.
  - Richard is going to take a look at the PR and give feedback.
  - Raphael has an open question regardin redundancy in key derivation and will bring it up later.


- PR #331 Making ratcheting optional for Adds
  - This PR suggests that Adds can be made without adding new entropy to the group, 
    i.e. one could commit an Add without doing an update.
  - (I missed a lot of the discussion due to choppy audio from the other side of the Atlantic. Sorry about that!)


- PR #337 n-PRF (multi-PSK injection)
  - This PR enables the injection of multiple PSKs into the key schedule in a sound way.
  - Watson: The PR is inconsistent: Does it have to be at least two keys?
  - Chris Brzuska: The PR suggests a primitive for the injection of n PSKs, i.e. one or more.
  - Sean: Is it a problem that this suggestion deviates from the "standard way", which has 
    seen a lot of analysis and is known to be secure?
  - Chris: The suggestion was inspired from the analysis of the TLS 1.3 key schedule and is
    a simplification that actually makes it easier to analyse.
  - Chris: There is an additional requirement: We need a (per-use) unique value when using 
    the primitive to prevent collisions.
  - Watson: If we rely on the Random Oracle Model (ROM), then a hash function would do.
  - Chris: Yes, if we are ok with operating in the ROM, the key schedule can be simplified significantly.
  - Britta: In terms of operations: What is the overhead we get with this approach?
  - Chris: The overhead is # of secrets you want to combine plus 1 HKDF invocations. 
    (Chris please correct me if I got this wrong.)
  - Britta: Using the primitive suggested, it would be 1 more HKDF invocation for the standard use case
    than in the current approach.
  - Raphael: Should this be discussed on the mailing list?
  - Sean: Yes, this should get a wider review.
  - Chris: Ok, I will send a mail to the list.

- Sean: Thanks for joining! The next interim is on June 2nd!