Re: [rtcweb] Resolving RTP/SDES question in Paris

["Ravindran, Parthasarathi" <[e-mail]>]

Adding one another issue faced in SRTP-DTLS implementation (http://www.ietf.org/mail-archive/web/siprec/current/msg03199.html).

Including Leon in this mail thread for more info. 

Thanks
Partha 

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf
>Of Iñaki Baz Castillo
>Sent: Tuesday, March 20, 2012 7:46 PM
>To: Roman Shpount
>Cc: [e-mail]
>Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
>
>2012/3/20 Roman Shpount <[e-mail]>:
>> The other proposal was not to use DTLS at all, since it is an overkill
>> both complexity and feature wise. DTLS is designed the way it is
>> primarily to extend TLS to UDP. DTLS-SRTP is a bolt on of SRTP into
>> DTLS. So we actually got a protocol twice reused with design goals
>> changing dramatically in the process. The desired attribute of
>> DTLS-SRTP is that encryption keys are not transmitted in clear text.
>> The rest (security handshake separated from signaling and ICE
>> handshake, support for data encryption schemes other then SRTP,
>support for certificate validation, etc) is actually just a liability.
>> All of those things imply slower setup and interop problems. So, my
>> second proposal was not to use DTLS at all, just include the public
>> keys for supported key exchange protocols in the SDP and send the
>> encrypted SRTP private key in the ICE message. Or something similar to
>> that. This will definitely not interop with DTLS, but will make
>> implementation of encryption very simple.
>
>So that proposal would modify even ICE protocol, am I right? Too much
>dramatic IMHO :)
>
>Ok, given the fact that DTLS is still an utopia (all the people know
>about it but it seems that nobody has seen it in action), why not to
>leave it for a future version of WebRTC and go now with SDES + encrypted
>signaling path? In this way:
>
>- We get interoperability with other technologies *already* implementing
>SDES+SRTP (so ***tested***).
>
>- DTLS can be added once it's mature/tested/widely-implemented and we
>can learn from other implementations (what do they implement, interop
>problems, bugs...?).
>
>- Adding DTLS later to WebRTC does not break nothing since its usage
>would be still negotiable during the session initiation.
>
>
>Yes, I do know that SDES+SRTP is not the best solution, but I've never
>seen a scenario in which all the cool and fantastic features of DTLS are
>required. Given the comments about DTLS in this long thread it seems
>that choosing DTLS would be a risk (WebRTC would become a DTLS beta-
>tester...).
>
>
>Regards.
>
>--
>Iñaki Baz Castillo
><[e-mail]>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb