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

As someone who designed a protocol that overlaps NAT traversal / consent and key agreement, I agree that putting it in the ICE exchange would be beneficial.

Matthew Kaufman

(Sent from my iPhone)

> On 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).
> 
> It also significantly clutters the SDP (even more) !
> 
> As you point out, it weakens the usefulness of longer term certs, which
> would be a major nuisance IMHO.
> 
> Tim.
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic