Re: [Sframe] RFC Feedback

[Bret Lorimore <[e-mail]>]

Thanks Youenn!

On Sat, Mar 4, 2023 at 06:34 Youenn Fablet <[e-mail]> wrote:

> Thanks Bret,
>
> I filed GitHub issues on your behalf for each of your point, see below for
> the links.
> Let’s continue the discussion there.
> Y
>
> On 2 Mar 2023, at 16:58, Bret Lorimore <[e-mail]> wrote:
>
> 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”
>
>
> [image: 100.png]
>
> The notion and semantics of SFrame “streams” are not well defined · Issue
> #100 · sframe-wg/sframe <https://github.com/sframe-wg/sframe/issues/100>
> github.com <https://github.com/sframe-wg/sframe/issues/100>
> <https://github.com/sframe-wg/sframe/issues/100>
>
>
>
>    1.
>
>    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.
>
> [image: 99.png]
>
> Retrieving a key from its ID is ambiguous as it can be a new key or a
> ratchet of a new received key · Issue #99 · sframe-wg/sframe
> <https://github.com/sframe-wg/sframe/issues/99>
> github.com <https://github.com/sframe-wg/sframe/issues/99>
> <https://github.com/sframe-wg/sframe/issues/99>
>
>
>    1.
>
>    Question: In section 4.3, is KLEN the actual key id length, or key id
>    length minus one, as LEN is
>
>
> [image: 98.png]
>
> In section 4.3, is KLEN the actual key id length, or key id length minus
> one, as LEN is? · Issue #98 · sframe-wg/sframe
> <https://github.com/sframe-wg/sframe/issues/98>
> github.com <https://github.com/sframe-wg/sframe/issues/98>
> <https://github.com/sframe-wg/sframe/issues/98>
>
>
>
> 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.
>
>
> [image: 96.png]
>
> Is the document talking too much about RTP? · Issue #96 · sframe-wg/sframe
> <https://github.com/sframe-wg/sframe/issues/96>
> github.com <https://github.com/sframe-wg/sframe/issues/96>
> <https://github.com/sframe-wg/sframe/issues/96>
>
>
>
>    1.
>
>    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.
>
> [image: 97.png]
>
> MUST statement for out-of-scope key management · Issue #97 ·
> sframe-wg/sframe <https://github.com/sframe-wg/sframe/issues/97>
> github.com <https://github.com/sframe-wg/sframe/issues/97>
> <https://github.com/sframe-wg/sframe/issues/97>
>
>
> Thanks, all. I am really excited for this RFC to land. I hope these notes
> are somewhat helpful.
>
>
> Best,
>
> Bret
>
> --
> Sframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sframe
>
>
>