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

Jim Barnett <1jhbarnett@gmail.com> Thu, 06 March 2014 14:38 UTC

Return-Path: <1jhbarnett@gmail.com>
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 CB4111A041F for <rtcweb@ietfa.amsl.com>; Thu, 6 Mar 2014 06:38:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_18=0.6, SPF_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 BPJhOpFh4FtY for <rtcweb@ietfa.amsl.com>; Thu, 6 Mar 2014 06:38:10 -0800 (PST)
Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 44C1B1A041C for <rtcweb@ietf.org>; Thu, 6 Mar 2014 06:38:10 -0800 (PST)
Received: by mail-qc0-f181.google.com with SMTP id e9so2940301qcy.12 for <rtcweb@ietf.org>; Thu, 06 Mar 2014 06:38:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=FlIT/u9j6KOQ/KhQri7wyOYSXK5WrS3gFg9mYqRsdk0=; b=nZCJOzBtsJ/DyEMfuCmtyaoC+KswHPtv63u2BHpaQG7UDoD5UZgo7j+JT+xJU7hd/X Rn8arYHjJ5tHE6lv9IWTyisNH0GzsAXd+sbHDYFHbsuZL47fFC4nUassxvDVWrbmutRs gUDNtWsBS4ReD08C97JMRDoHyVA8BgG4tQh9Lwk4ozQMYk/SiggxRAebIkdogWKS7h8F UlOfONnRMzhWfBXBE/LYGMMSAu540oE+zECw+vdN1oFf2fIberVTIBnqIbBljiMsJE62 njB1QT1VkEnFkRjTUWW3kIEnr/3brCfT2M8FkpD9lWqxAi75pqUQLUOarWOP0K77gnt7 guoQ==
X-Received: by 10.140.49.210 with SMTP id q76mr2866862qga.103.1394116683174; Thu, 06 Mar 2014 06:38:03 -0800 (PST)
Received: from [192.168.1.3] (pool-173-76-134-50.bstnma.fios.verizon.net. [173.76.134.50]) by mx.google.com with ESMTPSA id n8sm19425337qaz.18.2014.03.06.06.38.02 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 06:38:02 -0800 (PST)
Message-ID: <53188835.4000806@gmail.com>
Date: Thu, 06 Mar 2014 09:37:41 -0500
From: Jim Barnett <1jhbarnett@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CABkgnnVZpOJU=2ip88jF=sa2a7K=jBhZA0zkovPo_vvTBwA-GQ@mail.gmail.com>
In-Reply-To: <CABkgnnVZpOJU=2ip88jF=sa2a7K=jBhZA0zkovPo_vvTBwA-GQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/raIiMAuTYpTYVdIr9lzMAUb2ToE
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 14:38:16 -0000

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

-- 
Jim Barnett
Genesys