From 080a93947683f20a5e247014a0e73966a2506dc5 Mon Sep 17 00:00:00 2001 From: Bernard Aboba Date: Mon, 9 Sep 2019 15:04:51 -0700 Subject: [PATCH] Requirements for Secure Web Conferencing (Revised) Revised based on feedback from the June Interim of the WEBRTC WG. Potential fix for Issue https://github.com/w3c/webrtc-nv-use-cases/issues/37 Based on PR https://github.com/w3c/webrtc-nv-use-cases/pull/21 submitted by Cullen Jennings Rebased version of PR https://github.com/w3c/webrtc-nv-use-cases/pull/39 --- index.html | 129 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 129 insertions(+) diff --git a/index.html b/index.html index 246005b..c910b5a 100644 --- a/index.html +++ b/index.html @@ -282,6 +282,122 @@

Virtual Reality Gaming

References: Mailing list discussion +
+

Don't Pown My Video Conferencing

+

+ Cloud video conferencing systems have no need to be able to access + the cleartext media and text flowing through their servers. + Some of these conferencing services desire to be able to promote trust + by explicitly showing they do not have access to contents of their + users' calls. They are trusted to connect the right people to the + conference and to route the packets but they are not trusted to access + the audio and video media or text in the call. +

+

Solutions to this problem fall into two major categories: one where + the JavaScript comes from a source trusted to see the media contents, + and one where it does not. +

+
+

Untrusted JavaScript Cloud Conferencing

+

+ There are many cases where a system such as WebEx is trusted to + connect the members of a conference but has no need to access the + contents of the conference. This is true of the majority of + conferencing systems on the web today. Just to highlight the + scope of this requirement, there are more minutes of WebRTC + that are used in conferences where the servers have no need + to access the contents (e.g. where audio is forwarded rather than + mixed) than any other use of WebRTC audio by orders of magnitude. + This is one of the primary use case for WebRTC audio and accounts + for billions of minutes per month of potential use of WebRTC. +

+

+ In this use case, the JavaScript comes from the operator of the + conference bridge. The isolated media features of WebRTC can + prevent the JavaScript from accessing the media and the identity + features are used to provide a user interface that allows the + user to know it connected to the correct conference. The goal is + for the end users to be able to see the contents, but the web + service that provides the JS and the media switching bridges + and Selective Forwarding Units (SFUs) cannot access the contents + (audio, video, text). The browser may choose to reveal some + metadata, such as the audio power level, to the media server, + in order to support functions like speaker switching. +

+

+ A possible solution this problem is the browser to negotiate + end-to-end encryption keys which are not revealed to the + JavaScript. +

+

+ Security requirements relating to this use case are discussed + in [[MLS-ARCH]], and include the following: +

+ +
+   ----------------------------------------------------------------
+   REQ-ID          DESCRIPTION
+   ----------------------------------------------------------------
+   N25             Only current group members can receive media or
+                   text sent to the group.
+   N26             A group member cannot send media or text that
+                   appears to be from another group member.
+   N27             The conference server must not have access to
+                   cleartext media or text or to the identity of
+                   group members.
+   N28             Perfect Forward Secrecy (FCS): access to encrypted
+                   traffic as well as all current keying material does
+                   not compromise the secrecy of media or text older
+                   than the oldest key of a compromised client.
+   N29             Post Compromise Security (PCS). Protection against
+                   past or future device compromise.
+
+
+
+

Trusted Javascript

+

In some highly controlled situations such as military uses, + the JavaScript can come from a trusted source while the servers + that distribute the packets are not trusted to access the + contents in cleartext. The servers are trusted to forward + packets as appropriate and not launch denial of service attacks + on the conferences. +

+

+ In this case, the JavaScript running the WebRTC application comes + from a trusted source and is allowed to access the contents in + cleartext. These use cases tend to be relatively small deployments + as they require the JavaScript come from a trusted source, but they + use a media server from an untrusted source. The contents need to be + encrypted with keys that are not known to the operator of the servers, + servers, then sent to the conference server. The browser may choose + to reveal some metadata, such as the audio power level, to the + media server, in order to support functions like speaker switching. +

+

+ Security requirements relating to this use case are discussed + in [[MLS-ARCH]], and include the following: +

+ +
+   ----------------------------------------------------------------
+   REQ-ID          DESCRIPTION
+   ----------------------------------------------------------------
+   N25             Only current group members can receive media or
+                   text sent to the group.
+   N26             A group member cannot send media or text that
+                   appears to be from another group member.
+   N27             The conference server must not have access to
+                   cleartext media or text or to the identity of
+                   group members.
+   N28             Perfect Forward Secrecy (FCS): access to encrypted
+                   traffic as well as all current keying material does
+                   not compromise the secrecy of media or text older
+                   than the oldest key of a compromised client.
+   N29             Post Compromise Security (PCS). Protection against
+                   past or future device compromise.
+
+
+

Requirements Summary

@@ -353,6 +469,19 @@

Requirements Summary

N23 The user agent must be able to send data synchronized with audio. N24 CSP support for WebRTC + N25 Only current group members can receive media or + text sent to the group. + N26 A group member cannot send media or text that + appears to be from another group member. + N27 The conference server must not have access to + cleartext media or text or to the identity of + group members. + N28 Perfect Forward Secrecy (FCS): access to encrypted + traffic as well as all current keying material does + not compromise the secrecy of media or text older + than the oldest key of a compromised client. + N29 Post Compromise Security (PCS). Protection against + past or future device compromise.