Subject: [Perc] Question about draft-ietf-perc-private-media-framework

From: Bernard Aboba <[email-masked]>
Date: Fri, 15 Jun 2018 11:38:29 -0700

The W3C WEBRTC WG has been discussing potential future APIs for enabling
scenarios discussed in draft-ietf-perc-private-media-framework

That discussion raises some questions about API implications for browser
security.

For example, the following paragraph from Section 2 says that the browser
is a trusted entity:

   Trusted Endpoint: An RTP flow terminating entity that has possession
   of E2E media encryption keys and terminates E2E encryption.  This may
   include embedded user conferencing equipment or browsers on
   computers, media gateways, MCUs, media recording device and more that
   are in the trusted domain for a given deployment.

In Section 3.2.1, it says that an "endpoint" is assumed to be trusted:

   An endpoint is considered trusted and will have access to E2E key
   information.  While it is possible for an endpoint to be compromised,
   subsequently performing in undesired ways, defining endpoint
   resistance to compromise is outside the scope of this document.
   Endpoints will take measures to mitigate the adverse effects of
   denial of service attacks (refer to Section 6
<https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-06#section-6>)
from other entities,
   including from other endpoints, to a level equal to or better than
   traditional conference (i.e., non-PERC) deployments.

However, in Section 3.1 it says that the "conferencing infrastructure"
is not trusted:

   The conferencing infrastructure in
   such a domain is still trusted with reliably connecting the
   participants together in a conference, but not trusted with keying
   material needed to decrypt any of the participant's media.

So is a Javascript application considered to be an "endpoint" or part
of the "conferencing infrastructure"?  If the JS generates an Electron
or React application, I might lean toward the "endpoint"
interpretation.  However, if this is JS downloaded from the
conferencing provider, and running in a browser, it would seem to be
part of the "conferencing infrastructure" just like the MDD.  In that
case, access to e2e keys or cleartext media would appear to be
prohibited, right?

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 16 Jun 2018 05:58:09 +0800

What has been discussed in meetings before is that people didn't want to extend trust to the JS layer responsible for rendering the UI or used to initiate PERC calls. The desire is to ensure that layer doesn't have access to the keys.

Thus, the downloaded JS that you're referencing is special. It's part of the endpoint, in my mind, that's not trusted.

Paul