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

[Magnus Westerlund <[e-mail]>]

Hi,

Thanks for working on addressing my comments when on vacation.

I think you mostly arravied at a good place. However, I would like to make one
remark about the added language.

When it comes to threat models it can't be the intersection of threats across
those that occur in the intended usages, it needs to be the union of threats.
The formulation added implies intersection to me. 

Cheers

Magnus

On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote:
> 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]
> > > > Torshamnsgatan 23           | Mobile [phone]
> > > > SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> > > > ----------------------------------------------------------------------
> > > > 
> > > > 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------