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

Martin Thomson <martin.thomson@gmail.com> Fri, 04 April 2014 20:50 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 176061A0116 for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 13:50:55 -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 RI_nwusXPTu2 for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 13:50:49 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7422C1A010B for <rtcweb@ietf.org>; Fri, 4 Apr 2014 13:50:49 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id d1so1993683wiv.9 for <rtcweb@ietf.org>; Fri, 04 Apr 2014 13:50:44 -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=mQTAdQD4z5U6ekCNKxYHu/Ifi/yoGVClmoyCb6CGhBo=; b=sOWGeWLX8kIETgz8j9U5vHr9nJ8SZGdlyYipkhNbDQXsA5+NF/PPMEx+7yePmOwUho HbvFqOHPxmmV4XMWnPGCDaANskDLhkAdctMA79/EtYR6jyK0zvJUzgUp7+05CGxMZwfr CpvpdtasTDiK2cz/ziJZLbVuV9JNT02O3Ur3N2HYpA9bkZc9TjwgBETKUHrlgyNE8ozl kYQYzyAm8ot6OYF+OzW0HY68NgzrZqyFEknuok2abbir2yCvleKKIat8ZHoWHOmIRrdK bzho4AQDfM95e29tEEGLD5BPSBU+M5bDL3wPkpcBFEWKM4fIN8sOwyJBcsJEA84L1paC vvpQ==
MIME-Version: 1.0
X-Received: by 10.180.89.211 with SMTP id bq19mr7333505wib.58.1396644644091; Fri, 04 Apr 2014 13:50:44 -0700 (PDT)
Received: by 10.227.147.10 with HTTP; Fri, 4 Apr 2014 13:50:44 -0700 (PDT)
In-Reply-To: <533F191D.8050109@alum.mit.edu>
References: <CABkgnnWWuU63Vd=gw+wrh2ADgVYtQzhoRzRE1sv5azJE=MhWDg@mail.gmail.com> <533F191D.8050109@alum.mit.edu>
Date: Fri, 04 Apr 2014 13:50:44 -0700
Message-ID: <CABkgnnVht5EmJ7a2LDh50ivjUdoTpJ8GannQKReBSJbVGQGmgA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_AyC979J88pK_ORD96VplUYU_UU
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 20:50:55 -0000

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.

> - 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.

> - 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.