Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Requirements for Secure Web Conferencing (Revised) #48

Closed
wants to merge 1 commit into from
Closed

Requirements for Secure Web Conferencing (Revised) #48

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
129 changes: 129 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -282,6 +282,122 @@ <h3>Virtual Reality Gaming</h3>
References:
<a href="https://lists.w3.org/Archives/Public/public-webrtc/2018May/0063.html">Mailing list discussion</a>
</section>
<section id="no-trust-webex">
<h3>Don't Pown My Video Conferencing </h3>
<p>
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.
</p>
<p>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.
</p>
<section id="untrusted*">
<h4>Untrusted JavaScript Cloud Conferencing</h4>
<p>
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.
</p>
<p>
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.
</p>
<p>
A possible solution this problem is the browser to negotiate
end-to-end encryption keys which are not revealed to the
JavaScript.
</p>
<p>
Security requirements relating to this use case are discussed
in [[MLS-ARCH]], and include the following:
</p>

<pre class="highlight">
----------------------------------------------------------------
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.
</pre>
</section>
<section id="trusted*">
<h4>Trusted Javascript</h4>
<p>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.
</p>
<p>
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.
</p>
<p>
Security requirements relating to this use case are discussed
in [[MLS-ARCH]], and include the following:
</p>

<pre class="highlight">
----------------------------------------------------------------
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.
</pre>
</section>
</section>
</section>
<section id="requirements*">
<h3>Requirements Summary</h3>
Expand Down Expand Up @@ -353,6 +469,19 @@ <h3>Requirements Summary</h3>
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.
</pre>
</section>
</body>
Expand Down