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

"Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net> Thu, 06 March 2014 15:04 UTC

Return-Path: <matthew.kaufman@skype.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1E21A01B6 for <rtcweb@ietfa.amsl.com>; Thu, 6 Mar 2014 07:04:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_idX9tJ4I25 for <rtcweb@ietfa.amsl.com>; Thu, 6 Mar 2014 07:04:04 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE161A0063 for <rtcweb@ietf.org>; Thu, 6 Mar 2014 07:04:04 -0800 (PST)
Received: from BLUPR03CA033.namprd03.prod.outlook.com (10.141.30.26) by BLUPR03MB167.namprd03.prod.outlook.com (10.255.212.143) with Microsoft SMTP Server (TLS) id 15.0.893.10; Thu, 6 Mar 2014 15:03:59 +0000
Received: from BL2FFO11FD043.protection.gbl (2a01:111:f400:7c09::155) by BLUPR03CA033.outlook.office365.com (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 mail.microsoft.com (131.107.125.37) by BL2FFO11FD043.mail.protection.outlook.com (10.173.161.139) with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Thu, 6 Mar 2014 15:03:58 +0000
Received: from TK5EX14MBXC296.redmond.corp.microsoft.com ([169.254.2.186]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0174.002; Thu, 6 Mar 2014 15:03:20 +0000
From: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
To: Martin Thomson <martin.thomson@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Preserving stream isolation when traversing the network
Thread-Index: AQHPOUdyI9MeBv5M3k+xX+b+Po4uuZrUJ4DQ
Date: Thu, 6 Mar 2014 15:03:19 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A4844FABBEDF@TK5EX14MBXC296.redmond.corp.microsoft.com>
References: <CABkgnnVZpOJU=2ip88jF=sa2a7K=jBhZA0zkovPo_vvTBwA-GQ@mail.gmail.com>
In-Reply-To: <CABkgnnVZpOJU=2ip88jF=sa2a7K=jBhZA0zkovPo_vvTBwA-GQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.73]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; 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; H:mail.microsoft.com; CLIP:131.107.125.37; 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 skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com;
X-OriginatorOrg: skype.net
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JHkqdE1zq9yAxBoLBEIJUSpYHJk
Subject: Re: [rtcweb] Preserving stream isolation when traversing the network
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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 [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