Subject: [rtcweb] Preserving stream isolation when traversing the network

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Mar 2014 14:21:54 +0000

There was a bit of confusion yesterday regarding stream isolation.
Mostly the reasons for its existence.  This email is an attempt to
explain the rationale in more detail, as well as to explore some of
the options.

# Problem Statement

This is the feature that we rely on for creating end-to-end protected
and authenticated calls.  We rely on the browser preventing
applications from accessing these streams so that they can't be
modified, recorded, sent to or through servers, rendered to canvas,
pushed into web audio, etc...

The basic idea of isolation is already an important part of the web
security model.  Streams that come from sources other than WebRTC
already require protections of this sort.  For instance, <video> tags
from different origins can't be rendered to canvas, and web audio
cannot take the output of <audio> if it was cross origin (though CORS
can be used to work around this limitation).

The problem I outlined was that any isolation property is not
preserved by WebRTC.  This provides a trivial means of circumvention
of isolated streams.  Sending media using WebRTC effectively strips
away isolation.

# Solution Options

As I described in the working group session, I see two ways to solve
this problem.  One in-band in TLS, the other in signaling.

We seemed to have general agreement that a signal in (D)TLS would be
best.  Signaling creates extra attack modes.  This more closely binds
the isolation guarantee to the security context.

To that end, I've submitted an extension draft to the TLS WG.  I
recommend that you read it and provide comments on its applicability
to RTCWEB here, and comments on the mechanism itself over in TLS.

http://datatracker.ietf.org/doc/draft-thomson-tls-acp/

There is another option I really just thought of, and that is to add
an authenticated parameter to RTP for this purpose.  Probably as an
RTP header extension.  This has different properties, mostly which
apply to the scope question.

# Scope

We agreed yesterday that identity assertions would be scoped to the
session level and that a=identity is session scoped.

I am going to propose that stream isolation is also scoped to the
session.  This implies that all streams from both peers MUST be either
all isolated, or that they are all accessible to the application.

There's an argument that you could scope this to a BUNDLE, but that
seems like unnecessary complication to me.  For instance, we don't
have any API artifacts at this level, upon which this property could
be attached.

# Data Channels

The question as to whether data channels are affected by this
isolation is an interesting one.  Data channels are inherently NEVER
isolated (though we could work on that for some use cases, e.g., file
sharing, I don't think that we're ready for that today.)

I would like to say that data channels can't be created on a
PeerConnection that has isolated streams.  It's logically cleaner that
way.  If we do ever decide to do confidential file transfer (for
example), it would also enable that without new contortions.

I'm not going to get militant on this point though if someone has a
plausible reason to allow use of data channels in the same PC as
isolated streams.

---

From: Jim Barnett <[email-masked]>
Date: Thu, 06 Mar 2014 09:37:41 -0500

