Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP

Tim Panton <tim@phonefromhere.com> Tue, 05 April 2016 09:52 UTC

Return-Path: <tim@phonefromhere.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9252212D140 for <mmusic@ietfa.amsl.com>; Tue, 5 Apr 2016 02:52:14 -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 HclHXoXCLIGx for <mmusic@ietfa.amsl.com>; Tue, 5 Apr 2016 02:52:12 -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 127EA12D10B for <mmusic@ietf.org>; Tue, 5 Apr 2016 02:52:11 -0700 (PDT)
Received: (qmail 54324 invoked from network); 5 Apr 2016 09:52:10 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769/0 3177
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 5 Apr 2016 09:52:10 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 014B418A00F5; Tue, 5 Apr 2016 10:52:10 +0100 (BST)
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id E464A18A0727; Tue, 5 Apr 2016 10:52:09 +0100 (BST)
Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id BE15518A00F5; Tue, 5 Apr 2016 10:52:09 +0100 (BST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_73971B90-CF02-43F3-83D4-3475486FCF6D"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <CAOJ7v-3pov_NC0b8wkNyvfxHTG934RW-QnLRSQ0TzmpU3LvawA@mail.gmail.com>
Date: Tue, 05 Apr 2016 10:52:09 +0100
Message-Id: <F11EA410-2086-442A-8519-BE77A421E938@phonefromhere.com>
References: <CABcZeBOM1KoXpXFhvjS753EVpsMENWVen3CCdFj8ry36vPH0dg@mail.gmail.com> <D5416C24-0032-48CB-8CC6-FD5D4E046C0D@phonefromhere.com> <CAOJ7v-3pov_NC0b8wkNyvfxHTG934RW-QnLRSQ0TzmpU3LvawA@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/fsdm7WIGwtheZ-tYIQZD818HHjQ>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2016 09:52:14 -0000

> On 5 Apr 2016, at 03:06, Justin Uberti <juberti@google.com> wrote:
> 
> 
> 
> On Mon, Apr 4, 2016 at 8:39 AM, pfh <tim@phonefromhere.com <mailto:tim@phonefromhere.com>> wrote:
> 
>> On 4 Apr 2016, at 14:10, Eric Rescorla <ekr@rtfm.com <mailto: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).
> 
> I don't think the logging issue applies here. Only the public key would be logged, and it's already transmitted in cleartext during a normal DTLS handshake (it's a public key, after all). 

True, but over a different path. 

> 
> It also significantly clutters the SDP (even more) !
> 
> Please see Jonathan Lennox's comment about garbage piles. I think the only truly unattractive part here is the fact that the messages will need to be base64ed, resulting in minor blowup. But that seems like a reasonable downside for 1+ RTT upside.

Just when the WebRTC NG was freeing us from Offer/Answer and SDP….

Sigh.


> 
> 
> As you point out, it weakens the usefulness of longer term certs, which
> would be a major nuisance IMHO.
> 
> Tim.
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
>