Skip to main content

Secure Frame (SFrame)

Note: This ballot was opened for revision 07 and is now closed.

Murray Kucherawy
Orie Steele
(was No Objection) Yes
Comment (2024-03-28 for -07) Not sent
Thanks to Valery Smyslov for the ART-ART review. It appears all feedback has been addressed.
Thanks to Martin Thomson for the Shepherd writeup... Noting that it is partially complete.

expected sucess rate of the following form
Typo, see
Paul Wouters
(was Discuss) Yes
Comment (2024-04-04 for -07) Sent
Thanks for the discussion on my raised issues. I've updated my ballot to Yes
Zaheduzzaman Sarker
Comment (2024-04-04 for -07) Not sent
Thanks for working on this specification.
Deb Cooley
No Objection
Comment (2024-04-02 for -07) Sent
Thanks to Carl Wallace for his review.  I checked some of his nits, and they appear to be addressed, even though there was nothing on the mailing list to indicate that (at least not directly).

I thought this was well written.  I view these as pretty minor comments.  I'm happy to discuss them, and adjust.

Section 4.1, 7.1:  "an E2EE layer over an underlying HBH-encrypted transport".  It would be clearer to say "an E2EE layer inside a HBH-encrypted transport".  Obviously the HBH encryption has to be on the outside, right?  I'm assuming that 'over' means above it in the protocol stack.  If this is a common way to say this in the IETF, then it is fine (I'll get used to it eventually).

Section 4.4.1, para 2:  Potential re-use of counter values would be reduced in implementations if the previous counter value was stored (currently next counter is stored).  The client increments (and stores) at the start vice after the counter is used. It eliminates a failure to store the next value.  Only my opinion... If there are many implementations already, then I withdraw the comment.  Confusion caused mid implementation is worse than leaving it alone.

Section 4.4.2:  If 'sframe_key_label' and 'sframe_salt_label' is 'info' in the HKDF computation, that should be stated somewhere (or replace 'info' with the label name).

Section 4.4.3/4.4.4:  Metadata is both encrypted and appended in the clear (visible to the SFU)?  If so, is the decrypted metatdata compared with the appended metadata?  Assuming that the metadata is encrypted to provide integrity... Is this stated somewhere?  

Section 4.4.4:  Does the decryptor keep track of CTR state?  If so, what happens if a CTR value is re-used by the encryptor?  Is the sframe rejected?  Is there an error sent?  maybe out of band (through the signaling channel)?

Section 4.5.1: For "enc_key_sframe_key[..Nka]" add a comment stating that this is picking the first Nka bytes.  Also add a comment to "auth_key = sframe_key[Nka..]" stating to skip Nka bytes to pick the last Nh bytes.  (this is done as a comment later in the document, so do it here too)

Section 5:  Key management is the responsibility of the application.  And then there is section 5.1 and 5.2.  Are they options?  Suggestions?  Perhaps add 'Section 5.1 and 5.2 provide two options for partial key management frameworks.'  (framework might not be the right word, because neither 5.1 nor 5.2 discuss how the base_key gets generated.)
Erik Kline
No Objection
Gunter Van de Velde
No Objection
Comment (2024-03-29 for -07) Not sent
Jim Guichard
No Objection
John Scudder
No Objection
Comment (2024-04-03 for -07) Sent
Thanks for this document. To the extent I’m qualified to review it, I found it clear, comprehensive, and readable. I have a minor comment and a trivial question.


“Invalid ciphertexts SHOULD be discarded in a way that is indistinguishable (to an external observer) from having processed a valid ciphertext.”

This might be clear to someone within your ecosystem, but I wonder what exactly is meant by “external” here. I infer it means an observer without any access to a system that’s participating in the conference, because otherwise, I don’t see how this requirement could be met (consider the case where the discarded ciphertext is a keyframe, for example). 

Whether this calls for clarification or not is up to you. 


I also wonder as to the practical value of the compressed CTR representation — I would have imagined that most use cases would emit more than 8 plaintexts, and for that matter, if there are 8 or fewer plaintexts to be emitted over the lifetime of the KID, the application is so low-volume that maybe the optimization doesn’t buy you much as compared to, say, adding another bit to the compressed KID field. 

But this is just idle curiosity, even if the answer was “yeah, it’s not that useful” I wouldn’t advocate changing the encoding at this late date.
Roman Danyliw
No Objection
Comment (2024-04-02 for -07) Sent
Thank you to Linda Dunbar for the GENART review.  I reviewed this document for GEN area issues.

** Section 8.1.  Per the SFrame Cipher Suites registry, did the working group consider adding another column to the registry to capture the whether the IETF recommends the use of a given ciphersuite?  Consider the definition of a “Recommended” column in the TLS Ciphersuites and COSE Algorithms registries:


Could such a Recommendation column be added here?  It helps readers of the registry quickly understand which registrations have an IETF endorsement, while still making it easy to add code points.
Warren Kumari
No Objection
Comment (2024-04-02 for -07) Sent
Thank you for this document -- I found it a fascinating read.

I am balloting NoObj, but have some nits to offer to further improve it.

1: 1.  Hop-by-hop (HBH) encryption of media, metadata, and feedback messages between the the endpoints and SFU
s/the the/the/

2: "the receiving client collects all the fragments of the ciphertext, using an appropriate sequencing and start/end markers in the transport. "
s/an// (I think!)

3: ""_80" indicates a eighty-bit tag," 

4: Key IDs in this scheme have two parts, a "key generation" and a "ratchet step".

5: "Ratcheting the key forward is useful when adding new receivers to an SFrame-based interaction, since it assures that the new receivers can't decrypt any media encrypted before they were added."
s/assures/ensures/ (I think...?!)

6: Such a brute-force attack will have an expected sucess rate of the following form:
Éric Vyncke
No Objection
Comment (2024-04-04 for -07) Sent
Thank you for the work done in this I-D. It is *really* well-written and I love the neat SVG graphics!  Also a good idea to have test data.

While I am not familiar at all about MLS, I wonder whether only using E bits of the epoch in section 5.2 does not open a window for replay attack? Should there be some guidance for the minimum amount of E bits ?

Thanks as well to Suresh Krishnan for his int-dir review at: and I have read Richard's reply.


- be consistent for "hop-by-hop" or "hop by hop"
- expand RTX (and possibly FEC) at first use
- perhaps define 'frame' (I understood it like a MPEG frame but could be wrong)