[rtcweb] Preserving stream isolation when traversing the network

Martin Thomson <martin.thomson@gmail.com> Thu, 06 March 2014 14:22 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6FDAA1A03BD for <rtcweb@ietfa.amsl.com>; Thu, 6 Mar 2014 06:22:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1UqNCC3Wk94g for <rtcweb@ietfa.amsl.com>; Thu, 6 Mar 2014 06:21:59 -0800 (PST)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2A11A006B for <rtcweb@ietf.org>; Thu, 6 Mar 2014 06:21:59 -0800 (PST)
Received: by mail-we0-f175.google.com with SMTP id q58so3149600wes.6 for <rtcweb@ietf.org>; Thu, 06 Mar 2014 06:21:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=c6qo2Wy9Lrd7bSJgVOvn0xfsNYNps3ottL3a2uQsn5k=; b=q3743LcXtuieGbf9dfHfZDDF37sabrnBAZNHDJC3FIZeHgQlLHPhRrFVLMBSn52Jea XQtceIxvHu6zxGS3LPiCcy/ImSj5jLZrTTmWIWAYzO7vvrOlrmXkSlKj3JQjS4j33Bx6 mRlbimmFe3aQj7Z8VB0SHT7rpWdY6ixH8uiIFoVu8Qh1f0GRw8q+DPcL19R7FkeRqD6B G/cKPE4jNTJS5Su7ncJFcpMhU0D5v+L/fxLMZI2JRseb7OM+21Vu2SMMzIBJL7mnoY+5 bVbS3fepDl1r6/zHEN1UZgRA1SprhpibiBMW9nFvZzDCN9boviTXwc86yY4nozbkD7n/ 7xvw==
MIME-Version: 1.0
X-Received: by with SMTP id hx9mr10695122wjb.28.1394115714988; Thu, 06 Mar 2014 06:21:54 -0800 (PST)
Received: by with HTTP; Thu, 6 Mar 2014 06:21:54 -0800 (PST)
Date: Thu, 06 Mar 2014 14:21:54 +0000
Message-ID: <CABkgnnVZpOJU=2ip88jF=sa2a7K=jBhZA0zkovPo_vvTBwA-GQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LXOhP9YpPwbe3Eoriw0lW7SG5VQ
Subject: [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:22:01 -0000

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.