Re: [rtcweb] Tunnelling DTLS in SDP

[Harald Alvestrand <[e-mail]>]

On 04/05/2016 12:04 PM, Tim Panton wrote:
>
>> On 5 Apr 2016, at 10:53, Harald Alvestrand <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>> 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.
>
> 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 ?

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.

>
> T.
>
>
>
>>
>>
>> On 04/04/2016 03:10 PM, Eric Rescorla 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.
>>>
>>> Comments welcome.
>>>
>>> -Ekr
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>> -- 
>> Surveillance is pervasive. Go Dark.
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
> Tim Panton - Web/VoIP consultant and implementor
> www.westhawk.co.uk <http://www.westhawk.co.uk>
>
>
>


-- 
Surveillance is pervasive. Go Dark.