Re: [rtcweb] Tunnelling DTLS in SDP

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.

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
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Surveillance is pervasive. Go Dark.