Secure Frame (SFrame)
draft-ietf-sframe-enc-09

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-sframe-enc and RFC 9605, changed IESG state to RFC Published)

[Ballot discuss]
I have some questions that are likely easily answered and more indicative of my lack of experience in streaming infrastructure.

1) KID and CTR encoding

Is there really much to be gained from the SFrame Header KID and CTR encoding for small values? For example an audio or video stream
would almost immediately require the "extended encoding" for the CTR? I find it difficult to see the advantage of this added complexity.

2) Tag size

What is the real gain of allowing shorter authentication tags? Even the document itself states:

        Nonetheless, without these mitigations, an application that
        makes use of short tags will be at heightened risk of forgery
        attacks. In many cases, it is simpler to use full-size tags and
        tolerate slightly higher bandwidth usage rather than add the
        additional defenses necessary to safely use short tags.

Why not simplify on just 1 tag size?


3) IANA Considerations

Have you considered splitting the ciphersuites into a part that
requires standards action and a part that is specification required?

Related, have you considered using a RECOMMENDED column for ciphersuites,
where a RECOMMENDED=y can only be done via standards action?

[Ballot comment]
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: https://datatracker.ietf.org/doc/review-ietf-sframe-enc-07-intdir-telechat-krishnan-2024-03-29/ and I have read Richard's reply.

Nits:

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

[Ballot comment]
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.

Comment:

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

Question:

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.

[Ballot comment]
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:

-- https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
-- https://www.iana.org/assignments/cose/cose.xhtml#algorithms

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.

[Ballot comment]
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.)

[Ballot comment]
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,"
s/a/an/

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

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:
s/sucess/success/

[Ballot comment]
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 https://github.com/sframe-wg/sframe/pull/189

[Ballot comment]
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, and missing confirmation of IPR.


"""
expected sucess rate of the following form
"""

Typo, see https://github.com/sframe-wg/sframe/pull/189

[Ballot comment]
Thanks to Valery Smyslov for the ART-ART review. It appears all feedback has been addressed.
Thanks for Martin Thomson for the Shepherd writeup... Noting that it is partially complete, and missing confirmation of IPR.


"""
expected sucess rate of the following form
"""

Typo, see https://github.com/sframe-wg/sframe/pull/189

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-sframe-enc-06. If any part of this review is inaccurate, please let us know.

IANA has a question about the second action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, a new registry group is to be created on the IANA Matrix located at:

https://www.iana.org/protocols

The new registry group will be called SFrame and will have a reference of [ RFC-to-be ].

Second, a new registry will be created called Sframe Cipher Suites. The new registry will be located in the registry group created above. The values in the registry range from 0x0000 to 0xFFFF. The new registry is managed via Specification Required as defined in RFC8126.

There are initial registrations in the new registry as follows:

Value Name Reference
-----+-----+-----------
0x0001 AES_128_CTR_HMAC_SHA256_80 [ RFC-to-be ]
0x0002 AES_128_CTR_HMAC_SHA256_64 [ RFC-to-be ]
0x0003 AES_128_CTR_HMAC_SHA256_32 [ RFC-to-be ]
0x0004 AES_128_GCM_SHA256_128 [ RFC-to-be ]
0x0005 AES_256_GCM_SHA512_128 [ RFC-to-be ]
0x0006 - 0xEFFF Unassigned
0xF000 - 0xFFFF Reserved for private use [ RFC-to-be ]

IANA Question --> Is the value 0x0000 reserved or unassigned?

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-02-15):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sframe-enc@ietf.org, mt@lowentropy.net, sframe-chairs@ietf.org, sframe@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Secure Frame (SFrame)) to Proposed Standard


The IESG has received a request from the Secure Media Frames WG (sframe) to
consider the following document: - 'Secure Frame (SFrame)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-02-15. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the Secure Frame (SFrame) end-to-end
  encryption and authentication mechanism for media frames in a
  multiparty conference call, in which central media servers (selective
  forwarding units or SFUs) can access the media metadata needed to
  make forwarding decisions without having access to the actual media.

  The proposed mechanism differs from the Secure Real-Time Protocol
  (SRTP) in that it is independent of RTP (thus compatible with non-RTP
  media transport) and can be applied to whole media frames in order to
  be more bandwidth efficient.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sframe-enc/



No IPR declarations have been submitted directly on this I-D.

Document writeup for draft-ietf-sframe-enc-06
Shepherd: Martin Thomson
Date: 2023-12-06


# Document History

This document is the input document that caused the formation of the SFrame
working group.  It is substantially the same as that original input on a
technical level, though many aspects of that design have been tested in the
working group. The editorial quality is significantly improved and more robust
security and deployment considerations are now present.  The one major addition
was the inclusion of a concrete usage of MLS for key management, which was
originally in a separate draft.

This work spent a long time without a lot activity, interspersed with short
bursts of high productivity.  The WG chairs believe that sufficient input has
been received despite this.

Implementations and deployments exist.  Test vectors are included and are
produced and checked by an automated system.

# Reviews

This document includes a very straightforward integration of AEAD and HKDF.
Careful security review from outside of the working group will be helpful, but
this shepherd believes that this has a low risk profile due to the extreme lack
of novelty.  There is no formal analysis.

# Checks

The document is clear and precise.  The design is sensible and appropriately
scoped.

Checked: Status (std), IPR (checks in progress), issues, idnits (what a trash
fire of a program), references (no downrefs, no unfinished work), registries.

# Registry Experts

A new registry is established for ciphersuites.  This will need experts.  I
recommend that this include all of the draft authors (checking with authors in
progress).

Document writeup for draft-ietf-sframe-enc-06
Shepherd: Martin Thomson
Date: 2023-12-06


# Document History

This document is the input document that caused the formation of the SFrame
working group.  It is substantially the same as that original input on a
technical level, though many aspects of that design have been tested in the
working group. The editorial quality is significantly improved and more robust
security and deployment considerations are now present.  The one major addition
was the inclusion of a concrete usage of MLS for key management, which was
originally in a separate draft.

This work spent a long time without a lot activity, interspersed with short
bursts of high productivity.  The WG chairs believe that sufficient input has
been received despite this.

Implementations and deployments exist.  Test vectors are included and are
produced and checked by an automated system.

# Reviews

This document includes a very straightforward integration of AEAD and HKDF.
Careful security review from outside of the working group will be helpful, but
this shepherd believes that this has a low risk profile due to the extreme lack
of novelty.  There is no formal analysis.

# Checks

The document is clear and precise.  The design is sensible and appropriately
scoped.

Checked: Status (std), IPR (checks in progress), issues, idnits (what a trash
fire of a program), references (no downrefs, no unfinished work), registries.

# Registry Experts

A new registry is established for ciphersuites.  This will need experts.  I
recommend that this include all of the draft authors (checking with authors in
progress).