Subject: [Sframe] Adoption call for draft-omara-sframe-01

From: "Martin Thomson" <[email-masked]>
Date: Mon, 11 Oct 2021 10:35:54 +1100

https://datatracker.ietf.org/doc/html/draft-omara-sframe-01

Please respond to this email before AOE 31 October 2021 if you support adopting draft-omara-sframe (currently -01) as a working group item.  If you would prefer we not adopt this work, please respond with an explanation of why and ideally what you would like to see addressed before we do that.

We're running this a tiny bit longer than a typical adoption call.  Last time we talked about adoption there were a few concerns raised about the draft.  We want to make sure those concerns are addressed, or at least those with concerns are satisfied that their concerns could be addressed.

Martin, for the chairs

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 11 Oct 2021 10:37:57 +0200

> We're running this a tiny bit longer than a typical adoption call.  Last time we talked about adoption there were a few concerns raised about the draft.  We want to make sure those concerns are add…

I do support (speaking for Jitsi here) the adoption of the draft.

Quick question though: any reason why -01 and not the latest version?

Cheers,

-- 
Saúl

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 11 Oct 2021 20:18:50 +1100

> Quick question though: any reason why -01 and not the latest version?

My mistake.  I meant to cite the latest.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 14 Oct 2021 16:29:57 -0700

Here is my review.

Overall, I do not feel that this document is ready for adoption.  Viewed
purely as a document focusing on defining the SFrame format, it is
adequate.  Currently, the document mixes format considerations with key
management concerns while not adequately covering the full range of non-RTP
use cases.  By trying to do too much, the document falls short enough to be
potentially detrimental to long term success.

In particular, the goals of the effort, the threat model and the use cases
are not articulated well enough. My advice would be to pare the draft down
to its bare essentials, spinning off material not directly relevant to the
SFrame format into a separate document.

The non-RTP use cases (and potential integration with the Web media model)
in particular seem like they deserve more attention.

Section 1 states:

   In order for the SFU to work
   properly though, it needs to be able to access RTP metadata and RTCP
   feedback messages, which is not possible if all RTP/RTCP traffic is
   end-to-end encrypted....

   This document proposes a new end-to-end encryption mechanism known as
   SFrame, specifically designed to work in group conference calls with
   SFUs.

Later in Section 1, Figure 1 is included, showing the SRTP packet
format.  So Section 1 is very RTP (and conferencing) centric.  Yet at
the same time, Section 3 includes the following goals:

   2.  Decouple media encryption from key management to allow SFrame to
       be used with an arbitrary KMS.

   4.  Independence from the underlying transport, including use in non-
       RTP transports, e.g., WebTransport.

Is SFrame serious about these goals?  Personally, I hope so - but if
so, integration with the existing Web media framework as well as new
APIs (such as WebCodecs) needs to be considered.  In doing so, use
cases will likely expand beyond conferencing, to things like
low-latency streaming (for things like events, webinars, game
watching, etc.)

The existing Web media framework (as embodied by APIs such as MSE and
EME) supports both transport and key management independence, so
seeking these same goals for SFRAME seems quite natural.  For example,
today it is possible to transport containerized media for a wide range
of codecs using any transport, including WebTransport and RTCData
channel.  Once transported, the media is decoded and rendered using
MSE.  And of course, the containerized media can also be protected.
Note that the protection model addresses additional classes of attack
beyond those that might be executed by an SFU. For example, cleartext
media is not accessible to Javascript, mitigating against attacks such
as "deep fakes".

Why bother to consider these use cases for SFrame?  APIs such as
WebCodecs do not operate on containerized media, so there is a need to
define a format allowing encrypted but non-containerized media to be
carried over the wire. If that format is not SFrame, then an
equivalent will need to be invented, covering the same codecs that
SFrame seeks to support (e.g. Opus, H.264, VP8, VP9, AV1) plus maybe a
few others (e.g. AAC).

The benefit of working towards integration with the existing Web media
framework is that this will be more likely to lead to implementation
and deployment.  This shouldn't be hard to accommodate within a
document that focuses purely on the format, allowing the use cases and
threat models to be articulated elsewhere.

On Sun, Oct 10, 2021 at 4:36 PM Martin Thomson <[email-masked]> wrote:

> Please respond to this email before AOE 31 October 2021 if you support
> adopting draft-omara-sframe (currently -01) as a working group item.  If
> you would prefer we not adopt this work, please respond with an explanation
> of why and ideally what you would like to see addressed before we do that.
>
> We're running this a tiny bit longer than a typical adoption call.  Last
> time we talked about adoption there were a few concerns raised about the
> draft.  We want to make sure those concerns are addressed, or at least
> those with concerns are satisfied that their concerns could be addressed.
>
> Martin, for the chairs
>
> --
> Sframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sframe
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 15 Oct 2021 08:28:43 +0200

