Re: [dispatch] [Sframe] SFRame Next Steps (was SFrame proposed WG charter)

[Alexandre GOUAILLARD <[e-mail]>]

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.



On Fri, Aug 7, 2020 at 2:02 AM Emad Omara <emadomara=
[e-mail]> wrote:

> Thanks Magnus. I like the idea to explicitly call out the threat model, I
> think it will be good foundations that control all future design decisions,
> however I'm not sure if the charter is the right place to call this out.
> I'd recommend having a separate document that describes the system
> architecture, goals and threat model. What do you think?
>
> Emad
>
> On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund <
> [e-mail]> wrote:
>
>> Hi,
>>
>> On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote:
>> > But shouldn't the "delayed media" attack still be transport agnostic? I
>> > mean, this can happen on QUIC and WebRTC SFUs.
>>
>> Sorry if I gave the impression that it is not transport agnostic. It is
>> use case
>> dependent, any use case that isn't point to point, where there is more
>> than one
>> entity that can intentionally remove SFRAME creating gaps in the SFRAME
>> sequence. In a point to point scenario one can correlate transport losses
>> with
>> SFRAME gaps to know give a reasonably strong mitigation against any third
>> party
>> removing SFRAMEs or delaying them. That is much harder in a centralized
>> conference with one or more SFU.
>>
>> >
>> > Anyway, I agree that while SFrame is transport agnostic, the chapter
>> > should not ignore the interactions with webrtc/quic and we must ensure
>> > that we provide a complete working solution regardless of the
>> transport.
>> > If we identify that any further working items are required for a
>> > particular transport, we should at liaise with the appropriate working
>> > group for providing a solution.
>>
>> My main point is that SFRAME actually needs to discuss the threat model
>> for the
>> use cases it intendes to solve. And the mitigation can potentially include
>> functionality on the transport level. But the risks to media security in
>> centralized conferencing needs to be discussed. And centralized
>> conferencing
>> will still have the semi-trusted SFUs and all the rest of the third
>> parties in
>> addition to the end-points.
>>
>> Also what properties one have around end-points invited into the
>> conference has
>> a number of question around security properties that needs to be
>> discussed and
>> documented. Some examples that I know are relevant:
>>
>> - Source authentication: SRTP unless one use TESLA (which isn't really
>> used)
>> does only provided the property: Someone that has the key sent this. One
>> don't
>> know that it comes from a particular endpoint.
>>
>> - Confidentiality when group membership changes: So will SFRAME keying
>> support a
>> use case where only the current set of members in a conference can
>> decrypt the
>> media and one rekey the media session key for each time the membership
>> changes?
>> PERC do support this, will SFRAME?
>>
>> There are likely more questions that needs discussion. The PERC
>> discussion is a
>> good starting point, but I think when going transport agnostic some of the
>> issues needs to be more clearly discussed as the RTP transport can have
>> affected
>> how it was discussed, and what reliance on existing mechanism. Which for
>> SFRAME
>> likely require a general discussion and then requirements on the
>> transport and
>> invovled endpoints and SFU to accomplish mitigations. And thus also what
>> the
>> risks are of having no mitigation in place.
>>
>> I would really propose that SFRAME is chartered with publishing a security
>> consideration and threat model document that is seperate from the
>> solution to
>> give this topic full focus. The solution will of necessity need to
>> reference
>> that and document what migitagtions that exists in the SFRAME layer and
>> what
>> becomes requirements on the transport.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>>
>> ----------------------------------------------------------------------
>> Networks, Ericsson Research
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  [phone]
>> <+46%2010%20714%2082%2087>
>> Torshamnsgatan 23           | Mobile [phone]
>> <+46%2073%20094%2090%2079>
>> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>> ----------------------------------------------------------------------
>>
>>
>> --
> Sframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sframe
>