6 comments on “WebRTC MUST implement DTLS-SRTP but… MUST NOT implement SDES?

  1. The issue Victor is discussing is not endemic to WebRTC only. It is a general problem that the SIP world has tackled for a bit.

    The paper below provides relative merits and disadvantages of various keying schemes in an Internet multimedia telecommunication environment. If you would like a copy, you can send me an email at vkg AT bell-labs DOT com.

    Gurbani, V.K. and Kolesnikov, V., “A Survey and Analysis of Media Keying Techniques in the Session Initiation Protocol (SIP),” In IEEE Communications Surveys and Tutorials, 13(2), pp. 183-198, 2011.

  2. Thanks for the reference Vijay — very interesting paper.

    BTW, this new Internet-Draft was published a few hours ago: “Using ZRTP to Secure WebRTC”
    http://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-00

    Abstract: “WebRTC, Web Real-Time Communications, is a set of protocols and APIs used to enable web developers to add real-time communications into their web pages and applications with a few lines of JavaScript. WebRTC media flows are encrypted and authenticated by SRTP, the Secure Real-time Transport Protocol while the key agreement is provided by DTLS-SRTP, Datagram Transport Layer Security for Secure Real-time Transport Protocol. However, without some third party identity service or certificate authority, WebRTC media flows have no protection against a man-in-the-middle (MitM) attack. ZRTP, Media Path Key Agreement for Unicast Secure RTP, RFC 6189, does provide protection against MitM attackers using key continuity augmented with a Short Authentication String (SAS). This specification describes how ZRTP can be used over the WebRTC data channel to provide MitM protection for WebRTC media flows keyed using DTLS-SRTP. This provides users protection against MitM attackers without requiring browsers to support ZRTP or users to download a plugin or extension to implement ZRTP.”

  3. Quick update: Google just announced Chrome is phasing out SDES in a multi-step process

    “1) In Chrome 31, DTLS is now on by default, although SDES is still offered as well. You no longer need to pass the DtlsSrtpKeyAgreement:true constraint to enable DTLS. Since we are using per-origin certificate caching, the performance hit of generating a DTLS cert is no longer an issue, allowing us to make this the default. No application changes are needed at this time, although DTLS can be disabled by setting DtlsSrtpKeyAgreement:false, which reverts to SDES-only operation.

    2) In an upcoming version of Chrome, probably Chrome 33, SDES will no longer be offered by default, and will only be used if a new TBD constraint is specified. For applications that require SDES, this will require an application change to specify this new constraint.

    3) In a future version of Chrome, TBD at this point, this SDES constraint will be removed and only DTLS-SRTP will be supported. We expect this to occur sometime in 2014, so please begin migration of your applications to DTLS-SRTP as soon as possible.”

    Source: https://groups.google.com/forum/#!topic/discuss-webrtc/67W4zrTmoNs

  4. Thanks for the interesting post Victor.

    I was just searching for some security issues about WebRTC and I found this. Maybe, the current status about this has changed, due to the post was published about a year ago I am new in WebRTC, and everything appears that WebRTC is using DLTS-RTSP. However, What happens with the security in mobile phones?. As far as I know RTSP could be a little slow to decrypt Video, for example, in mobile plattforms.

    Thanks in advance

    Víctor Hidalgo

    • Please don’t mix up Real-time Streaming Protocol (RTSP) with Secure Real-time Transport (SRTP). WebRTC uses DTLS-SRTP.

      DTLS-SRTP like all encryption does require decryption, and there is some overhead associated with this but it is miniscule on modern devices. Concerns about encryption costs have usually been focused around server side equipment that needs to handle high volumes and therefore could potentially increase the price of offering a service.

      • Hi Chad,

        Right, I was referreing to DTLS-SRTP no DTLS-RTSP, sorry for my mistake.

        I wanted some kind of clarification before doing some test, since the minuscle overhead associated in modern devices is what I expected.

        Many thanks for your response.

        Víctor

Leave a Reply

Your email address will not be published. Required fields are marked *