Re: [rtcweb] Retransmit: Summary of Alternatives for media keying

Daryl Malas <D.Malas@cablelabs.com> Tue, 26 July 2011 13:58 UTC

Return-Path: <D.Malas@cablelabs.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 7FB2D21F8BB9 for <rtcweb@ietfa.amsl.com>; Tue, 26 Jul 2011 06:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.463
X-Spam-Level:
X-Spam-Status: No, score=-100.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 WrCh9qFtORMx for <rtcweb@ietfa.amsl.com>; Tue, 26 Jul 2011 06:58:04 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id B933F21F884F for <rtcweb@ietf.org>; Tue, 26 Jul 2011 06:58:04 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p6QDw2FC011296; Tue, 26 Jul 2011 07:58:02 -0600
Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 26 Jul 2011 07:58:02 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 26 Jul 2011 07:58:03 -0600
From: Daryl Malas <D.Malas@cablelabs.com>
To: Eric Rescorla <ekr@rtfm.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Tue, 26 Jul 2011 07:58:01 -0600
Thread-Topic: [rtcweb] Retransmit: Summary of Alternatives for media keying
Thread-Index: AcxLnAlVbogs3HaWSNKjH3eaee65xQ==
Message-ID: <CA543EC8.1A3F1%d.malas@cablelabs.com>
In-Reply-To: <CABcZeBMctaVJTQajXkAoYHYE1vFEFFyPBDPBK-zHdtw=kiCy6g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.12.0.110505
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Approved: ondar
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: Tue, 26 Jul 2011 13:58:05 -0000

Ekr et al,

I support Alternative B, and the reason is the support for plain RTP.  My
first reaction was Alternative A, and someone would be foolish to use
plain RTP over the Internet (unless they live in Hollywood and love to
have their phone calls recorded and played back on TMZ).  I think some
enterprises will want this level of support for interoperability with
their "older" IP-PBX/Media Gateway, and they will require their users to
use a VPN for using the web application within the enterprise (assuming a
enterprise web application for remote users), hence encrypting the media
anyway.  This will save them on additional costs they don't want to incur
for encryption/decryption.

Regards,

Daryl



On 7/26/11 6:33 AM, "Eric Rescorla" <ekr@rtfm.com> wrote:

>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
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb