Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

"DRUTA, DAN" <dd5826@att.com> Fri, 26 April 2013 17:27 UTC

Return-Path: <dd5826@att.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 B378C21F9971 for <rtcweb@ietfa.amsl.com>; Fri, 26 Apr 2013 10:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 MOUCofijZkTo for <rtcweb@ietfa.amsl.com>; Fri, 26 Apr 2013 10:27:20 -0700 (PDT)
Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id BB13721F996C for <rtcweb@ietf.org>; Fri, 26 Apr 2013 10:27:19 -0700 (PDT)
Received: from unknown [144.160.112.28] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 7f8ba715.58afe940.189568.00-551.531120.nbfkord-smmo08.seg.att.com (envelope-from <dd5826@att.com>); Fri, 26 Apr 2013 17:27:19 +0000 (UTC)
X-MXL-Hash: 517ab8f77dbfd523-0dc85c7b8d6936127a7bd5f571f185c38d0c4825
Received: from unknown [144.160.112.28] (EHLO tlpi048.enaf.dadc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 5f8ba715.0.189549.00-311.531059.nbfkord-smmo08.seg.att.com (envelope-from <dd5826@att.com>); Fri, 26 Apr 2013 17:27:18 +0000 (UTC)
X-MXL-Hash: 517ab8f63d2edd33-272761b43aa524bbe90a6bf40775f0e160a1e01b
Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id r3QHRFiE004956; Fri, 26 Apr 2013 12:27:17 -0500
Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id r3QHR9U1004903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Apr 2013 12:27:13 -0500
Received: from WABOTH9MSGHUB8D.ITServices.sbc.com (waboth9msghub8d.itservices.sbc.com [135.163.35.93]) by alpi134.aldc.att.com (RSA Interceptor); Fri, 26 Apr 2013 17:26:52 GMT
Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([135.163.35.98]) by WABOTH9MSGHUB8D.ITServices.sbc.com ([135.163.35.93]) with mapi id 14.02.0342.003; Fri, 26 Apr 2013 10:26:51 -0700
From: "DRUTA, DAN" <dd5826@att.com>
To: Oscar Ohlsson <oscar.ohlsson@ericsson.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
Thread-Index: AQHOQc2XOVTqncPMgEulpjOy2XJ1wJjn1nSAgAACAICAABhyAIAAp5GAgAAPRICAAGaOgP//q29A
Date: Fri, 26 Apr 2013 17:26:50 +0000
Message-ID: <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com>
References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <AE1A6B5FD507DC4FB3C5166F3A05A48416281FDB@tk5ex14mbxc272.redmond.corp.microsoft.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <CAErhfrx6xi7rNmc6CZc5iyKiYv+oZbi3sBa5QywB7dUKtms2Aw@mail.gmail.com> <C643F355C8D33C48B983F1C1EA702A450B49EA@ESESSMB301.ericsson.se>
In-Reply-To: <C643F355C8D33C48B983F1C1EA702A450B49EA@ESESSMB301.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.163.34.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <dd5826@att.com>
X-SOURCE-IP: [144.160.112.28]
X-AnalysisOut: [v=2.0 cv=V4/KJ5bi c=1 sm=0 a=srMsL6ituuWTYeky9Bs9mA==:17 a]
X-AnalysisOut: [=YnP4VLJI-BoA:10 a=fROPODMLp6sA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=JE1MetyYUdEA:10 a=48vgC7mUAAAA:8 a=ag3Orf1RAAAA:8]
X-AnalysisOut: [ a=AZsloQztJqdZGUtGKUoA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA]
X-AnalysisOut: [:10 a=KwNp_X_GjOYA:10 a=vmdV1jIo-2wyaiGR:21 a=-zw1msHzJDcj]
X-AnalysisOut: [IvMK:21]
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
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: Fri, 26 Apr 2013 17:27:20 -0000

I would like to see the user-agent support for SDES as a "MUST" for RTCWeb. 
I don't think I need to restate why. One additional point though is that it will make interop easier, expand and accelerate the adoption for RTCWeb/WebRTC. Isn't this the ultimate goal?  
In regards to security considerations I would challenge the group to come up with ways to identify and convey the risks back to the end user through the user-agent implementation in a very simple and easy to understand UI (if necessary). I know this could be a big rat hole and I can hear already arguments that it's already too confusing but as the Web is becoming more of a platform and browser complexity increases we should acknowledge it with better transparency rather than with restrictions and limitations. Users make their own decisions in the end.

Best Regards,
Dan
    

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Oscar Ohlsson
Sent: Friday, April 26, 2013 7:57 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

I'm also in favour of supporting SDES (no big surprise). But we need to analyze how SDES should be enabled and how it can be negotiated in SDP. If people are concerned with bidding down attacks then we could add a separate JavaScript instruction for enabling SDES. If SDES is not enabled then it wouldn't be offered or accepted.

Regards,

Oscar


From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Xavier Marjou
Sent: den 26 april 2013 10:50
To: rtcweb@ietf.org
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

+1 for supporting SDES as a keying method for WebRTC
Cheers,
Xavier

On Fri, Apr 26, 2013 at 9:55 AM, Hutton, Andrew <andrew.hutton@siemens-enterprise.com> wrote:
Also agree that we should support SDES in additional to DTLS-SRTP.

Regards
Andy

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Ejzak, Richard P (Richard)
> Sent: 25 April 2013 22:55
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
>
> I also agree that we should support SDES in addition to DTLS-SRTP.
>
> This raises a further question about SCTP/DTLS for DataChannels.  It
> seems that if we support SDES-SRTP, don't we also need to provide an
> SDES keying mechanism for DataChannels?  Ekr: What is needed to realize
> this?
>
> Richard Ejzak
>
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > Behalf Of Matthew Kaufman (SKYPE)
> > Sent: Thursday, April 25, 2013 3:28 PM
> > To: Bogineni, Kalyani; 'Cullen Jennings'; rtcweb@ietf.org
> > Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
> >
> > I agree. The ability to set the cipher suite and keys from JavaScript
> > is critical for certain applications. SDES is the best we'll get with
> > SDP as the API. DTLS-SRTP-only would be unacceptably limiting.
> >
> > Matthew Kaufman
> >
> > > -----Original Message-----
> > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > > Behalf Of Bogineni, Kalyani
> > > Sent: Thursday, April 25, 2013 1:21 PM
> > > To: 'Cullen Jennings'; rtcweb@ietf.org
> > > Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and
> RTCWeb
> > >
> > > We would like to support the use of SDES as a keying method for
> > WebRTC.
> > >
> > > Kalyani Bogineni
> > > Verizon
> > >
> > > -----Original Message-----
> > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > > Behalf Of Cullen Jennings
> > > Sent: Thursday, April 25, 2013 11:57 AM
> > > To: rtcweb@ietf.org
> > > Subject: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
> > >
> > >
> > > The working groups committed some time ago to have a further
> > > discussion on whether SDP Security Descriptions (RFC 4568 aka SDES)
> > > would be usable as a keying method for WebRTC.  As we prepare for
> > that
> > > discussion, we'd like to have expressions of interest or support
> for
> > > that approach which indicate the general outlines of support
> > proposed.
> > > If you wish to make such an expression of support, please send it
> to
> > the chairs or the list.
> > >
> > > Cullen, Magnus, & Ted <The Chairs>
> > >
> > >
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb