Change:
If X flag is 0, then the KID is in the range of 0-7 and the counter (CTR) is found in the next LEN bytes: <del> If X flag is 1 then KLEN is the length of the key (KID).  The KID is </del> <ins> If X flag is 1 then KLEN is the length of the key (KID) in bytes, minus one (the range of possible lengths is thus 1-8).  The KID is </ins> encoded in the KLEN bytes following the metadata byte, and the counter (CTR) is encoded in the next LEN bytes:

Discussion:
Feedback from URL In section 4.3, is KLEN the actual key id length, or key id length minus one, as LEN is?
My interpretation of the intent is to be key id length minus one.
URL 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-URL). 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” 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. Question: In section 4.3, is KLEN the actual key id length, or key id length minus one, as LEN is 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. 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