Re: [Sframe] RFC Feedback

[Youenn Fablet <[e-mail]>]

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:
> 
> 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:
> 
> 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.
> 
> 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.
> 
> 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”
> 

https://github.com/sframe-wg/sframe/issues/100
The notion and semantics of SFrame “streams” are not well defined · Issue #100 · sframe-wg/sframe
github.com


> 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.
> 
https://github.com/sframe-wg/sframe/issues/99
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
github.com

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

https://github.com/sframe-wg/sframe/issues/98
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
github.com


> 
> Editorial:
> 
> 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.
> 

https://github.com/sframe-wg/sframe/issues/96
Is the document talking too much about RTP? · Issue #96 · sframe-wg/sframe
github.com


> 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.
> 
https://github.com/sframe-wg/sframe/issues/97
MUST statement for out-of-scope key management · Issue #97 · sframe-wg/sframe
github.com

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