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

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 06 April 2014 18:37 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 E4DB51A04C1 for <rtcweb@ietfa.amsl.com>; Sun, 6 Apr 2014 11:37:18 -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 FqeAcXjhyjre for <rtcweb@ietfa.amsl.com>; Sun, 6 Apr 2014 11:37:14 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 35C9C1A04B8 for <rtcweb@ietf.org>; Sun, 6 Apr 2014 11:37:14 -0700 (PDT)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta14.westchester.pa.mail.comcast.net with comcast id miSu1n0031ei1Bg5Eid8Cl; Sun, 06 Apr 2014 18:37:08 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id mid81n00f3ZTu2S3kid8jD; Sun, 06 Apr 2014 18:37:08 +0000
Message-ID: <53419ED4.8020102@alum.mit.edu>
Date: Sun, 06 Apr 2014 14:37:08 -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: Martin Thomson <martin.thomson@gmail.com>
References: <CABkgnnWWuU63Vd=gw+wrh2ADgVYtQzhoRzRE1sv5azJE=MhWDg@mail.gmail.com> <533F191D.8050109@alum.mit.edu> <CABkgnnVht5EmJ7a2LDh50ivjUdoTpJ8GannQKReBSJbVGQGmgA@mail.gmail.com>
In-Reply-To: <CABkgnnVht5EmJ7a2LDh50ivjUdoTpJ8GannQKReBSJbVGQGmgA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396809428; bh=T7sKLC0ASoO5dbFxEo1/8RQe/axFfta36Gac7vgNrpw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EpHeya/NtFxWchvVeAGCQYvba6BXlPgo5L+SwUWzV/nJGZG83BwB7xP3ZuJGdK80T /i8OQdRcqRMhoIhTAYVwXT4o6RrcZaHMGJnELFfzaANaafVdK00di5P/BYY9VEsoLx nky0w1HjEEhqVDTpkspMnPderezpbT4MWmpBAPvN6zku1+3yNan/VUQXlRp2tYSPuY nktaSC41Osco+flMjkDui3HhNIpzeJ/G4FsU0sNYKQpGMbn5cq3UIsxJROyE/eAGoc 8Gk30FvaZ4B7PhYOQIp0if5jUjPtDZyviwLYK2T+dsBXjS1jR6Tl9ZHeP/O7eygw6y rWKz4gZrH6H6Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JFAdDVSnEDI-bBmElUwd2JG9M6c
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: Sun, 06 Apr 2014 18:37:19 -0000

On 4/4/14 4:50 PM, Martin Thomson wrote:
> Fair questions...
>
> On 4 April 2014 13:42, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>> - IIUC this isolation is a browser thing. If the other end doesn't
>>    have a browser then what does it mean?
>
> Yes, this is specific to a browser.  A non-browser peer would probably
> respect this isolation property without any effort at all.  After all,
> few non-browser applications permit the running of arbitrary,
> remotely-source code in the way that a browser does.

But ISTM there would need to be a different set of limitations for 
non-browsers. For instance, to not echo the stream back to the source. 
And not to store the stream in a place that the sender can retrieve.

Maybe it is possible to define a set of rules, but I don't have a vision 
of what that would be.

>> - 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 question of scope is an important one.  The isolation property is,
> at least at the most abstract layer, applicable to a MediaStreamTrack.
>   I believe that the right approach is to broaden this scope to
> RTCPeerConnection, where the identity controls exist.  This means that
> you won't be able to mix isolated and non-isolated streams in the same
> RTCPeerConnection.

I'll wait to see what others have to say about this.
I haven't been able to wrap my head around it.

>> - 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).
>
> This is true only in the strictest academic or abstract sense.  We are
> already taking things from the DTLS handshake and using those things
> to make assertions about the properties of the SRTP.  Certificates.
>
> Since you raise data channels, I'll note that we have no way to use
> data channels in an isolated fashion.  Thus, I conclude that if we
> intend to make this property consistent, we should not be using data
> channels in the same RTCPeerConnection as media streams.  Of course,
> I'm open to taking the pragmatists approach too, unless we think that
> there is a use case for - say, file transfer - where it makes sense
> for data to be isolated in the same way I'm proposing that media be.

Again I'm interested to hear what others have to say about this.

	Thanks,
	Paul