Subject: Re: [dispatch] SFrame WG Charter

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Aug 2020 16:30:32 -0700

"""
The SFrame specification will detail the specific security properties that
the encapsulation provides, and discuss their implications under common
usage scenarios / threat models.
"""
[BA] This seems to be putting the cart before the horse. It is the combination of SFrame, the negotiated ciphersuite and the key exchange mechanism that provides a system whose security properties can be analyzed. So you can’t just look at SFrame security properties.
The point of RFC 7202 was that RTP usage scenarios require different security solutions and therefore mandating a single mandatory key exchange mechanism does not make sense.
Given the potential wide applicability of SFrame, the argument is even stronger here. So I agree with Dr. Alex that multiple use cases will need to be analyzed. The RTC and streaming use cases could in particular generate quite different requirements (e.g. need for DRM). Even within RTC use cases we will need to separate out the requirements on the authentication system and media protection given frequently cited concerns anout “hidden participants”, “unauthorized recording” and “deep fakes”.
Based on those analyses one can then look at the use case requirements and detail which ones are addressed by SFrame, the ciphersuites, underlying platform security and potential key exchange mechanisms. 
I am reminded of the importance of a thorough use case analysis as I talk to customers and hear *very* different use cases, each of which a customer believes are solved by E2E security. Unfortunately the use cases differ in their threat models, desired security properties and (probably) key exchange requirements.

>> On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD <
>> [email-masked]> wrote:
>> 
>> guys,
>> 
>> sorry for jumping in so late, quarantine here is very strict.
>> 
>> We had long discussions about this specific point ahead of the draft
>> submission.
>> We had reached the following consensus:
>> - there are multiple usage of media over the internet, e.g. conferencing
>> and streaming/broadcast
>> - they have very different threat/trust models, with different solutions
>> implemented today (transport layer E / E2EE / DRM / Encrypted Media
>> Extentions / ...)
>> - they all can benefit from SFrame
>> 
>> PERC was, by design, limited to RTP and to Conferencing. Many other use
>> case coul benefit from Enhanced Privacy.
>> 
>> We concluded that it would be better to keep SFrame (the media encryption
>> part, equivalent to PERC double conceptually), and to have separated
>> documents that describe the threat models and the corresponding key
>> exchange, signaling and system level decision for each use case. Emad had
>> taken an action item for example to make two additional documents to
>> describe the Video Conferencing use case, and how SFrame could be used in
>> conjunction with MLS to address that specific use case. Someone else could
>> take the different use case of the Browsers (which have a specific trust
>> model) and make a document showing how SFrame con work with Insertable
>> Frame API (and likely some more) to address that use case. CoSMo is
>> interested in doing the same thing for Real-Time streaming/Broadcasting.
>> 
>> I think it is a more reasonable approach as, even spending a lot of time
>> brainstorming with everyone around the tabel including bernard, we couldn't
>> think about one solution to fit all the different "media over internet"'s
>> threat model. In my mind, each case should first have an informal document
>> to define scope and threat model, and subsequent document to define the
>> corresponding specifications.
>> - Secure Conferencing Threat model (emad and co.)
>> - Secure Conferencing Signalling using MLS (emad and co.)
>> - Secure Conferencing using MLS In the browser (contributed by w3c people)
>> 
>> Magnus, what do you think?
>> 
>> Regards,
>> 
>> Dr. ALex.