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

[Jim Barnett <[e-mail]>]

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:
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Jim Barnett
Genesys