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

> On 11 Jul 2016, at 17:19, Roman Shpount <roman@telurix.com> wrote:
> 
> I would definitely like to proceed with this. There are certain issues related to forking and new associations being setup by the answering party, but I think they are resolvable. On the other hand, the benefits of reduced call setup up time definitely make this worthwhile.

As I said (remotely) at the last meeting,  
I am distinctly _unkeen_ on the aesthetics of this - it ties us to ever uglier and larger SDP, it breaks software layer separation in the stacks, 
it will no doubt presume a single DTLS implementation, it will be _fun_ to test, and I anticipate it will open some ugly attack vectors
to the javascript kiddies. 

Last I heard EKR was going to experiment with it and come back with a view on how (in)accurate my doom-saying was. 
I haven't heard the reply...

- If folks want a corridor conversation about this next week in Berlin, I'll be there.

T.

> 
> _____________
> Roman Shpount
> 
> On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings <fluffy@cisco.com <mailto:fluffy@cisco.com>> wrote:
> 
> Quick questions for folks …  is an idea that we should explore a bit deeper before making decisions about it? or should we not proceed? or should we proceed? Just looking for feedback on where this should go next 
> 
> Thanks, Cullen
> 
> 
>> On Apr 18, 2016, at 7:59 AM, Roman Shpount <roman@telurix.com <mailto:roman@telurix.com>> wrote:
>> 
>> On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote:
>> 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 <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.
>> 
>> 
>> One other issue I thought off was that with DTLS SDP either offerer or answerer can start a new DTLS association. When answerer starts a new session it will have exactly the same problems as forking, since this will create multiple DTLS sessions with the same client random. This can be solved with some sort of fallback mechanism to either regular DTLS setup or to sending a ClientHello in the answer.
>> 
>> Regards,
>> _____________
>> Roman Shpount
>>  
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org <mailto:mmusic@ietf.org>
> https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>