Subject: [rtcweb] 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: pfh <[email-masked]>
Date: Mon, 4 Apr 2016 16:39:03 +0100

> On 4 Apr 2016, at 14:10, Eric Rescorla <[email-masked]> 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 <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).

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.

---

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:

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

---

From: pfh <[email-masked]>
Date: Mon, 4 Apr 2016 17:14:56 +0100

> On 4 Apr 2016, at 16:52, Roman Shpount <[email-masked]> wrote:
> 
> 
> 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.

That isn’t quite the same, currently in a MITM’d scenario you have the option of not completing the DTLS handshake (assuming you had a way
to verify the fingerprints.). With this change you’ll have all the certs logged in a web server somewhere.

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

DTLS does have support for packet assembly/disassembly. I’d be surprised if the DTLS handshake packets exceeded a reasonable MTU,
unless you are sending a full chain of certificates or stuffing a logo into the x509 :-) 

Stepping back from the detail, (D)TLS implementations are brittle enough as it is, we should avoid introducing a whole new level
of complexity if we can. Implementing this piggybacking in ICE at least keeps it in the media path, rather than spreading it through the
signalling and web servers too.

T.

> 
> Regards,
> _____________
> Roman Shpount
> 
> On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> Hi folks,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 4 Apr 2016 12:47:26 -0400

On Mon, Apr 4, 2016 at 12:14 PM, pfh <[email-masked]> wrote:

