Re: [rtcweb] Asking TLS for help with media isolation

Watson Ladd <watsonbladd@gmail.com> Fri, 04 April 2014 01:51 UTC

Return-Path: <watsonbladd@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 AC89C1A0390 for <rtcweb@ietfa.amsl.com>; Thu, 3 Apr 2014 18:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 wOQokyTDrYQw for <rtcweb@ietfa.amsl.com>; Thu, 3 Apr 2014 18:51:29 -0700 (PDT)
Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 19A001A0401 for <rtcweb@ietf.org>; Thu, 3 Apr 2014 18:51:28 -0700 (PDT)
Received: by mail-yh0-f41.google.com with SMTP id v1so2573432yhn.0 for <rtcweb@ietf.org>; Thu, 03 Apr 2014 18:51:24 -0700 (PDT)
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=8gt0kfSPJ9d/2dtrTyh/qt1xniUFgnEEpUHjg0BEGlM=; b=gDLb4f1uVr8cq8zcGjol4XTbgcCsLOTdqofWk8tWRQ/opGL/lMwUl+4hLD95Fmao+F 383NdF0ABbYOFhOEE9rIUgEymbaNovbfRr9wHL0g5/OvGjEXiDs19KJUmLTYk447/oqf aKAlut35l/Ebo9D5UeVzsQuti83YbtW/Pnt5AQfFF1NbgRUes/+N7C/CFP28cZdhWp0g w/4psjAHuKKUyraZagEZmOYZOjUtikgXB/8gAo1+8Y5u3DhEUEpX5xbsWjuR5zSW7JbC 9RAnOavPtWjh1c6w5RkEK69rQADI1p2xRuyo0QibDhScAUyGpv2ciCrBRuZDlvZnzHJI 5EMg==
MIME-Version: 1.0
X-Received: by 10.236.200.67 with SMTP id y43mr12931927yhn.77.1396576284528; Thu, 03 Apr 2014 18:51:24 -0700 (PDT)
Received: by 10.170.63.197 with HTTP; Thu, 3 Apr 2014 18:51:24 -0700 (PDT)
In-Reply-To: <CABkgnnWWuU63Vd=gw+wrh2ADgVYtQzhoRzRE1sv5azJE=MhWDg@mail.gmail.com>
References: <CABkgnnWWuU63Vd=gw+wrh2ADgVYtQzhoRzRE1sv5azJE=MhWDg@mail.gmail.com>
Date: Thu, 3 Apr 2014 18:51:24 -0700
Message-ID: <CACsn0cmX55Eewak8GBxBbSFF3v7tRTVqRt0eLwkR2-Tk_V7gHA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OSzlA6reV6tKQ-w6kX90ckDhZD0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Asking TLS for help with media isolation
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, 04 Apr 2014 01:51:34 -0000

On Thu, Apr 3, 2014 at 5:14 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> As I described briefly at the last meeting, ensuring that media is
> isolated from the application or web site is a key part of addressing
> our security goals.
>
> The key part of that is making sure that any media that is isolated on
> the sending side of RTCPeerConnection remains isolated when it reaches
> the other side.
>
> As I noted, this is also necessary in order to ensure the integrity of
> the same origin model.  In that model, cross origin media is required
> to be inaccessible to content, and as it stands RTCPeerConnection
> could be used to work around those restrictions (implementations can
> implement other protections, as Firefox already does).
>
> The alternatives as I see them (and I hope that this is sufficiently
> exhaustive) are:
>
>  1. ask the TLS working group for a TLS-based solution
>  2. build something into the session signaling (i.e., new SDP bits)
>  3. give up on the idea
>
> I prefer 1 for reasons already outlined.

Putting on my TLS hat, TLS already lets you send data across the
network securely. Why does this bit need to be treated differently
from all others?

Sincerely,
Watson Ladd


-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin