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

[Richard Barnes <[e-mail]>]

Hey all,

I agree that all of this stuff is valuable to capture somewhere.  In the
interest of keeping the charter fairly succinct, I've added the following:

"""
The SFrame specification will detail the specific security properties that
the encapsulation provides, and discuss their implications under common
usage scenarios / threat models.
"""

With that, I think that all the comments we've gotten so far have been
addressed.

--Richard


On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD <
[e-mail]> 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.
>
>
>
> 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
>>
>