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

Martin Thomson <martin.thomson@gmail.com> Fri, 07 March 2014 09:19 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8981A0253 for <rtcweb@ietfa.amsl.com>; Fri, 7 Mar 2014 01:19:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 kom_mel3JCjc for <rtcweb@ietfa.amsl.com>; Fri, 7 Mar 2014 01:19:26 -0800 (PST)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 48FE51A0258 for <rtcweb@ietf.org>; Fri, 7 Mar 2014 01:19:25 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id k14so4629265wgh.23 for <rtcweb@ietf.org>; Fri, 07 Mar 2014 01:19:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O8xU3nSUwREqiWvnaCvOJYbluyyHglp2sXDD4Q7EWAk=; b=WW2l0qC9FMK41hCWCkM+xAV+HqhScOdWxcjRvzEDs0IHlKuutMaByvCLK4RLZw8ZQX 4Z6hC6R8CGh7VIyrCugAvj1Aca87Jm7btaEQHB75YRrt0wJdo0kxN7aZ66Q3e0VZhzU5 Nch45XVHyGiJOLkiOka1T3yzhOMfqUu6OPNALmpxaBcoAYlEVq5eG+Sa8AprffQlUTS5 Iej6QCJgsoYIB4aFmv5CDMgnM9RGDNagLRpr/u4iuJsYMn1TJSBAsTEey9XS0KGtEUTd /BwPmmemEfQCC+1amlTKZYZXXywWDDhaMzuNbKc33eqQUGFlB1IUxhGHPt70dgvWtSmg ue5A==
MIME-Version: 1.0
X-Received: by 10.194.110.41 with SMTP id hx9mr17468906wjb.28.1394183960440; Fri, 07 Mar 2014 01:19:20 -0800 (PST)
Received: by 10.227.10.196 with HTTP; Fri, 7 Mar 2014 01:19:20 -0800 (PST)
In-Reply-To: <53188835.4000806@gmail.com>
References: <CABkgnnVZpOJU=2ip88jF=sa2a7K=jBhZA0zkovPo_vvTBwA-GQ@mail.gmail.com> <53188835.4000806@gmail.com>
Date: Fri, 7 Mar 2014 09:19:20 +0000
Message-ID: <CABkgnnVuMEmUSQO4WB=9NmU34G6RObvEnU8OYJCeSnv=-VVuPQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Jim Barnett <1jhbarnett@gmail.com>
Content-Type: multipart/alternative; boundary=089e010d89e0b6b54904f400bfa9
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ztz3y_g-PE5jQFL3JpDaQ5G3gl0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Fri, 07 Mar 2014 09:19:28 -0000

On Mar 6, 2014 2:38 PM, "Jim Barnett" <1jhbarnett@gmail.com> wrote:
>
> 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.)

The idea is that ÄĻŁ streams/tracks would be protected and that means that
both sides would have to apply the same treatment.

That has several consequences, some of which could be considered negative.
There are a few API niceties that could be added here to mitigate these.  I
omitted those from the first analysis, but I've added them here.

For streams that change between isolated and non-isolated, there are two
ways we handle this.  We already have guidance that streams should send
black/silence if they are (or become) isolated.  And streams that become
non-isolated fail safe.  These protections are the most important, because
they are fundamental properties required by the web sandbox.

The scenario you describe is where each side starts with a different idea
about what isolation properties are required.  Without any other
mechanisms, this fails safe - the (D)TLS handshake would be required to
fail when implementations detect a mismatch in isolate state.

In order to avoid issues with this, we probably need to consider the
addition of a flag in SDP.  That flag would be advisory only, but it would
ensure that you could surface an error in createAnswer that indicates this
mismatch prior to having the problem blow up in less obvious ways.

BTW, we don't have to, but for mixed streams on one side, we should add an
error to createOffer/createAnswer to block the creation of SDP when there
are mixed isolation on streams.  Again, that avoids the issue of having
things break in non-obvious ways later.