Hi Bernard,

Trying to understand the changes that would be required in order to address
your concerns. If I understand correctly, you are proposing splitting the
document in 3 or 4 documents:

- SFrame architecture & overview, explaining the use cases, thread models
and key management considerations
- SFrame format and encryption process (based on the current draft)
- SFrame usage within WebRTC
- SFrame usage within frame based transports

Is that correct?

Regarding the integration with frame based transports (i.e. quic or
webtransport, webrtc DC or even rtmp), the charter only mentions that
WebRTC end to end solution for webrtc should be explicitly addressed. This
is mainly because applying SFrame to webtransport/quic should be
straightforward and trivial.

What topics do you think needs to be addressed or explained in detail for
web transport for example?

Best regards
Sergio

On Fri, Oct 15, 2021 at 1:30 AM Bernard Aboba <[email-masked]>
wrote:

> Later in Section 1, Figure 1 is included, showing the SRTP packet format.  So Section 1 is very RTP (and conferencing) centric.  Yet at the same time, Section 3 includes the following goals:
>
>
> Is SFrame serious about these goals?  Personally, I hope so - but if so, integration with the existing Web media framework as well as new APIs (such as WebCodecs) needs to be considered.  In doing so, use cases will likely expand beyond conferencing, to things like low-latency streaming (for things like events, webinars, game watching, etc.)
>
>
> The existing Web media framework (as embodied by APIs such as MSE and EME) supports both transport and key management independence, so seeking these same goals for SFRAME seems quite natural.  For example, today it is possible to transport containerized media for a wide range of codecs using any transport, including WebTransport and RTCData channel.  Once transported, the media is decoded and rendered using MSE.  And of course, the containerized media can also be protected. Note that the protection model addresses additional classes of attack beyond those that might be executed by an SFU. For example, cleartext media is not accessible to Javascript, mitigating against attacks such as "deep fakes".
>
>
> Why bother to consider these use cases for SFrame?  APIs such as WebCodecs do not operate on containerized media, so there is a need to define a format allowing encrypted but non-containerized media to be carried over the wire. If that format is not SFrame, then an equivalent will need to be invented, covering the same codecs that SFrame seeks to support (e.g. Opus, H.264, VP8, VP9, AV1) plus maybe a few others (e.g. AAC).
>
>
> The benefit of working towards integration with the existing Web media framework is that this will be more likely to lead to implementation and deployment.  This shouldn't be hard to accommodate within a document that focuses purely on the format, allowing the use cases and threat models to be articulated elsewhere.
>
>
>
>
>
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 14 Oct 2021 23:46:47 -0700

Comments below.

On Thu, Oct 14, 2021 at 23:28 Sergio Garcia Murillo <
[email-masked]> wrote:

>
> Hi Bernard,
>
> Trying to understand the changes that would be required in order to
> address your concerns. If I understand correctly, you are proposing
> splitting the document in 3 or 4 documents:
>

Two documents would probably be sufficient for now - the frame format (the
current draft) and an overview/framework document.

> straightforward and trivial.

Applying SFrame to WebTransport/quic is neither trivial nor straightforward.
To enable SFrame over non-RTP alternatives, you’d need to explain the use
cases, as well as defining the formats and key management requirements. For
example, is the WebTransport use case conferencing, or something else, such
as low-latency streaming.

BTW, it’s not at all clear to me that conferencing over WebTransport is
viable, given the lack of support for RTC congestion control within the
browser implementations of WebTransport.  Low latency streaming from the
cloud to the browser is more credible since in that use case WebTransport
CC would be replaced by something more like an RMCAT algorithm. However, in
that use case we wouldn’t be talking about MLS key management, but rather
one of the algorithms supported by EME. Also, the threat model would be
quite different from the RTP/SFU use case.

> web transport for example?

The most important is probably to explain the use case - since it’s most
likely *not* conferencing.

>> In particular, the goals of the effort, the threat model and the use
>> cases are not articulated well enough. My advice would be to pare the draft
>> down to its bare essentials, spinning off material not directly relevant to
>> the SFrame format into a separate document.
>>
>> The non-RTP use cases (and potential integration with the Web media
>> model) in particular seem like they deserve more attention.
>>
>> Section 1 states:
>>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 15 Oct 2021 09:29:24 +0200

IMO key management and key exchange are out of the scope of the SFRAME WG,
the charter only mentions that we should provide a way to use MLS keys
within the SFrame.

