Subject: [MMUSIC] Tunnelling DTLS in SDP

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Apr 2016 10:10:46 -0300

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 4 Apr 2016 11:52:48 -0400

The proposal makes sense to me.

1. Why do you need to send both fingerprints and certificates in answer? If
certificate is sent, fingerprint can be calculated from it and will be
completely redundant.

2. Can you show where and how the DTLS-SRTP keys are going to be sent? I
assume they will be transmitted together with ChangeCipherSpec.

I think sending certificate in the answer instead of data path does not
compromise security since if signaling path is compromised, data traffic
can be redirected to MITM agent which can collect exactly the same data.

This has the benefit over sending DTLS handshake using ICE/STUN messages
that it does not need to deal with packet fragmentation and reassembly.

Regards,
_____________
Roman Shpount

On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla <[email-masked]> wrote:

> Hi folks,
>
> I wanted to call your attention to a draft I just published with a
> possibly stupid
> idea.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Apr 2016 14:34:29 -0300

On 4 April 2016 at 12:39, pfh <[email-masked]> wrote:
> 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.

One of the goals for connectivity checks is to keep them small.
Cramming DTLS in is not compatible with this.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Apr 2016 18:02:32 +0000

Hi,

Regarding forking, you cannot assume that forking entities will remove the SDP attribute. Unless they support the attribute, they will most likely just forward it. The offerer will find out if forking has occurred, but he answerer(s) will not know.

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: 04 April 2016 16:11
To: mmusic WG <[email-masked]>; [email-masked]
Subject: [rtcweb] Tunnelling DTLS in SDP

Hi folks,

I wanted to call your attention to a draft I just published with a possibly stupid
idea.

Comments welcome.

-Ekr

---

From: Justin Uberti <[email-masked]>
Date: Mon, 4 Apr 2016 19:06:50 -0700

On Mon, Apr 4, 2016 at 8:39 AM, pfh <[email-masked]> wrote:

>
> On 4 Apr 2016, at 14:10, Eric Rescorla <[email-masked]> wrote:
>
> Hi folks,
>
> It strikes me we could get the same reduced latency benefits by
> piggybacking on ICE
> 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.
>
>

---

From: pfh <[email-masked]>
Date: Mon, 4 Apr 2016 16:39:03 +0100

> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 <https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00>
> 

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).

Tim.

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 4 Apr 2016 20:34:41 -0700

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 <[email-masked]> wrote:
> 
> 
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Tim Panton <[email-masked]>
Date: Tue, 5 Apr 2016 10:52:09 +0100

> On 5 Apr 2016, at 03:06, Justin Uberti <[email-masked]> wrote:
> 
> 
> 
> On Mon, Apr 4, 2016 at 8:39 AM, pfh <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On 4 Apr 2016, at 14:10, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi folks,
>> 
> 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). 

True, but over a different path. 

> 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.

Just when the WebRTC NG was freeing us from Offer/Answer and SDP….

Sigh.

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

---

From: Tim Panton <[email-masked]>
Date: Tue, 5 Apr 2016 10:58:24 +0100

> On 4 Apr 2016, at 18:34, Martin Thomson <[email-masked]> wrote:
> 

It wouldn’t be in every ICE packet, just in ones with (say) USE-CANDIDATE set.

T.

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 7 Apr 2016 08:03:02 -0700

> Just when the WebRTC NG was freeing us from Offer/Answer and SDP….
​The general idea here is "put the beginning of the crypto handshake in the
signaling"​.  That's not tied to SDP.  WebRTC NG could easily do the same
thing without SDP.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 18 Apr 2016 10:59:56 -0400

> in the SDP offer/answer exchange, thus reducing latency.
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