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

[Bernard Aboba <[e-mail]>]

Comments below.

On Fri, Oct 15, 2021 at 00:29 Sergio Garcia Murillo <
[e-mail]> wrote:

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

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

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.


> Best regards
> Sergio
>
>
>
>
>
> On Fri, Oct 15, 2021 at 8:46 AM Bernard Aboba <[e-mail]>
> wrote:
>
>>
>>> 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.
>>>
>>
>> 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.
>>
>>
>>> What topics do you think needs to be addressed or explained in detail
>>> for web transport for example?
>>>
>>
>> The most important is probably to explain the use case - since it’s most
>> likely *not* conferencing.
>>
>>
>>> Best regards
>>> Sergio
>>>
>>> On Fri, Oct 15, 2021 at 1:30 AM Bernard Aboba <[e-mail]>
>>> wrote:
>>>
>>>> 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 <[e-mail]>
>>>> wrote:
>>>>
>>>>> 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
>>>>>
>>>>> --
>>>>> Sframe mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/sfram
>>>>> <https://www.ietf.org/mailman/listinfo/sframe>
>>>>
>>>>