[rtcweb] Preserving stream isolation when traversing the network

[Martin Thomson <[e-mail]>]

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.