Subject: [Perc] Comments on draft-westerlund-perc-webrtc-use-case-00

From: Eric Rescorla <[email-masked]>
Date: Sat, 11 Jul 2015 20:05:17 -0400

I have reviewed draft-westerlund-perc-webrtc-use-case-00, but I don't
think it meets either the security requirements listed in the document
or the larger requirement to protect the user from the conference
bridge.

Section 4.2. says
4.2.  Dealing with JavaScript related Attacks

   The JavaScript code run in the browser is a potential attack vector.
   Using various attacks, including cross-site scripting, the JavaScript
   can be compromised and perform the actions an attacker dictates.
   Even if the JS running in the browser is malicious it must not be
   able to compromise the security of the conference, only perform
   denial of service attacks such as preventing the user from joining
   the conference.

However, I don't believe that the described system actually provides
this property: while the EKT key may be available only to the browser
(and this is actually fairly unclear given the sketchy description
here), it's not bound to any particular PeerConection so nothing stops
the JS from attaching it to one (or more PCs, including those which
are actually connected to itself) and therefore capturing the user's
traffic. Compare this to WebRTC with isolated streams and identity,
where you know exactly who you are connected to.

In addition, because you are sending the keys over an HTTP channel,
we have to worry about the HTTP security/logging issues we have with
SDES.

-Ekr

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Jul 2015 10:29:26 +0200

Hi EKR,

Thanks for the review and comments. Our goal with the document is two 
fold. We want to ensure we have sufficient discussion about the WebRTC 
challenges and requirements and any constraints that may lead to. The 
primary goal here is to ensure we have the security we need. Secondly, 
we are exploring ways of solving the authorization and distribution of 
the EKT master key, while considering web ways of doing things.

> where you know exactly who you are connected to.

We might not have been clear, but we see that all media streams in a 
context using E2E security (PERC) will be forced into the 
confidentiality mode. Thus, media as plain-text will not be accessible 
to the JS. And as a result of that any PeerConnection created will need 
to be required to use the end-to-end encryption. So if you would select 
to forward the media, it would still be secured and not accessible to an 
attacker.

I do note that this will require keeping the keys in use within one 
context to keys provided by one specific KMF. Otherwise the attacker 
could use a key of itself and still export the media of the endpoint.
However, this falls under the same general case of applying policies to 
a WebRTC endpoint. The endpoint when using PERC must

> we have to worry about the HTTP security/logging issues we have with

Yes, but that is general issue in that case for the Content Encryption 
mechanism. What are the HTTPS security issues, beyond the issues with 
PKI trust? The PKI trust issue I would claim are shared with DTLS when 
connecting to servers, like the KMF. The logging is a question of 
implementation, one that apparently needs consideration on what to logg 
and not logg.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Jul 2015 05:49:10 -0700

On Tue, Jul 14, 2015 at 1:29 AM, Magnus Westerlund <
[email-masked]> wrote:

> primary goal here is to ensure we have the security we need. Secondly, we
> are exploring ways of solving the authorization and distribution of the EKT
> master key, while considering web ways of doing things.
>
> context using E2E security (PERC) will be forced into the confidentiality
> mode.

I don't understand what you're suggesting here at all.

> Thus, media as plain-text will not be accessible to the JS. And as a
> result of that any PeerConnection created will need to be required to use
> the end-to-end encryption. So if you would select to forward the media, it
> would still be secured and not accessible to an attacker.
>
> I do note that this wil require keeping the keys in use within one context
> to keys provided by one specific KMF. Otherwise the attacker could use a
> key of itself and still export the media of the endpoint.
> However, this falls under the same general case of applying policies to a
> WebRTC endpoint. The endpoint when using PERC must

> mechanism. What are the HTTPS security issues, beyond the issues with PKI
> trust? The PKI trust issue I would claim are shared with DTLS when
> implementation, one that apparently needs consideration on what to logg and
> not logg.
>

Well, it's an issue that doesn't exit if you only use the DTLS channel.

-Ekr

Cheers

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Jul 2015 15:10:12 +0200

