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

On Mon, 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).
>

I don't think the logging issue applies here. Only the public key would be
logged, and it's already transmitted in cleartext during a normal DTLS
handshake (it's a public key, after all).

>
> It also significantly clutters the SDP (even more) !
>

Please see Jonathan Lennox's comment about garbage piles. I think the only
truly unattractive part here is the fact that the messages will need to be
base64ed, resulting in minor blowup. But that seems like a reasonable
downside for 1+ RTT upside.

> As you point out, it weakens the usefulness of longer term certs, which
> would be a major nuisance IMHO.
>
> Tim.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>