> That isn’t quite the same, currently in a MITM’d scenario you have the
> option of not completing the DTLS handshake (assuming you had a way

In the scenario I had in mind MTIM will not modify fingerprints, it will
modify the transport addresses or put itself on the media path using a
compromised router so that it can log the DTLS handshake (and subsequent
media). This will provide exactly the same security risk as logging
signaling exchange when certificate is sent in the signaling path. In order
to compromise media, attacker needs access to the media path. Once it gets
access to the media path, it gets access to DTLS handshake and
certificates. If one of those certificates is sent over signaling channel,
it does not make the whole flow any less secure. Actually you might argue
it makes it more secure, since now attacker needs to compromise both media
and signaling paths in order to decode.
_____________
Roman Shpount

---

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

> rather than SDP, e.g. embedding the DTLS packet as data in a new STUN

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

---

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

On 4 April 2016 at 13:14, pfh <[email-masked]> wrote:
> I’d be surprised if the DTLS handshake packets exceeded a reasonable MTU,

Fragmentation is common.

---

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,

Comments welcome.

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 4 Apr 2016 22:42:07 +0200

On 04/04/2016 05:39 PM, pfh wrote:
>
>> On 4 Apr 2016, at 14:10, Eric Rescorla <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Hi folks,
>>

Piggybacking in ICE means that you have to repeat it in every probe
packet, since you don't know which is going to make it through.

And you can't start ICE probing until the handshake has completed.

---

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

> media. (The SDES issues of logging keys in the web servers apply to the

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.

---

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.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 5 Apr 2016 11:53:57 +0200

On first read, this makes sense to me.

I wonder if it could/should be made into a general concept, to fit with
the tendency in WebRTC:NG to separate signalling format even more from
operation?

We could call it "out of band DTLS setup", say that in general, a DTLS
session can be started in one medium (SDP signalling, in this case), and
continued in another medium (the DTLS-protected media channel), and have
a section describing the details of carrying DTLS-over-SDP.

When viewing it in this way, using the same technique with Jabber or
proprietary signalling becomes a reasonably obvious exercise. There are
some other twists that seem obvious too - for instance, one could
continue the setup over the SDP channel in subsequent offer/answers if
the first exchange failed to set up a media channel. I'm not sure that
makes sense, though.

One SDP twist: If forking happens, it could be treated like any other
attempt to generate multiple answers to a ClientHello, I think. I'm sure
it's well defined how to respond to that - it's an obvious attack. Only
one leg of the fork would ever succeed, I assume.

-- 
Surveillance is pervasive. Go Dark.

---

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: Tim Panton <[email-masked]>
Date: Tue, 5 Apr 2016 11:04:20 +0100

> On 5 Apr 2016, at 10:53, Harald Alvestrand <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I wonder if it could/should be made into a general concept, to fit with the tendency in WebRTC:NG to separate signalling format even more from operation?
> 
> We could call it "out of band DTLS setup", say that in general, a DTLS session can be started in one medium (SDP signalling, in this case), and continued in another medium (the DTLS-protected media channel), and have a section describing the details of carrying DTLS-over-SDP.
> 
> When viewing it in this way, using the same technique with Jabber or proprietary signalling becomes a reasonably obvious exercise. There are some other twists that seem obvious too - for instance, one could continue the setup over the SDP channel in subsequent offer/answers if the first exchange failed to set up a media channel. I'm not sure that makes sense, though.
> 
> One SDP twist: If forking happens, it could be treated like any other attempt to generate multiple answers to a ClientHello, I think. I'm sure it's well defined how to respond to that - it's an obvious attack. Only one leg of the fork would ever succeed, I assume.

Doesn’t passing the DTLS Hellos through javascript open us to a whole pile of bid-down attacks where
the lists of supported crypto suites and extensions are manipulated in the js ? E.G It  might allow the javascript to insert 
the magic extension that says "this isn’t being recorded”  without the browser actually being in that mode. 
Or is there a way that DTLS can detect this ?

T.

>> in the SDP offer/answer exchange, thus reducing latency.

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk <http://www.westhawk.co.uk/>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 5 Apr 2016 12:18:21 +0200

On 04/05/2016 12:04 PM, Tim Panton wrote:
>> I wonder if it could/should be made into a general concept, to fit
>> with the tendency in WebRTC:NG to separate signalling format even
>> more from operation?
>>
>> We could call it "out of band DTLS setup", say that in general, a
>> DTLS session can be started in one medium (SDP signalling, in this
>> case), and continued in another medium (the DTLS-protected media
>> channel), and have a section describing the details of carrying
>> DTLS-over-SDP.
>>
>> proprietary signalling becomes a reasonably obvious exercise. There
>> are some other twists that seem obvious too - for instance, one could
>> continue the setup over the SDP channel in subsequent offer/answers
>> if the first exchange failed to set up a media channel. I'm not sure
>> that makes sense, though.
>>
>> attempt to generate multiple answers to a ClientHello, I think. I'm
>> sure it's well defined how to respond to that - it's an obvious
>> attack. Only one leg of the fork would ever succeed, I assume.
>
> the lists of supported crypto suites and extensions are manipulated in
> the js ? E.G It  might allow the javascript to insert 

It certainly reduces the setup security from one where only network
on-path attackers can do MITM attacks on the handshake to one where
everyone with access to the Javascript can do MITM attacks on the handshake.

Given that DTLS is supposed to be a reasonable option when you have
on-path attackers on the network path, I certainly hope the defenses are
adequate in this case too, but I don't know DTLS well enough to be able
to say what those defenses are.

> www.westhawk.co.uk <http://www.westhawk.co.uk>
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Apr 2016 09:39:36 -0300

On Tue, Apr 5, 2016 at 7:18 AM, Harald Alvestrand <[email-masked]>
wrote:

> On 5 Apr 2016, at 10:53, Harald Alvestrand < <[email-masked]>
> [email-masked]> wrote:
>
> continued in another medium (the DTLS-protected media channel), and have a
> section describing the details of carrying DTLS-over-SDP.
>
> some other twists that seem obvious too - for instance, one could continue
> the setup over the SDP channel in subsequent offer/answers if the first
> exchange failed to set up a media channel. I'm not sure that makes sense,
> though.
>
> it's well defined how to respond to that - it's an obvious attack. Only one
> leg of the fork would ever succeed, I assume.
>
>
> the lists of supported crypto suites and extensions are manipulated in the
> js ? E.G It  might allow the javascript to insert

Well, attackers who control the signaling can put themselves on the network
by manipulating the
ICE parameters.

> adequate in this case too, but I don't know DTLS well enough to be able to
> say what those defenses are.
>

However the messages are sent, the handshake is tied to the endpoint keys.

-Ekr

> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --
> www.westhawk.co.uk

---

From: Roman Shpount <[email-masked]>
Date: Tue, 5 Apr 2016 09:21:16 -0400

> leg of the fork would ever succeed, I assume.

The biggest issue with reusing ClientHello in case of forking would be
reusing client random across multiple connections. Unless I am missing
something, this should be generally safe.

Another issue is what will happen if two DTLS association are established
for a single m= line (i.e. RTCP bundle is not used). Does this mean the
same ClientHello is used for both connection?

Regards,
_____________
Roman Shpount

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 5 Apr 2016 13:40:27 +0000

Just to note that when I first saw the draft, I went looking in it for a discussion of this aspect, and failed to find it.

Maybe we could have an update that at least puts that issue in the security considerations.

Regards

Keith

From: rtcweb [mailto:[email-masked]] On Behalf Of EXT Eric Rescorla
Sent: 05 April 2016 13:40
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] Tunnelling DTLS in SDP

On Tue, Apr 5, 2016 at 7:18 AM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
On 04/05/2016 12:04 PM, Tim Panton wrote:

On 5 Apr 2016, at 10:53, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:

It certainly reduces the setup security from one where only network on-path attackers can do MITM attacks on the handshake to one where everyone with access to the Javascript can do MITM attacks on the handshake.

Well, attackers who control the signaling can put themselves on the network by manipulating the
ICE parameters.

Given that DTLS is supposed to be a reasonable option when you have on-path attackers on the network path, I certainly hope the defenses are adequate in this case too, but I don't know DTLS well enough to be able to say what those defenses are.

-Ekr

T.

Comments welcome.

-Ekr

rtcweb mailing list

[email-masked]<mailto:[email-masked]>

--

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

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk<http://www.westhawk.co.uk>

--

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

---

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: Peter Thatcher <[email-masked]>
Date: Thu, 7 Apr 2016 08:07:10 -0700

> exchange failed to set up a media channel. I'm not sure that makes sense,

In ORTC language, we could simply have an event on the DtlsTransport that
is something like .onpacket and another that's .addpacket, and when the
transport wants to send a packet, it lets the JS know so it can do so over
the signalling path, and then the JS can take care of optimizing it (or
not).

---

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