Eric Rescorla skrev den 2015-07-14 14:49:
>
>
> On Tue, Jul 14, 2015 at 1:29 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi EKR,
>
>     Thanks for the review and comments. Our goal with the document is
>     two fold. We want to ensure we have sufficient discussion about the
>     WebRTC challenges and requirements and any constraints that may lead
>     to. The primary goal here is to ensure we have the security we need.
>     Secondly, we are exploring ways of solving the authorization and
>     distribution of the EKT master key, while considering web ways of
>     doing things.
>
>     confidentiality mode.

The media confidentiality (isolation) mode that is enabled by the ALPN 
tag "c-webrtc" as described in:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/

>     result of that any PeerConnection created will need to be required
>     to use the end-to-end encryption. So if you would select to forward
>     the media, it would still be secured and not accessible to an attacker.
>
>     I do note that this wil require keeping the keys in use within one
>     However, this falls under the same general case of applying policies
>     to a WebRTC endpoint. The endpoint when using PERC must
>
>
>
>
>     Yes, but that is general issue in that case for the Content
>     Encryption mechanism. What are the HTTPS security issues, beyond the
>     issues with PKI trust? The PKI trust issue I would claim are shared
>     with DTLS when connecting to servers, like the KMF. The logging is a
>     question of implementation, one that apparently needs consideration
>     on what to logg and not logg.
>
>

Agreed, but not being alone with a problem makes it more likely that you 
can reach the critical mass to address the issue.

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Jul 2015 09:22:07 -0700

On Tue, Jul 14, 2015 at 6:10 AM, Magnus Westerlund <
[email-masked]> wrote:

> The media confidentiality (isolation) mode that is enabled by the ALPN tag
> "c-webrtc" as described in:

I don't see how this solves the problem. The issue is that from the
browser's perspective,
the DTLS connection is to the MDD, so how does he know what the MDD is
doing with
the data?

-Ekr

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Jul 2015 18:49:34 +0200

Eric Rescorla skrev den 2015-07-14 18:22:
>
>     The media confidentiality (isolation) mode that is enabled by the
>     ALPN tag "c-webrtc" as described in:

Sorry, for not being explicit enough. The UA that is establishing an 
PeerConnection with end-to-end security, must locally apply the media 
isolation to all media it sends. The media it receives from a 
PeerConnection using E2E security must also be isolated. It could be 
allowed to be forwarded, but if and only if the outgoing PeerConnection 
applies E2E security using a group key from the same KMF instance. I 
think it might be simpler to have the whole context being locked into 
isolation mode for all media streams when an E2E security PeerConnection 
is created.

This is independent of use keying mechanism, and will apply also if the 
group key is done by DTLS.

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Jul 2015 09:52:49 -0700

On Tue, Jul 14, 2015 at 9:49 AM, Magnus Westerlund <
[email-masked]> wrote:

> applies E2E security using a group key from the same KMF instance. I think
> it might be simpler to have the whole context being locked into isolation
> mode for all media streams when an E2E security PeerConnection is created.
>

I'm still not sure how this addresses the problem.

In ordinary E2E calls with Identity, you are told who the counterparty who
will
be receiving the media is in the permissions prompt and this is all bound
to DTLS.
In this case, however, as the DTLS connection is to the MDD, it will show
the MDD's
identity.

-Ekr

Cheers

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Jul 2015 19:04:26 +0200

Eric Rescorla skrev den 2015-07-14 18:52:
>
>
> On Tue, Jul 14, 2015 at 9:49 AM, Magnus Westerlund
>     PeerConnection with end-to-end security, must locally apply the
>     media isolation to all media it sends. The media it receives from a
>     allowed to be forwarded, but if and only if the outgoing
>     PeerConnection applies E2E security using a group key from the same
>     KMF instance. I think it might be simpler to have the whole context
>     being locked into isolation mode for all media streams when an E2E
>     security PeerConnection is created.
>
>     This is independent of use keying mechanism, and will apply also if
>     the group key is done by DTLS.
>
>
> In ordinary E2E calls with Identity, you are told who the counterparty
> who will
> be receiving the media is in the permissions prompt and this is all
> bound to DTLS.
> In this case, however, as the DTLS connection is to the MDD, it will
> show the MDD's
> identity.
>

Okay, we appear to be talking past each other and likely are not talking 
about the same security issue / problem.

