Re: [rtcweb] Tunnelling DTLS in SDP

On Tue, Apr 5, 2016 at 7:18 AM, Harald Alvestrand <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>
> 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 listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --
> Surveillance is pervasive. Go Dark.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> Tim Panton - Web/VoIP consultant and implementor
> www.westhawk.co.uk
>
>
>
>
>
> --
> Surveillance is pervasive. Go Dark.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>