Re: [rtcweb] Tunnelling DTLS in SDP

Harald Alvestrand <> Tue, 05 April 2016 09:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B49912D140 for <>; Tue, 5 Apr 2016 02:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x7BYXRuPP9BX for <>; Tue, 5 Apr 2016 02:54:06 -0700 (PDT)
Received: from ( [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 721A512D17F for <>; Tue, 5 Apr 2016 02:54:06 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3E627C7C0B for <>; Tue, 5 Apr 2016 11:54:04 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RGVX8vbnH0Zp for <>; Tue, 5 Apr 2016 11:54:03 +0200 (CEST)
Received: from [IPv6:2001:67c:370:136:2154:8066:f6ed:c7f7] (unknown [IPv6:2001:67c:370:136:2154:8066:f6ed:c7f7]) by (Postfix) with ESMTPSA id 23A1A7C7C03 for <>; Tue, 5 Apr 2016 11:54:02 +0200 (CEST)
References: <>
From: Harald Alvestrand <>
Message-ID: <>
Date: Tue, 05 Apr 2016 11:53:57 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------000008020101080200000803"
Archived-At: <>
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 09:54:09 -0000

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

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.

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
> idea.
> 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.
> -Ekr
> _______________________________________________
> rtcweb mailing list

Surveillance is pervasive. Go Dark.