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

Bernard Aboba <bernard.aboba@gmail.com> Mon, 07 April 2014 18:01 UTC

Return-Path: <bernard.aboba@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 4A0F01A082F for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 11:01:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 GguWhoY8c3Fz for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 11:01:17 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2AA1A081E for <rtcweb@ietf.org>; Mon, 7 Apr 2014 11:01:10 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id d1so5591296wiv.7 for <rtcweb@ietf.org>; Mon, 07 Apr 2014 11:01:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=84/Qm7KfjasCa8AdFjhvDWfd2DHHXVPlhL8VJ/T+YnE=; b=Ph8vfk/uPHlK5jMsJMaHYb/EzNHfttBV2IWSLnCEgbrldVae2EAss/Jj2ockezsqpH xl9S2Nq6cOrt8jacsPzCYUo8rEQ1klKrAY1Sc6vuwQqMITXG5TgkxwykQhtGv99zkXY4 3i6jiE/+5IG4bCrTAiLnwEzDv2UlMIwooVvIDrCkgTTF9Zuf/RREUF1l0uVuoIaMlxx8 87WxulrTo7whMoGy+XiC46d/t6Qfv+F1ptNAXt26GH9OLBMr90vVnO0ii38cpzs3cojE HMc+tv1rUpupkWT6AYn8WwZmiFW4LqJJiAhLcOIB1Wdfb3JDp+fD8YI3HUrYKC4UN6bc XVuA==
X-Received: by 10.194.174.42 with SMTP id bp10mr43635038wjc.57.1396893664494; Mon, 07 Apr 2014 11:01:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.102.130 with HTTP; Mon, 7 Apr 2014 11:00:43 -0700 (PDT)
In-Reply-To: <CABkgnnUov2o+-NDL1Qcm_hVtOrvhuf=bM+drQdD+bWzFLK+DOw@mail.gmail.com>
References: <CABkgnnWWuU63Vd=gw+wrh2ADgVYtQzhoRzRE1sv5azJE=MhWDg@mail.gmail.com> <CACsn0cmX55Eewak8GBxBbSFF3v7tRTVqRt0eLwkR2-Tk_V7gHA@mail.gmail.com> <CAOW+2dtKq4S68rNJAKbKbwMEnuD8rMbW4K_LfcjPBg5ps22BGw@mail.gmail.com> <CACsn0cnJcwjcn8GV1bv4z3=b6RTXKQ1X02Sj6ec-jNmrO9G=bg@mail.gmail.com> <CABkgnnUov2o+-NDL1Qcm_hVtOrvhuf=bM+drQdD+bWzFLK+DOw@mail.gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 7 Apr 2014 11:00:43 -0700
Message-ID: <CAOW+2dvagpWtbZ2PF1MvLfk8YSkph_A9G6BJ_1KxvRggHGub3w@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=089e01493cb4a94dd404f677a65f
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cB39fVFe85-emEumLFMDMLHyqvo
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: Mon, 07 Apr 2014 18:01:23 -0000

Martin said:

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

[BA] Agreed.  To be clear, the "marked session" we are talking about is the
DTLS session.  All DTLS/SRTP sessions subsequently occurring within that
DTLS marked session inherit the "isolation" property, correct?

The implication here is that not only do media sharing the same DTLS
session (e.g. audio and video multiplexed on the same port) share the
"isolation" property, but even if audio and video are not multiplexed, if
the same DTLS session is used by subsequent DTLS/SRTP sessions, then the
"isolation" property is also shared.

>From RFC 5764, Section 3:

   RTP and RTCP traffic MAY be multiplexed on a single UDP port
   [RFC5761 <http://tools.ietf.org/html/rfc5761>].  In this case, both
RTP and RTCP packets may be sent over
   the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions
   needed.  This improves the cryptographic performance of DTLS, but may
   cause problems when RTCP and RTP are subject to different network
   treatment (e.g., for bandwidth reservation or scheduling reasons).

   Between a single pair of participants, there may be multiple media
   sessions.  There MUST be a separate DTLS-SRTP session for each
   distinct pair of source and destination ports used by a media session
   (though the sessions can share a single DTLS session and hence
   amortize the initial public key handshake!).







On Thu, Apr 3, 2014 at 8:25 PM, Martin Thomson <martin.thomson@gmail.com>wrote;wrote:

> 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 <watsonbladd@gmail.com> 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.
>