Re: [rtcweb] Retransmit: Summary of Alternatives for media keying
"Elwell, John" <john.elwell@siemens-enterprise.com> Thu, 28 July 2011 12:04 UTC
Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDAE21F8C1F for <rtcweb@ietfa.amsl.com>; Thu, 28 Jul 2011 05:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.587
X-Spam-Level:
X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=-0.988, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQ+yMAHX4B1m for <rtcweb@ietfa.amsl.com>; Thu, 28 Jul 2011 05:04:14 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 95A7A21F8C19 for <rtcweb@ietf.org>; Thu, 28 Jul 2011 05:04:13 -0700 (PDT)
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id CD50A1EB849B; Thu, 28 Jul 2011 14:04:12 +0200 (CEST)
Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 28 Jul 2011 14:04:12 +0200
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Thu, 28 Jul 2011 14:04:10 +0200
Thread-Topic: [rtcweb] Retransmit: Summary of Alternatives for media keying
Thread-Index: AcxM7g9dcIBOmCLeRXOquEWZxmywQgALnXxg
Message-ID: <A444A0F8084434499206E78C106220CA08F1D75CF0@MCHP058A.global-ad.net>
References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com>
In-Reply-To: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2011 12:04:15 -0000
> But anyway... with regards to your alternatives below, you > seem to imply that using DTLS-SRTP is by itself "secure", > such that the UI could display a lock-icon for example. I > was under the impression that DTLS-SRTP provided no guarantee > of anything without the humans on both ends verifying they're > using the same keying material/SAS/etc. Is that not the > case? (okay yes it requires being a MitM to subvert, but > that's not a high enough bar to claim anything) > > Assuming that's true, and given how few humans would actually > know to perform manual verification of dtls-srtp, I think > this topic isn't as cut-and-dried as choosing between > "secure" vs. "insecure". Both alternatives are capable of > being secure or insecure, and it's up to the human to do > something to figure it out in either case. There is no real > alternative which is inherently "secure", afaict. [JRE] I agree with Hadriel's concern. DTLS-SRTP itself, if using only self-signed certs at the endpoints, requires other means (signalling path or human-assisted) to provide strong guarantees that you are talking to the person or organization you expect. For SIP, the (theoretical) solution is to send a fingerprint of the certificate and have that bound to authenticated identity in accordance with RFC 4474, although not feasible in most deployed SIP environments. Although RTC-Web is not specifying signalling, clearly it needs to say something about the problem, and can't just indicate to the user that communication is secure just because DTLS-SRTP is used. Secondly, if interworking with legacy SIP, where DTLS-SRTP (or whatever we select) is terminated at a gateway, there is a real problem ensuring that the user knows the call is not necessarily secure end-to-end. Perhaps this argues towards option B, since if DTLS-SRTP is not used from browser to gateway, at least the browser should know to indicate a lesser level of security to the user. The whole issue of the browser knowing what it can tell the user concerning the security posture of a communication is a really difficult problem. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG. > > -hadriel > > > Recently EKR wrote: > > 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 > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >
- [rtcweb] Retransmit: Summary of Alternatives for … Eric Rescorla
- Re: [rtcweb] Recordings from last interim meeting Bernard Aboba
- Re: [rtcweb] Recordings from last interim meeting Ted Hardie
- Re: [rtcweb] Retransmit: Summary of Alternatives … Daryl Malas
- Re: [rtcweb] Retransmit: Summary of Alternatives … Hadriel Kaplan
- Re: [rtcweb] Retransmit: Summary of Alternatives … Bernard Aboba
- Re: [rtcweb] Retransmit: Summary of Alternatives … Matthew Kaufman
- Re: [rtcweb] Retransmit: Summary of Alternatives … Elwell, John
- Re: [rtcweb] Retransmit: Summary of Alternatives … Matthew Kaufman
- Re: [rtcweb] Retransmit: Summary of Alternatives … Hadriel Kaplan
- Re: [rtcweb] Retransmit: Summary of Alternatives … Matthew Kaufman
- Re: [rtcweb] Retransmit: Summary of Alternatives … Harald Alvestrand
- Re: [rtcweb] Retransmit: Summary of Alternatives … Eric Rescorla
- Re: [rtcweb] Retransmit: Summary of Alternatives … Matthew Kaufman
- Re: [rtcweb] Retransmit: Summary of Alternatives … Randell Jesup
- Re: [rtcweb] Retransmit: Summary of Alternatives … Randell Jesup
- Re: [rtcweb] Retransmit: Summary of Alternatives … Hadriel Kaplan
- Re: [rtcweb] Retransmit: Summary of Alternatives … Hadriel Kaplan
- Re: [rtcweb] Retransmit: Summary of Alternatives … Matthew Kaufman
- Re: [rtcweb] Retransmit: Summary of Alternatives … Matthew Kaufman
- Re: [rtcweb] Retransmit: Summary of Alternatives … Matthew Kaufman
- Re: [rtcweb] Retransmit: Summary of Alternatives … Randell Jesup
- Re: [rtcweb] Retransmit: Summary of Alternatives … Hadriel Kaplan
- Re: [rtcweb] Retransmit: Summary of Alternatives … Matthew Kaufman
- Re: [rtcweb] Retransmit: Summary of Alternatives … Hadriel Kaplan
- Re: [rtcweb] Retransmit: Summary of Alternatives … Randell Jesup