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

[Magnus Westerlund <[e-mail]>]

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