I am talking an WebRTC issue related issue, of how you prevent the media 
content to be compromised by the JS running in the WebRTC Endpoint. This 
include both local analysis as well as getting it off the endpoint so 
that an attacker controlling the JS can get to a plain text version of 
the content at some other endpoint.

So what problem are you talking about?

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Jul 2015 10:11:52 -0700

On Tue, Jul 14, 2015 at 10:04 AM, Magnus Westerlund <
[email-masked]> wrote:

> include both local analysis as well as getting it off the endpoint so that
> an attacker controlling the JS can get to a plain text version of the
> content at some other endpoint.
>

The same problem.

As I understand it, the desired behavior in your model is that the user
consents to media access with
an identity tied to the MDD (because he is going to set up a DTLS
connection to
the MDD). The UA then contacts the KMF and gets the EKT key which it somehow
attaches to the PC. Is that correct?

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jul 2015 11:05:08 -0700

I can imagine several arrangements, but I think that the one Magnus
envisages here is one where you connect to the MDD with DTLS-SRTP, but
don't transmit media through that connection until you learn the group
key from the KMF and can properly encipher toward the group.  With the
aim to making the MDD equivalent to any other on-path adversary with
respect to media confidentiality.

This is not described particularly well in the draft.  Furthermore, I
think that we would need some new system of peer identification to
support it.

The biggest concern I have here is that the KMF role can't be assumed
by one of the conference participants, at least as specified.  I can
imagine being able to use data channels in some new way to support
that function, but then we have something (again) fundamentally
different.

On 14 July 2015 at 10:11, Eric Rescorla <[email-masked]> wrote:
>
>
> On Tue, Jul 14, 2015 at 10:04 AM, Magnus Westerlund
> <[email-masked]> wrote:
>>
> an identity tied to the MDD (because he is going to set up a DTLS connection
> to
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 16 Jul 2015 14:25:18 +0200

> attaches to the PC. Is that correct?

No. The model we have is that the participant, uses its identity to log 
into the conference (identified by an URI). Assuming the identity 
matches the conference rooster as established by the conference inviter, 
the participant will get credentials back tied to the participant's 
endpoint. Using these credentials it will do an HTTPS request to the KMF 
for the conference's group key (EKT master key). It will receive it back 
using Content Encryption header. The web application gets an key-id. 
Then the application establish the PeerConnection with the MDD, 
indicating the identity of the conference. Giving the key-id as the 
group key to use for this PeerConnection. During the PeerConnection 
establishment the hop-by-hop will be established. We propose to use new 
CSP directives given by the origin to force the application to establish 
PeerConnections using end-to-end security as well as which KMF that is 
the one to use.

Thus, we are not explicitly tying the media to the MDD. We are tying it 
to the KMF. And the KMF is the one controlling who gets the group key. 
Assuming that is safe. If you can't get local media off the endpoint 
within this browser context except by having it end-to-end protected 
there are no sever consequences of having it sent around.

cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Jul 2015 06:52:48 -0700

On Thu, Jul 16, 2015 at 5:25 AM, Magnus Westerlund <
[email-masked]> wrote:

> into the conference (identified by an URI). Assuming the identity matches
> the conference rooster as established by the conference inviter, the
> participant will get credentials back tied to the participant's endpoint.
> Using these credentials it will do an HTTPS request to the KMF for the
> conference's group key (EKT master key). It will receive it back using
> Content Encryption header. The web application gets an key-id. Then the
> application establish the PeerConnection with the MDD, indicating the
> identity of the conference. Giving the key-id as the group key to use for
> this PeerConnection. During the PeerConnection establishment the hop-by-hop
> will be established. We propose to use new CSP directives given by the
> origin to force the application to establish PeerConnections using
> end-to-end security as well as which KMF that is the one to use.
>

Hmm... I guess I'd need to see your proposed CSP directives.This seems kind
of
out of the wheelhouse for WebAppSec though.

-Ekr

> Thus, we are not explicitly tying the media to the MDD. We are tying it to
> the KMF. And the KMF is the one controlling who gets the group key.
> Assuming that is safe. If you can't get local media off the endpoint within
> this browser context except by having it end-to-end protected there are no
> sever consequences of having it sent around.
>
> cheers
>
> Magnus Westerlund
>