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

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:rtcweb-bounces@ietf.org] On Behalf Of Martin
> Thomson
> Sent: Thursday, March 6, 2014 2:22 PM
> To: rtcweb@ietf.org
> Subject: [rtcweb] Preserving stream isolation when traversing the network
> 
> 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.
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb