<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'><div dir='ltr'>
Rather than asking the group to choose between two closely related alternatives, <br>it would probably make more sense to talk about the general requirements for<br>cryptographic support in the browser. <br><br>The reality is that support for media keying by no means ubiquitous today, but among<br>the solutions that have been implemented, SDES is probably by far the most popular,<br>followed by ZRTP. I believe it's fair to say that DTLS/SRTP has not gained widespread<br>support so far. <br><br>Given this, there will probably be a practical need for RTCWEB to be able to support<br>multiple media keying solutions. However, having to support multiple solutions<br>natively is not a very appealing prospect. Therefore it would be a (more?) useful <br>discussion to talk about the breakdown of functionality between native and <br>javascript. <br><br><br><div>> From: ekr@rtfm.com<br>> Date: Mon, 25 Jul 2011 23:14:11 -0400<br>> To: rtc-web@alvestrand.no<br>> Subject: [RTW] Summary of Alternatives for media keying<br>> <br>> Hi Folks,<br>> <br>> This is very late, but here is my attempted summary of the discussion<br>> about COMSEC choices at the interim. I'm not saying that this captures<br>> everyone's position, but the following positions are the ones that in<br>> my view have significant levels of support.<br>> <br>> <br>> Alternative A: [DTLS MUST, NO SDES, NO RTP]<br>> <br>> An RTC-Web client MUST support DTLS-SRTP and ONLY DTLS-SRTP for<br>> media, without support for either SRTP with supplied keying<br>> material (SDES-style) AND plain RTP. DTLS-SRTP provides for<br>> end-to-end key negotation between the two RTCWEB clients. The<br>> client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 protection<br>> profile and the DTLS cipher suite<br>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement<br>> differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA<br>> in that it mandates support for Diffie-Hellman key exchange in<br>> order to provide Perfect Forward Secrecy.<br>> <br>> An RTCWEB client MUST provide its user with the ability to to see<br>> keying material information sufficient to allow indepent<br>> verification of their peer's identity. (REF<br>> draft-kaufman-rtcweb-security-ui).<br>> <br>> The primary drawback of this alternative is the lack of backwards<br>> compatibility with devices and software that only support plain<br>> RTP, but the requirement for a handshake makes interoperation with<br>> these devices not completely trivial anyway.<br>> <br>> <br>> <br>> Alternative B: [DTLS-SRTP MUST, SDES MAY, RTP MUST]<br>> <br>> An RTC-Web client MUST support DTLS-SRTP for media. DTLS-SRTP<br>> provides for end-to-end key negotation between the two RTCWEB<br>> clients. The client MUST support the SRTP_AES128_CM_HMAC_SHA1_80<br>> protection profile and the DTLS cipher suite<br>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement<br>> differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA<br>> in that it mandates support for Diffie-Hellman key exchange in<br>> order to provide Perfect Forward Secrecy. This MUST be the default<br>> mode of operation.<br>> <br>> An RTCWEB client MAY support SRTP with the keying material supplied<br>> via the signaling channel with the SRTP_AES128_CM_HMAC_SHA1_80<br>> protection profile. In the case of a web browser client, the<br>> keying material should be supplied via a Javascript API.<br>> DTLS-SRTP, with its end-to-end keying and authentication capability<br>> is preferred over SDES-style [RFC4568] keying. However, the<br>> additional API overhead required to add support for a way to force<br>> a particular key is low. In addition, once plain RTP is to be<br>> supported the arguments against the lower security level provided<br>> by SDES-style keying are no longer relevant. Also there are a<br>> small number of potential use cases where interoperability with<br>> existing SDES-keyed software or devices may be achieved if the<br>> RTCWEB endpoint supports this mode of keying.<br>> <br>> An RTCWEB client MUST support RTP. This provides no privacy but<br>> maximizes interoperability. Note that SRTP with a Null cipher has<br>> equivalent security but does not meet the interoperability<br>> requirement. Plain RTP provides no protection for the media, and<br>> so is discouraged as a mode of operation for RTCWEB. However,<br>> support for RTP is required in order to provide interoperability<br>> with legacy RTP devices and software that do not support<br>> encryption. In addition, some use cases such as high-volume PSTN<br>> or PBX gateways within an organization may scale more readily<br>> without the overhead of media encryption.<br>> <br>> An RTCWEB client MUST provide its user with the ability to know<br>> whether or not the media they are sending is protected by encryption<br>> and with the ability to see keying material information sufficient<br>> to allow indepent verification of their peer's identity.<br>> (REF draft-kaufman-rtcweb-security-ui). Note that this user<br>> interface element is much more critical---and hence much more<br>> problematic than with alternative A. If DTLS-SRTP is always<br>> used, then the user knows what security mechanisms are provided.<br>> As soon as multiple alternatives with widely varying security<br>> (or no security in the case of RTP) are provided, then users<br>> need to actually verify that the security level is satisfactory,<br>> which is inherently problematic given typical user behavior.<br>> <br>> I expect to leave time for discussion of this during my slot tomorrow.<br>> I look forward to a good discussion.<br>> <br>> Best,<br>> -Ekr<br>> _______________________________________________<br>> RTC-Web mailing list<br>> RTC-Web@alvestrand.no<br>> http://www.alvestrand.no/mailman/listinfo/rtc-web<br></div> </div></body>
</html>