On the scoping question, suppose SideA creates isolated streams (that 
can only be sent to SideB) while SideB creates unprotected streams to 
send to SideA.  Are SideA's streams treated as unprotected, or are 
SideB's treated as isolated?  Normally I would think that the weakest 
restriction would win, so that both sides' streams would be unprotected, 
but it would come as quite a surprise to A that something B did could 
cause his streams  to lose isolation (in his own browser, I mean - A 
obviously can't control what B does with the stream once it gets there.)

- Jim
On 3/6/2014 9:21 AM, Martin Thomson wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Jim Barnett
Genesys

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 6 Mar 2014 15:03:19 +0000

Would be good to think about whether the default should be isolated (with a special way for sites to ask the browser to relax the restriction) or not isolated (with a way to ask for isolation). The traditional way for "the web" is to do the latter, but I think by now we've seen why we might have wished otherwise.

Matthew Kaufman

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Martin
> Thomson
> Sent: Thursday, March 6, 2014 2:22 PM
> To: [email-masked]
> Subject: [rtcweb] Preserving stream isolation when traversing the network
> 
> Mostly the reasons for its existence.  This email is an attempt to explain the
> rationale in more detail, as well as to explore some of the options.
> 
> # Problem Statement
> 
> This is the feature that we rely on for creating end-to-end protected and
> authenticated calls.  We rely on the browser preventing applications from
> accessing these streams so that they can't be modified, recorded, sent to or
> through servers, rendered to canvas, pushed into web audio, etc...
> 
> The basic idea of isolation is already an important part of the web security
> model.  Streams that come from sources other than WebRTC already require
> protections of this sort.  For instance, <video> tags from different origins
> can't be rendered to canvas, and web audio cannot take the output of
> <audio> if it was cross origin (though CORS can be used to work around this
> limitation).
> 
> The problem I outlined was that any isolation property is not preserved by
> WebRTC.  This provides a trivial means of circumvention of isolated streams.
> Sending media using WebRTC effectively strips away isolation.
> 
> # Solution Options
> 
> As I described in the working group session, I see two ways to solve this
> problem.  One in-band in TLS, the other in signaling.
> 
> We seemed to have general agreement that a signal in (D)TLS would be best.
> Signaling creates extra attack modes.  This more closely binds the isolation
> guarantee to the security context.
> 
> To that end, I've submitted an extension draft to the TLS WG.  I recommend
> that you read it and provide comments on its applicability to RTCWEB here,
> and comments on the mechanism itself over in TLS.
> 
> There is another option I really just thought of, and that is to add an
> authenticated parameter to RTP for this purpose.  Probably as an RTP header
> extension.  This has different properties, mostly which apply to the scope
> question.
> 
> # Scope
> 
> We agreed yesterday that identity assertions would be scoped to the session
> level and that a=identity is session scoped.
> 
> I am going to propose that stream isolation is also scoped to the session.  This
> implies that all streams from both peers MUST be either all isolated, or that
> they are all accessible to the application.
> 
> There's an argument that you could scope this to a BUNDLE, but that seems
> like unnecessary complication to me.  For instance, we don't have any API
> artifacts at this level, upon which this property could be attached.
> 
> # Data Channels
> 
> The question as to whether data channels are affected by this isolation is an
> interesting one.  Data channels are inherently NEVER isolated (though we
> could work on that for some use cases, e.g., file sharing, I don't think that
> we're ready for that today.)
> 
> I would like to say that data channels can't be created on a PeerConnection
> that has isolated streams.  It's logically cleaner that way.  If we do ever decide
> to do confidential file transfer (for example), it would also enable that
> without new contortions.
> 
> I'm not going to get militant on this point though if someone has a plausible
> reason to allow use of data channels in the same PC as isolated streams.
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Mar 2014 09:19:20 +0000

On Mar 6, 2014 2:38 PM, "Jim Barnett" <[email-masked]> wrote:
>
> On the scoping question, suppose SideA creates isolated streams (that can
only be sent to SideB) while SideB creates unprotected streams to send to
SideA.  Are SideA's streams treated as unprotected, or are SideB's treated
as isolated?  Normally I would think that the weakest restriction would
win, so that both sides' streams would be unprotected, but it would come as
quite a surprise to A that something B did could cause his streams  to lose
isolation (in his own browser, I mean - A obviously can't control what B
does with the stream once it gets there.)

The idea is that ÄĻŁ streams/tracks would be protected and that means that
both sides would have to apply the same treatment.

That has several consequences, some of which could be considered negative.
There are a few API niceties that could be added here to mitigate these.  I
omitted those from the first analysis, but I've added them here.

For streams that change between isolated and non-isolated, there are two
ways we handle this.  We already have guidance that streams should send
black/silence if they are (or become) isolated.  And streams that become
non-isolated fail safe.  These protections are the most important, because
they are fundamental properties required by the web sandbox.

The scenario you describe is where each side starts with a different idea
about what isolation properties are required.  Without any other
mechanisms, this fails safe - the (D)TLS handshake would be required to
fail when implementations detect a mismatch in isolate state.

In order to avoid issues with this, we probably need to consider the
addition of a flag in SDP.  That flag would be advisory only, but it would
ensure that you could surface an error in createAnswer that indicates this
mismatch prior to having the problem blow up in less obvious ways.

BTW, we don't have to, but for mixed streams on one side, we should add an
error to createOffer/createAnswer to block the creation of SDP when there
are mixed isolation on streams.  Again, that avoids the issue of having
things break in non-obvious ways later.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Mar 2014 09:21:39 +0000

> Would be good to think about whether the default should be isolated (with a special way for sites to ask the browser to relax the restriction) or not isolated (with a way to ask for isolation). The…

We've talked about this in the past.  There are two aspects that we've
considered: whether to prompt for access to isolated streams (we
decided that this could be considered creepy), and whether to default
to isolation.  I don't think that we can realistically default to
isolation at this point.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Mar 2014 09:59:17 +0000

> apply to the scope question.

Having thought about this, I think that we can discount it.  A
security property of this sort needs to be reliably attached to the
stream.  That means an extension in every SRTP packet if we do it that
way.  In the (D)TLS handshake, it costs much less.

If we wanted isolation on a much more granular level, then this would
be OK, but I don't think that we should be making it that granular.

---

From: Tim Panton <[email-masked]>
Date: Fri, 7 Mar 2014 10:19:51 +0000

> to isolation.  I don't think that we can realistically default to

I'm skeptical about the usefulness of isolation. If I understand it correctly, it would disable the ability
of a user interface to do any webGL or webAudio processing on the audio or video signals.
Many of the use cases I see use these APIs to do things like add titlebars, mix audio streams play audio prompts etc,
isolation reduces webRTC to  door-intercom like functionality, whilst there are good usages of that, I suspect they are in the 
minority.

So I'd oppose any move to make streams isolated by default.

T.

---

From: Tim Panton <[email-masked]>
Date: Fri, 7 Mar 2014 10:23:30 +0000

> way.  In the (D)TLS handshake, it costs much less.

Where in the DTLS handshake? There is a risk that if it is too early, 
then we are raising an un encrypted flag saying to the DPI crowd 
"look at me, I'm interesting".

The whole thrust of the IETF's 'encrypt all the things' is to make encryption
default and therefor unexceptional, we shouldn't do anything that makes
isolated calls visibly 'special'.

T.

> be OK, but I don't think that we should be making it that granular.

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Mar 2014 10:23:59 +0000

I agree with the conclusion, however:

> Many of the use cases I see use these APIs to do things like add titlebars, mix audio streams play audio prompts etc,

The stuff you cite can be achieved without having to of webgl or
webaudio.  But I agree with the principle: there are cases where
isolation is inconvenient.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Mar 2014 10:25:59 +0000

> "look at me, I'm interesting".

Ahh yes, and I wish them luck.

So if you read the draft I referenced (it's short), it's a TLS extension.

In TLS 1.2, those are in the clear.

But in TLS 1.3 we are encrypting extensions.  I expect that browsers
will have TLS 1.3 fairly quickly.

---

From: Jim Spring <[email-masked]>
Date: Thu, 6 Mar 2014 21:18:04 +0000

My preference is for the former with the caveat of "asking the browser to relax the restriction" not involve ye olde generic popup asking the user for permission.  The former fits in better with the current behavior of audio/video tags.

-jim

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 07 Mar 2014 11:57:19 +0100

> isolation is inconvenient.

I'd put this a bit more strongly:

Every single non-trivial application that uses WebRTC today is going to
fail if isolation is turned on by default.

Some of the things that will fail:

- Content-sensitive video overlays ("funny hats")
- Color enhancements that attempt to "fix" videos that are "too dark" /
"too light" and so on
- Bluescreening / background replacement
- Volume measurement via WebAudio
- "Voice effects" (also applied via WebAudio)
- Retransmission ("mesh conferencing")
- Any type of recording

All of these are being done by Javascript if they are done at all today.

If data channels are included in the isolate-by-default zone too, of
course every application that uses data channels will fail too - at the
moment there is *nothing* you can do with a data channel that doesn't
expose the data to the Javascript.

I don't think we've thought through the threat model here (well, Martin
may have, but I don't think we have a joint understanding of it), or
what the things are that we won't be able to do without inevitably
exposing our streams to the kinds of manipulation described here.

The threat model I heard at the meeting was that the sender wants a
guarantee from the receiver's browser that it will keep the streams
confidential against Javascript running in the receiver. It gains no
security against compromised receivers, or receivers that participate in
the RTCWEB protocol dialog but aren't Javascript-executing browsers - in
that case, the promise is simply irrelevant.

The promise might  be relevant for some use cases - in particular, the
use case of interactive videoconferencing where the users trust each
other, but not their Javascript, and where they're willing to give up
funny hats, recording and the other things listed above.

I think that's a very specialized use case.

-- 
Surveillance is pervasive. Go Dark.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Mar 2014 11:04:43 +0000

> I think that's a very specialized use case.

While I agree with much of the rest of your argument, casting this as
specialized does our future users a disservice, I think.

I appreciate that some companies consider their "value-add" to be so
compelling that isolation is something they would not consider.  That
doesn't mean that everyone will.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 07 Mar 2014 12:16:08 +0100

> doesn't mean that everyone will.
There may be people in both camps. Probably will be.

I don't think that "companies' value-add" matters in this situation.
What matters is whether JS access to the media is necessary to achieve
the applications' purpose.

We've seen virtual drum kits that you play by waving your hands in front
of a camera. That application simply can't be made without JS access to
media; it's inherent in what the function is.

That's my point - there are many such applications.

---

From: Randell Jesup <[email-masked]>
Date: Fri, 07 Mar 2014 20:42:32 -0500

> the applications' purpose.

Right.  The example given by Cullen in previous conversations was that 
if someone is using a service provided by Large Company to have internal 
discussions, they want some assurance that Large Company (serving the JS 
code to them for both ends of the conference) doesn't have access to the 
media streams.

I presented an early look at this issue and the use of origins in the W3 
part of the Feb 2012 IETF/W3 interim in MV.

The more general case is a service that wants to provide people with 
secure calls can use isolated streams (modulo the ability of the 
participants to verify through browser UI that they're being used), or 
conversely the ability to tell the browser not to let the JS application 
(*or* the application at the other side!) access the mediastreams.  
(Note that some uses might break, or (if the app was written knowing the 
user can do this) would disable features. That's fine)

This is solely to protect against the JS.  It does not protect against 
other attacks or the far-end user themselves (who could always have a 
camera/mic pointed at the screen).  Even if you trust the application 
provider, in some cases they may have been hacked, or they may have been 
coerced into spying on you (how *would* that happen....)

The ability to do this is important to some people, for the same sort of 
reasons why someone I worked with building videophones kept a post-it 
note over the camera of the videophone on her desk; she didn't feel safe 
without it.

> That's my point - there are many such applications.

Sure.  I don't think anyone is seriously proposing making isolated 
streams the default (or aren't anymore).

-- 
Randell Jesup -- rjesup a t mozilla d o t com