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

From: Cullen Jennings <[email-masked]>
Date: Mon, 11 Jul 2016 08:22:18 -0400

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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Roman Shpount <[email-masked]>
Date: Mon, 11 Jul 2016 12:19:10 -0400

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.

_____________
Roman Shpount

On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings <[email-masked]> 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 <[email-masked]> wrote:
>
> On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla <[email-masked]> wrote:
>
>> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00
>>
> 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
>
> [email-masked]
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: T H Panton <[email-masked]>
Date: Mon, 11 Jul 2016 17:33:23 +0100

> On 11 Jul 2016, at 17:19, Roman Shpount <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
> 
> 
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jul 2016 16:58:54 +0000

Hi,

All I'll say at this point is that you cannot assume that forking entities will remove the attribute. You either need to have a fallback procedure in case of forking, or say that the mechanism MUST NOT be used in environments where forking can occur (which makes the mechanism more or less useless in virtually all SIP environments).

Regards,

Christer

Sent from my Windows Phone
________________________________
From: T H Panton<mailto:[email-masked]>
Sent: ‎11/‎07/‎2016 19:33
To: Roman Shpount<mailto:[email-masked]>
Cc: Cullen Jennings<mailto:[email-masked]>; RTCWeb IETF<mailto:[email-masked]>; mmusic WG<mailto:[email-masked]>
Subject: Re: [MMUSIC] [rtcweb]   Tunnelling DTLS in SDP

On 11 Jul 2016, at 17:19, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

T.

_____________
Roman Shpount

On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings <[email-masked]<mailto:[email-masked]>> wrote:

Thanks, Cullen

On Apr 18, 2016, at 7:59 AM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
I wanted to call your attention to a draft I just published with a possibly stupid
idea.

Comments welcome.

Regards,
_____________
Roman Shpount

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 11 Jul 2016 19:11:34 +0200

2016-07-11 18:58 GMT+02:00 Christer Holmberg <[email-masked]>:
> All I'll say at this point is that you cannot assume that forking entities
> will remove the attribute. You either need to have a fallback procedure in
> case of forking, or say that the mechanism MUST NOT be used in environments
> where forking can occur (which makes the mechanism more or less useless in
> virtually all SIP environments).

SIP devices can just ignore this spec like if it was Outbound or GRUU.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Jul 2016 15:40:40 -0700

On Mon, Jul 11, 2016 at 9:33 AM, T H Panton <[email-masked]> wrote:

> 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

> I haven't heard the reply...

We're working on an implementation now but it took a while to divert the
staff.

-Ekr