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

Martin Thomson <> Fri, 04 April 2014 03:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 11FF61A03CD for <>; Thu, 3 Apr 2014 20:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4IPbNgOIkkFL for <>; Thu, 3 Apr 2014 20:25:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::231]) by (Postfix) with ESMTP id CEE481A042B for <>; Thu, 3 Apr 2014 20:25:56 -0700 (PDT)
Received: by with SMTP id u57so2707554wes.22 for <>; Thu, 03 Apr 2014 20:25:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k1Esk/IphZuHorG1mQmgs/r/0kFmE7J/0dZxzOkoxz0=; b=r04avJLcr/ZXpM4FNKIo33+K53j65Qqq0orxwL43t/5vNR8JzWi7NKpRD1F55moNOh cSyO9ZAsPCOnbQuY8Pz6Cjcws+lQdYpqsidw+w3EKxegJDT8vXn0XydeQxRHRL6ENTmp 8UxUWcKPngv6gIkfKrCR5Z1+y8ex982cajJZNQfCBuBTErrl3NkaKdNCgkjjLHPmIsIB FIpn1wnmFzZH8syE/jqiIEopJLuOi3MErs9avWpZqqVzWyXd+gHCv2+MjiB/xZ5/m+cM D63w9pLoN8Gv0nx64JeaAjsJIiv+T6/uAjKEzyqXiBYUsdBgttHlXAuC8zylla6eDdCr u3zg==
MIME-Version: 1.0
X-Received: by with SMTP id la7mr16206554wjc.4.1396581952033; Thu, 03 Apr 2014 20:25:52 -0700 (PDT)
Received: by with HTTP; Thu, 3 Apr 2014 20:25:51 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 03 Apr 2014 20:25:51 -0700
Message-ID: <>
From: Martin Thomson <>
To: Watson Ladd <>
Content-Type: text/plain; charset="UTF-8"
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: Fri, 04 Apr 2014 03:26:05 -0000

Perhaps some more context is necessary.

(D)TLS provides us good protection against network attackers.  The
problem is that this protection ends at the browser, and our security
story doesn't.  Media streams in the browser are an extension of those
that traverse the network, and we need something of a gentlemen's
agreement between browsers to be reached.  That agreement says that
your browser and mine will agree between themselves to protect media
from the application that is running in their sandbox: all that nasty
JavaScript that came from a site (or sites) that we might not want to
include in our conversation.

On 3 April 2014 19:49, Watson Ladd <> wrote:
> The MITM can kill any TLS connection containing the extension. My
> understanding is that signalling data is immutable, hence the need to
> ask the browser to generate it.

Signaling is totally mutable, which is a big problem.  Once an
application gets it, there's a lot that can be changed between peers.

>> However once the desire for isolation is communicated E2E (either via ACP or
>> ALPN tokens), there is nothing in the SRTP traffic (keyed by DTLS/SRTP) that
>> indicates that the traffic is to be isolated.
> I don't see why the isolation status cannot be included as an
> extension to SRTP. You aren't asking TLS to make extensions for video
> resolution and codec after all.

That's a good question, and it's an option I should have added to the
list.  The problem there is that nothing in RTP is reliable, and this
signal needs to be reliable.  Combine that with the fact that the
extent of an RTP session is essentially unknowable, and you end up
having to put an RTP header extension on every packet.  RTP header
extensions have other drawback as well, though I suspect most of those
aren't applicable in this context.

With the TLS handshake, you either get a marked session, or you don't
get a session at all.  That's a big advantage with this approach.  And
it costs far fewer bytes.