IETF Logo Mail Archive

Re: [rtcweb] Tunnelling DTLS in SDP

pfh <tim@phonefromhere.com> Mon, 04 April 2016 15:39 UTC

Return-Path: <tim@phonefromhere.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAFE12D5A7 for <rtcweb@ietfa.amsl.com>; Mon, 4 Apr 2016 08:39:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 3Qr4gF1hsJtd for <rtcweb@ietfa.amsl.com>; Mon, 4 Apr 2016 08:39:09 -0700 (PDT)
Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BBAA12D5A0 for <rtcweb@ietf.org>; Mon, 4 Apr 2016 08:39:09 -0700 (PDT)
Received: (qmail 54293 invoked from network); 4 Apr 2016 15:39:07 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769/0 9605
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 4 Apr 2016 15:39:07 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 0884D18A05A7; Mon, 4 Apr 2016 16:39:04 +0100 (BST)
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id EE56C18A06CD; Mon, 4 Apr 2016 16:39:03 +0100 (BST)
Received: from [192.67.4.155] (unknown [192.67.4.155]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id C66F018A05A7; Mon, 4 Apr 2016 16:39:03 +0100 (BST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C9F1BDF5-1050-464A-9585-99CC41E96A78"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: pfh <tim@phonefromhere.com>
In-Reply-To: <CABcZeBOM1KoXpXFhvjS753EVpsMENWVen3CCdFj8ry36vPH0dg@mail.gmail.com>
Date: Mon, 04 Apr 2016 16:39:03 +0100
Message-Id: <D5416C24-0032-48CB-8CC6-FD5D4E046C0D@phonefromhere.com>
References: <CABcZeBOM1KoXpXFhvjS753EVpsMENWVen3CCdFj8ry36vPH0dg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/iposHO9RmP7qzFrARn_WtTogLGs>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Subject: Re: [rtcweb] Tunnelling DTLS in SDP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 04 Apr 2016 15:39:12 -0000

> On 4 Apr 2016, at 14:10, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> Hi folks,
> 
> I wanted to call your attention to a draft I just published with a possibly stupid
> idea.
> 
> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 <https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00>
> 
> 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.

It strikes me we could get the same reduced latency benefits by piggybacking on ICE
rather than SDP, e.g. embedding the DTLS packet as data in a new STUN attribute type.

The downside of piggybacking on the SDP is that you are increasing the trust you have to place in the
signalling server undermining the elegant decoupling we have at the moment between signalling and 
media. (The SDES issues of logging keys in the web servers apply to the public certs as well).

It also significantly clutters the SDP (even more) !

As you point out, it weakens the usefulness of longer term certs, which
would be a major nuisance IMHO.

Tim.

v2.23.0 | Report a Bug | By Email