[rtcweb] Retransmit: Summary of Alternatives for media keying

[Eric Rescorla <[e-mail]>]

Sorry, sent to wrong list so some of you may not have it.

Hi Folks,

This is very late, but here is my attempted summary of the discussion
about COMSEC choices at the interim. I'm not saying that this captures
everyone's position, but the following positions are the ones that in
my view have significant levels of support.


Alternative A: [DTLS MUST, NO SDES, NO RTP]

   An RTC-Web client MUST support DTLS-SRTP and ONLY DTLS-SRTP for
   media, without support for either SRTP with supplied keying
   material (SDES-style) AND plain RTP. DTLS-SRTP provides for
   end-to-end key negotation between the two RTCWEB clients. The
   client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 protection
   profile and the DTLS cipher suite
   TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement
   differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA
   in that it mandates support for Diffie-Hellman key exchange in
   order to provide Perfect Forward Secrecy.

   An RTCWEB client MUST provide its user with the ability to to see
   keying material information sufficient to allow indepent
   verification of their peer's identity.  (REF
   draft-kaufman-rtcweb-security-ui).

   The primary drawback of this alternative is the lack of backwards
   compatibility with devices and software that only support plain
   RTP, but the requirement for a handshake makes interoperation with
   these devices not completely trivial anyway.



Alternative B: [DTLS-SRTP MUST, SDES MAY, RTP MUST]

   An RTC-Web client MUST support DTLS-SRTP for media. DTLS-SRTP
   provides for end-to-end key negotation between the two RTCWEB
   clients.  The client MUST support the SRTP_AES128_CM_HMAC_SHA1_80
   protection profile and the DTLS cipher suite
   TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement
   differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA
   in that it mandates support for Diffie-Hellman key exchange in
   order to provide Perfect Forward Secrecy. This MUST be the default
   mode of operation.

   An RTCWEB client MAY support SRTP with the keying material supplied
   via the signaling channel with the SRTP_AES128_CM_HMAC_SHA1_80
   protection profile.  In the case of a web browser client, the
   keying material should be supplied via a Javascript API.
   DTLS-SRTP, with its end-to-end keying and authentication capability
   is preferred over SDES-style [RFC4568] keying.  However, the
   additional API overhead required to add support for a way to force
   a particular key is low.  In addition, once plain RTP is to be
   supported the arguments against the lower security level provided
   by SDES-style keying are no longer relevant.  Also there are a
   small number of potential use cases where interoperability with
   existing SDES-keyed software or devices may be achieved if the
   RTCWEB endpoint supports this mode of keying.

   An RTCWEB client MUST support RTP.  This provides no privacy but
   maximizes interoperability.  Note that SRTP with a Null cipher has
   equivalent security but does not meet the interoperability
   requirement.  Plain RTP provides no protection for the media, and
   so is discouraged as a mode of operation for RTCWEB.  However,
   support for RTP is required in order to provide interoperability
   with legacy RTP devices and software that do not support
   encryption.  In addition, some use cases such as high-volume PSTN
   or PBX gateways within an organization may scale more readily
   without the overhead of media encryption.

   An RTCWEB client MUST provide its user with the ability to know
   whether or not the media they are sending is protected by encryption
   and with the ability to see keying material information sufficient
   to allow indepent verification of their peer's identity.
   (REF draft-kaufman-rtcweb-security-ui). Note that this user
   interface element is much more critical---and hence much more
   problematic than with alternative A. If DTLS-SRTP is always
   used, then the user knows what security mechanisms are provided.
   As soon as multiple alternatives with widely varying security
   (or no security in the case of RTP) are provided, then users
   need to actually verify that the security level is satisfactory,
   which is inherently problematic given typical user behavior.

I expect to leave time for discussion of this during my slot tomorrow.
I look forward to a good discussion.

Best,
-Ekr