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
>