Addressing the non-videoconferencing use case (i.e. streaming/broadcasting)
is an absolute must, and something Alex and I have been advocating since
the beginning (it is the only use case we care about in fact). But this
should be done in a transport agnostic way as it is not webtransport/quic
specific, that is, doing massive broadcasting/streaming in webrtc is
possible 😉

Best regards
Sergio

>>>> We're running this a tiny bit longer than a typical adoption call.
>>>> Last time we talked about adoption there were a few concerns raised about
>>>> the draft.  We want to make sure those concerns are addressed, or at least
>>>> https://www.ietf.org/mailman/listinfo/sfram
>>>> <https://www.ietf.org/mailman/listinfo/sframe>
>>>
>>>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 15 Oct 2021 00:47:56 -0700

Comments below.

> IMO key management and key exchange are out of the scope of the SFRAME WG,

That’s fine, because there are already other standards available to address
that (e.g. MLS, EME).

> specific, that is, doing massive broadcasting/streaming in webrtc is

Indeed, but the SFrame threat model is quite different for non-RTP
transport scenarios.  For example, consider a Concert or Sporting event.
The video upload, handled via WISH (RTP) or RUSH (QUIC), may not utilize
Sframe protection, either because the uploader trusts the video ingestion
site or because the ingestor is transcoding or compositing the video feeds
(e.g. superimposing fans on the seats in the stadium obtained from the
on-field camera).  However, SFrame is desired on the downlink in order to
protect the composited content from being modified or copied. This could be
done today without SFrame by transporting containerized media over
RTCDataChannel/WebTransport and rendering with MSE, but if WebCodecs is
used for rendering instead, then containerization is just a waste of CPU
cycles.

>>> What topics do you think needs to be addressed or explained in detail
>>> for web transport for example?
>>>
>>
>>>> Overall, I do not feel that this document is ready for adoption.
>>>> Viewed purely as a document focusing on defining the SFrame format, it is

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 15 Oct 2021 14:49:38 +0200

> Addressing the non-videoconferencing use case (i.e.
>> streaming/broadcasting) is an absolute must, and something Alex and I have
>> been advocating since the beginning (it is the only use case we care about
>> in fact). But this should be done in a transport agnostic way as it is not
>> webtransport/quic specific, that is, doing massive broadcasting/streaming
>> in webrtc is possible 😉
>>
>
The SFrame WG charter explicitly states  that the intention of SFRAME is
protecting the media to be decrypted by intermediary servers to provide end
to end encryption. So, SFRAME scope and protection/security properties end
when the media frame is transformed by the decryption process. DRM or
content protection is applied after that point and IMO out of the scope of
the SFRAME WG.

Not saying that it would not be interesting to explore the possibility of
using SFRAME for more extended usages, but I don't feel that requiring
SFRAME to cover this use case as a prerequisite to be adopted is the right
way to go.

Best regards
Sergio

---

From: Richard Barnes <[email-masked]>
Date: Fri, 15 Oct 2021 10:42:00 -0400

I support adopting this draft.

Bernard is correct to point out that it needs some polishing, but that's
what we do in a WG.  Even with the rough edges, it captures the core of
what we want to get to.  In other words, the core technical bits around how
to do the actual framing and encryption are largely right, we just need to
put them in the right context.  And now that we've had a couple of rounds
of SDP/RTP conversation (with a few more to go), it seems like we have a
pretty good idea of where the cut lines should be, so I have confidence
that the WG will be able to come to consensus.

--Richard

---

From: Youenn Fablet <[email-masked]>
Date: Fri, 15 Oct 2021 19:05:41 +0200

I support adopting this draft as a working group item.

The SFrame format, or variants of it, are being deployed in existing applications.
This gives confidence in the fact that the SFrame format described in the document is solving real problems.
The current draft document allowed to implement it in at least two independent implementations (Cisco and Safari), both implementations passing the same test suite.
This gives confidence in the level of details used to describe the SFrame format.

I look forward for additional work in the area, to address Bernard’s points and more.
The suggestion to move part of the current document in a separate document seems a good idea.
This modularity would for instance be useful in W3C specifications building on the SFrame format, in particular the being standardised SFrameTransform.

I do not think that this is a blocker for adopting the document as is.
Adoption by the WG is just a starting point, and I believe that contributors of this document are aware that more work is needed.

Thanks,
	Y

> ---------- Forwarded message ---------
> From: Martin Thomson <[email-masked] <mailto:[email-masked]>>
> Date: Sun, Oct 10, 2021 at 7:36 PM
> Subject: [Sframe] Adoption call for draft-omara-sframe-01
> To: <[email-masked] <mailto:[email-masked]>>
> 
> 
> https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 <https://datatracker.ietf.org/doc/html/draft-omara-sframe-01>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sframe <https://www.ietf.org/mailman/listinfo/sframe>

