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

[Bernard Aboba <[e-mail]>]

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/sframe
>