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

Matthew Kaufman <matthew@matthew.at> Tue, 05 April 2016 03:41 UTC

Return-Path: <matthew@matthew.at>
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 6DB5612D0FD; Mon, 4 Apr 2016 20:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=unavailable 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 tTC7yeCSWQUQ; Mon, 4 Apr 2016 20:41:43 -0700 (PDT)
Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id 31EAB12D648; Mon, 4 Apr 2016 20:34:42 -0700 (PDT)
Received: from [10.10.155.209] (unknown [10.10.155.209]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id 185DE5C73E8; Mon, 4 Apr 2016 20:34:42 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-3EBB4CF7-A937-4D7B-B1B4-9F27D17AEBAA
Mime-Version: 1.0 (1.0)
From: Matthew Kaufman <matthew@matthew.at>
X-Mailer: iPhone Mail (13E234)
In-Reply-To: <D5416C24-0032-48CB-8CC6-FD5D4E046C0D@phonefromhere.com>
Date: Mon, 4 Apr 2016 20:34:41 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <F2080E80-ECB4-43DE-A4F2-1C6E1A155295@matthew.at>
References: <CABcZeBOM1KoXpXFhvjS753EVpsMENWVen3CCdFj8ry36vPH0dg@mail.gmail.com> <D5416C24-0032-48CB-8CC6-FD5D4E046C0D@phonefromhere.com>
To: pfh <tim@phonefromhere.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/aoHtB_3MOxkR3jl-WMh3iafEdGY>
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 03:41:44 -0000

As someone who designed a protocol that overlaps NAT traversal / consent and key agreement, I agree that putting it in the ICE exchange would be beneficial.

Matthew Kaufman

(Sent from my iPhone)

> On Apr 4, 2016, at 8:39 AM, pfh <tim@phonefromhere.com> wrote:
> 
> 
>> 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
>> 
>> 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.
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic