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

[Richard Barnes <[e-mail]>]

Hi Magnus,

I think the intent here is to have a mechanism that provides a subset of
the security properties required for a given scenario, but which can be
augmented with additional mechanisms to provide the rest.  For example,
even in the most obvious SFrame+SRTP case, there's a division of labor
between the two protocols, where SFrame only protects content, and SRTP
also protects the RTP header and guards against reply by network attackers.

So in a sense it is an intersection (in that it does something that is
needed by all the use cases), but it might need other things to provide all
the properties you need in a given scenario.

--Richard

On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlund <
[e-mail]> wrote:

> 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]
> ----------------------------------------------------------------------
>
>
>