Re: [rtcweb] Tunnelling DTLS in SDP

pfh <tim@phonefromhere.com> Mon, 04 April 2016 16:15 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 A3C2912D0E7 for <rtcweb@ietfa.amsl.com>; Mon, 4 Apr 2016 09:15:06 -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 nd09p9nRi5bg for <rtcweb@ietfa.amsl.com>; Mon, 4 Apr 2016 09:15:05 -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 6DFD412D18B for <rtcweb@ietf.org>; Mon, 4 Apr 2016 09:15:04 -0700 (PDT)
Received: (qmail 14689 invoked from network); 4 Apr 2016 16:15:02 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769/0 10215
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 4 Apr 2016 16:15:02 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id A27FF18A06B9; Mon, 4 Apr 2016 17:14:56 +0100 (BST)
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 9450F18A06CD; Mon, 4 Apr 2016 17:14:56 +0100 (BST)
Received: from [192.67.4.155] (unknown [192.67.4.155]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7207018A06B9; Mon, 4 Apr 2016 17:14:56 +0100 (BST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CBA730B1-49D0-4F83-ADCE-6D47B641E939"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: pfh <tim@phonefromhere.com>
In-Reply-To: <CAD5OKxtaw3P-csYvxSsqK6_BD6AywTkK7hCc-04APa7ib2Ea1Q@mail.gmail.com>
Date: Mon, 04 Apr 2016 17:14:56 +0100
Message-Id: <87A18530-F6C8-4960-A5B8-215B677E5913@phonefromhere.com>
References: <CABcZeBOM1KoXpXFhvjS753EVpsMENWVen3CCdFj8ry36vPH0dg@mail.gmail.com> <CAD5OKxtaw3P-csYvxSsqK6_BD6AywTkK7hCc-04APa7ib2Ea1Q@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/FdIKw2ITTngNVRV-UaFdCohorxQ>
Cc: "rtcweb@ietf.org" <rtcweb@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 16:15:06 -0000

> On 4 Apr 2016, at 16:52, Roman Shpount <roman@telurix.com> wrote:
> 
> 
> I think sending certificate in the answer instead of data path does not compromise security since if signaling path is compromised, data traffic can be redirected to MITM agent which can collect exactly the same data.

That isn’t quite the same, currently in a MITM’d scenario you have the option of not completing the DTLS handshake (assuming you had a way
to verify the fingerprints.). With this change you’ll have all the certs logged in a web server somewhere.

> 
> This has the benefit over sending DTLS handshake using ICE/STUN messages that it does not need to deal with packet fragmentation and reassembly.

DTLS does have support for packet assembly/disassembly. I’d be surprised if the DTLS handshake packets exceeded a reasonable MTU,
unless you are sending a full chain of certificates or stuffing a logo into the x509 :-) 

Stepping back from the detail, (D)TLS implementations are brittle enough as it is, we should avoid introducing a whole new level
of complexity if we can. Implementing this piggybacking in ICE at least keeps it in the media path, rather than spreading it through the
signalling and web servers too.

T.


> 
> Regards,
> _____________
> Roman Shpount
> 
> On Mon, Apr 4, 2016 at 9:10 AM, 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.
> 
> Comments welcome.
> 
> -Ekr
> 
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb