[rtcweb] JSEP draft query [was RE: SRTP not mandatory-to-use]

"Ravindran, Parthasarathi" <pravindran@sonusnet.com> Thu, 12 January 2012 01:13 UTC

Return-Path: <pravindran@sonusnet.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 B61EC11E808D for <rtcweb@ietfa.amsl.com>; Wed, 11 Jan 2012 17:13:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sv7S4Ob7l9n for <rtcweb@ietfa.amsl.com>; Wed, 11 Jan 2012 17:13:36 -0800 (PST)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4B711E8074 for <rtcweb@ietf.org>; Wed, 11 Jan 2012 17:13:36 -0800 (PST)
Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0C1EIHI028502; Wed, 11 Jan 2012 20:14:18 -0500
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 20:05:02 -0500
Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 06:35:56 +0530
Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Thu, 12 Jan 2012 06:35:55 +0530
From: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
To: Justin Uberti <juberti@google.com>
Thread-Topic: JSEP draft query [was RE: [rtcweb] SRTP not mandatory-to-use]
Thread-Index: AQHM0MZVMFBIgjy5SEWGFT5o4RsLlg==
Date: Thu, 12 Jan 2012 01:05:54 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DD0610@inba-mail02.sonusnet.com>
References: <CAErhfrwu322=HTS0JZhum9EGfb73KmYS6CU_KMESyzEWhtvg2w@mail.gmail.com> <CAKhHsXHnT2p7yncha5-BQ=-Lzk3-N+tuijM-UqwfP1mPUi173A@mail.gmail.com> <BLU152-W1140980759D89AC3C1D0CA93940@phx.gbl> <CA+9kkMBdX7YT1tPj5M3VrzAPKa6tXNGZVvvhjW9V4oOEC7g_kA@mail.gmail.com> <CAOJ7v-1_qMoHBb3K7rV=hG9EadqL=xn4KEdG0zdWnKZU9_TipQ@mail.gmail.com> <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <CAKhHsXEes+Lf+uKdTrjXoy+3PMy2uNumNL-W-0s4_xRXW6FiZg@mail.gmail.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <CALiegfkejnU2rTe-FibUVxTrRS9SivkhGXB5eK+FhD8Vu6iTMA@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <CALiegfn07bS58B+4ZyzRTnO4LCpw1e96dnqpSM+TT1y3QG2Zwg@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <CAOJ7v-20+yL7r+_ODx_czHTiujXZZWESaZRB7MQjhvScg3RFtw@mail.gmail.com> <4F0DFD0B.2000009@jesup.org> <CAD5OKxsOqzXDz3WYhLejDtB-zGUcZYMCApHxPyU3XV++_RZhBg@mail.gmail.com> <CAOJ7v-2Y3SLYko1r_BTp-8B2ea-L+7y9CRsVAc-RkYU9hWvQ_Q@mail.gmail.com>
In-Reply-To: <CAOJ7v-2Y3SLYko1r_BTp-8B2ea-L+7y9CRsVAc-RkYU9hWvQ_Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [121.242.142.186]
Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C01DD0610inbamail02sonus_"
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Jan 2012 01:05:56.0230 (UTC) FILETIME=[569F8A60:01CCD0C6]
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: [rtcweb] JSEP draft query [was RE: SRTP not mandatory-to-use]
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, 12 Jan 2012 01:13:37 -0000

Hi Justin,

Sorry,  I have trouble in accessing JSEP draft at IETF RTCWeb site (http://tools.ietf.org/wg/rtcweb/) and googling does not yield any draft. Could you please forward me JSEP draft to see how DTLS keys are negotiated in JSEP proposal even  before the answer is received from the remote WebRTC client.

Thanks
Partha

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Thursday, January 12, 2012 4:48 AM
To: Roman Shpount
Cc: Randell Jesup; rtcweb@ietf.org
Subject: Re: [rtcweb] SRTP not mandatory-to-use


On Wed, Jan 11, 2012 at 5:50 PM, Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> wrote:
On Wed, Jan 11, 2012 at 4:20 PM, Randell Jesup <randell-ietf@jesup.org<mailto:randell-ietf@jesup.org>> wrote:

I'd like to explore the possibility of making sure there's a workable DTLS-SRTP implementation openly available, and locking WebRTC down to that only.

I should note that while libsrtp 1.4.2 (last official release) doesn't have DTLS-SRTP support, there are DTLS-SRTP support functions and test code in the project's CVS since ~2006, and resiprocate/recon supports DTLS-SRTP via a modified OpenSSL.  So, I'm not sure the barrier is huge given DTLS support already.

Can you name a single soft-phone, hard-phone, SBC, or gateway that currently supports DTLS-SRTP?

The reason I am asking is libsrtp, despite being widely used, is extremely buggy (last official release for instance crashes with GPF), and does not even provide full DES-SRTP implementation (no F8_128_HMAC_SHA1_8 support).

As far as DTLS (non-SRTP) implementations are concerned, can anybody provide an indication on how widely they are used? I know that OpenSSL supported DTLS for a while, but what commonly used software is using this?

Also, what would be the impact of adding DTLS to SBC? It would be interesting to hear from SBC implementers before decision is made.

How many additional round trips does DTLS require for connection setup? Are we planning to support certificate validation?

When used with JSEP, DTLS should not require any additional roundtrips for connection setup, since DTLS can be brought up as part of transport establishment. In fact, connection setup should occur faster than when using SDES, since the keys can be negotiated before the answer arrives. This prevents clipping of the answerer's media from occurring.