Re: [rtcweb] Tunnelling DTLS in SDP

Just to note that when I first saw the draft, I went looking in it for a discussion of this aspect, and failed to find it.

Maybe we could have an update that at least puts that issue in the security considerations.

Regards

Keith

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of EXT Eric Rescorla
Sent: 05 April 2016 13:40
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Tunnelling DTLS in SDP

On Tue, Apr 5, 2016 at 7:18 AM, Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>> wrote:
On 04/05/2016 12:04 PM, Tim Panton wrote:

On 5 Apr 2016, at 10:53, Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>> wrote:

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 operation?

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.

Doesn’t passing the DTLS Hellos through javascript open us to a whole pile of bid-down attacks where
the lists of supported crypto suites and extensions are manipulated in the js ? E.G It  might allow the javascript to insert
the magic extension that says "this isn’t being recorded”  without the browser actually being in that mode.
Or is there a way that DTLS can detect this ?

It certainly reduces the setup security from one where only network on-path attackers can do MITM attacks on the handshake to one where everyone with access to the Javascript can do MITM attacks on the handshake.

Well, attackers who control the signaling can put themselves on the network by manipulating the
ICE parameters.

Given that DTLS is supposed to be a reasonable option when you have on-path attackers on the network path, I certainly hope the defenses are adequate in this case too, but I don't know DTLS well enough to be able to say what those defenses are.

However the messages are sent, the handshake is tied to the endpoint keys.

-Ekr

T.

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.

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

--

Surveillance is pervasive. Go Dark.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk<http://www.westhawk.co.uk>

--

Surveillance is pervasive. Go Dark.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb