Minutes interim-2020-mls-13: Tue 12:00
minutes-interim-2020-mls-13-202005191200-00

# 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!