Re: [rtcweb] Tunnelling DTLS in SDP

"Drage, Keith (Nokia - GB)" <> Tue, 05 April 2016 13:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E548E12D923 for <>; Tue, 5 Apr 2016 06:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o2D2DWbVLJuU for <>; Tue, 5 Apr 2016 06:41:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B422912D974 for <>; Tue, 5 Apr 2016 06:41:00 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 938FE87740B7E; Tue, 5 Apr 2016 13:40:56 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id u35DewMm026677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2016 13:40:58 GMT
Received: from ( []) by (GMO) with ESMTP id u35DeQEj016428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Apr 2016 15:40:55 +0200
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 15:40:28 +0200
From: "Drage, Keith (Nokia - GB)" <>
To: EXT Eric Rescorla <>, Harald Alvestrand <>
Thread-Topic: [rtcweb] Tunnelling DTLS in SDP
Date: Tue, 05 Apr 2016 13:40:27 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADEB9E7DFR712WXCHMBA11z_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [rtcweb] Tunnelling DTLS in SDP
X-Mailman-Version: 2.1.17
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: Tue, 05 Apr 2016 13:41:10 -0000

Just to note that when I first saw the draft, I went looking in it for a discussion of this aspect, and failed to find it.

Maybe we could have an update that at least puts that issue in the security considerations.



From: rtcweb [] On Behalf Of EXT Eric Rescorla
Sent: 05 April 2016 13:40
To: Harald Alvestrand
Subject: Re: [rtcweb] Tunnelling DTLS in SDP

On Tue, Apr 5, 2016 at 7:18 AM, Harald Alvestrand <<>> wrote:
On 04/05/2016 12:04 PM, Tim Panton wrote:

On 5 Apr 2016, at 10:53, Harald Alvestrand <<>> wrote:

On first read, this makes sense to me.

I wonder if it could/should be made into a general concept, to fit with the tendency in WebRTC:NG to separate signalling format even more from operation?

We could call it "out of band DTLS setup", say that in general, a DTLS session can be started in one medium (SDP signalling, in this case), and continued in another medium (the DTLS-protected media channel), and have a section describing the details of carrying DTLS-over-SDP.

When viewing it in this way, using the same technique with Jabber or proprietary signalling becomes a reasonably obvious exercise. There are some other twists that seem obvious too - for instance, one could continue the setup over the SDP channel in subsequent offer/answers if the first exchange failed to set up a media channel. I'm not sure that makes sense, though.

One SDP twist: If forking happens, it could be treated like any other attempt to generate multiple answers to a ClientHello, I think. I'm sure it's well defined how to respond to that - it's an obvious attack. Only one leg of the fork would ever succeed, I assume.

Doesn’t passing the DTLS Hellos through javascript open us to a whole pile of bid-down attacks where
the lists of supported crypto suites and extensions are manipulated in the js ? E.G It  might allow the javascript to insert
the magic extension that says "this isn’t being recorded”  without the browser actually being in that mode.
Or is there a way that DTLS can detect this ?

It certainly reduces the setup security from one where only network on-path attackers can do MITM attacks on the handshake to one where everyone with access to the Javascript can do MITM attacks on the handshake.

Well, attackers who control the signaling can put themselves on the network by manipulating the
ICE parameters.

Given that DTLS is supposed to be a reasonable option when you have on-path attackers on the network path, I certainly hope the defenses are adequate in this case too, but I don't know DTLS well enough to be able to say what those defenses are.

However the messages are sent, the handshake is tied to the endpoint keys.



On 04/04/2016 03:10 PM, Eric Rescorla wrote:
Hi folks,

I wanted to call your attention to a draft I just published with a possibly stupid

A nontrivial fraction of call setup time in WebRTC is the DTLS handshake.
This document describes how to piggyback the first few handshake messages
in the SDP offer/answer exchange, thus reducing latency.

Comments welcome.



rtcweb mailing list<>


Surveillance is pervasive. Go Dark.
rtcweb mailing list<>

Tim Panton - Web/VoIP consultant and implementor<>


Surveillance is pervasive. Go Dark.

rtcweb mailing list<>