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

"Matthew Kaufman (SKYPE)" <> Thu, 06 March 2014 15:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2A1E21A01B6 for <>; Thu, 6 Mar 2014 07:04:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y_idX9tJ4I25 for <>; Thu, 6 Mar 2014 07:04:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9FE161A0063 for <>; Thu, 6 Mar 2014 07:04:04 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.893.10; Thu, 6 Mar 2014 15:03:59 +0000
Received: from (2a01:111:f400:7c09::155) by (2a01:111:e400:879::26) with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Thu, 6 Mar 2014 15:03:59 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Thu, 6 Mar 2014 15:03:58 +0000
Received: from ([]) by ([]) with mapi id 14.03.0174.002; Thu, 6 Mar 2014 15:03:20 +0000
From: "Matthew Kaufman (SKYPE)" <>
To: Martin Thomson <>, "" <>
Thread-Topic: [rtcweb] Preserving stream isolation when traversing the network
Thread-Index: AQHPOUdyI9MeBv5M3k+xX+b+Po4uuZrUJ4DQ
Date: Thu, 06 Mar 2014 15:03:19 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(199002)(189002)(51704005)(377454003)(46102001)(53806001)(77096001)(49866001)(81542001)(47736001)(81342001)(47976001)(50986001)(4396001)(95416001)(97336001)(93136001)(85852003)(83072002)(93516002)(92566001)(51856001)(86362001)(92726001)(74502001)(74662001)(76482001)(87266001)(65816001)(76796001)(56776001)(66066001)(47446002)(54316002)(54356001)(80022001)(85306002)(94946001)(94316002)(31966008)(76786001)(2656002)(47776003)(20776003)(63696002)(77982001)(59766001)(79102001)(74706001)(90146001)(56816005)(23726002)(46406003)(55846006)(95666003)(6806004)(44976005)(69226001)(19580405001)(83322001)(19580395003)(80976001)(15202345003)(97186001)(81686001)(33656001)(81816001)(74366001)(50466002)(74876001)(87936001)(15975445006); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB167;; CLIP:; FPR:BEBCC16D.A3E29202.EEF3317B.4AE5D261.204BD; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0142F22657
Received-SPF: Pass (: domain of designates as permitted sender) receiver=; client-ip=;;
Subject: Re: [rtcweb] Preserving stream isolation when traversing the network
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Mar 2014 15:04:09 -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 [] On Behalf Of Martin
> Thomson
> Sent: Thursday, March 6, 2014 2:22 PM
> To:
> 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.
> 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