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

Paul Kyzivat <> Sun, 06 April 2014 18:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E4DB51A04C1 for <>; Sun, 6 Apr 2014 11:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FqeAcXjhyjre for <>; Sun, 6 Apr 2014 11:37:14 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:212]) by (Postfix) with ESMTP id 35C9C1A04B8 for <>; Sun, 6 Apr 2014 11:37:14 -0700 (PDT)
Received: from ([]) by with comcast id miSu1n0031ei1Bg5Eid8Cl; Sun, 06 Apr 2014 18:37:08 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id mid81n00f3ZTu2S3kid8jD; Sun, 06 Apr 2014 18:37:08 +0000
Message-ID: <>
Date: Sun, 06 Apr 2014 14:37:08 -0400
From: Paul Kyzivat <>
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 <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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==
Cc: "" <>
Subject: Re: [rtcweb] Asking TLS for help with media isolation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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.