[rtcweb] Asking TLS for help with media isolation

Martin Thomson <martin.thomson@gmail.com> Fri, 04 April 2014 00:14 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 389B61A0407 for <rtcweb@ietfa.amsl.com>; Thu, 3 Apr 2014 17:14:30 -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 8yqB5DG4VN0m for <rtcweb@ietfa.amsl.com>; Thu, 3 Apr 2014 17:14:24 -0700 (PDT)
Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 05D401A0406 for <rtcweb@ietf.org>; Thu, 3 Apr 2014 17:14:23 -0700 (PDT)
Received: by mail-ob0-f173.google.com with SMTP id gq1so2767917obb.4 for <rtcweb@ietf.org>; Thu, 03 Apr 2014 17:14:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MQIC5TeNwAiVQDJX0ul+kLU/M8jMxCWCzj+6gTlPpLI=; b=DNdzFIJQFM+7DaVn9K4zAblE+cMHRuP0pPMieOfXC1TOtBSS36RtTt1Oop3jMmM4wp Fp4gbMkZjMzDcKlOqWvJLSgJTEhWZ/UBTBWg9R/ZoC2Nh0BUsHMMN4WD5wv2u4wQBovP 6B5POT2zJIy2nohnaZUNTQa+m9eMYVeSFX1UoFjcEKwEQCA6I7Nmix7UZrOr1++Vs7k4 /r5/RvNo4/ebL+LUtyi5J181mJhKE+p15hspQlGPIo45gA5omp1mOsv8Q6NcM2c+jZuS Gcwgq3MQwPWyxFm9TRB8LM8qpSYiz0RizJQBFykew5sGvkYCQB4y2w25YM0TCSRFLkiW VcNQ==
MIME-Version: 1.0
X-Received: by 10.60.15.38 with SMTP id u6mr13205867oec.26.1396570459624; Thu, 03 Apr 2014 17:14:19 -0700 (PDT)
Received: by 10.60.118.37 with HTTP; Thu, 3 Apr 2014 17:14:19 -0700 (PDT)
Date: Thu, 03 Apr 2014 17:14:19 -0700
Message-ID: <CABkgnnWWuU63Vd=gw+wrh2ADgVYtQzhoRzRE1sv5azJE=MhWDg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dVoCdDDk2NzXFmVSLYoUg6vNq6E
Subject: [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 00:14:30 -0000

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.