From ekr at rtfm.com Tue Jul 26 05:14:11 2011 From: ekr at rtfm.com (Eric Rescorla) Date: Mon, 25 Jul 2011 23:14:11 -0400 Subject: [RTW] Summary of Alternatives for media keying Message-ID: 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 From bernard_aboba at hotmail.com Tue Jul 26 13:00:30 2011 From: bernard_aboba at hotmail.com (Bernard Aboba) Date: Tue, 26 Jul 2011 04:00:30 -0700 Subject: [RTW] Summary of Alternatives for media keying In-Reply-To: References: Message-ID: Rather than asking the group to choose between two closely related alternatives, it would probably make more sense to talk about the general requirements for cryptographic support in the browser. The reality is that support for media keying by no means ubiquitous today, but among the solutions that have been implemented, SDES is probably by far the most popular, followed by ZRTP. I believe it's fair to say that DTLS/SRTP has not gained widespread support so far. Given this, there will probably be a practical need for RTCWEB to be able to support multiple media keying solutions. However, having to support multiple solutions natively is not a very appealing prospect. Therefore it would be a (more?) useful discussion to talk about the breakdown of functionality between native and javascript. > From: ekr at rtfm.com > Date: Mon, 25 Jul 2011 23:14:11 -0400 > To: rtc-web at alvestrand.no > Subject: [RTW] Summary of Alternatives for media keying > > 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 > _______________________________________________ > RTC-Web mailing list > RTC-Web at alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekr at rtfm.com Tue Jul 26 13:14:59 2011 From: ekr at rtfm.com (Eric Rescorla) Date: Tue, 26 Jul 2011 07:14:59 -0400 Subject: [RTW] Summary of Alternatives for media keying In-Reply-To: References: Message-ID: On Tue, Jul 26, 2011 at 7:00 AM, Bernard Aboba wrote: > Given this, there will probably be a practical need for RTCWEB to be able to > support > multiple media keying solutions.?? However, having to support multiple > solutions > natively is not a very appealing prospect.? Therefore it would be a (more?) > useful > discussion to talk about the breakdown of functionality between native and > javascript. This was covered fairly extensively in Alan's, Matthew's, and my respective documents, and in Alan's and my presentations at the interim. If you wish to have a system which can even in principle be secure against attack by the calling site, you need to have more or less the entire key exchange implementation and SRTP implementation in the browser, not in the JS. Moroever, as Alan and Matthew have observed, the implementation must allow the users to have direct access (unmediated by the JS) to enough keying material to verify peer identity (presuming they have some secure channel with which to do so). -Ekr From mnot at mnot.net Tue Jul 26 20:17:29 2011 From: mnot at mnot.net (Mark Nottingham) Date: Tue, 26 Jul 2011 14:17:29 -0400 Subject: [RTW] Summary of Alternatives for media keying In-Reply-To: References: Message-ID: <6471BCA5-20C2-48BB-98BA-884CE57C0AC3@mnot.net> I thought this list was dead... On 26/07/2011, at 7:14 AM, Eric Rescorla wrote: > On Tue, Jul 26, 2011 at 7:00 AM, Bernard Aboba > wrote: >> Given this, there will probably be a practical need for RTCWEB to be able to >> support >> multiple media keying solutions. However, having to support multiple >> solutions >> natively is not a very appealing prospect. Therefore it would be a (more?) >> useful >> discussion to talk about the breakdown of functionality between native and >> javascript. > > This was covered fairly extensively in Alan's, Matthew's, and my > respective documents, > and in Alan's and my presentations at the interim. > > If you wish to have a system which can even in principle be secure > against attack by > the calling site, you need to have more or less the entire key > exchange implementation > and SRTP implementation in the browser, not in the JS. Moroever, as > Alan and Matthew > have observed, the implementation must allow the users to have direct access > (unmediated by the JS) to enough keying material to verify peer > identity (presuming > they have some secure channel with which to do so). > > -Ekr > _______________________________________________ > RTC-Web mailing list > RTC-Web at alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web -- Mark Nottingham http://www.mnot.net/