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

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 04 April 2014 20:42 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 54C9E1A028E for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 13:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 SlOWVnHDYW5R for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 13:42:11 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA151A01BD for <rtcweb@ietf.org>; Fri, 4 Apr 2014 13:42:10 -0700 (PDT)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id lnx91n0071ei1Bg5Awi6Wz; Fri, 04 Apr 2014 20:42:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id lwi51n00g3ZTu2S3kwi6uF; Fri, 04 Apr 2014 20:42:06 +0000
Message-ID: <533F191D.8050109@alum.mit.edu>
Date: Fri, 04 Apr 2014 16:42:05 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CABkgnnWWuU63Vd=gw+wrh2ADgVYtQzhoRzRE1sv5azJE=MhWDg@mail.gmail.com>
In-Reply-To: <CABkgnnWWuU63Vd=gw+wrh2ADgVYtQzhoRzRE1sv5azJE=MhWDg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396644126; bh=XajOGkw4YAcXgo+S5h31EzW5R0211xAgrlI7rBWSn7c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iGwyxej4Xp+aSzbPvNw561onIR3CJFtyLYg0cXH8Phw0bcyjpnfwkZuXI/5QLtwu2 W5P6tJlOuol70yhBk25Wg1wcETXZwS/B5JcbRnH1qS4WsiiA3x1eNd0/CLR2RMMWbj d9UbJUzSXfc6VVdIVu+v5vdYnkf+UuD4evFjHecU4uYNR3pu+c1uNhes3AuAJqZYfZ i4eQTwOteFdpX7/VD5dAEVHqFzEC+8n5gwrvKFxVduM/xgs7HkJnbk+nZIBlgxPkBE Z+jhPEh/qZJh6dQjb+hL2A/CptmS2fK3i8r8MjVTn2OzIBH/EuMrRVShMQ4aJabfg1 2qCnjXhbB0avw==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OxdF06-SqZKaXEK8Xipnjy-GmBo
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 20:42:15 -0000

I'm confused by this, in at least a couple of respects:

- IIUC this isolation is a browser thing. If the other end doesn't
   have a browser then what does it mean?

- Isn't the isolation supposed to be on a per-stream basis?
   (Or is it really on a peer-connection basis.) If it is per-stream
   then how does signaling it on a per-TLS basis work?

- The use of DTLS to do SRTP keying is a sort of hack, since it
   isn't about the DTLS payload at all. I would think that whatever
   new you introduce into TLS for this would most naturally apply
   to the DTLS payload (the data channels).

	Thanks,
	Paul

On 4/3/14 8:14 PM, Martin Thomson 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.
>
> I propose that we formally request the TLS working group recommend or
> define a mechanism whereby we can signal in the TLS handshake that the
> session contents are to be protected from access (where the
> description of that protection may need to our responsibility).
>
> I have pointed to draft-thomson-tls-acp as a potential solution here,
> but others have noted that ALPN tokens could be used.  I expect that
> TLS are capable of making the right decision here.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>