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

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

On Mar 6, 2014, at 3:03 PM, Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net> wrote:

> 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
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb