[Sframe] RFC Feedback

[Bret Lorimore <[e-mail]>]

Hey all,

I know a couple folks here, but not many. My name is Bret. I am a SWE at
Meta and have been working on calling E2EE for some time. Per Bobo’s
request, I wanted to share my thoughts on the latest RFC draft (
https://sframe-wg.github.io/sframe/draft-ietf-sframe-enc.html). I think the
doc makes sense generally, but have several thoughts, of both a technical
and editorial nature:

Technical:


   1.

   The notion and semantics of SFrame “streams” are alluded to throughout
   the document without being well defined. Does the RFC need to define the
   notion of an SFrame “stream”, consisting of media encrypted all with the
   same key and cipher suite? It seems like managing such streams is a
   requirement of the application, but the exact requirements are not spelled
   out. Here are examples where the notion of a stream comes up:
   1.

      In section 4.3 it describes a scenario where KIDs are unique to each
      sender, sort of implying that given an SFrame payload (including
the SFrame
      header) a receiver should be able to decrypt it.
      2.

      Then in section 4.5 it describes how “In a session that uses multiple
      media streams, different ciphersuites might be configured for different
      media streams”, of course implying that if KIDs are per sender, there
      would need to be some other mechanism to demux from KID →
stream, as there
      could be multiple cipher suites per stream.
      3.

      This is mentioned head on in section 5.1, where the draft states “In
      this scheme, it is assumed that receivers have a signal outside of SFrame
      for which client has sent a given frame, for example the RTP SSRC”
      2.

   It might be worth adding more details to section 5.1 to more clearly
   spell out how sender keys should (or could) work. For example, it states
   that “A receiver who receives from a sender with a new KID computes the
   new key as above [using an HKDF ratchet]”, yet later on says that “Evicting
   a participant requires each sender to send a fresh sender key to all
   receivers.”. Given both of these, it is not clear how a sender would
   signal a receiver that a frame is using a “fresh sender key” as opposed to
   a ratchet (or multiple) of a previously received key.
   3.

   Question: In section 4.3, is KLEN the actual key id length, or key id
   length minus one, as LEN is


Editorial:


   1.

   Throughout the doc there are numerous sections (e.g. 4.4.3, 6) which are
   very RTP specific, despite a stated goal of the RFC being that SFrame is
   transport agnostic.
   2.

   Section 7.2 states that key exchange is out of scope for this doc, yet
   it states that clients “MUST change their keys when new clients joins or
   leaves the call”. IMO if this is an absolute requirement of the RFC, as
   per the definition of an all caps MUST, then the exact requirements of this
   should be spelled out more, and possibly a reference protocol given.


Thanks, all. I am really excited for this RFC to land. I hope these notes
are somewhat helpful.


Best,

Bret