---

From: Emad Omara <[email-masked]>
Date: Fri, 15 Oct 2021 10:13:56 -0700

On Fri, Oct 15, 2021 at 10:05 AM Youenn Fablet <youenn=
[email-masked]> wrote:

> The current draft document allowed to implement it in at least two
> independent implementations (Cisco and Safari), both implementations
> passing the same test suite.
> This modularity would for instance be useful in W3C specifications
> building on the SFrame format, in particular the being standardised
> SFrameTransform.
>
> Adoption by the WG is just a starting point, and I believe that
> contributors of this document are aware that more work is needed.
>
> Thanks,
> Y
>
> From: Martin Thomson <[email-masked]>
> To: <[email-masked]>

---

From: Benjamin Beurdouche <[email-masked]>
Date: Fri, 15 Oct 2021 19:15:58 +0200

I support adoption as a WG item.
B.

> On Oct 15, 2021, at 7:14 PM, Emad Omara <[email-masked]> wrote:
> 
> 
>> On Fri, Oct 15, 2021 at 10:05 AM Youenn Fablet <youenn=[email-masked]> wrote:

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 15 Oct 2021 14:16:07 -0700

TL;DR. This document needs a fair bit of work but I think
we should adopt it and work on it in the WG rather than
making the authors do a pile of work beforehand.

At the high level, I tend to agree with Bernard that this is
doing a bit too much. Specifically, while SFrame is designed
to be embedded in an E2E keying system, there's not much
about it that requires E2E. I would consider breaking that
material out into a different document or perhaps moving
it into an appendix as stage setting.

I also think it would be good if the document were somewhat
more agnostic about SPacket and SFrame; it seems like each
version has advantages in some cases.

DETAILED COMMENTS
S 4.

The stuff here 4. seems informational.

   We propose a frame level encryption mechanism that provides effective
   end-to-end encryption, is simple to implement, has no dependencies on
   RTP, and minimizes encryption bandwidth overhead.  Because SFrame
   encrypts the full frame, rather than individual packets, bandwidth
   overhead is reduced by having a single IV and authentication tag for
   each media frame.

As noted above, there's nothing E2E about this. It's just designed to
it into a certain setting. I *do* think it would be useful to explain
the extent to which this depends on SRTP for security, if at all.

S 4.2.
   Since each endpoint can send multiple media layers, each frame will
   have a unique frame counter that will be used to derive the
   encryption IV.  The frame counter must be unique and monotonically
   increasing to avoid IV reuse.

   Reserved (R): 1 bit This field MUST be set to zero on sending, and
   MUST be ignored by receivers.  Counter Length (LEN): 3 bits This
   field indicates the length of the CTR fields in bytes (1-8).

I am having trouble reading this text. Is it saying that the CTR field
can be 1-8 bytes long? But of course, 3 bits can only encode 0-7, so
you need to explain it's +1, I guess?

S 4.3.5.

   Unlike messaging application, in video calls, receiving a duplicate
   frame doesn't necessary mean the client is under a replay attack,
   there are other reasons that might cause this, for example the sender
   might just be sending them in case of packet loss.

This is true for messaging as well.

   SFrame decryptors
   use the highest received frame counter to protect against this.  It
   allows only older frame pithing a short interval to support out of
   order delivery.

Should this say "within". You will eventually need more detail here
about how this works. In particular, you shouldn't update until you
have decrypted.

S 4.4.

     +========+==========================+====+====+====+===========+
     | Value  | Name                     | Nh | Nk | Nn | Reference |
     +========+==========================+====+====+====+===========+
     | 0x0001 | AES_CM_128_HMAC_SHA256_8 | 32 | 16 | 12 | RFC XXXX  |
     +--------+--------------------------+----+----+----+-----------+
     | 0x0002 | AES_CM_128_HMAC_SHA256_4 | 32 | 16 | 12 | RFC XXXX  |
     +--------+--------------------------+----+----+----+-----------+
     | 0x0003 | AES_GCM_128_SHA256       | 32 | 16 | 12 | RFC XXXX  |
     +--------+--------------------------+----+----+----+-----------+
     | 0x0004 | AES_GCM_256_SHA512       | 64 | 32 | 12 | RFC XXXX  |
     +--------+--------------------------+----+----+----+-----------+

A 4 byte tag is pretty short.

What's the reason for specifyin anything with SHA-512 as the
KDF?

   In a session that uses multiple media streams, different ciphersuites
   might be configured for different media streams.  For example, in
   order to conserve bandwidth, a session might use a ciphersuite with
   80-bit tags for video frames and another ciphersuite with 32-bit tags
   for audio frames.

A little weird to say this when you don't specify anything with 80 bit
tags.