From ibc@aliax.net Thu Mar 1 01:22:34 2012 Return-Path: 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 B40A421F863E for ; Thu, 1 Mar 2012 01:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 7HXQu-8ToTpY for ; Thu, 1 Mar 2012 01:22:31 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE3B421F85F8 for ; Thu, 1 Mar 2012 01:22:30 -0800 (PST) Received: by yenm5 with SMTP id m5so120700yen.31 for ; Thu, 01 Mar 2012 01:22:30 -0800 (PST) Received-SPF: pass (google.com: domain of ibc@aliax.net designates 10.236.153.36 as permitted sender) client-ip=10.236.153.36; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ibc@aliax.net designates 10.236.153.36 as permitted sender) smtp.mail=ibc@aliax.net Received: from mr.google.com ([10.236.153.36]) by 10.236.153.36 with SMTP id e24mr5612111yhk.67.1330593750397 (num_hops = 1); Thu, 01 Mar 2012 01:22:30 -0800 (PST) Received: by 10.236.153.36 with SMTP id e24mr4358476yhk.67.1330593750315; Thu, 01 Mar 2012 01:22:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.119.11 with HTTP; Thu, 1 Mar 2012 01:22:10 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E083267@inba-mail01.sonusnet.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11355D49DF5@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <005BC7E2-88EE-4D8F-8AEA-4614D39A6DC6@employees.org> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A12E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C11355D4A14E@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04CD6A@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804BC2DC3BA@HKGMBOXPRD22.polycom.com> <387F9047F55E8C42850AD6B3A7A03C6C0E05647F@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E083267@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 1 Mar 2012 10:22:10 +0100 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlt8IgSjabo3Xmd+LTmwmHgUwuCCvf5JLAEw93Am2fkdqnYbdRzldhhwEerKWfkRhWmIlWP Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on JSEP/ROAP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 09:22:34 -0000 2012/3/1 Ravindran, Parthasarathi : > Inaki, > > I agree that we have two different architecture in mind. Partha, 4 months ago you talked all the time about "SIP to ROAP gateway". Now you talk about "SIP to JSEP" gateway. I'm not sure whether you properly understand that ROAP/JSEP is just a signaling protocol/mechanism/API between JavaScript and the browser's WebRTC stack to handle *WebRTC media* sessions: http://tools.ietf.org/html/draft-uberti-rtcweb-jsep-02#section-2 ------------------------------------------------------------------ JSEP's handling of session descriptions is simple and straightforward. Whenever an offer/answer exchange is needed, the initiating side creates an offer by calling a createOffer() API on PeerConnection. The application can do massaging of that offer, if it wants to, and then uses it to set up its local config via a setLocalDescription() API. The offer is then sent off to the remote side over its preferred signaling mechanism (e.g. WebSockets); upon receipt of that offer, the remote party installs it using a setRemoteDescription() API. -------------------------------------------------------------------- Please read http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protoc= ol-00 (just replace ROAP with JSEP everywhere), and then please let me know if you understand that ROAP/JSEP information can be sent in ***multiple*** ways between web browser and HTTP/WebSocket server (and vice versa), but "something more" than a media negotiation body is *required*. If you still think that JSEP is "mapeable" to SIP, then why does SIP exist? why don't you directly send an SDP body over UDP or TCP? Response: you need SIP because you need to tell the server who you want to call to, and that information is NOT in the SDP, but in the INVITE's Request URI. So ok, JSEP has NOT "Request URI", so the desired destination of the media session must be indicated in some other way (not always needed, see example 5.3. "Poker Game" in the above draft) and you CANNOT standarize that because each web site has his own HTTP logic, his own users identificator format (numeric ID, URI, token...), his own everything. Please see the examples in the above draft. I hope this is clear after 4 months repeating it. > Ranjit/Inaki, > > After IETF-83, I can write the informational mapping document to show how= to implement simple standard SIP using JSEP. Let implementers choose wheth= er JSEP-SIP gateway or SIP over WebSocket is the way to go. See above (JSEP is not mapeable to SIP), so you cannot build a JSEP to SIP gateway. It seems that you want to build the "standard-and-unique-Web-to-SIP-Gateway= ". I'm sorry but this is NOT a competition. I'm not a vendor and I don't sell gateways. And people can use SIP over WebSocket or a custom protocol with a SIP gateway or whatever they want. Best regards. --=20 I=C3=B1aki Baz Castillo From fluffy@iii.ca Thu Mar 1 09:22:22 2012 Return-Path: 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 3D6FA21E8061 for ; Thu, 1 Mar 2012 09:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599] 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 a9MhYrEF8PgK for ; Thu, 1 Mar 2012 09:22:21 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id AD7D221E803C for ; Thu, 1 Mar 2012 09:22:21 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2D11A22E256; Thu, 1 Mar 2012 12:22:14 -0500 (EST) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2012 10:22:13 -0700 Message-Id: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings Subject: [rtcweb] Draft Agenda for WebRTC at IETF83 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 17:22:22 -0000 Given we are still before the draft deadline, this is a very draft = agenda. Roughly speaking the plan is to spend the first session on = security and second session on other things.=20 Cullen, Magnus, & Ted Agenda=20 First Session ------------------- Admin Update - 10 min=20 - update from mmusic, avtcore, and other WG=20 W3C Update - 10 min Identity Proxy - 50 min=20 What to do about RTP and/or SDES - 80 min=20 Second Session ----------------------- Admin - 10 min=20 - scheduling of next interim meeting=20 Signaling - 60 min =20 Data Channel - 30 min Codec Selection - 50 min From fluffy@iii.ca Thu Mar 1 09:26:29 2012 Return-Path: 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 DD0D421E8061 for ; Thu, 1 Mar 2012 09:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.794 X-Spam-Level: X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599] 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 lPaAL6ckIhFT for ; Thu, 1 Mar 2012 09:26:29 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4874821E808E for ; Thu, 1 Mar 2012 09:26:29 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AE07622E256 for ; Thu, 1 Mar 2012 12:26:28 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Cullen Jennings In-Reply-To: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> Date: Thu, 1 Mar 2012 10:26:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [rtcweb] Draft Agenda for WebRTC at IETF83 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 17:26:30 -0000 Uh, note the subject should have been RTCWeb not WebRTC. Sorry. On Mar 1, 2012, at 10:22 AM, Cullen Jennings wrote: >=20 > Given we are still before the draft deadline, this is a very draft = agenda. Roughly speaking the plan is to spend the first session on = security and second session on other things.=20 >=20 > Cullen, Magnus, & Ted >=20 >=20 >=20 > Agenda=20 >=20 > First Session ------------------- >=20 > Admin Update - 10 min=20 > - update from mmusic, avtcore, and other WG=20 >=20 > W3C Update - 10 min >=20 > Identity Proxy - 50 min=20 >=20 > What to do about RTP and/or SDES - 80 min=20 >=20 >=20 >=20 > Second Session ----------------------- >=20 > Admin - 10 min=20 > - scheduling of next interim meeting=20 >=20 > Signaling - 60 min =20 >=20 > Data Channel - 30 min >=20 > Codec Selection - 50 min >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From igor.faynberg@alcatel-lucent.com Thu Mar 1 10:46:42 2012 Return-Path: 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 98A8021E8201 for ; Thu, 1 Mar 2012 10:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.04 X-Spam-Level: X-Spam-Status: No, score=-9.04 tagged_above=-999 required=5 tests=[AWL=1.559, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 j5PeBn9eQ-kD for ; Thu, 1 Mar 2012 10:46:42 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 062DF21E8202 for ; Thu, 1 Mar 2012 10:46:41 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q21IkfmS002954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Mar 2012 12:46:41 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q21IkeGD008639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 1 Mar 2012 12:46:41 -0600 Received: from [135.244.20.3] (faynberg.lra.lucent.com [135.244.20.3]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q21IkeHx024473; Thu, 1 Mar 2012 12:46:40 -0600 (CST) Message-ID: <4F4FC410.5020200@alcatel-lucent.com> Date: Thu, 01 Mar 2012 13:46:40 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> In-Reply-To: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [rtcweb] Draft Agenda for WebRTC at IETF83 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 18:46:42 -0000 Thanks, Cullen! I always wanted security to be on the agenda for the first session (to stimulate more discussions in between) , and I am happy that this is happening now. Igor On 3/1/2012 12:22 PM, Cullen Jennings wrote: > Given we are still before the draft deadline, this is a very draft agenda. Roughly speaking the plan is to spend the first session on security and second session on other things. > > Cullen, Magnus,& Ted > > > > Agenda > > First Session ------------------- > > Admin Update - 10 min > - update from mmusic, avtcore, and other WG > > W3C Update - 10 min > > Identity Proxy - 50 min > > What to do about RTP and/or SDES - 80 min > > > > Second Session ----------------------- > > Admin - 10 min > - scheduling of next interim meeting > > Signaling - 60 min > > Data Channel - 30 min > > Codec Selection - 50 min > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Thu Mar 1 10:58:36 2012 Return-Path: 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 60EEC21E8291 for ; Thu, 1 Mar 2012 10:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.511 X-Spam-Level: X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 kPWAg3kGOoOF for ; Thu, 1 Mar 2012 10:58:32 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9882F21E823D for ; Thu, 1 Mar 2012 10:58:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A04CF39E0D2; Thu, 1 Mar 2012 19:58:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P57DUoQ8hKH0; Thu, 1 Mar 2012 19:58:30 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7126039E0A7; Thu, 1 Mar 2012 19:58:30 +0100 (CET) Message-ID: <4F4FC6D6.1040002@alvestrand.no> Date: Thu, 01 Mar 2012 19:58:30 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Cullen Jennings References: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> In-Reply-To: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Draft Agenda for WebRTC at IETF83 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 18:58:36 -0000 Good to get things out early! Some other things that may want to be on the agenda, either as reporting from other groups or as items to discuss whether to take up elsewhere: - SDP updates: msid and bundle - our use of those functions being defined in MMUSIC - Use of multiplexing functions described by AVTCORE - Congestion control as discussed in the ICCRG meeting - RTP feature profiling: What do we use? (mandatory / permitted / recommended-against) - SDP feature profiling: What do we use? (same alternatives) - Video resolution negotiation per SSRC: What are the alternatives? Can we recommend one? And of course: - Implementation feedback that should lead to specification updates, if any On 03/01/2012 06:22 PM, Cullen Jennings wrote: > Given we are still before the draft deadline, this is a very draft agenda. Roughly speaking the plan is to spend the first session on security and second session on other things. > > Cullen, Magnus,& Ted > > > > Agenda > > First Session ------------------- > > Admin Update - 10 min > - update from mmusic, avtcore, and other WG > > W3C Update - 10 min > > Identity Proxy - 50 min > > What to do about RTP and/or SDES - 80 min > > > > Second Session ----------------------- > > Admin - 10 min > - scheduling of next interim meeting > > Signaling - 60 min > > Data Channel - 30 min > > Codec Selection - 50 min > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Fri Mar 2 04:41:28 2012 Return-Path: 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 E060221F8B89 for ; Fri, 2 Mar 2012 04:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.514 X-Spam-Level: X-Spam-Status: No, score=-110.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 aMt0Kh1OjcPS for ; Fri, 2 Mar 2012 04:41:14 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 69CCA21F8B8B for ; Fri, 2 Mar 2012 04:41:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7A11939E0A7 for ; Fri, 2 Mar 2012 13:41:13 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gkn+FULKL-9 for ; Fri, 2 Mar 2012 13:41:13 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id ED8A839E01E for ; Fri, 2 Mar 2012 13:41:12 +0100 (CET) Message-ID: <4F50BFE8.6010200@alvestrand.no> Date: Fri, 02 Mar 2012 13:41:12 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] SCTP description in SDP - does this group need to take an initiative? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 12:41:29 -0000 In preparing for the Paris meeting, I stumbled across this freshly expired draft: http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-00 It seems to me that it would be of interest to this WG to make sure this draft: a) doesn't die b) defines a "DTLS/SCTP" transport for SCTP on top of DTLS Is there anything we need to do here? Harald From salvatore.loreto@ericsson.com Fri Mar 2 04:47:04 2012 Return-Path: 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 E119921F8BB7 for ; Fri, 2 Mar 2012 04:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.836 X-Spam-Level: X-Spam-Status: No, score=-109.836 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 uW2ie8dWRwP9 for ; Fri, 2 Mar 2012 04:47:04 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0C07F21F87B2 for ; Fri, 2 Mar 2012 04:47:03 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-a3-4f50c146b1e8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 89.82.01970.641C05F4; Fri, 2 Mar 2012 13:47:03 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Mar 2012 13:47:02 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9886C2321 for ; Fri, 2 Mar 2012 14:47:02 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 90763520FC for ; Fri, 2 Mar 2012 14:47:02 +0200 (EET) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4D73F51E2D for ; Fri, 2 Mar 2012 14:47:02 +0200 (EET) Message-ID: <4F50C145.4000702@ericsson.com> Date: Fri, 2 Mar 2012 14:47:01 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F50BFE8.6010200@alvestrand.no> In-Reply-To: <4F50BFE8.6010200@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] SCTP description in SDP - does this group need to take an initiative? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 12:47:05 -0000 Hi Harald, I am going to refresh the draft soon ... I have on my todo list and I will do most likely next week after the 00 deadline. I am going do define labels for SCTP on top of DTLS and also for SCTP encapsulated in UDP (but this is not of interest for RTCWeb). thanks Salvatore On 3/2/12 2:41 PM, Harald Alvestrand wrote: > In preparing for the Paris meeting, I stumbled across this freshly > expired draft: > > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-00 > > It seems to me that it would be of interest to this WG to make sure this > draft: > > a) doesn't die > b) defines a "DTLS/SCTP" transport for SCTP on top of DTLS > > Is there anything we need to do here? > > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Michael.Tuexen@lurchi.franken.de Fri Mar 2 10:38:36 2012 Return-Path: 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 36AA021F85D2 for ; Fri, 2 Mar 2012 10:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 3v2JupM4Bzjg for ; Fri, 2 Mar 2012 10:38:35 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 52FCC21F857A for ; Fri, 2 Mar 2012 10:38:35 -0800 (PST) Received: from [192.168.1.2] (p5481BA23.dip.t-dialin.net [84.129.186.35]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 086B21C0B4615; Fri, 2 Mar 2012 19:38:32 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <4F50BFE8.6010200@alvestrand.no> Date: Fri, 2 Mar 2012 19:38:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F50BFE8.6010200@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1257) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SCTP description in SDP - does this group need to take an initiative? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 18:38:36 -0000 On Mar 2, 2012, at 1:41 PM, Harald Alvestrand wrote: > In preparing for the Paris meeting, I stumbled across this freshly = expired draft: >=20 > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-00 >=20 > It seems to me that it would be of interest to this WG to make sure = this draft: >=20 > a) doesn't die > b) defines a "DTLS/SCTP" transport for SCTP on top of DTLS As far as I understand, DTLS over SCTP is considered (the document refers to RFC 6083) and not SCTP over DTLS. Best regards Michael >=20 > Is there anything we need to do here? >=20 > Harald >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From dburnett@voxeo.com Fri Mar 2 13:17:56 2012 Return-Path: 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 2BA9B21E8065 for ; Fri, 2 Mar 2012 13:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 9URnBg+xMY35 for ; Fri, 2 Mar 2012 13:17:55 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC3821E805C for ; Fri, 2 Mar 2012 13:17:55 -0800 (PST) Received: from [76.111.43.10] (account dburnett@voxeo.com HELO [192.168.15.108]) by voxeo.com (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 107724752 for rtcweb@ietf.org; Fri, 02 Mar 2012 21:17:54 +0000 From: Dan Burnett Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Mar 2012 16:17:53 -0500 Message-Id: To: "" Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [rtcweb] New draft-burnett-rtcweb-constraints-registry-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 21:17:56 -0000 Group, I have just submitted a new draft [1] to create a registry for HTML = Media constraints for use by the W3C getusermedia and WebRTC specs. An = early email proposal on this subject (not the registry, but the use of = it) is available [2] for background. I will be updating that with a = fuller proposal that incorporates changes discussed on the Media Capture = Task Force teleconference [3], so don't be surprised if you notice = slight differences in the syntax in the registry from what was proposed = in email [2]. I don't know how much discussion will happen on this list for this = draft, but at the least this group should be aware of the W3C need for = it. -- dan [1] = https://datatracker.ietf.org/doc/draft-burnett-rtcweb-constraints-registry= / [2] http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0198.html [3] = http://lists.w3.org/Archives/Public/public-media-capture/2012Feb/att-0053/= minutes-2012-02-28.html From keith.drage@alcatel-lucent.com Fri Mar 2 17:14:11 2012 Return-Path: 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 0AF9121E801A for ; Fri, 2 Mar 2012 17:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.469 X-Spam-Level: X-Spam-Status: No, score=-107.469 tagged_above=-999 required=5 tests=[AWL=-1.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 irvd0a2L6psK for ; Fri, 2 Mar 2012 17:14:10 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 44D8D21E8011 for ; Fri, 2 Mar 2012 17:14:09 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q231E2TA032362 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 3 Mar 2012 02:14:05 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sat, 3 Mar 2012 02:14:02 +0100 From: "DRAGE, Keith (Keith)" To: Dan Burnett Date: Sat, 3 Mar 2012 02:14:00 +0100 Thread-Topic: [rtcweb] New draft-burnett-rtcweb-constraints-registry-00 Thread-Index: Acz4ufacpq3sbhYpQh6Z6FzRa/jPTwAFwQzQ Message-ID: References: In-Reply-To: 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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "" Subject: Re: [rtcweb] New draft-burnett-rtcweb-constraints-registry-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 01:14:11 -0000 Pedantic process issue. Do we need a proposed standard to create an IANA registry which only needs = expert review to add a value, or will informational suffice? Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Dan Burnett > Sent: 02 March 2012 21:18 > To: > Subject: [rtcweb] New draft-burnett-rtcweb-constraints-registry-00 >=20 > Group, >=20 > I have just submitted a new draft [1] to create a registry for HTML Media > constraints for use by the W3C getusermedia and WebRTC specs. An early > email proposal on this subject (not the registry, but the use of it) is > available [2] for background. I will be updating that with a fuller > proposal that incorporates changes discussed on the Media Capture Task > Force teleconference [3], so don't be surprised if you notice slight > differences in the syntax in the registry from what was proposed in email > [2]. >=20 > I don't know how much discussion will happen on this list for this draft, > but at the least this group should be aware of the W3C need for it. >=20 > -- dan >=20 > [1] https://datatracker.ietf.org/doc/draft-burnett-rtcweb-constraints- > registry/ > [2] http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0198.html > [3] http://lists.w3.org/Archives/Public/public-media-capture/2012Feb/att- > 0053/minutes-2012-02-28.html >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From internet-drafts@ietf.org Sat Mar 3 21:17:09 2012 Return-Path: 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 5F4F321F8642; Sat, 3 Mar 2012 21:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, 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 mJ7KBndmPgBO; Sat, 3 Mar 2012 21:17:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA66D21F860D; Sat, 3 Mar 2012 21:17:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120304051708.8288.46081.idtracker@ietfa.amsl.com> Date: Sat, 03 Mar 2012 21:17:08 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 05:17:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Javascript Session Establishment Protocol Author(s) : Justin Uberti Cullen Jennings Filename : draft-ietf-rtcweb-jsep-00.txt Pages : 27 Date : 2012-03-03 This document proposes a mechanism for allowing a Javascript application to fully control the signaling plane of a multimedia session, and discusses how this would work with existing signaling protocols. This document is an input document for discussion. It should be discussed in the RTCWEB WG list, rtcweb@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-00.txt From salvatore.loreto@ericsson.com Sun Mar 4 11:08:52 2012 Return-Path: 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 3154521F8663 for ; Sun, 4 Mar 2012 11:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.855 X-Spam-Level: X-Spam-Status: No, score=-109.855 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 lExx5FBT-dLz for ; Sun, 4 Mar 2012 11:08:51 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8A221F8661 for ; Sun, 4 Mar 2012 11:08:50 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-8d-4f53bdc1ac1f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 24.13.27041.1CDB35F4; Sun, 4 Mar 2012 20:08:49 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Sun, 4 Mar 2012 20:08:49 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2B9572321 for ; Sun, 4 Mar 2012 21:08:49 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F29B9522DA for ; Sun, 4 Mar 2012 21:08:48 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AAD0B522C7 for ; Sun, 4 Mar 2012 21:08:48 +0200 (EET) Message-ID: <4F53BDC0.1050000@ericsson.com> Date: Sun, 4 Mar 2012 21:08:48 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20120304105354.21020.42306.idtracker@ietfa.amsl.com> In-Reply-To: <20120304105354.21020.42306.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120304105354.21020.42306.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010903030104020309060508" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Fwd: New Version Notification for draft-tuexen-tsvwg-sctp-dtls-encaps-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 19:08:52 -0000 --------------010903030104020309060508 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit FYI the following draft has been submitted to tsv wg cheers Salvatore -------- Original Message -------- Subject: New Version Notification for draft-tuexen-tsvwg-sctp-dtls-encaps-00.txt Date: Sun, 4 Mar 2012 11:53:54 +0100 From: internet-drafts@ietf.org To: tuexen@fh-muenster.de CC: Salvatore Loreto , "randall@lakerest.net" , "randell_ietf@jesup.org" A new version of I-D, draft-tuexen-tsvwg-sctp-dtls-encaps-00.txt has been successfully submitted by Michael Tuexen and posted to the IETF repository. Filename: draft-tuexen-tsvwg-sctp-dtls-encaps Revision: 00 Title: DTLS Encapsulation of SCTP Packets for RTCWEB Creation date: 2012-03-04 WG ID: Individual Submission Number of pages: 8 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This memo document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. SCTP over DTLS is used by the RTCWeb protocol suite for transporting non- media data between browsers. The IETF Secretariat --------------010903030104020309060508 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit FYI

the following draft has been submitted to tsv wg

cheers
Salvatore

-------- Original Message --------
Subject: New Version Notification for draft-tuexen-tsvwg-sctp-dtls-encaps-00.txt
Date: Sun, 4 Mar 2012 11:53:54 +0100
From: internet-drafts@ietf.org <internet-drafts@ietf.org>
To: tuexen@fh-muenster.de <tuexen@fh-muenster.de>
CC: Salvatore Loreto <salvatore.loreto@ericsson.com>, "randall@lakerest.net" <randall@lakerest.net>, "randell_ietf@jesup.org" <randell_ietf@jesup.org> 


A new version of I-D, draft-tuexen-tsvwg-sctp-dtls-encaps-00.txt has been successfully submitted by Michael Tuexen and posted to the IETF repository.

Filename:	 draft-tuexen-tsvwg-sctp-dtls-encaps
Revision:	 00
Title:		 DTLS Encapsulation of SCTP Packets for RTCWEB
Creation date:	 2012-03-04
WG ID:		 Individual Submission
Number of pages: 8

Abstract:
   The Stream Control Transmission Protocol (SCTP) is a transport
   protocol originally defined to run on top of the network protocols
   IPv4 or IPv6.  This memo document specifies how SCTP can be used on
   top of the Datagram Transport Layer Security (DTLS) protocol.  SCTP
   over DTLS is used by the RTCWeb protocol suite for transporting non-
   media data between browsers.

                                                                                  


The IETF Secretariat
--------------010903030104020309060508-- From mperumal@cisco.com Sun Mar 4 13:28:21 2012 Return-Path: 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 D155821F8595 for ; Sun, 4 Mar 2012 13:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.952 X-Spam-Level: X-Spam-Status: No, score=-8.952 tagged_above=-999 required=5 tests=[AWL=1.647, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 IZmoczaUq7ph for ; Sun, 4 Mar 2012 13:28:21 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 309F921F858E for ; Sun, 4 Mar 2012 13:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=1956; q=dns/txt; s=iport; t=1330896501; x=1332106101; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=o1oy/WXiRe7Kj/+4JLBhzoHqoFC05+E0Ia3Wh2nU/1g=; b=KUoKIwTdeVSPypLlwBkYtNRtpnMenlVeEqsQB+S3UhN5IB0WAPf2nYDB LtnUYNfxPNjuRhLJLkRRBkwfIF/DqdzV8+flY9scTkL2b0zmZjySQ8F39 PwnT0Ljd3ZMEZfOmfvl6p3rMVm0906CxkgPNc4VWUy8NjSG4IkuiwwfqP I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EADneU09Io8UY/2dsb2JhbABDtVaBfQEBAQQBAQEPAR0KNBcGAQgRBAEBCwYNCgEHJh8HAQEFBAEECwgIARmHZQufMYEnAZYVjTuCP2MEiE6YEIRygms X-IronPort-AV: E=Sophos;i="4.73,530,1325462400"; d="scan'208";a="7071945" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 04 Mar 2012 21:28:10 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q24LSASt011975 for ; Sun, 4 Mar 2012 21:28:10 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 02:58:10 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Mar 2012 02:58:09 +0530 Message-ID: <1D062974A4845E4D8A343C653804920207BF0446@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-muthu-behave-consent-freshness-00.txt Thread-Index: Acz6R35Ou7QXi4NgRu2c98nsE863sQABhnug From: "Muthu Arul Mozhi Perumal (mperumal)" To: X-OriginalArrivalTime: 04 Mar 2012 21:28:10.0079 (UTC) FILETIME=[B27BDEF0:01CCFA4D] Subject: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 21:28:21 -0000 This I-D describes a new STUN usage for enabling WebRTC implementations to perform consent freshness. It is far from complete, but comments (especially on the design considerations/approach) are welcome.. Muthu -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, March 05, 2012 2:14 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-muthu-behave-consent-freshness-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : STUN Usage for Consent Freshness Author(s) : Muthu Arul Mozhi Perumal Dan Wing Hadriel Kaplan Filename : draft-muthu-behave-consent-freshness-00.txt Pages : 10 Date : 2012-03-04 This document describes a STUN usage that enables WebRTC implementations to verify the peer consent for continuing to receive traffic on a candidate pair ICE is using for a media component after session establishment. Verification of peer consent is necessary to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks. This form of consent verification also serves the purpose of refreshing NAT bindings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muthu-behave-consent-freshness -00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-muthu-behave-consent-freshness- 00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From harald@alvestrand.no Sun Mar 4 13:56:37 2012 Return-Path: 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 75D9A21F8611 for ; Sun, 4 Mar 2012 13:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.285 X-Spam-Level: X-Spam-Status: No, score=-110.285 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, 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 5pbVRt4puPLv for ; Sun, 4 Mar 2012 13:56:36 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 69DF121F85EE for ; Sun, 4 Mar 2012 13:56:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4BCCB39E099 for ; Sun, 4 Mar 2012 22:56:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRKDYudWdxW4 for ; Sun, 4 Mar 2012 22:56:34 +0100 (CET) Received: from [192.168.11.107] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 8760039E088 for ; Sun, 4 Mar 2012 22:56:34 +0100 (CET) Message-ID: <4F53E513.40002@alvestrand.no> Date: Sun, 04 Mar 2012 22:56:35 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------070905040602090207080404" Subject: [rtcweb] draft-jesup-rtp-congestion-reqs-00.txt: Requirements for RTP congestion control X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 21:56:37 -0000 This is a multi-part message in MIME format. --------------070905040602090207080404 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit For the WG's interest. This (among other inputs) will be discussed in the IRTF ICCRG WG on Tuesday in Paris. Harald -------- Original Message -------- Subject: New Version Notification for draft-jesup-rtp-congestion-reqs-00.txt Date: Sun, 04 Mar 2012 06:19:29 -0800 From: internet-drafts@ietf.org To: harald@alvestrand.no CC: randell-ietf@jesup.org A new version of I-D, draft-jesup-rtp-congestion-reqs-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-jesup-rtp-congestion-reqs Revision: 00 Title: Congestion Control Requirements For Real Time Media Creation date: 2012-03-04 WG ID: Individual Submission Number of pages: 7 Abstract: Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real time multimedia, which needs by low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages, and the TCP algorithms are not suitable for this traffic. This document attempts to describe a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose. The IETF Secretariat --------------070905040602090207080404 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit For the WG's interest.
This (among other inputs) will be discussed in the IRTF ICCRG WG on Tuesday in Paris.

              Harald

-------- Original Message --------
Subject: New Version Notification for draft-jesup-rtp-congestion-reqs-00.txt
Date: Sun, 04 Mar 2012 06:19:29 -0800
From: internet-drafts@ietf.org
To: harald@alvestrand.no
CC: randell-ietf@jesup.org 


A new version of I-D, draft-jesup-rtp-congestion-reqs-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.

Filename:	 draft-jesup-rtp-congestion-reqs
Revision:	 00
Title:		 Congestion Control Requirements For Real Time Media
Creation date:	 2012-03-04
WG ID:		 Individual Submission
Number of pages: 7

Abstract:
   Congestion control is needed for all data transported across the
   Internet, in order to promote fair usage and prevent congestion
   collapse.  The requirements for interactive, point-to-point real time
   multimedia, which needs by low-delay, semi-reliable data delivery,
   are different from the requirements for bulk transfer like FTP or
   bursty transfers like Web pages, and the TCP algorithms are not
   suitable for this traffic.

   This document attempts to describe a set of requirements that can be
   used to evaluate other congestion control mechanisms in order to
   figure out their fitness for this purpose.


                                                                                  


The IETF Secretariat
--------------070905040602090207080404-- From jmpolk@cisco.com Sun Mar 4 14:16:43 2012 Return-Path: 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 22DCB21F853B for ; Sun, 4 Mar 2012 14:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.563 X-Spam-Level: X-Spam-Status: No, score=-109.563 tagged_above=-999 required=5 tests=[AWL=0.809, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, 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 NnuG+5R9XrCQ for ; Sun, 4 Mar 2012 14:16:42 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 450D521F8531 for ; Sun, 4 Mar 2012 14:16:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2806; q=dns/txt; s=iport; t=1330899402; x=1332109002; h=message-id:date:to:from:subject:in-reply-to:references: mime-version:content-transfer-encoding; bh=cbOJOM1P1NaZtcLL0qr2TvlMBzm6s58qhPjXLzKVTR4=; b=LaV+E24hF20GWpmTN8vWnt/y2Thz4dPd0qycR5Rj2dNZZLr+ezS+Wiun 0/rZ9Puuw9f2GqK9KdFb/vX31BqNSlTvV/mF1b43gJUNEbbC9h9b1Dtxk OFFegUwcUYJRFCaAI8I7VdKX4K3OVfxMTWECJW7yT08qIrWQNG2BKtMN4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANLoU0+rRDoH/2dsb2JhbABDtEKBB4F9AQEBBAEBAQ8BJTYXBAcCAhEDAQIBJwcZDh8JCAYBCQkJGYdkDJltAZ17kF0EiB0znQCDAg X-IronPort-AV: E=Sophos;i="4.73,531,1325462400"; d="scan'208";a="31867478" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 04 Mar 2012 22:16:41 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q24MGfal019061; Sun, 4 Mar 2012 22:16:41 GMT Message-Id: <201203042216.q24MGfal019061@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Mar 2012 16:16:40 -0600 To: Harald Alvestrand , "rtcweb@ietf.org" From: "James M. Polk" In-Reply-To: <4F53E513.40002@alvestrand.no> References: <4F53E513.40002@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] draft-jesup-rtp-congestion-reqs-00.txt: Requirements for RTP congestion control X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 22:16:43 -0000 Harald Which of these two is expected to be the conflict with rtp-congestion hour? TUESDAY, March 27, 2012 1500-1520 Beverage and Snack Break I - Hall Maillot A 1520-1700 Afternoon Session II 252A IRTF iccrg=20 Internet Congestion Control Research Group Maillot RAI avtext=20 Audio/Video Transport Extensions WG 253 RAI vipr=20 Verification Involving PSTN Reachability WG 1710-1810 Afternoon Session III 252A IRTF iccrg=20 Internet Congestion Control Research Group 252B RAI sipcore=20 Session Initiation Protocol Core WG I vote for Session II, but that's just one voice. Since most of us aren't part of the ICCRG mailing=20 list, can you ask and pass along which session=20 the rtp-congestion hour long discussion will be in? Thanks BTW - there already is no TSV conflict during either timeslot. James At 03:56 PM 3/4/2012, Harald Alvestrand wrote: >For the WG's interest. >This (among other inputs) will be discussed in=20 >the IRTF ICCRG WG on Tuesday in Paris. > >=C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 Harald > >-------- Original Message -------- >Subject: New Version Notification for= draft-jesup-rtp-congestion-reqs-00.txt >Date: Sun, 04 Mar 2012 06:19:29 -0800 >From: internet-drafts@ietf.org >To: harald@alvestrand.no >CC: randell-ietf@jesup.org > > > >A new version of I-D,=20 >draft-jesup-rtp-congestion-reqs-00.txt has been=20 >successfully submitted by Harald Alvestrand and posted to the IETF= repository. > >Filename: draft-jesup-rtp-congestion-reqs >Revision: 00 >Title: Congestion Control Requirements For Real Time Media >Creation date: 2012-03-04 >WG ID: Individual Submission >Number of pages: 7 > >Abstract: > Congestion control is needed for all data transported across the > Internet, in order to promote fair usage and prevent congestion > collapse. The requirements for interactive, point-to-point real time > multimedia, which needs by low-delay, semi-reliable data delivery, > are different from the requirements for bulk transfer like FTP or > bursty transfers like Web pages, and the TCP algorithms are not > suitable for this traffic. > > This document attempts to describe a set of requirements that can be > used to evaluate other congestion control mechanisms in order to > figure out their fitness for this purpose. > > >=20 > > > >The IETF Secretariat > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Sun Mar 4 21:32:32 2012 Return-Path: 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 AA47C21F8613 for ; Sun, 4 Mar 2012 21:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.297 X-Spam-Level: X-Spam-Status: No, score=-110.297 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, 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 0u1M3p297BS3 for ; Sun, 4 Mar 2012 21:32:31 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1781921F8646 for ; Sun, 4 Mar 2012 21:32:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4E34339E0D2; Mon, 5 Mar 2012 06:32:30 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CqLqLu+-Bxy; Mon, 5 Mar 2012 06:32:29 +0100 (CET) Received: from [192.168.11.107] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 31C8739E088; Mon, 5 Mar 2012 06:32:29 +0100 (CET) Message-ID: <4F544FEF.6060702@alvestrand.no> Date: Mon, 05 Mar 2012 06:32:31 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "James M. Polk" References: <4F53E513.40002@alvestrand.no> <201203042216.q24MGfal019061@mtv-core-2.cisco.com> In-Reply-To: <201203042216.q24MGfal019061@mtv-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-jesup-rtp-congestion-reqs-00.txt: Requirements for RTP congestion control X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 05:32:33 -0000 On 03/04/2012 11:16 PM, James M. Polk wrote: > Harald > > Which of these two is expected to be the conflict with rtp-congestion > hour? Thanks for the pointer to the conflict - I'll pass along to the ICCRG chairs. > > TUESDAY, March 27, 2012 > > 1500-1520 Beverage and Snack Break I - Hall Maillot A > 1520-1700 Afternoon Session II > 252A IRTF iccrg Internet Congestion Control > Research Group > Maillot RAI avtext Audio/Video Transport > Extensions WG > 253 RAI vipr Verification Involving PSTN > Reachability WG > > 1710-1810 Afternoon Session III > 252A IRTF iccrg Internet Congestion Control > Research Group > 252B RAI sipcore Session Initiation Protocol > Core WG > > I vote for Session II, but that's just one voice. I think so too. I don't know of RTCWEB related material in either session. > > Since most of us aren't part of the ICCRG mailing list, can you ask > and pass along which session the rtp-congestion hour long discussion > will be in? Thanks Will do. > > BTW - there already is no TSV conflict during either timeslot. > > James > > At 03:56 PM 3/4/2012, Harald Alvestrand wrote: >> For the WG's interest. >> This (among other inputs) will be discussed in the IRTF ICCRG WG on >> Tuesday in Paris. >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Harald >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-jesup-rtp-congestion-reqs-00.txt >> Date: Sun, 04 Mar 2012 06:19:29 -0800 >> From: internet-drafts@ietf.org >> To: harald@alvestrand.no >> CC: randell-ietf@jesup.org >> >> >> >> A new version of I-D, draft-jesup-rtp-congestion-reqs-00.txt has been >> successfully submitted by Harald Alvestrand and posted to the IETF >> repository. >> >> Filename: draft-jesup-rtp-congestion-reqs >> Revision: 00 >> Title: Congestion Control Requirements For Real Time Media >> Creation date: 2012-03-04 >> WG ID: Individual Submission >> Number of pages: 7 >> >> Abstract: >> Congestion control is needed for all data transported across the >> Internet, in order to promote fair usage and prevent congestion >> collapse. The requirements for interactive, point-to-point real time >> multimedia, which needs by low-delay, semi-reliable data delivery, >> are different from the requirements for bulk transfer like FTP or >> bursty transfers like Web pages, and the TCP algorithms are not >> suitable for this traffic. >> >> This document attempts to describe a set of requirements that can be >> used to evaluate other congestion control mechanisms in order to >> figure out their fitness for this purpose. >> >> >> >> >> >> >> The IETF Secretariat >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > From jmpolk@cisco.com Sun Mar 4 23:01:30 2012 Return-Path: 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 E866D21F8594 for ; Sun, 4 Mar 2012 23:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.598 X-Spam-Level: X-Spam-Status: No, score=-109.598 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, 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 K6zNkwcj6cGD for ; Sun, 4 Mar 2012 23:01:30 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA9F21F8593 for ; Sun, 4 Mar 2012 23:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3317; q=dns/txt; s=iport; t=1330930890; x=1332140490; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=05+t2zBY2mgUk93T0Vz9lJgPpVuExydpnOHRR+b0CSw=; b=mRidMFoB+u3mZM0/b8RZoYrKSaP1nLcxVGsDFtmk0qaYvLw8t75A+VwY q1hjSSrfLq+CFKjY5STvDi5+wA7QT8T/uSvUPKqynOSkEds3I9UGQh0bU F09mlZqPlOJajqowzb4nurV3xm5ZSinLnEFQVm3SzSSz/mvCtZRNiVR3l Q=; X-IronPort-AV: E=Sophos;i="4.73,532,1325462400"; d="scan'208";a="31907363" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 05 Mar 2012 07:01:29 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2571SVT030459; Mon, 5 Mar 2012 07:01:28 GMT Message-Id: <201203050701.q2571SVT030459@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 05 Mar 2012 01:01:27 -0600 To: Harald Alvestrand , "James M. Polk" From: "James M. Polk" In-Reply-To: <4F544FEF.6060702@alvestrand.no> References: <4F53E513.40002@alvestrand.no> <201203042216.q24MGfal019061@mtv-core-2.cisco.com> <4F544FEF.6060702@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-jesup-rtp-congestion-reqs-00.txt: Requirements for RTP congestion control X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 07:01:31 -0000 At 11:32 PM 3/4/2012, Harald Alvestrand wrote: >On 03/04/2012 11:16 PM, James M. Polk wrote: >>Harald >> >>Which of these two is expected to be the conflict with rtp-congestion= hour? >Thanks for the pointer to the conflict - I'll pass along to the ICCRG= chairs. >> >>TUESDAY, March 27, 2012 >> >>1500-1520 Beverage and Snack Break I - Hall Maillot A >>1520-1700 Afternoon Session II >>252A IRTF iccrg Internet=20 >>Congestion Control Research Group >>Maillot RAI avtext Audio/Video Transport Extensions WG >>253 RAI vipr=20 >>Verification Involving PSTN Reachability WG >> >>1710-1810 Afternoon Session III >>252A IRTF iccrg Internet=20 >>Congestion Control Research Group >>252B RAI sipcore Session Initiation Protocol Core= WG >> >>I vote for Session II, but that's just one voice. >I think so too. I don't know of RTCWEB related material in either session. fair - but you know there are a LOT of SIP heads in RTCWEB... James >>Since most of us aren't part of the ICCRG=20 >>mailing list, can you ask and pass along which=20 >>session the rtp-congestion hour long discussion will be in? Thanks > >Will do. > >> >>BTW - there already is no TSV conflict during either timeslot. >> >>James >> >>At 03:56 PM 3/4/2012, Harald Alvestrand wrote: >>>For the WG's interest. >>>This (among other inputs) will be discussed in=20 >>>the IRTF ICCRG WG on Tuesday in Paris. >>> >>>=C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 Harald >>> >>>-------- Original Message -------- >>>Subject: New Version Notification for= draft-jesup-rtp-congestion-reqs-00.txt >>>Date: Sun, 04 Mar 2012 06:19:29 -0800 >>>From: internet-drafts@ietf.org >>>To: harald@alvestrand.no >>>CC: randell-ietf@jesup.org >>> >>> >>> >>>A new version of I-D,=20 >>>draft-jesup-rtp-congestion-reqs-00.txt has=20 >>>been successfully submitted by Harald=20 >>>Alvestrand and posted to the IETF repository. >>> >>>Filename: draft-jesup-rtp-congestion-reqs >>>Revision: 00 >>>Title: Congestion Control Requirements For Real Time Media >>>Creation date: 2012-03-04 >>>WG ID: Individual Submission >>>Number of pages: 7 >>> >>>Abstract: >>> Congestion control is needed for all data transported across the >>> Internet, in order to promote fair usage and prevent congestion >>> collapse. The requirements for interactive, point-to-point real time >>> multimedia, which needs by low-delay, semi-reliable data delivery, >>> are different from the requirements for bulk transfer like FTP or >>> bursty transfers like Web pages, and the TCP algorithms are not >>> suitable for this traffic. >>> >>> This document attempts to describe a set of requirements that can be >>> used to evaluate other congestion control mechanisms in order to >>> figure out their fitness for this purpose. >>> >>> >>> >>> >>> >>> >>>The IETF Secretariat >>> >>> >>>_______________________________________________ >>>rtcweb mailing list >>>rtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb >> From stefan.lk.hakansson@ericsson.com Mon Mar 5 06:19:27 2012 Return-Path: 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 6051D21F86B0 for ; Mon, 5 Mar 2012 06:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.593 X-Spam-Level: X-Spam-Status: No, score=-9.593 tagged_above=-999 required=5 tests=[AWL=1.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 PuLzxL8LUvDI for ; Mon, 5 Mar 2012 06:19:26 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 27AD621F871E for ; Mon, 5 Mar 2012 06:19:25 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-53-4f54cb69b653 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F5.BC.01970.96BC45F4; Mon, 5 Mar 2012 15:19:21 +0100 (CET) Received: from [150.132.142.230] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Mar 2012 15:19:21 +0100 Message-ID: <4F54CB67.9010508@ericsson.com> Date: Mon, 5 Mar 2012 15:19:19 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> <4F4FC6D6.1040002@alvestrand.no> In-Reply-To: <4F4FC6D6.1040002@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Draft Agenda for WebRTC at IETF83 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 14:19:27 -0000 On 03/01/2012 07:58 PM, Harald Alvestrand wrote: > Good to get things out early! > > Some other things that may want to be on the agenda, either as reporting > from other groups or as items to discuss whether to take up elsewhere: > > - SDP updates: msid and bundle - our use of those functions being > defined in MMUSIC > - Use of multiplexing functions described by AVTCORE > - Congestion control as discussed in the ICCRG meeting > - RTP feature profiling: What do we use? (mandatory / permitted / > recommended-against) > - SDP feature profiling: What do we use? (same alternatives) > - Video resolution negotiation per SSRC: What are the alternatives? Can > we recommend one? I assume that you include re-negotiation as well (i.e. if the display size is changed during the session) in this topic. I think all the above are important topics, and we could also consider touching on: - Mute/hold signaling (per SSRC) - How to convey label/id of a MediaStreamTrack over a PeerConnection I don't know if it is appropriate to use meeting time for this, or if it should be done on the list, but these are things we need to sort out. Stefan > > And of course: > > - Implementation feedback that should lead to specification updates, if any > > > On 03/01/2012 06:22 PM, Cullen Jennings wrote: >> Given we are still before the draft deadline, this is a very draft agenda. Roughly speaking the plan is to spend the first session on security and second session on other things. >> >> Cullen, Magnus,& Ted >> >> >> >> Agenda >> >> First Session ------------------- >> >> Admin Update - 10 min >> - update from mmusic, avtcore, and other WG >> >> W3C Update - 10 min >> >> Identity Proxy - 50 min >> >> What to do about RTP and/or SDES - 80 min >> >> >> >> Second Session ----------------------- >> >> Admin - 10 min >> - scheduling of next interim meeting >> >> Signaling - 60 min >> >> Data Channel - 30 min >> >> Codec Selection - 50 min >> >> >> >> >> >> >> >> _______________________________________________ >> 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 From harald@alvestrand.no Mon Mar 5 06:37:11 2012 Return-Path: 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 C564021F8746 for ; Mon, 5 Mar 2012 06:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.522 X-Spam-Level: X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 DTy+Ai34l-5T for ; Mon, 5 Mar 2012 06:37:11 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D3B3121F8720 for ; Mon, 5 Mar 2012 06:37:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 254B439E08A for ; Mon, 5 Mar 2012 15:37:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnHtyyXxOKnE for ; Mon, 5 Mar 2012 15:37:09 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5EFFE39E062 for ; Mon, 5 Mar 2012 15:37:09 +0100 (CET) Message-ID: <4F54CF94.6050509@alvestrand.no> Date: Mon, 05 Mar 2012 15:37:08 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------030402090305050105020405" Subject: [rtcweb] Fwd: [MMUSIC] Request for MMUSIC review: draft-alvestrand-rtcweb-msid-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 14:37:11 -0000 This is a multi-part message in MIME format. --------------030402090305050105020405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI - I just sent the following message to MMUSIC. I have also asked for agenda time in MMUSIC in Paris. Please follow up in that list. Harald -------- Original Message -------- Subject: [MMUSIC] Request for MMUSIC review: draft-alvestrand-rtcweb-msid-01 Date: Mon, 05 Mar 2012 15:29:15 +0100 From: Harald Alvestrand To: mmusic Hello, this is a request for a cross-group review and evaluation for wider application: In the WebRTC effort, the W3C group has identified a preferred programming model that involves bundling one or more video or audio tracks together in something called a "MediaStream". The RTCWEB WG has decided that it is not appropriate to use a CNAME to group these together, since one identity or synchronization context (which CNAME is the primary identifier for) may be the source of multiple MediaStreams. This means that media flows inside an RTP session have to be associated with MediaStreams some other way. One suggestion for this function is described here: draft-alvestrand-rtcweb-msid-01 which also contains some background and notes about other approaches we did not pick. A presentation of the function is available from the minutes of the RTCWEB interim meeting here: http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/proceedings.html the URL of the presentation is: http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/slides/rtcweb-5.pdf I hope this information is suitable for the MMUSIC group to give guidance on further processing, including whether this draft needs to be an MMUSIC draft or an RTCWEB draft. Harald _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------030402090305050105020405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI - I just sent the following message to MMUSIC. I have also asked for agenda time in MMUSIC in Paris.
Please follow up in that list.

               Harald

-------- Original Message --------
Subject: [MMUSIC] Request for MMUSIC review: draft-alvestrand-rtcweb-msid-01
Date: Mon, 05 Mar 2012 15:29:15 +0100
From: Harald Alvestrand <harald@alvestrand.no>
To: mmusic <mmusic@ietf.org> 


Hello,

this is a request for a cross-group review and evaluation for wider 
application:

In the WebRTC effort, the W3C group has identified a preferred 
programming model that involves bundling one or more video or audio 
tracks together in something called a "MediaStream".

The RTCWEB WG has decided that it is not appropriate to use a CNAME to 
group these together, since one identity or synchronization context 
(which CNAME is the primary identifier for) may be the source of 
multiple MediaStreams.

This means that media flows inside an RTP session have to be associated 
with MediaStreams some other way.

One suggestion for this function is described here:

draft-alvestrand-rtcweb-msid-01

which also contains some background and notes about other approaches we 
did not pick.

A presentation of the function is available from the minutes of the 
RTCWEB interim meeting here:
http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/proceedings.html

the URL of the presentation is:

http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/slides/rtcweb-5.pdf

I hope this information is suitable for the MMUSIC group to give 
guidance on further processing, including whether this draft needs to be 
an MMUSIC draft or an RTCWEB draft.

                            Harald

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
--------------030402090305050105020405-- From fluffy@iii.ca Mon Mar 5 07:29:26 2012 Return-Path: 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 4EFC121F8794 for ; Mon, 5 Mar 2012 07:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599] 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 IdVDTngKcy+d for ; Mon, 5 Mar 2012 07:29:25 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C94E621F8780 for ; Mon, 5 Mar 2012 07:29:25 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4697F22E256 for ; Mon, 5 Mar 2012 10:29:19 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Cullen Jennings In-Reply-To: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> Date: Mon, 5 Mar 2012 08:29:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [rtcweb] Draft Agenda for WebRTC at IETF83 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:29:26 -0000 Another possible topic is the Behave chairs would prefer we deal with = the STUN and TURN URIs in RTCWeb.=20 On Mar 1, 2012, at 10:22 AM, Cullen Jennings wrote: >=20 > Given we are still before the draft deadline, this is a very draft = agenda. Roughly speaking the plan is to spend the first session on = security and second session on other things.=20 >=20 > Cullen, Magnus, & Ted >=20 >=20 >=20 > Agenda=20 >=20 > First Session ------------------- >=20 > Admin Update - 10 min=20 > - update from mmusic, avtcore, and other WG=20 >=20 > W3C Update - 10 min >=20 > Identity Proxy - 50 min=20 >=20 > What to do about RTP and/or SDES - 80 min=20 >=20 >=20 >=20 > Second Session ----------------------- >=20 > Admin - 10 min=20 > - scheduling of next interim meeting=20 >=20 > Signaling - 60 min =20 >=20 > Data Channel - 30 min >=20 > Codec Selection - 50 min >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From igor.faynberg@alcatel-lucent.com Mon Mar 5 07:43:12 2012 Return-Path: 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 25B6921F87BC for ; Mon, 5 Mar 2012 07:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.17 X-Spam-Level: X-Spam-Status: No, score=-7.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UsCsHPQcASbK for ; Mon, 5 Mar 2012 07:43:11 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 72A0421F87B5 for ; Mon, 5 Mar 2012 07:43:11 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q25Fh9wh016994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 5 Mar 2012 09:43:09 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q25Fh8lQ032463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Mar 2012 09:43:09 -0600 Received: from [135.244.19.210] (faynberg.lra.lucent.com [135.244.19.210]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q25Fh8wZ000585; Mon, 5 Mar 2012 09:43:08 -0600 (CST) Message-ID: <4F54DF0C.2000408@alcatel-lucent.com> Date: Mon, 05 Mar 2012 10:43:08 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [rtcweb] Draft Agenda for WebRTC at IETF83 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:43:12 -0000 One question: How do the STUN and TURN matters in the RTCWeb environment differ from those in non-RTCWeb environments? In other words, what will RTCWeb do differently? Igor On 3/5/2012 10:29 AM, Cullen Jennings wrote: > Another possible topic is the Behave chairs would prefer we deal with the STUN and TURN URIs in RTCWeb. > > On Mar 1, 2012, at 10:22 AM, Cullen Jennings wrote: > >> Given we are still before the draft deadline, this is a very draft agenda. Roughly speaking the plan is to spend the first session on security and second session on other things. >> >> Cullen, Magnus,& Ted >> >> >> >> Agenda >> >> First Session ------------------- >> >> Admin Update - 10 min >> - update from mmusic, avtcore, and other WG >> >> W3C Update - 10 min >> >> Identity Proxy - 50 min >> >> What to do about RTP and/or SDES - 80 min >> >> >> >> Second Session ----------------------- >> >> Admin - 10 min >> - scheduling of next interim meeting >> >> Signaling - 60 min >> >> Data Channel - 30 min >> >> Codec Selection - 50 min >> >> >> >> >> >> >> >> _______________________________________________ >> 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 From petithug@acm.org Mon Mar 5 07:59:11 2012 Return-Path: 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 ADB5921F87ED for ; Mon, 5 Mar 2012 07:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 64I8wMQ5DMIi for ; Mon, 5 Mar 2012 07:59:11 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id CA39721F87E3 for ; Mon, 5 Mar 2012 07:59:10 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 21A7E20474; Mon, 5 Mar 2012 15:42:22 +0000 (UTC) Message-ID: <4F54E2CA.7060301@acm.org> Date: Mon, 05 Mar 2012 07:59:06 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> <4F54DF0C.2000408@alcatel-lucent.com> In-Reply-To: <4F54DF0C.2000408@alcatel-lucent.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Draft Agenda for WebRTC at IETF83 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:59:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/05/2012 07:43 AM, Igor Faynberg wrote: > One question: How do the STUN and TURN matters in the RTCWeb environment > differ from those in non-RTCWeb environments? It is not about STUN/TURN, it is about STUN/TURN *URI*, i.e. how the STUN/TURN server is provisioned. > > In other words, what will RTCWeb do differently? > > Igor > > > > > On 3/5/2012 10:29 AM, Cullen Jennings wrote: >> Another possible topic is the Behave chairs would prefer we deal with the >> STUN and TURN URIs in RTCWeb. >> >> On Mar 1, 2012, at 10:22 AM, Cullen Jennings wrote: >> >>> Given we are still before the draft deadline, this is a very draft >>> agenda. Roughly speaking the plan is to spend the first session on >>> security and second session on other things. >>> >>> Cullen, Magnus,& Ted >>> >>> >>> >>> Agenda >>> >>> First Session ------------------- >>> >>> Admin Update - 10 min - update from mmusic, avtcore, and other WG >>> >>> W3C Update - 10 min >>> >>> Identity Proxy - 50 min >>> >>> What to do about RTP and/or SDES - 80 min >>> >>> >>> >>> Second Session ----------------------- >>> >>> Admin - 10 min - scheduling of next interim meeting >>> >>> Signaling - 60 min >>> >>> Data Channel - 30 min >>> >>> Codec Selection - 50 min >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ 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 > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPVOLJAAoJECnERZXWan7EYEIP/3X6eq+RTgD4H7AxEZQ1mLXY Pp9MboW4uf47IYd54E0nJLQhIggRLjnARElLSQ2MtuBIQOOUb5LwpGUiuMuuWHO9 7QWHUhWrE3aKjFWAjWrEEmeGVDt+Y9dqTAYFCunfuWevVQOVPUXtJ+YRuPzyq8Wj VxWniXgCaS78JCruqamWVvmuvR3W/elfAhFf8Q5jM2dlSZNg1dQ/HEQgBjttYS0r 0L47yEIDtI3srfb0dIHe1E/bRg0UMDkxC14pfhpHB8pkg7Qh6qrS5ZBwh7HV7g/W S04T+pdz4I1oXP3SXu48mjkyrzd85SqZpATitBIrS6xXScTcvjcXVE2es0baBD1i ZPeyzc59b3DhK+wQH2HrM3b9ZljakfJIYl3KB8bOIbgeuI+R0R52swDxPXWfXtJJ PWhTbSSdlOSHAD3X8/L8EiFHEt2EO1MNF+RiSX8XCHpT5YQfV8wI8tM3Ujg5e6dL 7L5rfsR/KYnxF9zL2NWa7WOlcUKWyCabLIB69HBXEngYg/LtJOQAM/n1BiNsl0jb 766TADKA+2YBtnnB68Fdm3ZayHHTwPEfwZTR3Aj+r6Jqs5hKlcFDCG+z4xmKKO5Y JP+31BixA/o7XKOCGeCf5WGEZwrXg4PSLW+/2zQreDCmcrbOV/gfNCwySTNu8VrC fq7frHeDNcRi1Re001I6 =ebgo -----END PGP SIGNATURE----- From harald@alvestrand.no Mon Mar 5 11:05:57 2012 Return-Path: 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 2136521F8836 for ; Mon, 5 Mar 2012 11:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 SlsdV6eGm1u2 for ; Mon, 5 Mar 2012 11:05:56 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1836821F87FA for ; Mon, 5 Mar 2012 11:05:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0370939E08A for ; Mon, 5 Mar 2012 20:05:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0nYybSUtnkP for ; Mon, 5 Mar 2012 20:05:54 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3EF6939E062 for ; Mon, 5 Mar 2012 20:05:54 +0100 (CET) Message-ID: <4F550E91.8020002@alvestrand.no> Date: Mon, 05 Mar 2012 20:05:53 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------000403020808000607010204" Subject: [rtcweb] Fwd: Proof of concept: ROAP on top of JSEP - 184 lines and counting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:05:57 -0000 This is a multi-part message in MIME format. --------------000403020808000607010204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This might be of interest to people on rtcweb too. Please keep the discussion on webrtc if at all possible, so that we don't do it in both places all the time. Harald -------- Original Message -------- Subject: Proof of concept: ROAP on top of JSEP - 184 lines and counting Resent-Date: Mon, 05 Mar 2012 13:02:06 +0000 Resent-From: public-webrtc@w3.org Date: Mon, 05 Mar 2012 14:01:25 +0100 From: Harald Alvestrand To: public-webrtc@w3.org Hi, my weekend project is now visible to the world: I implemented a layer of Javascript code that allows you to program against the ROAP interface while using a JSEP object underneath it. I have not implemented all aspects, but it's enough to do some testing. For instance, close() is not implemented :-) - and I also left out retransmission and actual glare handling. (Of course, since JSEP isn't implemented yet, I had to create a dummy JSEP to run my code against... this is also included.) There are several aspects that show some degree of DOM/JS ignorance, for instance: - I don't know how to dispatch a signal from Javascript. Instead, I use window.setTimeout() to achieve a similar-looking result: Getting something to happen after the current function finishes. - I don't know the proper way to generate errors for throwing. So the code throws text strings when something bad happens. Still, it's a fairly self-contained piece of code; I think it demonstrates the order of magnitude of the library that's needed to allow people to use a ROAP programming model on top of JSEP. Comments (and patches) welcome! The code is here: http://code.google.com/p/webrtc-samples/source/browse/#svn%2Ftrunk%2Froap-jsep Have fun! Harald --------------000403020808000607010204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This might be of interest to people on rtcweb too.
Please keep the discussion on webrtc if at all possible, so that we don't do it in both places all the time.

              Harald

-------- Original Message --------
Subject: Proof of concept: ROAP on top of JSEP - 184 lines and counting
Resent-Date: Mon, 05 Mar 2012 13:02:06 +0000
Resent-From: public-webrtc@w3.org
Date: Mon, 05 Mar 2012 14:01:25 +0100
From: Harald Alvestrand <harald@alvestrand.no>
To: public-webrtc@w3.org <public-webrtc@w3.org> 


Hi,

my weekend project is now visible to the world:
I implemented a layer of Javascript code that allows you to program 
against the ROAP interface while using a JSEP object underneath it.

I have not implemented all aspects, but it's enough to do some testing. 
For instance, close() is not implemented :-) - and I also left out 
retransmission and actual glare handling.

(Of course, since JSEP isn't implemented yet, I had to create a dummy 
JSEP to run my code against... this is also included.)

There are several aspects that show some degree of DOM/JS ignorance, for 
instance:

- I don't know how to dispatch a signal from Javascript. Instead, I use 
window.setTimeout() to achieve a similar-looking result: Getting 
something to happen after the current function finishes.

- I don't know the proper way to generate errors for throwing. So the 
code throws text strings when something bad happens.

Still, it's a fairly self-contained piece of code; I think it 
demonstrates the order of magnitude of the library that's needed to 
allow people to use a ROAP programming model on top of JSEP.

Comments (and patches) welcome!

The code is here:

http://code.google.com/p/webrtc-samples/source/browse/#svn%2Ftrunk%2Froap-jsep

Have fun!

                        Harald
--------------000403020808000607010204-- From igor.faynberg@alcatel-lucent.com Mon Mar 5 14:21:56 2012 Return-Path: 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 3034221E8035 for ; Mon, 5 Mar 2012 14:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EsjfEc7TQIG7 for ; Mon, 5 Mar 2012 14:21:55 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id EB83821E8049 for ; Mon, 5 Mar 2012 14:21:54 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q25MLpL4017041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Mar 2012 16:21:52 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q25MLpYe013429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Mar 2012 16:21:51 -0600 Received: from [135.222.134.168] (USMUYN0L055118.mh.lucent.com [135.222.134.168]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q25MLoXq008280; Mon, 5 Mar 2012 16:21:51 -0600 (CST) Message-ID: <4F553C7E.4080100@alcatel-lucent.com> Date: Mon, 05 Mar 2012 17:21:50 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> <4F54DF0C.2000408@alcatel-lucent.com> <4F54E2CA.7060301@acm.org> In-Reply-To: <4F54E2CA.7060301@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Draft Agenda for WebRTC at IETF83 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:21:56 -0000 Ah, I have not followed this discussion on Behave. I will be interested in learning what has transpired there. Igor On 3/5/2012 10:59 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 03/05/2012 07:43 AM, Igor Faynberg wrote: >> One question: How do the STUN and TURN matters in the RTCWeb environment >> differ from those in non-RTCWeb environments? > It is not about STUN/TURN, it is about STUN/TURN *URI*, i.e. how the STUN/TURN > server is provisioned. > >> In other words, what will RTCWeb do differently? >> >> Igor >> >> >> >> >> On 3/5/2012 10:29 AM, Cullen Jennings wrote: >>> Another possible topic is the Behave chairs would prefer we deal with the >>> STUN and TURN URIs in RTCWeb. >>> >>> On Mar 1, 2012, at 10:22 AM, Cullen Jennings wrote: >>> >>>> Given we are still before the draft deadline, this is a very draft >>>> agenda. Roughly speaking the plan is to spend the first session on >>>> security and second session on other things. >>>> >>>> Cullen, Magnus,& Ted >>>> >>>> >>>> >>>> Agenda >>>> >>>> First Session ------------------- >>>> >>>> Admin Update - 10 min - update from mmusic, avtcore, and other WG >>>> >>>> W3C Update - 10 min >>>> >>>> Identity Proxy - 50 min >>>> >>>> What to do about RTP and/or SDES - 80 min >>>> >>>> >>>> >>>> Second Session ----------------------- >>>> >>>> Admin - 10 min - scheduling of next interim meeting >>>> >>>> Signaling - 60 min >>>> >>>> Data Channel - 30 min >>>> >>>> Codec Selection - 50 min >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ 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 >> > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJPVOLJAAoJECnERZXWan7EYEIP/3X6eq+RTgD4H7AxEZQ1mLXY > Pp9MboW4uf47IYd54E0nJLQhIggRLjnARElLSQ2MtuBIQOOUb5LwpGUiuMuuWHO9 > 7QWHUhWrE3aKjFWAjWrEEmeGVDt+Y9dqTAYFCunfuWevVQOVPUXtJ+YRuPzyq8Wj > VxWniXgCaS78JCruqamWVvmuvR3W/elfAhFf8Q5jM2dlSZNg1dQ/HEQgBjttYS0r > 0L47yEIDtI3srfb0dIHe1E/bRg0UMDkxC14pfhpHB8pkg7Qh6qrS5ZBwh7HV7g/W > S04T+pdz4I1oXP3SXu48mjkyrzd85SqZpATitBIrS6xXScTcvjcXVE2es0baBD1i > ZPeyzc59b3DhK+wQH2HrM3b9ZljakfJIYl3KB8bOIbgeuI+R0R52swDxPXWfXtJJ > PWhTbSSdlOSHAD3X8/L8EiFHEt2EO1MNF+RiSX8XCHpT5YQfV8wI8tM3Ujg5e6dL > 7L5rfsR/KYnxF9zL2NWa7WOlcUKWyCabLIB69HBXEngYg/LtJOQAM/n1BiNsl0jb > 766TADKA+2YBtnnB68Fdm3ZayHHTwPEfwZTR3Aj+r6Jqs5hKlcFDCG+z4xmKKO5Y > JP+31BixA/o7XKOCGeCf5WGEZwrXg4PSLW+/2zQreDCmcrbOV/gfNCwySTNu8VrC > fq7frHeDNcRi1Re001I6 > =ebgo > -----END PGP SIGNATURE----- From internet-drafts@ietf.org Mon Mar 5 15:49:14 2012 Return-Path: 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 DD43321E806A; Mon, 5 Mar 2012 15:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 5xlwFzmCkISx; Mon, 5 Mar 2012 15:49:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A9621E801E; Mon, 5 Mar 2012 15:49:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120305234914.31538.81101.idtracker@ietfa.amsl.com> Date: Mon, 05 Mar 2012 15:49:14 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:49:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : RTCWeb Datagram Connection Author(s) : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-channel-00.txt Pages : 12 Date : 2012-03-05 The Web Real-Time Communication (WebRTC) working group is charged to provide protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document describes the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing Web Browser to exchange generic data from peer to peer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-data-channel-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-data-channel-00.txt From martin.thomson@gmail.com Mon Mar 5 16:28:28 2012 Return-Path: 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 EC54821F8736 for ; Mon, 5 Mar 2012 16:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.936 X-Spam-Level: X-Spam-Status: No, score=-4.936 tagged_above=-999 required=5 tests=[AWL=-1.337, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 HwjMQ9R9pB5s for ; Mon, 5 Mar 2012 16:28:28 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32E6621F8701 for ; Mon, 5 Mar 2012 16:28:28 -0800 (PST) Received: by bkuw5 with SMTP id w5so4378750bku.31 for ; Mon, 05 Mar 2012 16:28:27 -0800 (PST) Received-SPF: pass (google.com: domain of martin.thomson@gmail.com designates 10.204.141.11 as permitted sender) client-ip=10.204.141.11; Authentication-Results: mr.google.com; spf=pass (google.com: domain of martin.thomson@gmail.com designates 10.204.141.11 as permitted sender) smtp.mail=martin.thomson@gmail.com; dkim=pass header.i=martin.thomson@gmail.com Received: from mr.google.com ([10.204.141.11]) by 10.204.141.11 with SMTP id k11mr11753562bku.5.1330993707355 (num_hops = 1); Mon, 05 Mar 2012 16:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LIrjFAu1+XuALY73sHOwWAIc8BjpCjCEPU/UVULcLl8=; b=opxvhG8F8pPCHDu/u5s2vFNsBcwKAtrkIFhHH2mrH1drJjXK7fRqzZBviQk3tuMKas w5Rx/sbgI7OKKgJPv405kj/INdxDB1hTiLmd/wieqSK//jIQX4FzxymwtKjo/c7tcLV/ 9ZSS1P6laQ77K1fY1imKmPh3WfgJQpBU7CZBlpVakD+ru3MDJYddA4aOY+j+bPHRceix R/+hAVxiEksEdqslxBKGO8aCr0+oouQJPOO0VEZ0J4tndH7Uafzpwyg8yVYmGSnsHDog zShqU4tmM3yBJIZ4JTOIPbhvjDK7q7lhccF459FJltmM53na2qelqcg4cmNs1Ej16GLZ 5o5Q== MIME-Version: 1.0 Received: by 10.204.141.11 with SMTP id k11mr9338227bku.5.1330993707157; Mon, 05 Mar 2012 16:28:27 -0800 (PST) Received: by 10.204.232.74 with HTTP; Mon, 5 Mar 2012 16:28:27 -0800 (PST) In-Reply-To: References: <1811FEAA-F080-4E10-A930-E5575CE5F86D@iii.ca> Date: Mon, 5 Mar 2012 16:28:27 -0800 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Draft Agenda for WebRTC at IETF83 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 00:28:29 -0000 On 5 March 2012 07:29, Cullen Jennings wrote: > Another possible topic is the Behave chairs would prefer we deal with the STUN and TURN URIs in RTCWeb. That's great, but I don't see how rtcweb can use them. I suspect that WebRTC could, maybe some implementations might, but if the idea is to poke STUN/TURN configuration into the browser, then rtcweb has very little to say about the matter. From rachel.huang@huawei.com Mon Mar 5 17:14:53 2012 Return-Path: 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 B63A021F8548 for ; Mon, 5 Mar 2012 17:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 0YylWlYAVaTb for ; Mon, 5 Mar 2012 17:14:53 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id EFF1321F8546 for ; Mon, 5 Mar 2012 17:14:52 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0F00MDHVGIA5@szxga03-in.huawei.com> for rtcweb@ietf.org; Tue, 06 Mar 2012 09:14:42 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0F00DB7VGI72@szxga03-in.huawei.com> for rtcweb@ietf.org; Tue, 06 Mar 2012 09:14:42 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHG27363; Tue, 06 Mar 2012 09:14:42 +0800 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 09:14:25 +0800 Received: from SZXEML539-MBX.china.huawei.com ([169.254.6.110]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Tue, 06 Mar 2012 09:14:37 +0800 Date: Tue, 06 Mar 2012 01:14:35 +0000 From: "Rachel Huang(yihong)" X-Originating-IP: [10.138.41.163] To: "rtcweb@ietf.org" Message-id: <51E6A56BD6A85142B9D172C87FC3ABBB23401073@szxeml539-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-huang-rtcweb-monitoring-00.txt Thread-index: AQHM+p7z270gEuRCh0+ynH4B/PEhyZZcc2UA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [rtcweb] FW: New Version Notification for draft-huang-rtcweb-monitoring-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 01:14:53 -0000 Hi all, We prepared a draft to describe the monitoring usage in RTCWEB. It discusses the current monitoring issues, and gives some guidelines for the selection of RTCP metrics. It is far from complete. Any comments and suggestions are welcomed. Best Regards! Rachel -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, March 05, 2012 3:09 PM To: Rachel Huang(yihong) Cc: Rachel Huang(yihong); roni.even@huawei.com Subject: New Version Notification for draft-huang-rtcweb-monitoring-00.txt A new version of I-D, draft-huang-rtcweb-monitoring-00.txt has been successfully submitted by Rachel Huang and posted to the IETF repository. Filename: draft-huang-rtcweb-monitoring Revision: 00 Title: Web Real-Time Communication (RTCWEB): Monitoring Usage Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 10 Abstract: This document describes the monitoring aspect usage in RTCWeb. It also gives some guidelines for which RTCP XR metrics and extentions need to be supported. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-huang-rtcweb-monitoring-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-huang-rtcweb-monitoring-00.txt The IETF Secretariat From randell-ietf@jesup.org Mon Mar 5 20:29:52 2012 Return-Path: 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 F28BB21F859E for ; Mon, 5 Mar 2012 20:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 nfYbNDDgGdxx for ; Mon, 5 Mar 2012 20:29:51 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 731BC21F8598 for ; Mon, 5 Mar 2012 20:29:51 -0800 (PST) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1S4m22-0006wI-HE for rtcweb@ietf.org; Mon, 05 Mar 2012 22:29:50 -0600 Message-ID: <4F55924B.50807@jesup.org> Date: Mon, 05 Mar 2012 23:27:55 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: [rtcweb] I-D Action: draft-jesup-rtcweb-data-protocoll-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 04:29:52 -0000 You can find the I-D here: http://www.ietf.org/id/draft-jesup-rtcweb-data-protocol-00.txt This (minor) protocol provides bidirectional data channels on top of SCTP, per recent discussions, to support the requirements of draft-ietf-rtcweb-data-channel. This protocol should be applicable to other uses of SCTP as well. Randell A new version of I-D, draft-jesup-rtcweb-data-protocol-00.txt has been successfully submitted by Randell Jesup and posted to the IETF repository. Filename: draft-jesup-rtcweb-data-protocol Revision: 00 Title: WebRTC Data Channel Protocol Creation date: 2012-03-06 WG ID: Individual Submission Number of pages: 9 Abstract: The Web Real-Time Communication (WebRTC) working group is charged to provide protocols to support for direct interactive rich communication using audio, video, and data between two peers' web- browsers. This document specifies an actual (minor) protocol for how the JS-layer dataChannel objects provide the data channels between the peers. This minor protocol has applicability to other bidirectional uses of SCTP. -- Randell Jesup randell-ietf@jesup.org From stefan.lk.hakansson@ericsson.com Tue Mar 6 01:28:35 2012 Return-Path: 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 02A7221F87F7 for ; Tue, 6 Mar 2012 01:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.665 X-Spam-Level: X-Spam-Status: No, score=-9.665 tagged_above=-999 required=5 tests=[AWL=0.934, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 PXbk9-Nall-T for ; Tue, 6 Mar 2012 01:28:34 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE1321F87E5 for ; Tue, 6 Mar 2012 01:28:33 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-ec-4f55d8c01002 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D5.B6.27041.0C8D55F4; Tue, 6 Mar 2012 10:28:32 +0100 (CET) Received: from [150.132.142.230] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Tue, 6 Mar 2012 10:28:32 +0100 Message-ID: <4F55D8BF.1040703@ericsson.com> Date: Tue, 6 Mar 2012 10:28:31 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Use-case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 09:28:35 -0000 Hi! The Use-case document () will expire in early April. The editors propose to add a new use-case when updating to -07. The new use-case is about large sessions and is inspired by input made earlier by Arno Bakker (http://www.ietf.org/mail-archive/web/rtcweb/current/msg00530.html) and recently by Harald Alvestrand (http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0066.html). Proposed text for the new use-case: On-line lecture =============== A lecture is given on-line by a very popular lecturer. The attendance is very large. Because of this it is not really feasible to have direct audiovisual feedback (for e.g. questions) for every participant, instead participants can request the floor by clicking a button, and gets a signal when audio and video has been set up (and the lecturer is ready to take the question). The question is heard by all participants (not only the lecturer). Participants can join and leave the lecture at any time (i.e. they do not need to be there at the start to be able to connect). The service is operated by the university of the lecturer. It is set up such that all participants connect to a central node. The university can not invest much in HW, so the processing required (per participant) must be minimized. New requirement: - It must be possible to set up media streams and encryption in such a way that processing in a central node is minimized (no transcoding required, no decryption/re-encryption for every outgoing flow - just simple forwarding). Let us know what you think. If there is support we will add this use-case, if not we will just make a new revision of the document (with no major changes to the content). Stefan for the editors From ekr@rtfm.com Tue Mar 6 05:01:53 2012 Return-Path: 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 C059C21F88F4 for ; Tue, 6 Mar 2012 05:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.089 X-Spam-Level: X-Spam-Status: No, score=-103.089 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 8F3UZh1ud0uT for ; Tue, 6 Mar 2012 05:01:52 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E50C21F88F3 for ; Tue, 6 Mar 2012 05:01:52 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so5042767vcb.31 for ; Tue, 06 Mar 2012 05:01:52 -0800 (PST) Received-SPF: pass (google.com: domain of ekr@rtfm.com designates 10.52.29.75 as permitted sender) client-ip=10.52.29.75; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ekr@rtfm.com designates 10.52.29.75 as permitted sender) smtp.mail=ekr@rtfm.com Received: from mr.google.com ([10.52.29.75]) by 10.52.29.75 with SMTP id i11mr41081317vdh.23.1331038912258 (num_hops = 1); Tue, 06 Mar 2012 05:01:52 -0800 (PST) Received: by 10.52.29.75 with SMTP id i11mr35151909vdh.23.1331038912137; Tue, 06 Mar 2012 05:01:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.70.136 with HTTP; Tue, 6 Mar 2012 05:01:12 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <4F55D8BF.1040703@ericsson.com> References: <4F55D8BF.1040703@ericsson.com> From: Eric Rescorla Date: Tue, 6 Mar 2012 05:01:12 -0800 Message-ID: To: Stefan Hakansson LK Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkuhezfV0Ks0BnUsk+pTc3/hBCsA2Lll7ucmhp8z7F5Aj04xT18IMy+lBFOeCmsl0Xep+ol Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Use-case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:01:53 -0000 Obviously, this is an interesting use case, but it's not clear to me that it's something you would want to address entirely via WebRTC 1. It seems likely that the lecturer will be using something rather more sophisticated than a Web browser in many cases (often these lecturers are actually joint on-line and in-person so you need microphone control in the room as well; see for instance the popular Sandel Justice lecturers out of Harvard). 2. You also probably want to actually support not just real-time viewing but also podcasting, time-shifting, etc., as well as support for people who don't have WebRTC. When you put these together, it might well be natural to have a one-way stream via Flash, HTML5 video, etc., and then individual WebRTC uplinks which get mixed into that single stream as necessary. That makes questions about transcoding, re-encryption, etc. a lot simpler. -Ekr On Tue, Mar 6, 2012 at 1:28 AM, Stefan Hakansson LK wrote: > Hi! > > The Use-case document > () > will expire in early April. > > The editors propose to add a new use-case when updating to -07. The new > use-case is about large sessions and is inspired by input made earlier > by Arno Bakker > (http://www.ietf.org/mail-archive/web/rtcweb/current/msg00530.html) and > recently by Harald Alvestrand > (http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0066.html). > > Proposed text for the new use-case: > > On-line lecture > =============== > > A lecture is given on-line by a very popular lecturer. The attendance is > very large. Because of this it is not really feasible to have > direct audiovisual feedback (for e.g. questions) for every participant, > instead participants can request the floor by clicking a button, and > gets a signal when audio and video has been set up (and the lecturer is > ready to take the question). The question is heard by all participants > (not only the lecturer). > > Participants can join and leave the lecture at any time (i.e. they do > not need to be there at the start to be able to connect). > > The service is operated by the university of the lecturer. It is set up such > that all participants connect to a central node. The university can not > invest much in HW, so the processing required (per participant) must be > minimized. > > > New requirement: > > - It must be possible to set up media streams and encryption in such a > way that processing in a central node is minimized (no transcoding > required, no decryption/re-encryption for every outgoing flow - just > simple forwarding). > > > Let us know what you think. If there is support we will add this use-case, > if not we will just make a new revision of the document (with no major > changes to the content). > > Stefan for the editors > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Ranjit.Avasarala@Polycom.com Tue Mar 6 22:07:43 2012 Return-Path: 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 A787721E8036 for ; Tue, 6 Mar 2012 22:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[AWL=1.613, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 kJIvrpxeYlpF for ; Tue, 6 Mar 2012 22:07:43 -0800 (PST) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFA521E8048 for ; Tue, 6 Mar 2012 22:07:41 -0800 (PST) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Wed, 7 Mar 2012 14:07:40 +0800 From: "Avasarala, Ranjit" To: Stefan Hakansson LK Date: Wed, 7 Mar 2012 14:07:38 +0800 Thread-Topic: [rtcweb] Use-case document - additional recording use case Thread-Index: Acz8KJhZrOMgVKF2QI2GCyneCSyk0g== Message-ID: <1F2A2C70609D9E41844A2126145FC09804BC4CE1F2@HKGMBOXPRD22.polycom.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 Cc: "Banerjee, Atin" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Use-case document - additional recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 06:07:44 -0000 Hi Stefan Could we add a use case related to session recording? The use case would be 4.2. x Simple Video Recording Service 4.2. x.1 Description The user who has joined a video communication service wants to record the c= ommunication data from the web browser. 4.2.x.1.1 Derived requirements TBD I also feel there is a need for a API requirement - the Web API should prov= ide a means to record the incoming media - both audio & video or audio only= or video only Regards Ranjit -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Stefan Hakansson LK Sent: Tuesday, March 06, 2012 2:59 PM To: rtcweb@ietf.org Subject: [rtcweb] Use-case document Hi! The Use-case document () will expire in early April. The editors propose to add a new use-case when updating to -07. The new use= -case is about large sessions and is inspired by input made earlier by Arno= Bakker (http://www.ietf.org/mail-archive/web/rtcweb/current/msg00530.html) and rec= ently by Harald Alvestrand (http://lists.w3.org/Archives/Public/public-webr= tc/2012Feb/0066.html). Proposed text for the new use-case: On-line lecture =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A lecture is given on-line by a very popular lecturer. The attendance is ve= ry large. Because of this it is not really feasible to have direct audiovis= ual feedback (for e.g. questions) for every participant, instead participan= ts can request the floor by clicking a button, and gets a signal when audio= and video has been set up (and the lecturer is ready to take the question)= . The question is heard by all participants (not only the lecturer). Participants can join and leave the lecture at any time (i.e. they do not n= eed to be there at the start to be able to connect). The service is operated by the university of the lecturer. It is set up suc= h that all participants connect to a central node. The university can not i= nvest much in HW, so the processing required (per participant) must be mini= mized. New requirement: - It must be possible to set up media streams and encryption in such a way = that processing in a central node is minimized (no transcoding required, no= decryption/re-encryption for every outgoing flow - just simple forwarding)= . Let us know what you think. If there is support we will add this use-case, = if not we will just make a new revision of the document (with no major chan= ges to the content). Stefan for the editors _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Wed Mar 7 03:58:58 2012 Return-Path: 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 0761021F87AA for ; Wed, 7 Mar 2012 03:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.727 X-Spam-Level: X-Spam-Status: No, score=-9.727 tagged_above=-999 required=5 tests=[AWL=0.872, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 k-A9OM3YubKP for ; Wed, 7 Mar 2012 03:58:57 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA5521F87A9 for ; Wed, 7 Mar 2012 03:58:57 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-c4-4f574d8094de Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AD.EA.01970.08D475F4; Wed, 7 Mar 2012 12:58:56 +0100 (CET) Received: from [150.132.141.118] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Mar 2012 12:58:55 +0100 Message-ID: <4F574D7E.7070909@ericsson.com> Date: Wed, 7 Mar 2012 12:58:54 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F55924B.50807@jesup.org> In-Reply-To: <4F55924B.50807@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] I-D Action: draft-jesup-rtcweb-data-protocoll-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 11:58:58 -0000 On 03/06/2012 05:27 AM, Randell Jesup wrote: > You can find the I-D here: > http://www.ietf.org/id/draft-jesup-rtcweb-data-protocol-00.txt > > This (minor) protocol provides bidirectional data channels on top of > SCTP, per recent discussions, to support the requirements of > draft-ietf-rtcweb-data-channel. This protocol should be applicable > to other uses of SCTP as well. > > Randell > > A new version of I-D, draft-jesup-rtcweb-data-protocol-00.txt has > been successfully submitted by Randell Jesup and posted to the IETF > repository. > > Filename: draft-jesup-rtcweb-data-protocol Revision: 00 Title: > WebRTC Data Channel Protocol Creation date: 2012-03-06 WG ID: > Individual Submission Number of pages: 9 > > Abstract: The Web Real-Time Communication (WebRTC) working group is > charged to provide protocols to support for direct interactive rich > communication using audio, video, and data between two peers' > web- browsers. This document specifies an actual (minor) protocol > for how the JS-layer dataChannel objects provide the data channels > between the peers. > > This minor protocol has applicability to other bidirectional uses of > SCTP. > I had a quick glance, and it looks reasonable to me. //Stefan From harald@alvestrand.no Wed Mar 7 08:39:29 2012 Return-Path: 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 547C821E8084 for ; Wed, 7 Mar 2012 08:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.522 X-Spam-Level: X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 VkcATAmIcWhk for ; Wed, 7 Mar 2012 08:39:28 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9E36A21E8017 for ; Wed, 7 Mar 2012 08:39:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A68E939E241; Wed, 7 Mar 2012 17:39:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRe+yAfoEuKF; Wed, 7 Mar 2012 17:39:14 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A4D8939E1AE; Wed, 7 Mar 2012 17:39:14 +0100 (CET) Message-ID: <4F578F31.9000408@alvestrand.no> Date: Wed, 07 Mar 2012 17:39:13 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "rtp-congestion@alvestrand.no" , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------010205060602010505030508" Subject: [rtcweb] RTP congestion meeting hosted by ICCRG in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:39:29 -0000 This is a multi-part message in MIME format. --------------010205060602010505030508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This should be of interest to several of the participants. Note that the time slot for ICCRG conflicts with AVTEXT (first half) and SIPCORE (second half); we chose the SIPCORE conflict as the lesser evil. Please keep discussion of the technology on the rtp-congestion list, if you have to pick one. Harald -------- Original Message -------- Subject: [Iccrg] Preliminary agenda for ICCRG meeting @ IETF 83 Date: Wed, 07 Mar 2012 16:10:23 +0100 From: Michael Welzl To: iccrg@cs.ucl.ac.uk Ladies and gentlemen, Let me present to you the preliminary agenda for the ICCRG meeting at the upcoming Paris IETF, which is scheduled on Tuesday afternoon, in the 15:20-17:00 and 17:10-18:10 time slots. The second time slot is dedicated to congestion control for RTP-carried real-time media; this is an effort that comes out of rtcweb, with its own mailing list, see: http://www.alvestrand.no/mailman/listinfo/rtp-congestion The group is considering formation of a new WG, and that's why there is an item called "a possible WG charter" in the agenda - however, note that this meeting is not meant as a surrogate for a BoF (which is clearly not what a RG could or should "host"), so this will be just informational, not a time slot for wordsmithing. Content-wise, congestion control for RTP seems to be clearly in scope of ICCRG, and so I expect this to be an interesting session for all of us. Time slot 1, 15:20-17:00 * Agenda bashing and update - Michael Welzl (5 min) * Congestion Control and Notification over Longer Time Scales and at Higher Layers - Dave McDysan (20 min) draft-mcdysan-iccrg-usecases-00 * On the Fairness of Transport Protocols in a Multi-Path Environment - Hakim Adhari (15 min) (based on an upcoming ICC 2012 paper) * Caching with TCP - Pasi Sarolahti (15 min) * End-to-End Transmission Control through Inference about the Network - Keith Winstein (30 min) (based on: http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final100.pdf) Time slot 2, 17:10-18:10 Topic chair: Harald Alvestrand * Introduction: The RTCWEB effort, and the traffic we expect to generate - Harald (10 min) o Doc: draft-ietf-rtcweb-overview-02 o Doc: draft-jesup-rtp-congestion-reqs-00 * Nice behaviour for RTP-based services - Varun Singh, Colin Perkins (10 min) o Doc: draft-perkins-avtcore-rtp-circuit-breakers-00 * A delay based congestion control candidate - Stefan Holmer (15 min) o Doc: draft-alvestrand-rtcweb-congetstion-01 * Feedback mechanisms that might be useful - Harald Alvestrand (5 min) o Doc: draft-alvestrand-rmcat-remb-00 * A possible WG charter: RMCAT (15 min) o Doc: http://www.ietf.org/iesg/evaluation/rmcat-charter.txt * Summary, conclusions, next steps (5 min) The times in slot 1 are based on what the presenters requested, but I'd think that not everyone has planned for the normal (long) duration of discussions at IETF meetings, and so it's nice to have some headroom. This being said, I think we can still squeeze a presentation in there if need be. Cheers, Michael _______________________________________________ Iccrg mailing list Iccrg@cs.ucl.ac.uk http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg --------------010205060602010505030508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This should be of interest to several of the participants.
Note that the time slot for ICCRG conflicts with AVTEXT (first half) and SIPCORE (second half); we chose the SIPCORE conflict as the lesser evil.

Please keep discussion of the technology on the rtp-congestion list, if you have to pick one.

                          Harald

-------- Original Message --------
Subject: [Iccrg] Preliminary agenda for ICCRG meeting @ IETF 83
Date: Wed, 07 Mar 2012 16:10:23 +0100
From: Michael Welzl <michawe@ifi.uio.no>
To: iccrg@cs.ucl.ac.uk 


Ladies and gentlemen,

Let me present to you the preliminary agenda for the ICCRG meeting at 
the upcoming Paris IETF, which is scheduled on Tuesday afternoon, in the 
15:20-17:00 and 17:10-18:10 time slots. The second time slot is 
dedicated to congestion control for RTP-carried real-time media; this is 
an effort that comes out of rtcweb, with its own mailing list, see: 
http://www.alvestrand.no/mailman/listinfo/rtp-congestion
The group is considering formation of a new WG, and that's why there is 
an item called "a possible WG charter" in the agenda - however, note 
that this meeting is not meant as a surrogate for a BoF (which is 
clearly not what a RG could or should "host"), so this will be just 
informational, not a time slot for wordsmithing. Content-wise, 
congestion control for RTP seems to be clearly in scope of ICCRG, and so 
I expect this to be an interesting session for all of us.


Time slot 1, 15:20-17:00

* Agenda bashing and update - Michael Welzl (5 min)

* Congestion Control and Notification over Longer Time Scales and at 
Higher Layers - Dave McDysan (20 min)
  draft-mcdysan-iccrg-usecases-00

* On the Fairness of Transport Protocols in a Multi-Path Environment - 
Hakim Adhari (15 min)
  (based on an upcoming ICC 2012 paper)

* Caching with TCP - Pasi Sarolahti (15 min)

* End-to-End Transmission Control through Inference about the Network - 
Keith Winstein (30 min)
  (based on: 
http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final100.pdf)


Time slot 2, 17:10-18:10

Topic chair: Harald Alvestrand

    * Introduction: The RTCWEB effort, and the traffic we expect to 
generate - Harald (10 min)
          o Doc: draft-ietf-rtcweb-overview-02
          o Doc: draft-jesup-rtp-congestion-reqs-00
    * Nice behaviour for RTP-based services - Varun Singh, Colin 
Perkins (10 min)
          o Doc: draft-perkins-avtcore-rtp-circuit-breakers-00
    * A delay based congestion control candidate - Stefan Holmer (15 min)
          o Doc: draft-alvestrand-rtcweb-congetstion-01
    * Feedback mechanisms that might be useful - Harald Alvestrand (5 min)
          o Doc: draft-alvestrand-rmcat-remb-00
    * A possible WG charter: RMCAT (15 min)
          o Doc: http://www.ietf.org/iesg/evaluation/rmcat-charter.txt
    * Summary, conclusions, next steps (5 min)


The times in slot 1 are based on what the presenters requested, but I'd 
think that not everyone has planned for the normal (long) duration of 
discussions at IETF meetings, and so it's nice to have some headroom. 
This being said, I think we can still squeeze a presentation in there if 
need be.


Cheers,
Michael


_______________________________________________
Iccrg mailing list
Iccrg@cs.ucl.ac.uk
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
--------------010205060602010505030508-- From mkomu@cs.hut.fi Thu Mar 8 00:51:03 2012 Return-Path: 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 7E70121F8602 for ; Thu, 8 Mar 2012 00:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 a5IsQL1qU-uY for ; Thu, 8 Mar 2012 00:51:03 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE9021F85DB for ; Thu, 8 Mar 2012 00:51:02 -0800 (PST) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1S5Z3s-0000OU-NA for rtcweb@ietf.org; Thu, 08 Mar 2012 10:51:00 +0200 Message-ID: <4F5872F4.8070607@cs.hut.fi> Date: Thu, 08 Mar 2012 10:51:00 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] host identity protocol X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 08:51:03 -0000 Dear WG, I heard that you're making progress and have selected a specific protocol approach for rtcweb: http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel This is good news indeed. However, we noticed that the original comparison was missing few approaches like Teredo (RFC4380) or Host Identity Protocol (see e.g. RFC5770): http://tools.ietf.org/html/draft-jesup-rtcweb-data Despite the original document missed the two protocols, I'm sure that they were was discussed at some point, maybe even just in face-to-face conversations. Now, my goal is not advocate either of these protocols as a replacement for the WG as you have already consensus, but I'd rather like to get feedback why some protocols were excluded. To be more specific, we're working on a research paper on deployment analysis on Host Identity Protocol (HIP) in Aalto University and we'd like get your expert opinion on especially why HIP was not the adopted in the context of rtcweb. Here's few example considerations: - Never heard about HIP - The substitute technologies do their work better - Lack of implementation maturity or usability - Not standards track yet; we can build rtcweb out of standards track components - The fatal flaw for HIP in this particular context is X - HIP is in the wrong layer of the stack? Besides technical incentives, we're also interested business and political incentives. Feel free to respond me directly or via the mailing list (unless people think it's too off-the-topic). Your feedback will be anonymized in the publication. Thanks! From harald@alvestrand.no Thu Mar 8 02:16:16 2012 Return-Path: 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 BB5BA21F8639 for ; Thu, 8 Mar 2012 02:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.525 X-Spam-Level: X-Spam-Status: No, score=-110.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 6YiUMqCxJOqL for ; Thu, 8 Mar 2012 02:16:16 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E698F21F85F2 for ; Thu, 8 Mar 2012 02:16:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B929239E149; Thu, 8 Mar 2012 11:16:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy6+8+OzZy7r; Thu, 8 Mar 2012 11:16:14 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id E718D39E048; Thu, 8 Mar 2012 11:16:13 +0100 (CET) Message-ID: <4F5886ED.5090803@alvestrand.no> Date: Thu, 08 Mar 2012 11:16:13 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Miika Komu References: <4F5872F4.8070607@cs.hut.fi> In-Reply-To: <4F5872F4.8070607@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] host identity protocol X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 10:16:16 -0000 HIP was discussed at a far earlier stage, when talking about security. We chose to go with DTLS, SRTP and ICE instead, since these were mechanisms in (relatively) common use in this environment. As far as I understand HIP, it does not contain congestion control mechanisms, so its use was not considered when picking a protocol for the data channel. On 03/08/2012 09:51 AM, Miika Komu wrote: > Dear WG, > > I heard that you're making progress and have selected a specific > protocol approach for rtcweb: > > http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel > > This is good news indeed. However, we noticed that the original > comparison was missing few approaches like Teredo (RFC4380) or Host > Identity Protocol (see e.g. RFC5770): > > http://tools.ietf.org/html/draft-jesup-rtcweb-data > > Despite the original document missed the two protocols, I'm sure that > they were was discussed at some point, maybe even just in face-to-face > conversations. Now, my goal is not advocate either of these protocols > as a replacement for the WG as you have already consensus, but I'd > rather like to get feedback why some protocols were excluded. > > To be more specific, we're working on a research paper on deployment > analysis on Host Identity Protocol (HIP) in Aalto University and we'd > like get your expert opinion on especially why HIP was not the adopted > in the context of rtcweb. Here's few example considerations: > > - Never heard about HIP > - The substitute technologies do their work better > - Lack of implementation maturity or usability > - Not standards track yet; we can build rtcweb out of standards track > components > - The fatal flaw for HIP in this particular context is X > - HIP is in the wrong layer of the stack? > > Besides technical incentives, we're also interested business and > political incentives. Feel free to respond me directly or via the > mailing list (unless people think it's too off-the-topic). Your > feedback will be anonymized in the publication. > > Thanks! > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From pravindran@sonusnet.com Thu Mar 8 04:15:43 2012 Return-Path: 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 A424721F8634 for ; Thu, 8 Mar 2012 04:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] 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 o21KcA4QbkjK for ; Thu, 8 Mar 2012 04:15:42 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id C463321F8604 for ; Thu, 8 Mar 2012 04:15:42 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q28CGUUg022467; Thu, 8 Mar 2012 07:16:30 -0500 Received: from USMA-EX-HUB1.sonusnet.com ([66.203.90.16]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 07:15:40 -0500 Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 8 Mar 2012 07:15:47 -0500 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Thu, 8 Mar 2012 17:45:36 +0530 From: "Ravindran, Parthasarathi" To: Justin Uberti , Cullen Jennings Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-00.txt Thread-Index: AQHM+cYkO2Vju70NSkueFvCbcEhKMpZgVUpQ Date: Thu, 8 Mar 2012 12:15:35 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1F8FFF@inba-mail01.sonusnet.com> References: <20120304051708.8288.46081.idtracker@ietfa.amsl.com> In-Reply-To: <20120304051708.8288.46081.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 12:15:40.0290 (UTC) FILETIME=[2D527E20:01CCFD25] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 12:15:43 -0000 Justin/Cullen, I have noticed that "single offer and multiple answer" callflow is not upda= ted in the latest draft as discussed in http://www.ietf.org/mail-archive/we= b/rtcweb/current/msg03507.html, http://www.ietf.org/mail-archive/web/rtcweb= /current/msg03531.html. Could you please add the callflow in the draft or p= lease let me know any issues in the mentioned callflow. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of internet-drafts@ietf.org >Sent: Sunday, March 04, 2012 10:47 AM >To: i-d-announce@ietf.org >Cc: rtcweb@ietf.org >Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the Real-Time Communication in >WEB-browsers Working Group of the IETF. > > Title : Javascript Session Establishment Protocol > Author(s) : Justin Uberti > Cullen Jennings > Filename : draft-ietf-rtcweb-jsep-00.txt > Pages : 27 > Date : 2012-03-03 > > This document proposes a mechanism for allowing a Javascript > application to fully control the signaling plane of a multimedia > session, and discusses how this would work with existing signaling > protocols. > > This document is an input document for discussion. It should be > discussed in the RTCWEB WG list, rtcweb@ietf.org. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-00.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-00.txt > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Thu Mar 8 04:55:24 2012 Return-Path: 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 7454021F8609 for ; Thu, 8 Mar 2012 04:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.344 X-Spam-Level: X-Spam-Status: No, score=-110.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 URFMCknsK6hN for ; Thu, 8 Mar 2012 04:55:24 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 09BAF21F856A for ; Thu, 8 Mar 2012 04:55:19 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-5a-4f58ac360c9e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 23.23.27041.63CA85F4; Thu, 8 Mar 2012 13:55:18 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Mar 2012 13:55:17 +0100 Message-ID: <4F58AC35.1010500@ericsson.com> Date: Thu, 8 Mar 2012 13:55:17 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Proposal for media receiver request of codec parameter changes (draft-westerlund-avtext-codec-operation-point-00) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 12:55:24 -0000 WG, As an individual I would like to inform you that my colleagues and I have submitted a proposal to AVTEXT WG. This proposal is an RTCP extension that enables RTP session participants to request the media sender to adjust its media parameters, like video resolution. The draft can be retrieved here: https://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operation-point/ One use case we have designed this for is to enable the dynamic updates codec parameters as result of WebRTC applications usage of media streams. If the application changes the rendering layout or the user changes the browser window size, the size of a video playout can change. This may happen in a quite dynamic way and often enough that we think using a mechanism where the receiver can use a request over the media plane rather than the signalling plane to adjust the parameters will give a more responsive and satisfying experience. We have also designed it with centralized conferencing into mind, allowing the central node to aggregate requests to best suit the whole population. We request that feedback on the actual extension are directed to the AVTEXT WG mailing list: avtext@ietf.org I am happy to discuss the usage and applicability to WebRTC on this list. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Jim.Barnett@genesyslab.com Thu Mar 8 06:37:54 2012 Return-Path: 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 9626B21F86C3 for ; Thu, 8 Mar 2012 06:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.133, 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 u1YYZXg5k+Tr for ; Thu, 8 Mar 2012 06:37:53 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id F213721F85E6 for ; Thu, 8 Mar 2012 06:37:52 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q28Ebo6p002475 for ; Thu, 8 Mar 2012 06:37:52 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 06:37:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFD39.0A8B5490" Date: Thu, 8 Mar 2012 06:37:26 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] when should ICE start? Thread-Index: Acz9OPs0x3C37kv4QiyAakUCCbToEw== From: "Jim Barnett" To: X-OriginalArrivalTime: 08 Mar 2012 14:37:51.0735 (UTC) FILETIME=[0A75B070:01CCFD39] Subject: [rtcweb] when should ICE start? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 14:37:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFD39.0A8B5490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trying to tie up some loose ends from earlier discussions: 1. In the discussion of SDES, we stated that we don't trust the web server. 2. In a separate discussion, people indicated that there were serious privacy issues (disclosure of location) if ICE started before the answerer gave consent. 3. In the JSEP draft, ICE is started under control of the JavaScript 4. which is served by the web server we don't trust. =20 I may be confused, but it seems to me that 3-4 are in conflict with 1-2. For example, in the example in Section 8 of the JSEP draft, the offer is not sent until the user consents, but it looks to me like ICE can start on the answerer side before the user gives consent. In previous discussions, someone also observed that it also might be possible to set up a data channel without user consent, since it doesn't require media. =20 I'm not advocating a particular solution, but would like to hear how the group intends to restore consistency. It seems to me that there are 3 choices: A. decide we trust the web server after all B. decide that the security issues are not so serious after all C. set the default so that ICE does not start until the user consents (this would amount to turning 'startICE' into 'startICEOnceUserConsents'). We might also treat the data channel as a media channel requiring explicit consent, or say that data channels may only be created once media channels are already in place. =20 =20 If we choose option C, we should probably run through some examples to make sure that the potential delay in starting ICE doesn't cause problems.=20 =20 - Jim =20 =20 ------_=_NextPart_001_01CCFD39.0A8B5490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trying to = tie up some loose ends from earlier discussions:

1.       In = the discussion of SDES, we stated that we don’t trust the web = server.

2.       In = a separate discussion, people  indicated that there were serious = privacy issues (disclosure of location) if ICE started before the = answerer gave consent.

3.       In = the JSEP draft,  ICE is started under control of the = JavaScript

4.       = which is served by the web server we don’t = trust.

 

I may be confused, but it seems to me that 3-4 are in = conflict with 1-2.  For example, in the example in Section 8 of the = JSEP draft, the offer is not sent until the user consents, but it looks = to me like ICE can start on the answerer side  before the user = gives consent.   In previous discussions, someone also = observed that it also might be possible to set up a data channel without = user consent, since it doesn’t require media.  =

 

I’m not advocating a particular solution, but = would like to hear how the group intends to restore consistency.  = It seems to me that there are 3 choices:

A.      = decide we trust the web server after = all

B.      = decide that the security issues are not so = serious after all

C.      = set the default so that ICE does not start until = the user consents (this would amount to turning ‘startICE’ = into ‘startICEOnceUserConsents’).  We might also treat = the data channel as a media channel requiring explicit consent, or say = that data channels may only be created once media channels are already = in place. 

 

If we choose = option C, we should probably run through some examples to make sure that = the potential delay in starting ICE doesn’t cause problems. =

 

-          = Jim

 

 

------_=_NextPart_001_01CCFD39.0A8B5490-- From stefan.lk.hakansson@ericsson.com Thu Mar 8 07:13:00 2012 Return-Path: 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 25B0421F86EB for ; Thu, 8 Mar 2012 07:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.781 X-Spam-Level: X-Spam-Status: No, score=-9.781 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2-rChX5Oj0ZT for ; Thu, 8 Mar 2012 07:12:58 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id AB30D21F8642 for ; Thu, 8 Mar 2012 07:12:56 -0800 (PST) X-AuditID: c1b4fb3d-b7c6fae0000045c0-c8-4f58cc77c082 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 08.B1.17856.77CC85F4; Thu, 8 Mar 2012 16:12:55 +0100 (CET) Received: from [150.132.142.220] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Mar 2012 16:12:55 +0100 Message-ID: <4F58CC75.7080803@ericsson.com> Date: Thu, 8 Mar 2012 16:12:53 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Eric Rescorla References: <4F55D8BF.1040703@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Use-case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:13:00 -0000 On 03/06/2012 02:01 PM, Eric Rescorla wrote: > Obviously, this is an interesting use case, but it's not clear to me that > it's something you would want to address entirely via WebRTC > > 1. It seems likely that the lecturer will be using something > rather more sophisticated than a Web browser in many cases > (often these lecturers are actually joint on-line and in-person > so you need microphone control in the room as well; see for > instance the popular Sandel Justice lecturers out of Harvard). > > 2. You also probably want to actually support not just real-time > viewing but also podcasting, time-shifting, etc., as well as > support for people who don't have WebRTC. > > When you put these together, it might well be natural to have > a one-way stream via Flash, HTML5 video, etc., and then individual > WebRTC uplinks which get mixed into that single stream as necessary. > That makes questions about transcoding, re-encryption, etc. a lot > simpler. I agree to that the use-case proposed was perhaps not that well selected for the reasons you give above. What we were really after was to enable multi-party with really low cost for the central node (given that you're not doing a mesh). If you have to decrypt, alter RTP parameters, and then re-encrypt you quickly get into a situation where the central node needs a lot of processing power. If the packets simply can be forwarded you're much better off - and this is what we wanted to capture. It is also a way to in the use-case and requirement document reflect a bit of what JSEP enables; if the application can *set* certain parts of the media settings used by the browser, the app can set it up such that central node would not have to alter anything - just forward. We thought it would be nice to have a JSEP related req in the document! Stefan > > -Ekr > > > On Tue, Mar 6, 2012 at 1:28 AM, Stefan Hakansson LK > wrote: >> Hi! >> >> The Use-case document >> () >> will expire in early April. >> >> The editors propose to add a new use-case when updating to -07. The new >> use-case is about large sessions and is inspired by input made earlier >> by Arno Bakker >> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg00530.html) and >> recently by Harald Alvestrand >> (http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0066.html). >> >> Proposed text for the new use-case: >> >> On-line lecture >> =============== >> >> A lecture is given on-line by a very popular lecturer. The attendance is >> very large. Because of this it is not really feasible to have >> direct audiovisual feedback (for e.g. questions) for every participant, >> instead participants can request the floor by clicking a button, and >> gets a signal when audio and video has been set up (and the lecturer is >> ready to take the question). The question is heard by all participants >> (not only the lecturer). >> >> Participants can join and leave the lecture at any time (i.e. they do >> not need to be there at the start to be able to connect). >> >> The service is operated by the university of the lecturer. It is set up such >> that all participants connect to a central node. The university can not >> invest much in HW, so the processing required (per participant) must be >> minimized. >> >> >> New requirement: >> >> - It must be possible to set up media streams and encryption in such a >> way that processing in a central node is minimized (no transcoding >> required, no decryption/re-encryption for every outgoing flow - just >> simple forwarding). >> >> >> Let us know what you think. If there is support we will add this use-case, >> if not we will just make a new revision of the document (with no major >> changes to the content). >> >> Stefan for the editors >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Thu Mar 8 07:32:19 2012 Return-Path: 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 6F7D821F8762 for ; Thu, 8 Mar 2012 07:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.926 X-Spam-Level: X-Spam-Status: No, score=-109.926 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, 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 gE+voDcvgzAV for ; Thu, 8 Mar 2012 07:32:18 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2DC21F8670 for ; Thu, 8 Mar 2012 07:32:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C81CE39E27B; Thu, 8 Mar 2012 16:32:16 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ejdc9QFDhOUQ; Thu, 8 Mar 2012 16:32:15 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 58B4639E149; Thu, 8 Mar 2012 16:32:15 +0100 (CET) Message-ID: <4F58D0FE.9060909@alvestrand.no> Date: Thu, 08 Mar 2012 16:32:14 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Jim Barnett References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090202040708050707050204" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] when should ICE start? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:32:19 -0000 This is a multi-part message in MIME format. --------------090202040708050707050204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/08/2012 03:37 PM, Jim Barnett wrote: > > Trying to tie up some loose ends from earlier discussions: > > 1.In the discussion of SDES, we stated that we don't trust the web server. > Well... it's more a question of what we trust the web server with. > > 2.In a separate discussion, people indicated that there were serious > privacy issues (disclosure of location) if ICE started before the > answerer gave consent. > > 3.In the JSEP draft, ICE is started under control of the JavaScript > > 4.which is served by the web server we don't trust. > The Javascript is served by a Web server. The Web server already knows where I am. So there's no point in trying to guard that information from one that already knows. The one I'm guarding my location from is the person who's calling me, not the Web server that serves up my Javascript. In order to do that, I need the Web server (who knows where I am) to be on my side. > > I may be confused, but it seems to me that 3-4 are in conflict with > 1-2. For example, in the example in Section 8 of the JSEP draft, the > offer is not sent until the user consents, but it looks to me like ICE > can start on the answerer side before the user gives consent. In > previous discussions, someone also observed that it also might be > possible to set up a data channel without user consent, since it > doesn't require media. > ICE using relay candidates does not disclose my location. So I can start *that* part of ICE. > > I'm not advocating a particular solution, but would like to hear how > the group intends to restore consistency. It seems to me that there > are 3 choices: > > A.decide we trust the web server after all > > B.decide that the security issues are not so serious after all > > C.set the default so that ICE does not start until the user consents > (this would amount to turning 'startICE' into > 'startICEOnceUserConsents'). We might also treat the data channel as > a media channel requiring explicit consent, or say that data channels > may only be created once media channels are already in place. > > If we choose option C, we should probably run through some examples to > make sure that the potential delay in starting ICE doesn't cause > problems. > See above. I don't think those are the only options. > -Jim > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------090202040708050707050204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/08/2012 03:37 PM, Jim Barnett wrote:

Trying to tie up some loose ends from earlier discussions:

1.       In the discussion of SDES, we stated that we don’t trust the web server.

Well... it's more a question of what we trust the web server with.

2.       In a separate discussion, people  indicated that there were serious privacy issues (disclosure of location) if ICE started before the answerer gave consent.

3.       In the JSEP draft,  ICE is started under control of the JavaScript

4.       which is served by the web server we don’t trust.

The Javascript is served by a Web server. The Web server already knows where I am. So there's no point in trying to guard that information from one that already knows.
The one I'm guarding my location from is the person who's calling me, not the Web server that serves up my Javascript. In order to do that, I need the Web server (who knows where I am) to be on my side.

 

I may be confused, but it seems to me that 3-4 are in conflict with 1-2.  For example, in the example in Section 8 of the JSEP draft, the offer is not sent until the user consents, but it looks to me like ICE can start on the answerer side  before the user gives consent.   In previous discussions, someone also observed that it also might be possible to set up a data channel without user consent, since it doesn’t require media. 

ICE using relay candidates does not disclose my location. So I can start *that* part of ICE.

 

I’m not advocating a particular solution, but would like to hear how the group intends to restore consistency.  It seems to me that there are 3 choices:

A.      decide we trust the web server after all

B.      decide that the security issues are not so serious after all

C.      set the default so that ICE does not start until the user consents (this would amount to turning ‘startICE’ into ‘startICEOnceUserConsents’).  We might also treat the data channel as a media channel requiring explicit consent, or say that data channels may only be created once media channels are already in place. 

 

If we choose option C, we should probably run through some examples to make sure that the potential delay in starting ICE doesn’t cause problems.

See above. I don't think those are the only options.

 

-          Jim

 

 


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

--------------090202040708050707050204-- From Jim.Barnett@genesyslab.com Thu Mar 8 07:39:13 2012 Return-Path: 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 DDBA221F8794 for ; Thu, 8 Mar 2012 07:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, 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 wI2JiVasbNnl for ; Thu, 8 Mar 2012 07:39:07 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 6683721F873D for ; Thu, 8 Mar 2012 07:39:07 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q28Fd3w9011912; Thu, 8 Mar 2012 07:39:03 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 07:39:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFD41.96C5465E" Date: Thu, 8 Mar 2012 07:38:36 -0800 Message-ID: In-Reply-To: <4F58D0FE.9060909@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] when should ICE start? Thread-Index: Acz9QKbuDQi8WeCXQYey9d1y9IKqZgAAH2JA References: <4F58D0FE.9060909@alvestrand.no> From: "Jim Barnett" To: "Harald Alvestrand" X-OriginalArrivalTime: 08 Mar 2012 15:39:03.0153 (UTC) FILETIME=[96CB9E10:01CCFD41] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] when should ICE start? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:39:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFD41.96C5465E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Harald, You're right that the web server already knows where I am. I'm worried about it serving me malicious/careless JS that reveals my location to caller (Syrian secret police, etc.) before I'm aware that I'm being called. That's the sense in which I don't trust it. However you are right that there are more options than I outlined, and starting ICE using only relay candidates is one of them. =20 - Jim =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Thursday, March 08, 2012 10:32 AM To: Jim Barnett Cc: rtcweb@ietf.org Subject: Re: [rtcweb] when should ICE start? =20 On 03/08/2012 03:37 PM, Jim Barnett wrote:=20 Trying to tie up some loose ends from earlier discussions: In the discussion of SDES, we stated that we don't trust the web server. Well... it's more a question of what we trust the web server with. In a separate discussion, people indicated that there were serious privacy issues (disclosure of location) if ICE started before the answerer gave consent. In the JSEP draft, ICE is started under control of the JavaScript which is served by the web server we don't trust. The Javascript is served by a Web server. The Web server already knows where I am. So there's no point in trying to guard that information from one that already knows. The one I'm guarding my location from is the person who's calling me, not the Web server that serves up my Javascript. In order to do that, I need the Web server (who knows where I am) to be on my side. =20 I may be confused, but it seems to me that 3-4 are in conflict with 1-2. For example, in the example in Section 8 of the JSEP draft, the offer is not sent until the user consents, but it looks to me like ICE can start on the answerer side before the user gives consent. In previous discussions, someone also observed that it also might be possible to set up a data channel without user consent, since it doesn't require media. ICE using relay candidates does not disclose my location. So I can start *that* part of ICE. =20 I'm not advocating a particular solution, but would like to hear how the group intends to restore consistency. It seems to me that there are 3 choices: decide we trust the web server after all decide that the security issues are not so serious after all set the default so that ICE does not start until the user consents (this would amount to turning 'startICE' into 'startICEOnceUserConsents'). We might also treat the data channel as a media channel requiring explicit consent, or say that data channels may only be created once media channels are already in place. =20 =20 If we choose option C, we should probably run through some examples to make sure that the potential delay in starting ICE doesn't cause problems.=20 See above. I don't think those are the only options. =20 Jim =20 =20 =20 =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------_=_NextPart_001_01CCFD41.96C5465E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Harald,

You’re right that the web server already = knows where I am.  I’m worried about it serving me = malicious/careless JS that reveals my location to caller (Syrian secret = police, etc.) before I’m aware that I’m being called.  = That’s the sense in which I don’t trust it.  However = you are right that there are more options than I outlined, and starting = ICE using only relay candidates is one of them.

 

-          = Jim

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: = Thursday, March 08, 2012 10:32 AM
To: Jim = Barnett
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] = when should ICE start?

 

On = 03/08/2012 03:37 PM, Jim Barnett wrote:

Trying to tie up some loose ends from earlier = discussions:

In the discussion of SDES, we stated that = we don’t trust the web server.

Well... it's more a question of what we trust the web = server with.

In a separate discussion, people  = indicated that there were serious privacy issues (disclosure of = location) if ICE started before the answerer gave = consent.

In the JSEP draft,  ICE is started = under control of the JavaScript

which is served by = the web server we don’t trust.

The Javascript is served by a Web server. The Web server = already knows where I am. So there's no point in trying to guard that = information from one that already knows.
The one I'm guarding my = location from is the person who's calling me, not the Web server that = serves up my Javascript. In order to do that, I need the Web server (who = knows where I am) to be on my side.

 

I may be = confused, but it seems to me that 3-4 are in conflict with 1-2.  = For example, in the example in Section 8 of the JSEP draft, the offer is = not sent until the user consents, but it looks to me like ICE can start = on the answerer side  before the user gives consent.   In = previous discussions, someone also observed that it also might be = possible to set up a data channel without user consent, since it = doesn’t require media. 

ICE using relay candidates does not disclose my = location. So I can start *that* part of = ICE.

 

I’m = not advocating a particular solution, but would like to hear how the = group intends to restore consistency.  It seems to me that there = are 3 choices:

decide we trust the web server after = all

decide that the security issues are not so = serious after all

set the default so that ICE does not start = until the user consents (this would amount to turning = ‘startICE’ into = ‘startICEOnceUserConsents’).  We might also treat the = data channel as a media channel requiring explicit consent, or say that = data channels may only be created once media channels are already in = place. 

 

If we choose option C, we should probably run through = some examples to make sure that the potential delay in starting ICE = doesn’t cause problems.

See = above. I don't think those are the only = options.


 

Jim

 

 

 
<=
o:p> 
______________________________________________=
_
rtcweb mailing list
rtcweb@ietf.org
=
https://www.ietf.or=
g/mailman/listinfo/rtcweb

 

------_=_NextPart_001_01CCFD41.96C5465E-- From ekr@rtfm.com Thu Mar 8 07:54:25 2012 Return-Path: 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 7C6B921F87B7 for ; Thu, 8 Mar 2012 07:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.087 X-Spam-Level: X-Spam-Status: No, score=-103.087 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 7KeWBBYOi7Zd for ; Thu, 8 Mar 2012 07:54:24 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A85F621F879A for ; Thu, 8 Mar 2012 07:54:10 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so574481vcb.31 for ; Thu, 08 Mar 2012 07:54:10 -0800 (PST) Received: by 10.52.180.98 with SMTP id dn2mr10653114vdc.61.1331222050125; Thu, 08 Mar 2012 07:54:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.70.231 with HTTP; Thu, 8 Mar 2012 07:53:30 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4F58D0FE.9060909@alvestrand.no> From: Eric Rescorla Date: Thu, 8 Mar 2012 07:53:30 -0800 Message-ID: To: Jim Barnett Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm6mgncBTN5rHMF659atBAn6p2b40Ou4iG2oTEmsFd6DQZHxJhmcnLKqtqSyV/VZevgf7aX Cc: rtcweb@ietf.org Subject: Re: [rtcweb] when should ICE start? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:54:25 -0000 On Thu, Mar 8, 2012 at 7:38 AM, Jim Barnett wr= ote: > Harald, > > You=92re right that the web server already knows where I am. =A0I=92m wor= ried > about it serving me malicious/careless JS that reveals my location to cal= ler > (Syrian secret police, etc.) before I=92m aware that I=92m being called.= =A0 That=92s > the sense in which I don=92t trust it. Right but in the most common case, as soon as you connect to the server, the server knows your IP, so there's nothing we can do about this. -Ekr From Jim.Barnett@genesyslab.com Thu Mar 8 08:01:47 2012 Return-Path: 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 8648121F8666 for ; Thu, 8 Mar 2012 08:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] 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 s+8xr-VsOIma for ; Thu, 8 Mar 2012 08:01:46 -0800 (PST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [198.49.180.223]) by ietfa.amsl.com (Postfix) with ESMTP id A785721F8546 for ; Thu, 8 Mar 2012 08:01:46 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q28G1gBs006697; Thu, 8 Mar 2012 08:01:42 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 08:01:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 08:01:17 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] when should ICE start? Thread-Index: Acz9Q7RiA5lSznCkQIyPEBVZIfZEOQAACu8Q References: <4F58D0FE.9060909@alvestrand.no> From: "Jim Barnett" To: "Eric Rescorla" X-OriginalArrivalTime: 08 Mar 2012 16:01:42.0732 (UTC) FILETIME=[C12AE8C0:01CCFD44] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] when should ICE start? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:01:47 -0000 Yes, certainly if the Syrian secret police controls the server, I'm in = trouble no matter what. But isn't there a separate case where a = third-party server, not under police control, serves up careless JS that = reveals my location to the caller before I'm aware I'm being called? = This was the case we were worried about in the earlier discussion - that = the caller could discover the answerer's location even if the answerer = rejected the call. (I think that the example in Section 8 will permit = this.) So the trust question is: do we let the server decide whether = to allow this, or do we put defaults in the browser to protect location = information even if the server is carelessly coded? - Jim=20 -----Original Message----- From: Eric Rescorla [mailto:ekr@rtfm.com]=20 Sent: Thursday, March 08, 2012 10:54 AM To: Jim Barnett Cc: Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] when should ICE start? On Thu, Mar 8, 2012 at 7:38 AM, Jim Barnett = wrote: > Harald, > > You're right that the web server already knows where I am. =A0I'm=20 > worried about it serving me malicious/careless JS that reveals my=20 > location to caller (Syrian secret police, etc.) before I'm aware that=20 > I'm being called.=A0 That's the sense in which I don't trust it. Right but in the most common case, as soon as you connect to the server, = the server knows your IP, so there's nothing we can do about this. -Ekr From ted.ietf@gmail.com Thu Mar 8 08:27:48 2012 Return-Path: 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 E25F121F870B for ; Thu, 8 Mar 2012 08:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 WhFz8cIBQNYn for ; Thu, 8 Mar 2012 08:27:48 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C97821F854E for ; Thu, 8 Mar 2012 08:27:48 -0800 (PST) Received: by vbbez10 with SMTP id ez10so610558vbb.31 for ; Thu, 08 Mar 2012 08:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=THLgQp8V/RYfkr19JzQr4hGE+1QbXymhlUr9ERipijA=; b=pTrIoiHcDitA8zXHU1yeEfyerQMuf1VhSpeIfOgAXfFoI1r/DLlQSXIWQGWXaKfiCN HFTGml1hNFcEEoMs4MeMqQtpzeJ5e4CIPpRGilUhpEO88MUkNgE3Y8O8xnFfVZDNMz2c c1NHuh4t5oTuEPByfzve1ctCOjzYBJHCdh63dvlUfimuNqCIJJvMBv4VU64Uq/1aLKiB sDMvaJDn3Lj7I5GBuCbbjgpR8cd2ioVsjzXdcTX5Tda58CZ4uHuRX8wT83wCHUTKpba3 HPbdMf+FtwqNG/ycsIzltxtrHERCGC/CrSryzfIwyvR5DnZEw562HC2QvfWgph3YrDnP qDow== MIME-Version: 1.0 Received: by 10.52.71.114 with SMTP id t18mr10801696vdu.88.1331224067731; Thu, 08 Mar 2012 08:27:47 -0800 (PST) Received: by 10.52.115.66 with HTTP; Thu, 8 Mar 2012 08:27:47 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Mar 2012 08:27:47 -0800 Message-ID: From: Ted Hardie To: HIro Suzuki Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I'd like to discuss my proposal (jingle-web) at next WG session X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:27:49 -0000 Hi Suzuki-san, Given that this apparently revisits some decisions that were already made, the chairs would like to see working group discussion of the draft before allocating agenda time to it for the upcoming meeting. best regards, Ted Hardie for the Chairs On Wed, Feb 29, 2012 at 7:34 PM, HIro Suzuki wrote: > Hello RTCWeb WG members, > > > It's my first post to this ML, and at Feb 28th, I submitted my ID > from IETF ID submit tool. This ID's file name is > "draft-suzuki-rtcweb-jingle-web-00.txt" and this ID provides my proposal > to realize one of solutions of RTCWeb by using XMPP Jingle as a signaling > protocol. > > Following paragraph is abstract of my ID, and I'd like to discuss my > proposal at RTCWeb WG session in next Paris meeting. > > > --- > Abstract: > =A0XMPP Jingle specification defines an XMPP protocol extension for > =A0managing peer-to-peer media sessions between two users. And XMPP > =A0Jingle can manage multi contents simultaneously in one Jingle > =A0stream, but in the XMPP world there is no common way to layout > =A0variable multi contents on each display. In this document, a > =A0solution to this issue is provided by using Web browser's layout > =A0function. > > =A0This document describes a new concept to realize one of solutions > =A0of RTCWeb. Of course, "Web Browser" is used for Web applicat= ion's > =A0frontend for real-time communication, and XMPP Jingle specification > =A0(XEP-166) is used as signaling protocol. And a simple mapping > =A0manner between jingle contents and HTML graphical elements enables > =A0to unite Web browser's layout function and Jingle's media cont= ent > =A0management function to realize RTCWeb functions. > --- > > > Best Regards, > Yoshihiro Suzuki > (hiro.suzuki@d3communications.jp) > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Thu Mar 8 08:30:25 2012 Return-Path: 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 AE05D21F8639 for ; Thu, 8 Mar 2012 08:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.084 X-Spam-Level: X-Spam-Status: No, score=-103.084 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 tqrHAjOo2y7K for ; Thu, 8 Mar 2012 08:30:25 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA8221F855B for ; Thu, 8 Mar 2012 08:30:24 -0800 (PST) Received: by vbbez10 with SMTP id ez10so613616vbb.31 for ; Thu, 08 Mar 2012 08:30:24 -0800 (PST) Received: by 10.52.180.98 with SMTP id dn2mr10901044vdc.61.1331224224495; Thu, 08 Mar 2012 08:30:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.70.231 with HTTP; Thu, 8 Mar 2012 08:29:42 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4F58D0FE.9060909@alvestrand.no> From: Eric Rescorla Date: Thu, 8 Mar 2012 08:29:42 -0800 Message-ID: To: Jim Barnett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQngrRK6DUm7iwVKE6qdtid8FKl+J99Pb3wmfQKh0ykfXv7osY4k0R9ajyYdzZ5FZJ3Old/f Cc: rtcweb@ietf.org Subject: Re: [rtcweb] when should ICE start? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:30:25 -0000 On Thu, Mar 8, 2012 at 8:01 AM, Jim Barnett wr= ote: > Yes, certainly if the Syrian secret police controls the server, I'm in tr= ouble no matter what. =A0But isn't there a separate case where a third-part= y server, not under police control, serves up careless JS that reveals my l= ocation to the caller before I'm aware I'm being called? =A0This was the ca= se we were worried about in the earlier discussion - that the caller could = discover the answerer's =A0location even if the answerer rejected the call.= =A0(I think that the example in Section 8 will permit this.) =A0So the tru= st question is: =A0do we let the server decide whether to allow this, or do= we put defaults in the browser to protect location information even if the= server is carelessly coded? > I'm not sure that ICE and WebRTC create much of a new risk here. If the ser= ver is badly coded then there are a lot of ways to leak the user's location. To= give one, say I use targeted ad buys to get the server to show you JS that inclu= des (a) cookies and (b) calls back to my server to reveal location information. -Ekr From mkomu@cs.hut.fi Thu Mar 8 09:08:24 2012 Return-Path: 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 65D1E21F86C8 for ; Thu, 8 Mar 2012 09:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ub6+K99ullIX for ; Thu, 8 Mar 2012 09:08:21 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1134E21F86C4 for ; Thu, 8 Mar 2012 09:08:19 -0800 (PST) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1S5gp8-0004Rg-NE; Thu, 08 Mar 2012 19:08:18 +0200 Message-ID: <4F58E782.7010309@cs.hut.fi> Date: Thu, 08 Mar 2012 19:08:18 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <4F5872F4.8070607@cs.hut.fi> <4F5886ED.5090803@alvestrand.no> In-Reply-To: <4F5886ED.5090803@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] host identity protocol X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:08:24 -0000 Hi Harald, thanks for the quick response. You're absolutely right, HIP does not support congestion control. It actually even shouldn't support it because it's not a transport-layer protocol. Typically people use HIP/IPsec for end-to-end tunneling of TCP or UDP. The tunnel is encrusted in an extra UDP header to make HIP/ESP pass NAT boxes which actually makes it a nice fit for NAT penetration. The data-plane can be negotiated during the key exchange process and e.g. S-RTP has been proposed to replace IPsec. Are you sure about the reasoning - has it been a misunderstanding or maybe some other reasoning fits better? Thanks for your feedback! On 03/08/2012 12:16 PM, Harald Alvestrand wrote: > HIP was discussed at a far earlier stage, when talking about security. > We chose to go with DTLS, SRTP and ICE instead, since these were > mechanisms in (relatively) common use in this environment. > > As far as I understand HIP, it does not contain congestion control > mechanisms, so its use was not considered when picking a protocol for > the data channel. > > On 03/08/2012 09:51 AM, Miika Komu wrote: >> Dear WG, >> >> I heard that you're making progress and have selected a specific >> protocol approach for rtcweb: >> >> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel >> >> This is good news indeed. However, we noticed that the original >> comparison was missing few approaches like Teredo (RFC4380) or Host >> Identity Protocol (see e.g. RFC5770): >> >> http://tools.ietf.org/html/draft-jesup-rtcweb-data >> >> Despite the original document missed the two protocols, I'm sure that >> they were was discussed at some point, maybe even just in face-to-face >> conversations. Now, my goal is not advocate either of these protocols >> as a replacement for the WG as you have already consensus, but I'd >> rather like to get feedback why some protocols were excluded. >> >> To be more specific, we're working on a research paper on deployment >> analysis on Host Identity Protocol (HIP) in Aalto University and we'd >> like get your expert opinion on especially why HIP was not the adopted >> in the context of rtcweb. Here's few example considerations: >> >> - Never heard about HIP >> - The substitute technologies do their work better >> - Lack of implementation maturity or usability >> - Not standards track yet; we can build rtcweb out of standards track >> components >> - The fatal flaw for HIP in this particular context is X >> - HIP is in the wrong layer of the stack? >> >> Besides technical incentives, we're also interested business and >> political incentives. Feel free to respond me directly or via the >> mailing list (unless people think it's too off-the-topic). Your >> feedback will be anonymized in the publication. >> >> Thanks! >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > From fluffy@iii.ca Thu Mar 8 09:56:12 2012 Return-Path: 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 F1A8521F86B1 for ; Thu, 8 Mar 2012 09:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.767 X-Spam-Level: X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599] 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 hBwypkuTNbfK for ; Thu, 8 Mar 2012 09:56:12 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4181E21F8691 for ; Thu, 8 Mar 2012 09:56:12 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C5D7822E25D for ; Thu, 8 Mar 2012 12:56:05 -0500 (EST) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 10:56:03 -0700 Message-Id: <49AF9B93-9800-4F3E-8E85-CC0298F9320A@iii.ca> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Draft Agenda for RTCWeb at IETF83 v2 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:56:13 -0000 Here is an updated draft agenda. Please let me know what internet drafts = you think are mandatory reading material for each section.=20 Draft Agenda for RTCWeb at IETF83=20 (Version 2 of agenda done March 8) First Session ------------------- Admin Update (Chairs) - 10 min=20 - update from mmusic, avtcore, ICCRG and other WG=20 W3C Update (Harald) - 10 min Identity Proxy (Eric Rescorla) - 50 min=20 What to do about RTP and/or SDES (Dan Wing) - 80 min=20 Second Session ----------------------- Admin (Chairs) - 10 min=20 - scheduling the next interim meeting=20 Signaling (Justin Uberti) - 60 min =20 draft-ietf-rtcweb-jsep Data Channel (Salvatore Loreto) - 30 min draft-ietf-rtcweb-data-channel Codec Selection (Adam Roach) - 50 min There are some things that we did not put onto the agenda that I would = to comment on.=20 The following items have time in other meetings and the chairs will = provide summary information on what happened - SDP updates: msid and bundle - our use of those functions being = defined in MMUSIC - Use of multiplexing functions described by AVTCORE - Congestion control as discussed in the ICCRG meeting The following items are clearly areas where we need more work but, given = the time limits of the meeting and the list discussion to date, the = chairs hope to make these to be big topics at our next interim meeting.=20= - RTP feature profiling: What do we use? (mandatory / permitted / = recommended-against) - SDP feature profiling: What do we use? (same alternatives) There is also work that needs discussion but overlaps into the work = being done in MMUSIC and other place including: - Video resolution negotiation per SSRC: What are the alternatives? Can = we recommend one? - Mute/hold signaling (per SSRC) - How to convey label/id of a MediaStreamTrack over a PeerConnection The final topic which we believe can simply progress with mailing list = discussion is=20 - defining URIs for STUN and TURN servers=20 Cullen on behalf of the chairs From harald@alvestrand.no Thu Mar 8 10:07:43 2012 Return-Path: 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 70FBD21F86DE for ; Thu, 8 Mar 2012 10:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.426 X-Spam-Level: X-Spam-Status: No, score=-110.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 YxCjVGkjSK56 for ; Thu, 8 Mar 2012 10:07:42 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 799CF21F86DF for ; Thu, 8 Mar 2012 10:07:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B9EA439E29B; Thu, 8 Mar 2012 19:07:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjwE4UPJ5C-G; Thu, 8 Mar 2012 19:07:41 +0100 (CET) Received: from [192.168.11.107] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 26F2539E27B; Thu, 8 Mar 2012 19:07:41 +0100 (CET) Message-ID: <4F58F56B.8000301@alvestrand.no> Date: Thu, 08 Mar 2012 19:07:39 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Miika Komu References: <4F5872F4.8070607@cs.hut.fi> <4F5886ED.5090803@alvestrand.no> <4F58E782.7010309@cs.hut.fi> In-Reply-To: <4F58E782.7010309@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] host identity protocol X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:07:43 -0000 On 03/08/2012 06:08 PM, Miika Komu wrote: > Hi Harald, > > thanks for the quick response. You're absolutely right, HIP does not > support congestion control. It actually even shouldn't support it > because it's not a transport-layer protocol. Typically people use > HIP/IPsec for end-to-end tunneling of TCP or UDP. The tunnel is > encrusted in an extra UDP header to make HIP/ESP pass NAT boxes which > actually makes it a nice fit for NAT penetration. The data-plane can > be negotiated during the key exchange process and e.g. S-RTP has been > proposed to replace IPsec. > > Are you sure about the reasoning - has it been a misunderstanding or > maybe some other reasoning fits better? Thanks for your feedback! The last discussion was in september/october 2011. Please review the archives. > > On 03/08/2012 12:16 PM, Harald Alvestrand wrote: >> HIP was discussed at a far earlier stage, when talking about security. >> We chose to go with DTLS, SRTP and ICE instead, since these were >> mechanisms in (relatively) common use in this environment. >> >> As far as I understand HIP, it does not contain congestion control >> mechanisms, so its use was not considered when picking a protocol for >> the data channel. >> >> On 03/08/2012 09:51 AM, Miika Komu wrote: >>> Dear WG, >>> >>> I heard that you're making progress and have selected a specific >>> protocol approach for rtcweb: >>> >>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel >>> >>> This is good news indeed. However, we noticed that the original >>> comparison was missing few approaches like Teredo (RFC4380) or Host >>> Identity Protocol (see e.g. RFC5770): >>> >>> http://tools.ietf.org/html/draft-jesup-rtcweb-data >>> >>> Despite the original document missed the two protocols, I'm sure that >>> they were was discussed at some point, maybe even just in face-to-face >>> conversations. Now, my goal is not advocate either of these protocols >>> as a replacement for the WG as you have already consensus, but I'd >>> rather like to get feedback why some protocols were excluded. >>> >>> To be more specific, we're working on a research paper on deployment >>> analysis on Host Identity Protocol (HIP) in Aalto University and we'd >>> like get your expert opinion on especially why HIP was not the adopted >>> in the context of rtcweb. Here's few example considerations: >>> >>> - Never heard about HIP >>> - The substitute technologies do their work better >>> - Lack of implementation maturity or usability >>> - Not standards track yet; we can build rtcweb out of standards track >>> components >>> - The fatal flaw for HIP in this particular context is X >>> - HIP is in the wrong layer of the stack? >>> >>> Besides technical incentives, we're also interested business and >>> political incentives. Feel free to respond me directly or via the >>> mailing list (unless people think it's too off-the-topic). Your >>> feedback will be anonymized in the publication. >>> >>> Thanks! >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> > > From mkomu@cs.hut.fi Thu Mar 8 10:50:53 2012 Return-Path: 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 3ED1421F85E7 for ; Thu, 8 Mar 2012 10:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 d3ZKNiGRMEiU for ; Thu, 8 Mar 2012 10:50:52 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 11BFC21F84A7 for ; Thu, 8 Mar 2012 10:50:50 -0800 (PST) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1S5iQJ-0004xK-BA; Thu, 08 Mar 2012 20:50:47 +0200 Message-ID: <4F58FF87.1090804@cs.hut.fi> Date: Thu, 08 Mar 2012 20:50:47 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <4F5872F4.8070607@cs.hut.fi> <4F5886ED.5090803@alvestrand.no> <4F58E782.7010309@cs.hut.fi> <4F58F56B.8000301@alvestrand.no> In-Reply-To: <4F58F56B.8000301@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] host identity protocol X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:50:53 -0000 Hi Harald, On 03/08/2012 08:07 PM, Harald Alvestrand wrote: > On 03/08/2012 06:08 PM, Miika Komu wrote: >> Hi Harald, >> >> thanks for the quick response. You're absolutely right, HIP does not >> support congestion control. It actually even shouldn't support it >> because it's not a transport-layer protocol. Typically people use >> HIP/IPsec for end-to-end tunneling of TCP or UDP. The tunnel is >> encrusted in an extra UDP header to make HIP/ESP pass NAT boxes which >> actually makes it a nice fit for NAT penetration. The data-plane can >> be negotiated during the key exchange process and e.g. S-RTP has been >> proposed to replace IPsec. >> >> Are you sure about the reasoning - has it been a misunderstanding or >> maybe some other reasoning fits better? Thanks for your feedback! > The last discussion was in september/october 2011. Please review the > archives. I went through the archives and it appears that there was no technical reason for excluding HIP: http://www.ietf.org/mail-archive/web/rtcweb/current/msg01679.html So, it just appears that there was only one person suggesting HIP, i.e., the reason was the lack of contributors. Technically, it appears that the WG decision was based on an incomplete analysis of the solution space though (but, that's life). Nevertheless, I'm sure that you'll find inventive uses for SCTP associations in the context web - I wish you the very best luck in your endeavors! >> On 03/08/2012 12:16 PM, Harald Alvestrand wrote: >>> HIP was discussed at a far earlier stage, when talking about security. >>> We chose to go with DTLS, SRTP and ICE instead, since these were >>> mechanisms in (relatively) common use in this environment. >>> >>> As far as I understand HIP, it does not contain congestion control >>> mechanisms, so its use was not considered when picking a protocol for >>> the data channel. >>> >>> On 03/08/2012 09:51 AM, Miika Komu wrote: >>>> Dear WG, >>>> >>>> I heard that you're making progress and have selected a specific >>>> protocol approach for rtcweb: >>>> >>>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel >>>> >>>> This is good news indeed. However, we noticed that the original >>>> comparison was missing few approaches like Teredo (RFC4380) or Host >>>> Identity Protocol (see e.g. RFC5770): >>>> >>>> http://tools.ietf.org/html/draft-jesup-rtcweb-data >>>> >>>> Despite the original document missed the two protocols, I'm sure that >>>> they were was discussed at some point, maybe even just in face-to-face >>>> conversations. Now, my goal is not advocate either of these protocols >>>> as a replacement for the WG as you have already consensus, but I'd >>>> rather like to get feedback why some protocols were excluded. >>>> >>>> To be more specific, we're working on a research paper on deployment >>>> analysis on Host Identity Protocol (HIP) in Aalto University and we'd >>>> like get your expert opinion on especially why HIP was not the adopted >>>> in the context of rtcweb. Here's few example considerations: >>>> >>>> - Never heard about HIP >>>> - The substitute technologies do their work better >>>> - Lack of implementation maturity or usability >>>> - Not standards track yet; we can build rtcweb out of standards track >>>> components >>>> - The fatal flaw for HIP in this particular context is X >>>> - HIP is in the wrong layer of the stack? >>>> >>>> Besides technical incentives, we're also interested business and >>>> political incentives. Feel free to respond me directly or via the >>>> mailing list (unless people think it's too off-the-topic). Your >>>> feedback will be anonymized in the publication. >>>> >>>> Thanks! >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> >> >> > From Jim.Barnett@genesyslab.com Thu Mar 8 10:53:35 2012 Return-Path: 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 5272F21F85D1 for ; Thu, 8 Mar 2012 10:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 ta3QtsPKoQbx for ; Thu, 8 Mar 2012 10:53:34 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id C92E221F84A7 for ; Thu, 8 Mar 2012 10:53:34 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q28IrTXt010160; Thu, 8 Mar 2012 10:53:29 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 10:53:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 10:53:03 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] when should ICE start? Thread-Index: Acz9SMR8vFG1MWegS3GwSqPD1jsqoQAE7+5g References: <4F58D0FE.9060909@alvestrand.no> From: "Jim Barnett" To: "Eric Rescorla" X-OriginalArrivalTime: 08 Mar 2012 18:53:29.0997 (UTC) FILETIME=[C0C6BBD0:01CCFD5C] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] when should ICE start? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:53:35 -0000 Eric, I guess this amounts to my original option B - decide that the problem = isn't as serious as we thought. That's not what it sounded like during = the first discussion of the issue, but I'm fine with it others agree. - Jim -----Original Message----- From: Eric Rescorla [mailto:ekr@rtfm.com]=20 Sent: Thursday, March 08, 2012 11:30 AM To: Jim Barnett Cc: Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] when should ICE start? On Thu, Mar 8, 2012 at 8:01 AM, Jim Barnett = wrote: > Yes, certainly if the Syrian secret police controls the server, I'm in = trouble no matter what. =A0But isn't there a separate case where a = third-party server, not under police control, serves up careless JS that = reveals my location to the caller before I'm aware I'm being called? = =A0This was the case we were worried about in the earlier discussion - = that the caller could discover the answerer's =A0location even if the = answerer rejected the call. =A0(I think that the example in Section 8 = will permit this.) =A0So the trust question is: =A0do we let the server = decide whether to allow this, or do we put defaults in the browser to = protect location information even if the server is carelessly coded? > I'm not sure that ICE and WebRTC create much of a new risk here. If the = server is badly coded then there are a lot of ways to leak the user's = location. To give one, say I use targeted ad buys to get the server to = show you JS that includes (a) cookies and (b) calls back to my server to reveal location = information. -Ekr From harald@alvestrand.no Thu Mar 8 11:43:30 2012 Return-Path: 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 11D9F21E802B for ; Thu, 8 Mar 2012 11:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.442 X-Spam-Level: X-Spam-Status: No, score=-110.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 nhoKEmn5su75 for ; Thu, 8 Mar 2012 11:43:29 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 65A2E21E8028 for ; Thu, 8 Mar 2012 11:43:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F92B39E29B; Thu, 8 Mar 2012 20:43:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkD0HeJDvCtJ; Thu, 8 Mar 2012 20:43:28 +0100 (CET) Received: from [192.168.11.193] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0CE1039E27B; Thu, 8 Mar 2012 20:43:28 +0100 (CET) Message-ID: <4F590BDF.7050004@alvestrand.no> Date: Thu, 08 Mar 2012 20:43:27 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jim Barnett References: <4F58D0FE.9060909@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] when should ICE start? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:43:30 -0000 On 03/08/2012 07:53 PM, Jim Barnett wrote: > Eric, > I guess this amounts to my original option B - decide that the problem isn't as serious as we thought. That's not what it sounded like during the first discussion of the issue, but I'm fine with it others agree. It's strongly application dependent. Fedex' answering machine, or a call center switchboard, will take great pain to reply as quickly as possibly, and has no expectation of privacy; a subscriber to "anonymous flirting page" might have completely different expectations. When something is application dependent, I don't see that it's possible to make rules that allow "only one way to do it". > - Jim > > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Thursday, March 08, 2012 11:30 AM > To: Jim Barnett > Cc: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] when should ICE start? > > On Thu, Mar 8, 2012 at 8:01 AM, Jim Barnett wrote: >> Yes, certainly if the Syrian secret police controls the server, I'm in trouble no matter what. But isn't there a separate case where a third-party server, not under police control, serves up careless JS that reveals my location to the caller before I'm aware I'm being called? This was the case we were worried about in the earlier discussion - that the caller could discover the answerer's location even if the answerer rejected the call. (I think that the example in Section 8 will permit this.) So the trust question is: do we let the server decide whether to allow this, or do we put defaults in the browser to protect location information even if the server is carelessly coded? >> > I'm not sure that ICE and WebRTC create much of a new risk here. If the server is badly coded then there are a lot of ways to leak the user's location. To give one, say I use targeted ad buys to get the server to show you JS that includes > (a) cookies and (b) calls back to my server to reveal location information. > > -Ekr > From igor.faynberg@alcatel-lucent.com Thu Mar 8 12:35:06 2012 Return-Path: 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 F3A7621E8048 for ; Thu, 8 Mar 2012 12:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.126 X-Spam-Level: X-Spam-Status: No, score=-9.126 tagged_above=-999 required=5 tests=[AWL=1.473, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 guNU3EN1ssVs for ; Thu, 8 Mar 2012 12:35:05 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 652D221E801C for ; Thu, 8 Mar 2012 12:35:05 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q28KZ4pA018314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 Mar 2012 14:35:04 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q28KZ4rN020487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Mar 2012 14:35:04 -0600 Received: from [135.244.32.220] (faynberg.lra.lucent.com [135.244.32.220]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q28KZ38M000404; Thu, 8 Mar 2012 14:35:04 -0600 (CST) Message-ID: <4F5917F7.8090601@alcatel-lucent.com> Date: Thu, 08 Mar 2012 15:35:03 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F58D0FE.9060909@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] when should ICE start? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:35:06 -0000 Just following up on your original question: Can we " put defaults in the browser to protect location information"? Igor On 3/8/2012 1:53 PM, Jim Barnett wrote: > Eric, > I guess this amounts to my original option B - decide that the problem isn't as serious as we thought. That's not what it sounded like during the first discussion of the issue, but I'm fine with it others agree. > > - Jim > > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Thursday, March 08, 2012 11:30 AM > To: Jim Barnett > Cc: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] when should ICE start? > > On Thu, Mar 8, 2012 at 8:01 AM, Jim Barnett wrote: >> Yes, certainly if the Syrian secret police controls the server, I'm in trouble no matter what. But isn't there a separate case where a third-party server, not under police control, serves up careless JS that reveals my location to the caller before I'm aware I'm being called? This was the case we were worried about in the earlier discussion - that the caller could discover the answerer's location even if the answerer rejected the call. (I think that the example in Section 8 will permit this.) So the trust question is: do we let the server decide whether to allow this, or do we put defaults in the browser to protect location information even if the server is carelessly coded? >> > I'm not sure that ICE and WebRTC create much of a new risk here. If the server is badly coded then there are a lot of ways to leak the user's location. To give one, say I use targeted ad buys to get the server to show you JS that includes > (a) cookies and (b) calls back to my server to reveal location information. > > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Thu Mar 8 14:38:03 2012 Return-Path: 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 C00C221E8042 for ; Thu, 8 Mar 2012 14:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.971 X-Spam-Level: X-Spam-Status: No, score=-100.971 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_40=-0.185, HTML_MESSAGE=0.001, 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 KL2rrElxKCcC for ; Thu, 8 Mar 2012 14:38:02 -0800 (PST) Received: from blu0-omc2-s3.blu0.hotmail.com (blu0-omc2-s3.blu0.hotmail.com [65.55.111.78]) by ietfa.amsl.com (Postfix) with ESMTP id 494A321E8021 for ; Thu, 8 Mar 2012 14:37:59 -0800 (PST) Received: from BLU152-W30 ([65.55.111.71]) by blu0-omc2-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 14:37:58 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_0d932b52-f93e-44de-b591-104c008cea6d_" X-Originating-IP: [76.22.61.46] From: Bernard Aboba To: , Date: Thu, 8 Mar 2012 14:37:58 -0800 Importance: Normal In-Reply-To: <4F5917F7.8090601@alcatel-lucent.com> References: <4F58D0FE.9060909@alvestrand.no> , , <4F5917F7.8090601@alcatel-lucent.com> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 22:37:58.0963 (UTC) FILETIME=[1CE7D830:01CCFD7C] Subject: Re: [rtcweb] Location/Privacy protection X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 22:38:03 -0000 --_0d932b52-f93e-44de-b591-104c008cea6d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Protection of location (and privacy in general) depends on a number of indi= vidual decisions=2C not just use of relays.=20 For example=2C use of an FQDN in the CNAME can leak location information.=20 My recommendation would be to focus on the media plane rather than signalin= g=2C since there are a lot of ways to leak location in SIP (or XMPP=2C for that matter= ). =20 = --_0d932b52-f93e-44de-b591-104c008cea6d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Protection of location (and privacy in general) depends on a number of indi= vidual decisions=2C not just use of relays.

For example=2C use of a= n FQDN in the CNAME can leak location information.

My recommendatio= n would be to focus on the media plane rather than signaling=2C since
th= ere are a lot of ways to leak location in SIP (or XMPP=2C for that matter).=  =3B

=
= --_0d932b52-f93e-44de-b591-104c008cea6d_-- From bernard_aboba@hotmail.com Thu Mar 8 14:48:08 2012 Return-Path: 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 EF4AC21F8658 for ; Thu, 8 Mar 2012 14:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.134 X-Spam-Level: X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jng1bNPEY3st for ; Thu, 8 Mar 2012 14:48:07 -0800 (PST) Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by ietfa.amsl.com (Postfix) with ESMTP id 145B421F8657 for ; Thu, 8 Mar 2012 14:48:07 -0800 (PST) Received: from BLU152-W48 ([65.55.111.72]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 14:48:06 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_e2c9889c-2ff8-4234-9753-5a7ee3b6d722_" X-Originating-IP: [76.22.61.46] From: Bernard Aboba To: , Date: Thu, 8 Mar 2012 14:48:06 -0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 22:48:06.0604 (UTC) FILETIME=[871680C0:01CCFD7D] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I'd like to discuss my proposal (jingle-web) at next WG session X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 22:48:08 -0000 --_e2c9889c-2ff8-4234-9753-5a7ee3b6d722_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In general=2C Jingle extensions are within the purview of the XSF=2C rather= than IETF and the DOM is owned by W3C.=20 So other than the question of mandatory signaling implementation in browser= s (which as Ted noted=2C has already been discussed)=2C it seems to me that= much of this document is out of scope not only of RTCWEB=2C but the IETF. = =20 > Date: Thu=2C 8 Mar 2012 08:27:47 -0800 > From: ted.ietf@gmail.com > To: hiro.suzuki@d3communications.jp > CC: rtcweb@ietf.org > Subject: Re: [rtcweb] I'd like to discuss my proposal (jingle-web) at nex= t WG session >=20 > Hi Suzuki-san=2C >=20 > Given that this apparently revisits some decisions that were already > made=2C the chairs would like to see working group discussion of the > draft before allocating agenda time to it for the upcoming meeting. >=20 > best regards=2C >=20 > Ted Hardie for the Chairs >=20 > On Wed=2C Feb 29=2C 2012 at 7:34 PM=2C HIro Suzuki > wrote: > > Hello RTCWeb WG members=2C > > > > > > It's my first post to this ML=2C and at Feb 28th=2C I submitted my ID > > from IETF ID submit tool. This ID's file name is > > "draft-suzuki-rtcweb-jingle-web-00.txt" and this ID provides my proposa= l > > to realize one of solutions of RTCWeb by using XMPP Jingle as a signali= ng > > protocol. > > > > Following paragraph is abstract of my ID=2C and I'd like to discuss my > > proposal at RTCWeb WG session in next Paris meeting. > > > > > > --- > > Abstract: > > XMPP Jingle specification defines an XMPP protocol extension for > > managing peer-to-peer media sessions between two users. And XMPP > > Jingle can manage multi contents simultaneously in one Jingle > > stream=2C but in the XMPP world there is no common way to layout > > variable multi contents on each display. In this document=2C a > > solution to this issue is provided by using Web browser's layout > > function. > > > > This document describes a new concept to realize one of solutions > > of RTCWeb. Of course=2C "=3BWeb Browser"=3B is used for Web ap= plication's > > frontend for real-time communication=2C and XMPP Jingle specification > > (XEP-166) is used as signaling protocol. And a simple mapping > > manner between jingle contents and HTML graphical elements enables > > to unite Web browser'=3Bs layout function and Jingle'=3Bs media = content > > management function to realize RTCWeb functions. > > --- > > > > > > Best Regards=2C > > Yoshihiro Suzuki > > (hiro.suzuki@d3communications.jp) > > _______________________________________________ > > 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 = --_e2c9889c-2ff8-4234-9753-5a7ee3b6d722_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In general=2C Jingle extensions are within the purview of the XSF=2C rather= than IETF and the DOM is owned by W3C.

So other than the question = of mandatory signaling implementation in browsers (which as Ted noted=2C ha= s already been discussed)=2C it seems to me that much of this document is o= ut of scope not only of RTCWEB=2C but the IETF. =3B



>=3B Date: Thu=2C 8 Mar 2012 08:2= 7:47 -0800
>=3B From: ted.ietf@gmail.com
>=3B To: hiro.suzuki@d3c= ommunications.jp
>=3B CC: rtcweb@ietf.org
>=3B Subject: Re: [rtcw= eb] I'd like to discuss my proposal (jingle-web) at next WG session
>= =3B
>=3B Hi Suzuki-san=2C
>=3B
>=3B Given that this appare= ntly revisits some decisions that were already
>=3B made=2C the chairs= would like to see working group discussion of the
>=3B draft before a= llocating agenda time to it for the upcoming meeting.
>=3B
>=3B = best regards=2C
>=3B
>=3B Ted Hardie for the Chairs
>=3B >=3B On Wed=2C Feb 29=2C 2012 at 7:34 PM=2C HIro Suzuki
>=3B <= =3Bhiro.suzuki@d3communications.jp>=3B wrote:
>=3B >=3B Hello RTCW= eb WG members=2C
>=3B >=3B
>=3B >=3B
>=3B >=3B It's my= first post to this ML=2C and at Feb 28th=2C I submitted my ID
>=3B &g= t=3B from IETF ID submit tool. This ID's file name is
>=3B >=3B "dra= ft-suzuki-rtcweb-jingle-web-00.txt" and this ID provides my proposal
>= =3B >=3B to realize one of solutions of RTCWeb by using XMPP Jingle as a = signaling
>=3B >=3B protocol.
>=3B >=3B
>=3B >=3B Foll= owing paragraph is abstract of my ID=2C and I'd like to discuss my
>= =3B >=3B proposal at RTCWeb WG session in next Paris meeting.
>=3B &= gt=3B
>=3B >=3B
>=3B >=3B ---
>=3B >=3B Abstract:
&= gt=3B >=3B  =3BXMPP Jingle specification defines an XMPP protocol ext= ension for
>=3B >=3B  =3Bmanaging peer-to-peer media sessions be= tween two users. And XMPP
>=3B >=3B  =3BJingle can manage multi = contents simultaneously in one Jingle
>=3B >=3B  =3Bstream=2C bu= t in the XMPP world there is no common way to layout
>=3B >=3B  = =3Bvariable multi contents on each display. In this document=2C a
>=3B= >=3B  =3Bsolution to this issue is provided by using Web browser's l= ayout
>=3B >=3B  =3Bfunction.
>=3B >=3B
>=3B >=3B =  =3BThis document describes a new concept to realize one of solutions>=3B >=3B  =3Bof RTCWeb. Of course=2C &=3Bquot=3BWeb Browser&a= mp=3Bquot=3B is used for Web application's
>=3B >=3B  =3Bfronten= d for real-time communication=2C and XMPP Jingle specification
>=3B &g= t=3B  =3B(XEP-166) is used as signaling protocol. And a simple mapping<= br>>=3B >=3B  =3Bmanner between jingle contents and HTML graphical = elements enables
>=3B >=3B  =3Bto unite Web browser&=3B#39=3B= s layout function and Jingle&=3B#39=3Bs media content
>=3B >=3B &= nbsp=3Bmanagement function to realize RTCWeb functions.
>=3B >=3B --= -
>=3B >=3B
>=3B >=3B
>=3B >=3B Best Regards=2C
>= =3B >=3B Yoshihiro Suzuki
>=3B >=3B (hiro.suzuki@d3communications.= jp)
>=3B >=3B _______________________________________________
>= =3B >=3B rtcweb mailing list
>=3B >=3B rtcweb@ietf.org
>=3B &= gt=3B https://www.ietf.org/mailman/listinfo/rtcweb
>=3B ______________= _________________________________
>=3B rtcweb mailing list
>=3B r= tcweb@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/rtcweb
= --_e2c9889c-2ff8-4234-9753-5a7ee3b6d722_-- From ekr@rtfm.com Thu Mar 8 18:23:59 2012 Return-Path: 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 4FF2511E8080 for ; Thu, 8 Mar 2012 18:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.082 X-Spam-Level: X-Spam-Status: No, score=-103.082 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 0MFVVZ7S7ScY for ; Thu, 8 Mar 2012 18:23:58 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B29C611E8075 for ; Thu, 8 Mar 2012 18:23:58 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1160350vcb.31 for ; Thu, 08 Mar 2012 18:23:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=wq9NovzMtsHaUV0nEfeyLKF6OBKPTxoJwKpOKcNk84E=; b=d7QmPAzkogZiCrCElyHkqwFgSoEbHIidIfrG1hbd0Isrut99/j10u2YlytTmxpZut7 NNIt5MZFlFIu+UZrdxGXPKRPCCqO3gcY6GRFEqGadpZb/dlcBVXtWjl5kYze3KCL1E1r yn7VqaJQz3+DAhIGS7+fmeI1LDnRV9YJiHRhQuQ/TYsAI0NE9k1W5t06UAZc9uBqb7Yk +NPjoY0i6LyRCbhYruh/se/RD98eQjGwHpncPSklZgfZkcn5lvR0T9nf3hTeQaXaElxE zbihKheNADEoBTbHADfnr5dhvKjphCGWAs3CWRfYzU50RsnZYvptB5UdIv/TMp5QuKxJ iuqw== Received: by 10.52.70.175 with SMTP id n15mr856050vdu.10.1331259831421; Thu, 08 Mar 2012 18:23:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.70.231 with HTTP; Thu, 8 Mar 2012 18:23:11 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4F58D0FE.9060909@alvestrand.no> <4F590BDF.7050004@alvestrand.no> From: Eric Rescorla Date: Thu, 8 Mar 2012 18:23:11 -0800 Message-ID: To: Jim Barnett Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnHie8dkeb37PDEhBOCWBUSkC3dkzNeyZ3qVhLF4JNhKd4btQQX2SR49k19tiAWeeKsHMRI Cc: rtcweb@ietf.org Subject: Re: [rtcweb] when should ICE start? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 02:23:59 -0000 On Thu, Mar 8, 2012 at 6:16 PM, Jim Barnett wrote: > Yes, but if we can trust the anonymous flirting site to protect our > privacy, why can't we trust it not to record our calls if we use SDES? > Can we trust the web server to do what we expect, or should we be > systematically untrusting? Is this a trick question? 1. There's a pretty big difference between knowing where I am and being able to listen to my calls. 2. The IP-location privacy threat is pre-existing and not fundamentally a WebRTC problem. 3. Nevertheless, people are concerned about it, which is why things like Tor exist. -Ekr From magnus.westerlund@ericsson.com Fri Mar 9 02:50:51 2012 Return-Path: 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 A81FD21F85E5 for ; Fri, 9 Mar 2012 02:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.352 X-Spam-Level: X-Spam-Status: No, score=-110.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 NEYmvnjBiUDK for ; Fri, 9 Mar 2012 02:50:51 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 970EA21F855B for ; Fri, 9 Mar 2012 02:50:50 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-e2-4f59e0894b4b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3D.5E.27041.980E95F4; Fri, 9 Mar 2012 11:50:49 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Mar 2012 11:50:49 +0100 Message-ID: <4F59E086.2030802@ericsson.com> Date: Fri, 9 Mar 2012 11:50:46 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F58AC35.1010500@ericsson.com> In-Reply-To: <4F58AC35.1010500@ericsson.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Proposal for media receiver request of codec parameter changes (draft-westerlund-avtext-codec-operation-point-00) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 10:50:51 -0000 Hi, To make it clear. There is an IPR disclosure on this draft from Ericsson. https://datatracker.ietf.org/ipr/1701/ Regards Magnus On 2012-03-08 13:55, Magnus Westerlund wrote: > WG, > > As an individual I would like to inform you that my colleagues and I > have submitted a proposal to AVTEXT WG. This proposal is an RTCP > extension that enables RTP session participants to request the media > sender to adjust its media parameters, like video resolution. > > The draft can be retrieved here: > https://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operation-point/ > > One use case we have designed this for is to enable the dynamic updates > codec parameters as result of WebRTC applications usage of media > streams. If the application changes the rendering layout or the user > changes the browser window size, the size of a video playout can change. > This may happen in a quite dynamic way and often enough that we think > using a mechanism where the receiver can use a request over the media > plane rather than the signalling plane to adjust the parameters will > give a more responsive and satisfying experience. We have also designed > it with centralized conferencing into mind, allowing the central node to > aggregate requests to best suit the whole population. > > We request that feedback on the actual extension are directed to the > AVTEXT WG mailing list: avtext@ietf.org > > I am happy to discuss the usage and applicability to WebRTC on this list. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From zs68j2ee@gmail.com Fri Mar 9 09:40:45 2012 Return-Path: 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 967E421F863E for ; Fri, 9 Mar 2012 09:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] 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 Y6GZgObnh56l for ; Fri, 9 Mar 2012 09:40:45 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED80B21F8637 for ; Fri, 9 Mar 2012 09:40:44 -0800 (PST) Received: by obbta4 with SMTP id ta4so2752147obb.31 for ; Fri, 09 Mar 2012 09:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Fe4eiGqOlnVdw37pajlEJmS3hFKotBEGQLI5ie7v4q4=; b=whxR+Z5UD9cVRWmT8vYYfIAivaBqSunHRBJVU53EKLRW46wni/g7i/Bv7tmtPyGWTh 2Bxj2stziugx0/KOeYEBbInxL4UA0sGytFT2PGYrM5vvCrz6IRE469BxT7K/mNFNN7dz MD1wHDgCre7CS/j803JruCk/rCva7xhS5D5PozZxWiTW5/0HnYSU268SYlULmuzxMkFc 1e1FiugXOe+QqEhc+raTNlGV+eTISyM3Re7snks3tWKfN4Q3euADPLFIZyd2bpNJxRPb O6LNo8CNcKCiIfA+3yIoJ9ben9KLIMMnLm26K9NtCEMK8AjjzeIonQtxLQEqkEY8Nmrf kH4Q== MIME-Version: 1.0 Received: by 10.182.0.48 with SMTP id 16mr1309998obb.23.1331314844619; Fri, 09 Mar 2012 09:40:44 -0800 (PST) Received: by 10.60.142.234 with HTTP; Fri, 9 Mar 2012 09:40:44 -0800 (PST) In-Reply-To: References: Date: Sat, 10 Mar 2012 01:40:44 +0800 Message-ID: From: tom To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=f46d043893ff65d1f004bad2e45b Subject: [rtcweb] some thoughts on an alternative WebRTC approach: iWebPP - instant web p2p technology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:40:45 -0000 --f46d043893ff65d1f004bad2e45b Content-Type: text/plain; charset=UTF-8 Hi, WebRTC intends to setup P2P communication between browsers, then carry video/audio/text media, etc. For example, in the conference call, WebRTC takes four tasks: 1. pick up local medias: video, voice, etc 2. encoding local medias 3. streaming medias via p2p channel securely 4. decoding medias for item 1, it need to export OS level media interfaces to browser via JS. for item 3, it should implement Streaming Server in browser with html5 techs: web workers, etc for item 2 and 4, it should implement a lot of algorithms on video and audio. the most of them is redundant works against gstreamer/ffmpeg. AFAIK there are two reference implementations to WebRTC: Google's and Ericsson Lab's. Google is doing all stuff, while Ericsson reuses gstreamer. Item1 above has no many stories. But, item2,4 and item3 may have another stories. Why we need WebRTC? Firstly, Web is the most popular network app, secondly, video/voice brings the best user experience. But, the problem is that HTTP runs upon TCP by now, while P2P runs upon UDP normally. Suppose both web browser and server can run HTTP upon UDP(the protocol schema as HTTPP), what happen? Firstly, Web app developers can program HTTPP like HTTP, secondly, P2P traffic can be carried on HTTPP. Basically iWebPP consists of two parts: HTTPP-enabled web browser and web server. We have implemented a Firefox extension and Node.js variant to run HTTP upon UDP. They are the first step and will be open source soon. Any thoughts? thanks. Best regards Tom --f46d043893ff65d1f004bad2e45b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


= =C2=A0 WebRTC intends to setup P2P communication between browsers, then car= ry video/audio/text media, etc.

=C2=A0 For example, in the conf= erence call, WebRTC takes four tasks:
1. pick up local medias: video, voice, etc
2. encoding local medias
3. streaming medias via p2p channel securely4. decoding medias

for item 1, it need to export OS level media int= erfaces to browser via JS.
for item 3, it should implement Streaming Ser= ver in browser with html5 techs: web workers, etc
for item 2 and 4, it should implement a lot of algorithms on video and audi= o. the most of them is redundant works against gstreamer/ffmpeg.

AFAIK there are two reference implementations to WebRTC: Google's and= Ericsson Lab's. Google is doing all stuff, while Ericsson reuses gstre= amer.
Item1 above has no many stories. But, item2,4 and item3 may have anoth= er stories.=C2=A0

Why we need WebRTC? Firstly, Web= is the most popular network app, secondly, video/voice brings the best use= r experience.
But, the problem is that HTTP runs upon TCP by now, while P2P runs upo= n UDP normally.=C2=A0

Suppose both web browser and= server can run HTTP upon UDP(the protocol schema as HTTPP), what happen?
Firstly, Web app developers can program HTTPP like HTTP, secondly, P2P= traffic can be carried on HTTPP.=C2=A0

Basically = iWebPP consists of two parts: HTTPP-enabled web browser and web server.
We have implemented a Firefox extension and Node.js variant =C2=A0to r= un HTTP upon UDP. They are the first step and will be open source soon.

Any thoughts? thanks.

Best r= egards
=C2=A0 Tom

=C2=A0






--f46d043893ff65d1f004bad2e45b-- From salvatore.loreto@ericsson.com Mon Mar 12 00:36:04 2012 Return-Path: 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 28DE321F8546 for ; Mon, 12 Mar 2012 00:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.925 X-Spam-Level: X-Spam-Status: No, score=-109.925 tagged_above=-999 required=5 tests=[AWL=0.674, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 iYAwJim8Pl1E for ; Mon, 12 Mar 2012 00:36:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADB321F84D2 for ; Mon, 12 Mar 2012 00:36:03 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-0e-4f5da761255f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6C.0E.27041.167AD5F4; Mon, 12 Mar 2012 08:36:02 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Mon, 12 Mar 2012 08:36:01 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8C4FB230B for ; Mon, 12 Mar 2012 09:36:01 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8D6DB51E50 for ; Mon, 12 Mar 2012 09:36:01 +0200 (EET) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4A5374F2F7 for ; Mon, 12 Mar 2012 09:36:01 +0200 (EET) Message-ID: <4F5DA760.9080806@ericsson.com> Date: Mon, 12 Mar 2012 09:36:00 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F5DA093.7020900@ericsson.com> In-Reply-To: <4F5DA093.7020900@ericsson.com> X-Forwarded-Message-Id: <4F5DA093.7020900@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] draft-ietf-mmusic-sctp-sdp-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 07:36:04 -0000 Hi there, I have submitted a new version of the draft-ietf-mmusic-sctp-sdp, that other then fix some little mistakes defines the *DTLS/SCTP* protocol identifier to allow the usage of SCTP on top of the Datagram Transport Layer Security (DTLS) protocol, as defined in [I-D.tuexen-tsvwg-sctp-dtls-encaps], using SDP. SCTP over DTLS is used by the RTCWeb protocol suite for transporting non-media data between browsers. regards Salvatore -- Salvatore Loreto www.sloreto.com On 3/12/12 9:03 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) > Author(s) : Salvatore Loreto > Gonzalo Camarillo > Filename : draft-ietf-mmusic-sctp-sdp-01.txt > Pages : 10 > Date : 2012-03-12 > > SCTP (Stream Control Transmission Protocol) is a transport protocol > used to establish associations between two endpoints. This document > describes how to express media transport over SCTP in SDP (Session > Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' > and 'DTLS/SCTP' protocol identifiers for SDP. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-01.txt > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From internet-drafts@ietf.org Mon Mar 12 14:24:17 2012 Return-Path: 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 02D2011E80D7; Mon, 12 Mar 2012 14:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, 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 jocYnB3kTUT6; Mon, 12 Mar 2012 14:24:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBC811E809F; Mon, 12 Mar 2012 14:24:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312212416.15100.7909.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 14:24:16 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:24:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Web Real-Time Communication (WebRTC): Media Transport an= d Use of RTP Author(s) : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-02.txt Pages : 27 Date : 2012-03-12 The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-rtp-usage-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-rtp-usage-02.txt From ekr@rtfm.com Mon Mar 12 14:25:40 2012 Return-Path: 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 368A711E80F8 for ; Mon, 12 Mar 2012 14:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.779 X-Spam-Level: X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, 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 JIL47KX+1PVu for ; Mon, 12 Mar 2012 14:25:39 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68B8511E80E2 for ; Mon, 12 Mar 2012 14:25:37 -0700 (PDT) Received: by yenm5 with SMTP id m5so3480588yen.31 for ; Mon, 12 Mar 2012 14:25:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=/r4YxLQL25e8eclNIjsD3fp2njaXV/Zyqz7DWkVAlsQ=; b=ftDsxpCObxBzkq2/ZjC6vcI8UlKH0XsAlr2AyqWXEmAR7Bx3UxAAntbLSVa1iV/G0/ 742TzlPtwj7LV+wisHzjLoI5kKIjL0Lg0YH5YdQ7oqLlpvkcLxWnlAnfkuMRKEskjDN0 5YKyYsPpm9guz2yKLk/OrXHucR5E2gd6vUIbhlzgcij2kQvgou0QMSwwMtopvI4N6tyx lY8koLsApEHE7YdO/NsjIcNCVjMUgoITLIieaEoGTNbvzYM/KwuWQ5vLW6J355Mtt/Fe AYM7qi2FQCdQr2JbNIddzCA3RXz5ztRst7n1+TO/m6T5IGnW3nMa4Cbsa65N3LMAfP67 Cb3w== Received: by 10.52.70.175 with SMTP id n15mr15798944vdu.10.1331587535301; Mon, 12 Mar 2012 14:25:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.70.231 with HTTP; Mon, 12 Mar 2012 14:24:55 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4F2FE368.6040207@ericsson.com> References: <4F29BD31.9040700@ericsson.com> <4F2FE368.6040207@ericsson.com> From: Eric Rescorla Date: Mon, 12 Mar 2012 14:24:55 -0700 Message-ID: To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlIJrUlpLWnfbQqHDMLijiCr/pk/TSMLKyDv3fG8ngkqlIcP+SUCrSbzAzuPD9I/QKSdb65 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DoS attack despite ICE/STUN consent verification X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:25:40 -0000 I want to make sure I understand this attack correctly. Alice is making a call to Zed and either Zed is the attacker or the attacke= r somehow captures Alice's media parameters. The attacker then uses Alice's offer (and her parameters) to start ICE handshaking on a pile of Web browsers that he controls. They all start ICE and since the checks with Alice will succeed, then the attacker has apparent consent to send as much traffic as he wants to Alice from each machine. Do I have this right? If I understand this correctly, then the severity of the attack seems to be limited since Alice has to actually be calling someone that is malicious or that has very tight control of the network, and soon after Alice hangs up the phone, the problem goes away. (Assuming consent freshness). As Dan notes, the interaction with consent freshness seems like a key mitigation here. Moreover, I think this suggests that even if integrity is not used, as in draft-muthu, the ufrags should both be present (and unmodifiable from the JS). This would allow a client to discard ICE associations with ufrags that do not match whichever ICE association got selected for the call. -Ekr On Mon, Feb 6, 2012 at 6:27 AM, Magnus Westerlund wrote: > On 2012-02-06 11:19, Oscar Ohlsson wrote: >> >> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org >>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund >>> Sent: den 1 februari 2012 23:31 >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] DoS attack despite ICE/STUN consent verification >>> >>> Hi, >>> >>> As I brought up in yesterdays meeting I think there exist an >>> attack that should be considered. I don't think it is super >>> strong, but not without issues. >>> >>> Setting: >>> >>> Webserver is evil and have a target Alice. Alice can be a >>> legacy device, like a SIP/SDP video phone. It knows the >>> target is doing ICE and have Alice's ufrag and password and >>> candidates. The server would like to hammer this target by >>> utilizing its set of connected WebRTC clients (bob, charlie >>> etc.). Thus it would like to ensure that it gets the browser >>> to start sending RTP media when creating a PeerConnection in >>> the clients. >>> >>> So the server gets the client to open PeerConnections towards >>> the ICE parameters from the target (Alice). >>> >>> In default ICE behavior there is an optimization to allow the Offerer >>> (Alice) to respond to STUN binding requests from Bob without >>> having received an SDP answer from Bob. The STUN binding >>> request must only have the Alice's ufrag and its password. >>> This enables that Webrtc clients can get passed the data >>> consent step with ICE capable end-point for which the ICE >>> parameters can be retrieved. >>> >>> So from Alice perspective this attack will look like its >>> offer got forked to many peers based on the many different >>> peers that send STUN messages. The webserver could even >>> provide SIP/SDP answers to alice with the webclients. But >>> that is not necessary but is one variation of this. >> >> >> Correct me if I'm wrong, but I believe the webserver must provide the > SIP/SDP answers. As far as I can tell there are always two connectivity > checks, one for each direction (Section 2.2 RFC 5245): > >> =A0 =A0L =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0R >> =A0 =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- >> =A0 =A0STUN request -> =A0 =A0 =A0 =A0 =A0 =A0 \ =A0L's >> =A0 =A0 =A0 =A0 =A0 =A0 =A0<- STUN response =A0/ =A0check >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 <- STUN request =A0\ =A0R's >> =A0 =A0STUN response -> =A0 =A0 =A0 =A0 =A0 =A0/ =A0check >> >> Alice would automatically respond to the remote side's check. >> However, in order to genereate her own check (R's check in the >> diagram) she would need to have received the remote side's password. >> According to Section 7.1.2.3. in RFC 5245: >> >> "A connectivity check from R to L utilizes the username LFRAG:RFRAG >> and a password of LPASS." >> >> If this interpretation is correct then counter-measure A below would >> always be a possibility. >> > > Oscar, > > From L's perspective, the process of nomination and validation can > complete without R having succeeded. Thus L (WebRTC Browser) can start > send media to R without R having successfully validated any return path > from R to L. > > Thus, I don't see how A could be made to reliably work as a mitigation. > > In addition are there anyone who actually have this type of attack > protection in their SIP stacks or SIP proxies? > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From internet-drafts@ietf.org Mon Mar 12 14:30:07 2012 Return-Path: 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 3FD0011E8147; Mon, 12 Mar 2012 14:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, 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 kh7tMaFU4YyP; Mon, 12 Mar 2012 14:30:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB3911E813E; Mon, 12 Mar 2012 14:30:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312213000.18921.60881.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 14:30:00 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:30:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Overview: Real Time Protocols for Brower-based Applicati= ons Author(s) : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-03.txt Pages : 20 Date : 2012-03-12 This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion, unless the RTCWEB chairs have declared consensus on an item. This document is a work item of the RTCWEB working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-overview-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-overview-03.txt From ekr@rtfm.com Mon Mar 12 14:30:57 2012 Return-Path: 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 3AB6011E814B for ; Mon, 12 Mar 2012 14:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.77 X-Spam-Level: X-Spam-Status: No, score=-102.77 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, 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 WxWRwMiK2sch for ; Mon, 12 Mar 2012 14:30:56 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB8C011E814A for ; Mon, 12 Mar 2012 14:30:52 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so5495227vcb.31 for ; Mon, 12 Mar 2012 14:30:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=31s1yIiDOAR2xar/F4cOxfIWk4+JlS+FOMJs9LcQsK8=; b=nj8xog5s4ZVbLKT0EZUVvgCYqCBG/kSKZJyjASAtLkwilxyYGXKp+67+AQhIxvPJBJ qW86t8RzV4UsMzzshKwrBGUO4+wW/RgFkV159uItzSkDQQXJNHRnEcme50laanq24xuR KJjVeHb1nadbJeByLWhjW+HtX2oqenWzzR5E7nctnkc0o9UV5xiWP6nYH/belHqkifaQ yDyNDyP9XGCShArwY+8wf6WLdYUd8qlwIa68Hz+j+z+NJIbpoNzpKV8b+aaNwdlgm/Xb gvJ7DXjpzOR0k9gsUo+pjlntSBjLXMUEaHvtFPZ7T30kwlmSWiAxZF/pzNT+P+oZyjl1 4Fww== Received: by 10.52.180.98 with SMTP id dn2mr15598881vdc.61.1331587852159; Mon, 12 Mar 2012 14:30:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.70.231 with HTTP; Mon, 12 Mar 2012 14:30:12 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4F29BD31.9040700@ericsson.com> <4F2FE368.6040207@ericsson.com> From: Eric Rescorla Date: Mon, 12 Mar 2012 14:30:12 -0700 Message-ID: To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm62yTU2xwFx3FAe7eiRojFTxSSwe/LJSRaWV7zra82SRbujkd32kgwLNXdiQlxWg9U4wTr Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DoS attack despite ICE/STUN consent verification X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:30:57 -0000 I should also mention that the users will of course have to have given the attacker's site media access--at least for legacy SIP clients, the attempt by the zombies to form SCTP-over-DTLS associations will fail and therefore the data channel cannot be used here. -Ekr On Mon, Mar 12, 2012 at 2:24 PM, Eric Rescorla wrote: > I want to make sure I understand this attack correctly. > > Alice is making a call to Zed and either Zed is the attacker or the attac= ker > somehow captures Alice's media parameters. The attacker then uses > Alice's offer (and her parameters) to start ICE handshaking on a pile > of Web browsers that he controls. They all start ICE and since the > checks with Alice will succeed, then the attacker has apparent consent > to send as much traffic as he wants to Alice from each machine. > Do I have this right? > > If I understand this correctly, then the severity of the attack seems to > be limited since Alice has to actually be calling someone that is > malicious or that has very tight control of the network, and soon > after Alice hangs up the phone, the problem goes away. (Assuming > consent freshness). > > As Dan notes, the interaction with consent freshness seems like a key > mitigation here. Moreover, I think this suggests that even if integrity > is not used, as in draft-muthu, the ufrags should both be present > (and unmodifiable from the JS). This would allow a client to discard > ICE associations with ufrags that do not match whichever ICE > association got selected for the call. > > -Ekr > > > On Mon, Feb 6, 2012 at 6:27 AM, Magnus Westerlund > wrote: >> On 2012-02-06 11:19, Oscar Ohlsson wrote: >>> >>> >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org >>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund >>>> Sent: den 1 februari 2012 23:31 >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] DoS attack despite ICE/STUN consent verification >>>> >>>> Hi, >>>> >>>> As I brought up in yesterdays meeting I think there exist an >>>> attack that should be considered. I don't think it is super >>>> strong, but not without issues. >>>> >>>> Setting: >>>> >>>> Webserver is evil and have a target Alice. Alice can be a >>>> legacy device, like a SIP/SDP video phone. It knows the >>>> target is doing ICE and have Alice's ufrag and password and >>>> candidates. The server would like to hammer this target by >>>> utilizing its set of connected WebRTC clients (bob, charlie >>>> etc.). Thus it would like to ensure that it gets the browser >>>> to start sending RTP media when creating a PeerConnection in >>>> the clients. >>>> >>>> So the server gets the client to open PeerConnections towards >>>> the ICE parameters from the target (Alice). >>>> >>>> In default ICE behavior there is an optimization to allow the Offerer >>>> (Alice) to respond to STUN binding requests from Bob without >>>> having received an SDP answer from Bob. The STUN binding >>>> request must only have the Alice's ufrag and its password. >>>> This enables that Webrtc clients can get passed the data >>>> consent step with ICE capable end-point for which the ICE >>>> parameters can be retrieved. >>>> >>>> So from Alice perspective this attack will look like its >>>> offer got forked to many peers based on the many different >>>> peers that send STUN messages. The webserver could even >>>> provide SIP/SDP answers to alice with the webclients. But >>>> that is not necessary but is one variation of this. >>> >>> >>> Correct me if I'm wrong, but I believe the webserver must provide the >> SIP/SDP answers. As far as I can tell there are always two connectivity >> checks, one for each direction (Section 2.2 RFC 5245): >> >>> =A0 =A0L =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0R >>> =A0 =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- >>> =A0 =A0STUN request -> =A0 =A0 =A0 =A0 =A0 =A0 \ =A0L's >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<- STUN response =A0/ =A0check >>> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 <- STUN request =A0\ =A0R's >>> =A0 =A0STUN response -> =A0 =A0 =A0 =A0 =A0 =A0/ =A0check >>> >>> Alice would automatically respond to the remote side's check. >>> However, in order to genereate her own check (R's check in the >>> diagram) she would need to have received the remote side's password. >>> According to Section 7.1.2.3. in RFC 5245: >>> >>> "A connectivity check from R to L utilizes the username LFRAG:RFRAG >>> and a password of LPASS." >>> >>> If this interpretation is correct then counter-measure A below would >>> always be a possibility. >>> >> >> Oscar, >> >> From L's perspective, the process of nomination and validation can >> complete without R having succeeded. Thus L (WebRTC Browser) can start >> send media to R without R having successfully validated any return path >> from R to L. >> >> Thus, I don't see how A could be made to reliably work as a mitigation. >> >> In addition are there anyone who actually have this type of attack >> protection in their SIP stacks or SIP proxies? >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 >> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Mon Mar 12 14:31:08 2012 Return-Path: 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 211DA11E814B for ; Mon, 12 Mar 2012 14:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 CA8dKfKJpjfP for ; Mon, 12 Mar 2012 14:31:07 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 326A511E8145 for ; Mon, 12 Mar 2012 14:31:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0D47339E17A for ; Mon, 12 Mar 2012 22:31:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MpVdwY3SxaG for ; Mon, 12 Mar 2012 22:31:04 +0100 (CET) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7E85D39E173 for ; Mon, 12 Mar 2012 22:31:04 +0100 (CET) Message-ID: <4F5E6B15.7090503@alvestrand.no> Date: Mon, 12 Mar 2012 22:31:01 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------070804010801000409060708" Subject: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-overview-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:31:08 -0000 This is a multi-part message in MIME format. --------------070804010801000409060708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI. Not much has changed, but a number of new drafts got referenced. -------- Original Message -------- Subject: New Version Notification for draft-ietf-rtcweb-overview-03.txt Date: Mon, 12 Mar 2012 14:30:00 -0700 From: internet-drafts@ietf.org To: harald@alvestrand.no A new version of I-D, draft-ietf-rtcweb-overview-03.txt has been successfully submitted by Harald T. Alvestrand and posted to the IETF repository. Filename: draft-ietf-rtcweb-overview Revision: 03 Title: Overview: Real Time Protocols for Brower-based Applications Creation date: 2012-03-12 WG ID: rtcweb Number of pages: 20 Abstract: This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -"real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion, unless the RTCWEB chairs have declared consensus on an item. This document is a work item of the RTCWEB working group. The IETF Secretariat --------------070804010801000409060708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI. Not much has changed, but a number of new drafts got referenced.

-------- Original Message --------
Subject: New Version Notification for draft-ietf-rtcweb-overview-03.txt
Date: Mon, 12 Mar 2012 14:30:00 -0700
From: internet-drafts@ietf.org
To: harald@alvestrand.no 


A new version of I-D, draft-ietf-rtcweb-overview-03.txt has been successfully submitted by Harald T. Alvestrand and posted to the IETF repository.

Filename:	 draft-ietf-rtcweb-overview
Revision:	 03
Title:		 Overview: Real Time Protocols for Brower-based Applications
Creation date:	 2012-03-12
WG ID:		 rtcweb
Number of pages: 20

Abstract:
   This document gives an overview and context of a protocol suite
   intended for use with real-time applications that can be deployed in
   browsers - &quot;real time communication on the Web&quot;.

   It intends to serve as a starting and coordination point to make sure
   all the parts that are needed to achieve this goal are findable, and
   that the parts that belong in the Internet protocol suite are fully
   specified and on the right publication track.

   This work is an attempt to synthesize the input of many people, but
   makes no claims to fully represent the views of any of them.  All
   parts of the document should be regarded as open for discussion,
   unless the RTCWEB chairs have declared consensus on an item.

   This document is a work item of the RTCWEB working group.


                                                                                  


The IETF Secretariat
--------------070804010801000409060708-- From csp@csperkins.org Mon Mar 12 14:58:53 2012 Return-Path: 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 7E46021E80D4 for ; Mon, 12 Mar 2012 14:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 tNw2QXMGhUR9 for ; Mon, 12 Mar 2012 14:58:52 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9E51B21E804D for ; Mon, 12 Mar 2012 14:58:52 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1S7DGL-000154-cq for rtcweb@ietf.org; Mon, 12 Mar 2012 21:58:51 +0000 From: Colin Perkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 21:58:39 +0000 References: <20120312212416.15100.7909.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org Message-Id: <2DF80172-253F-4808-AB3D-E0A60A13735B@csperkins.org> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [rtcweb] Fwd: I-D Action: draft-ietf-rtcweb-rtp-usage-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:58:53 -0000 We've just posted an update to our draft on the use of RTP in the RTCWeb = context. This is a minor update, consisting almost entirely of editorial = cleanups. The only technical changes are to make RFC 6222 support = REQUIRED rather than RECOMMENDED, and to replace the discussion of = congestion control requirements with references to = draft-jesup-rtp-congestion-reqs-00 and = draft-perkins-avtcore-rtp-circuit-breakers-00. Colin Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-rtcweb-rtp-usage-02.txt > Date: 12 March 2012 21:24:16 GMT > To: i-d-announce@ietf.org > Cc: rtcweb@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : Web Real-Time Communication (WebRTC): Media = Transport and Use of RTP > Author(s) : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-ietf-rtcweb-rtp-usage-02.txt > Pages : 27 > Date : 2012-03-12 >=20 > The Web Real-Time Communication (WebRTC) framework provides support > for direct interactive rich communication using audio, video, text, > collaboration, games, etc. between two peers' web-browsers. This > memo describes the media transport aspects of the WebRTC framework. > It specifies how the Real-time Transport Protocol (RTP) is used in > the WebRTC context, and gives requirements for which RTP features, > profiles, and extensions need to be supported. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-rtp-usage-02.txt --=20 Colin Perkins http://csperkins.org/ From internet-drafts@ietf.org Mon Mar 12 15:01:56 2012 Return-Path: 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 B090821E810C; Mon, 12 Mar 2012 15:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 BTg3DcCdPGvz; Mon, 12 Mar 2012 15:01:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449DD21E8105; Mon, 12 Mar 2012 15:01:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312220156.2260.60599.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 15:01:56 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:01:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : RTCWEB Security Architecture Author(s) : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-01.txt Pages : 20 Date : 2012-03-12 The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers. The major use cases for RTCWEB technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP- based soft phones) RTCWEB communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. [I-D.ietf- rtcweb-security] defines the RTCWEB threat model. This document defines an architecture which provides security within that threat model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-arch-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-security-arch-01.txt From internet-drafts@ietf.org Mon Mar 12 15:28:54 2012 Return-Path: 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 62B2521E80E9; Mon, 12 Mar 2012 15:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, 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 KFBnAi6NTWow; Mon, 12 Mar 2012 15:28:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9D521F881E; Mon, 12 Mar 2012 15:28:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312222851.15696.64859.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 15:28:51 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:28:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Security Considerations for RTC-Web Author(s) : Eric Rescorla Filename : draft-ietf-rtcweb-security-02.txt Pages : 21 Date : 2012-03-12 The Real-Time Communications on the Web (RTC-Web) working group is tasked with standardizing protocols for real-time communications between Web browsers. The major use cases for RTC-Web technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP- based soft phones) RTC-Web communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. This document defines the RTC-Web threat model and defines an architecture which provides security within that threat model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-security-02.txt From magnus.westerlund@ericsson.com Mon Mar 12 15:42:05 2012 Return-Path: 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 D704A21E816F for ; Mon, 12 Mar 2012 15:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.063 X-Spam-Level: X-Spam-Status: No, score=-110.063 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8, 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 V-dACj7iYRzz for ; Mon, 12 Mar 2012 15:42:05 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6C03221E8167 for ; Mon, 12 Mar 2012 15:42:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-ca-4f5e7bb5966f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 21.05.17856.5BB7E5F4; Mon, 12 Mar 2012 23:41:57 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Mon, 12 Mar 2012 23:41:56 +0100 Message-ID: <4F5E7BB3.6030803@ericsson.com> Date: Mon, 12 Mar 2012 23:41:55 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Eric Rescorla References: <4F29BD31.9040700@ericsson.com> <4F2FE368.6040207@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DoS attack despite ICE/STUN consent verification X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:42:06 -0000 Hi, Yes, your understanding appears correct. I was maybe more considering of using this attack against SIP clients, especially the kind that can't move out of the way easily. Like call centers etc. In that context being able to direct a 1 mbps video stream onto a audio receiver works excellent if your goal is to just DoS the path. But I do agree that consent freshness appears to be an important method for mitigating this. It also seems to create a requirement on that mechanism. It can't be something that the far end can trick the target end-point to generate just by default. It needs to be something where the end-point takes a decision to respond to each. Cheers Magnus On 2012-03-12 22:24, Eric Rescorla wrote: > I want to make sure I understand this attack correctly. > > Alice is making a call to Zed and either Zed is the attacker or the attacker > somehow captures Alice's media parameters. The attacker then uses > Alice's offer (and her parameters) to start ICE handshaking on a pile > of Web browsers that he controls. They all start ICE and since the > checks with Alice will succeed, then the attacker has apparent consent > to send as much traffic as he wants to Alice from each machine. > Do I have this right? > > If I understand this correctly, then the severity of the attack seems to > be limited since Alice has to actually be calling someone that is > malicious or that has very tight control of the network, and soon > after Alice hangs up the phone, the problem goes away. (Assuming > consent freshness). > > As Dan notes, the interaction with consent freshness seems like a key > mitigation here. Moreover, I think this suggests that even if integrity > is not used, as in draft-muthu, the ufrags should both be present > (and unmodifiable from the JS). This would allow a client to discard > ICE associations with ufrags that do not match whichever ICE > association got selected for the call. > > -Ekr > > > On Mon, Feb 6, 2012 at 6:27 AM, Magnus Westerlund > wrote: >> On 2012-02-06 11:19, Oscar Ohlsson wrote: >>> >>> >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org >>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund >>>> Sent: den 1 februari 2012 23:31 >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] DoS attack despite ICE/STUN consent verification >>>> >>>> Hi, >>>> >>>> As I brought up in yesterdays meeting I think there exist an >>>> attack that should be considered. I don't think it is super >>>> strong, but not without issues. >>>> >>>> Setting: >>>> >>>> Webserver is evil and have a target Alice. Alice can be a >>>> legacy device, like a SIP/SDP video phone. It knows the >>>> target is doing ICE and have Alice's ufrag and password and >>>> candidates. The server would like to hammer this target by >>>> utilizing its set of connected WebRTC clients (bob, charlie >>>> etc.). Thus it would like to ensure that it gets the browser >>>> to start sending RTP media when creating a PeerConnection in >>>> the clients. >>>> >>>> So the server gets the client to open PeerConnections towards >>>> the ICE parameters from the target (Alice). >>>> >>>> In default ICE behavior there is an optimization to allow the Offerer >>>> (Alice) to respond to STUN binding requests from Bob without >>>> having received an SDP answer from Bob. The STUN binding >>>> request must only have the Alice's ufrag and its password. >>>> This enables that Webrtc clients can get passed the data >>>> consent step with ICE capable end-point for which the ICE >>>> parameters can be retrieved. >>>> >>>> So from Alice perspective this attack will look like its >>>> offer got forked to many peers based on the many different >>>> peers that send STUN messages. The webserver could even >>>> provide SIP/SDP answers to alice with the webclients. But >>>> that is not necessary but is one variation of this. >>> >>> >>> Correct me if I'm wrong, but I believe the webserver must provide the >> SIP/SDP answers. As far as I can tell there are always two connectivity >> checks, one for each direction (Section 2.2 RFC 5245): >> >>> L R >>> - - >>> STUN request -> \ L's >>> <- STUN response / check >>> >>> <- STUN request \ R's >>> STUN response -> / check >>> >>> Alice would automatically respond to the remote side's check. >>> However, in order to genereate her own check (R's check in the >>> diagram) she would need to have received the remote side's password. >>> According to Section 7.1.2.3. in RFC 5245: >>> >>> "A connectivity check from R to L utilizes the username LFRAG:RFRAG >>> and a password of LPASS." >>> >>> If this interpretation is correct then counter-measure A below would >>> always be a possibility. >>> >> >> Oscar, >> >> From L's perspective, the process of nomination and validation can >> complete without R having succeeded. Thus L (WebRTC Browser) can start >> send media to R without R having successfully validated any return path >> from R to L. >> >> Thus, I don't see how A could be made to reliably work as a mitigation. >> >> In addition are there anyone who actually have this type of attack >> protection in their SIP stacks or SIP proxies? >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ekr@rtfm.com Mon Mar 12 15:44:40 2012 Return-Path: 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 1228521E8170 for ; Mon, 12 Mar 2012 15:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.762 X-Spam-Level: X-Spam-Status: No, score=-102.762 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, 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 sMyt-2aS3ypx for ; Mon, 12 Mar 2012 15:44:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0745A21E8171 for ; Mon, 12 Mar 2012 15:44:38 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so5574972vcb.31 for ; Mon, 12 Mar 2012 15:44:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=Xx5pdDUV10kVyZiHjnvYsfkeGicmA4TPA5daMVecAgs=; b=nY8brs445063hU4ejvxey9CkWLIMK+O5LG50EbeCyVJ92tfr5Bi49BISfnUuukY1uT t5Y7t8tcYZVtmyzW1LQhUyPWXhrNyBPyJx9XXLUW3MeMEe6o2lOl0B3AZUftjNOjuthJ WuLHCRUC7c9vZi/80axLkSvxB5nmhdHm0UGVnrXO45gY8tGNWlxTZA7fntjsSLsXCeM2 sxMgL/I3rtF9AdNXhaj4fCqGiiQ1yZd2cAS/ILxJa5N22MdojHF0SKyFY0Q/mN4RbHzV wdSZ4PyaoorGe45LWu80fCrEEzGxqGT7GKnYG8euKIWE9FUTq8oMKuNOy/inhXDCv4Hs 5QWg== Received: by 10.52.180.98 with SMTP id dn2mr15732673vdc.61.1331592278126; Mon, 12 Mar 2012 15:44:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.70.231 with HTTP; Mon, 12 Mar 2012 15:43:58 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4F5E7BB3.6030803@ericsson.com> References: <4F29BD31.9040700@ericsson.com> <4F2FE368.6040207@ericsson.com> <4F5E7BB3.6030803@ericsson.com> From: Eric Rescorla Date: Mon, 12 Mar 2012 15:43:58 -0700 Message-ID: To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnBp1nGt81Q0oCIlrbrKK7UG+FQRfacsv2A+jQFePrPl4dCMUcircSrkRCJIrCGQH6jtV17 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DoS attack despite ICE/STUN consent verification X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:44:40 -0000 On Mon, Mar 12, 2012 at 3:41 PM, Magnus Westerlund wrote: > Hi, > > Yes, your understanding appears correct. I was maybe more considering of > using this attack against SIP clients, especially the kind that can't > move out of the way easily. Like call centers etc. In that context being > able to direct a 1 mbps video stream onto a audio receiver works > excellent if your goal is to just DoS the path. Yep. Though of course in the specific case of a call center, since it auto-answers you can just mount the attack with independent calls.... > But I do agree that consent freshness appears to be an important method > for mitigating this. It also seems to create a requirement on that > mechanism. It can't be something that the far end can trick the target > end-point to generate just by default. It needs to be something where > the end-point takes a decision to respond to each. Yeah. :( Maybe you, I, Dan, and anyone else who is interested can brainstorm on this a bit in Paris. -Ekr > Cheers > > Magnus > > On 2012-03-12 22:24, Eric Rescorla wrote: >> I want to make sure I understand this attack correctly. >> >> Alice is making a call to Zed and either Zed is the attacker or the atta= cker >> somehow captures Alice's media parameters. The attacker then uses >> Alice's offer (and her parameters) to start ICE handshaking on a pile >> of Web browsers that he controls. They all start ICE and since the >> checks with Alice will succeed, then the attacker has apparent consent >> to send as much traffic as he wants to Alice from each machine. >> Do I have this right? >> >> If I understand this correctly, then the severity of the attack seems to >> be limited since Alice has to actually be calling someone that is >> malicious or that has very tight control of the network, and soon >> after Alice hangs up the phone, the problem goes away. (Assuming >> consent freshness). >> >> As Dan notes, the interaction with consent freshness seems like a key >> mitigation here. Moreover, I think this suggests that even if integrity >> is not used, as in draft-muthu, the ufrags should both be present >> (and unmodifiable from the JS). This would allow a client to discard >> ICE associations with ufrags that do not match whichever ICE >> association got selected for the call. >> >> -Ekr >> >> >> On Mon, Feb 6, 2012 at 6:27 AM, Magnus Westerlund >> wrote: >>> On 2012-02-06 11:19, Oscar Ohlsson wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: rtcweb-bounces@ietf.org >>>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund >>>>> Sent: den 1 februari 2012 23:31 >>>>> To: rtcweb@ietf.org >>>>> Subject: [rtcweb] DoS attack despite ICE/STUN consent verification >>>>> >>>>> Hi, >>>>> >>>>> As I brought up in yesterdays meeting I think there exist an >>>>> attack that should be considered. I don't think it is super >>>>> strong, but not without issues. >>>>> >>>>> Setting: >>>>> >>>>> Webserver is evil and have a target Alice. Alice can be a >>>>> legacy device, like a SIP/SDP video phone. It knows the >>>>> target is doing ICE and have Alice's ufrag and password and >>>>> candidates. The server would like to hammer this target by >>>>> utilizing its set of connected WebRTC clients (bob, charlie >>>>> etc.). Thus it would like to ensure that it gets the browser >>>>> to start sending RTP media when creating a PeerConnection in >>>>> the clients. >>>>> >>>>> So the server gets the client to open PeerConnections towards >>>>> the ICE parameters from the target (Alice). >>>>> >>>>> In default ICE behavior there is an optimization to allow the Offerer >>>>> (Alice) to respond to STUN binding requests from Bob without >>>>> having received an SDP answer from Bob. The STUN binding >>>>> request must only have the Alice's ufrag and its password. >>>>> This enables that Webrtc clients can get passed the data >>>>> consent step with ICE capable end-point for which the ICE >>>>> parameters can be retrieved. >>>>> >>>>> So from Alice perspective this attack will look like its >>>>> offer got forked to many peers based on the many different >>>>> peers that send STUN messages. The webserver could even >>>>> provide SIP/SDP answers to alice with the webclients. But >>>>> that is not necessary but is one variation of this. >>>> >>>> >>>> Correct me if I'm wrong, but I believe the webserver must provide the >>> SIP/SDP answers. As far as I can tell there are always two connectivity >>> checks, one for each direction (Section 2.2 RFC 5245): >>> >>>> =A0 =A0L =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0R >>>> =A0 =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- >>>> =A0 =A0STUN request -> =A0 =A0 =A0 =A0 =A0 =A0 \ =A0L's >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<- STUN response =A0/ =A0check >>>> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 <- STUN request =A0\ =A0R's >>>> =A0 =A0STUN response -> =A0 =A0 =A0 =A0 =A0 =A0/ =A0check >>>> >>>> Alice would automatically respond to the remote side's check. >>>> However, in order to genereate her own check (R's check in the >>>> diagram) she would need to have received the remote side's password. >>>> According to Section 7.1.2.3. in RFC 5245: >>>> >>>> "A connectivity check from R to L utilizes the username LFRAG:RFRAG >>>> and a password of LPASS." >>>> >>>> If this interpretation is correct then counter-measure A below would >>>> always be a possibility. >>>> >>> >>> Oscar, >>> >>> From L's perspective, the process of nomination and validation can >>> complete without R having succeeded. Thus L (WebRTC Browser) can start >>> send media to R without R having successfully validated any return path >>> from R to L. >>> >>> Thus, I don't see how A could be made to reliably work as a mitigation. >>> >>> In addition are there anyone who actually have this type of attack >>> protection in their SIP stacks or SIP proxies? >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> ---------------------------------------------------------------------- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> ---------------------------------------------------------------------- >>> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 >>> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > From ekr@rtfm.com Mon Mar 12 16:06:44 2012 Return-Path: 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 8D63321E81C2 for ; Mon, 12 Mar 2012 16:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.054 X-Spam-Level: X-Spam-Status: No, score=-103.054 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 nq79yNd7wph7 for ; Mon, 12 Mar 2012 16:06:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E9AB621E81C0 for ; Mon, 12 Mar 2012 16:06:43 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so5597176vcb.31 for ; Mon, 12 Mar 2012 16:06:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=wdQRBv2zf0jLir1dKsPmOSBDvRLQJC1SFwSTJwUvl6U=; b=WiMQkeQqkYuTXHQCA81cAEooJzOuC+a0zUF1NfmtCYHyieD8uSB7y5F4JkD81SJciy /ftzfa9GwwbInB69C8gv2XWXfQrmYt9RXtZ3bWUYVUWtRsL8Xs8yF/Swu889Wp3sdTJK 9nkZmHC75XBRXvE6T9d+6esQaU3JHG/zqMlAzaR3hRrKiZAVYTzqc6McGVMLZBy+ltqa uJnsCblpwoJYBnrDsdRpqFFGAG8rLhckW+5a75/MtU0/63uzHtj6nmsRhCJoinb1LLDj hAQ+Rc8W26FnzbBhYqBHTrPE6ikDLme32+xasZnQmmaTmHAc/IwWUYV2LPcyiY7kJDZ0 Xmzg== Received: by 10.52.27.69 with SMTP id r5mr15625190vdg.129.1331593603239; Mon, 12 Mar 2012 16:06:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.70.231 with HTTP; Mon, 12 Mar 2012 16:06:03 -0700 (PDT) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Mon, 12 Mar 2012 16:06:03 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn8mqlipJVjJ2AeMmoAiYoKBQds9Pnv0Isdklz99s5FYku/i5COVkn6W3RdrppfYaK6+l5a Subject: [rtcweb] Updated security documents X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:06:44 -0000 I have submitted new versions of: * Security Considerations for RTC-Web http://tools.ietf.org/html/draft-ietf-rtcweb-security-02 Primary change was to remove Appendix A (now mostly draft-ietf-rtcweb-security-arch-01) and to harmonize with that document. * RTCWEB Security Architecture http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01 Updated to reflect the decisions made in the interim. Note that I did not try to specify a new STUN consent check b/c Perumal, Kaplan, and Wing got there first. If we have comments about that mechanism we should probably work them into that draft. * RTCWEB Generic Identity Provider Interface http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp-00 Minor editorial updates. -Ekr From martin.thomson@gmail.com Tue Mar 13 08:19:20 2012 Return-Path: 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 ACDD421F87B3 for ; Tue, 13 Mar 2012 08:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.523 X-Spam-Level: X-Spam-Status: No, score=-4.523 tagged_above=-999 required=5 tests=[AWL=-1.524, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] 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 c8V1On860geA for ; Tue, 13 Mar 2012 08:19:19 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 391AE21F87A2 for ; Tue, 13 Mar 2012 08:19:19 -0700 (PDT) Received: by bkuw5 with SMTP id w5so617236bku.31 for ; Tue, 13 Mar 2012 08:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=O4CbIgSzePA/FKgWgvmII7AsDfdbP4QWK9g1RLZeutM=; b=Kf+WWOO6tFKdhHTUXNq/NFBKI89OPm+ieo4bnBN9SGFVDpFYCQqWl+O+ncyb8EBV7O J8sGr6Dww4BEwQgLDbAbcWV6Vu15EqOFNtMtcVqNJxsuxydfxf8EyIr9aMI6MF+7QccD Bg/s3jZUx6iAGm1/BC1i6N+Y2HGfXCaG1OL7rWbjA8V+fgDjkmna5HfIHseKA9jjYBlh 0Oxnmv3kW4a/5ArcQdC2DvzVEwgntOBvgmqJHPtXkRMwArX/ls+UxuDPIH44psxHAJOw 52qcckrijI3vUlKwEm6L/TuzS+RSedc+Bbnh8fN5sPe6ceqSWa9tXbPOTcIQWzfPJUFS BkXg== MIME-Version: 1.0 Received: by 10.205.130.1 with SMTP id hk1mr6353836bkc.140.1331651958297; Tue, 13 Mar 2012 08:19:18 -0700 (PDT) Received: by 10.204.121.208 with HTTP; Tue, 13 Mar 2012 08:19:18 -0700 (PDT) In-Reply-To: References: <4F29BD31.9040700@ericsson.com> <4F2FE368.6040207@ericsson.com> <4F5E7BB3.6030803@ericsson.com> Date: Tue, 13 Mar 2012 08:19:18 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DoS attack despite ICE/STUN consent verification X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 15:19:20 -0000 Temporary Maximum Media Stream Bit Rate Request (TMMBR, RFC5104) should address the concerns with bandwidth exceeding expected limits. That is, if this can be mandated (see below). Rate limiting ICE nominations should limit the number of hosts that can send media. That is, you might have to limit the rate at which your peer can appear to "move". Then you only expose yourself to something like ceil((time between "moves" + 1) / (maximum time between consent checks, including timeout)) times the bandwidth that a host can generate in your direction. In order to do so, you have to fail to respond to (nominating) connectivity checks under certain conditions. All this gets much more sticky and disgusting if you can't reasonably mandate TMMBR and especially consent freshness checking. If you are expecting a SIP end host to be able to take media directly from browsers - without supporting any of these features - then let the brainstorming begin. --Martin On 12 March 2012 15:43, Eric Rescorla wrote: > On Mon, Mar 12, 2012 at 3:41 PM, Magnus Westerlund > wrote: >> Hi, >> >> Yes, your understanding appears correct. I was maybe more considering of >> using this attack against SIP clients, especially the kind that can't >> move out of the way easily. Like call centers etc. In that context being >> able to direct a 1 mbps video stream onto a audio receiver works >> excellent if your goal is to just DoS the path. > > Yep. Though of course in the specific case of a call center, since it > auto-answers you can just mount the attack with independent calls.... > > >> But I do agree that consent freshness appears to be an important method >> for mitigating this. It also seems to create a requirement on that >> mechanism. It can't be something that the far end can trick the target >> end-point to generate just by default. It needs to be something where >> the end-point takes a decision to respond to each. > > Yeah. :( > Maybe you, I, Dan, and anyone else who is interested can brainstorm > on this a bit in Paris. > > -Ekr > >> Cheers >> >> Magnus >> >> On 2012-03-12 22:24, Eric Rescorla wrote: >>> I want to make sure I understand this attack correctly. >>> >>> Alice is making a call to Zed and either Zed is the attacker or the att= acker >>> somehow captures Alice's media parameters. The attacker then uses >>> Alice's offer (and her parameters) to start ICE handshaking on a pile >>> of Web browsers that he controls. They all start ICE and since the >>> checks with Alice will succeed, then the attacker has apparent consent >>> to send as much traffic as he wants to Alice from each machine. >>> Do I have this right? >>> >>> If I understand this correctly, then the severity of the attack seems t= o >>> be limited since Alice has to actually be calling someone that is >>> malicious or that has very tight control of the network, and soon >>> after Alice hangs up the phone, the problem goes away. (Assuming >>> consent freshness). >>> >>> As Dan notes, the interaction with consent freshness seems like a key >>> mitigation here. Moreover, I think this suggests that even if integrity >>> is not used, as in draft-muthu, the ufrags should both be present >>> (and unmodifiable from the JS). This would allow a client to discard >>> ICE associations with ufrags that do not match whichever ICE >>> association got selected for the call. >>> >>> -Ekr >>> >>> >>> On Mon, Feb 6, 2012 at 6:27 AM, Magnus Westerlund >>> wrote: >>>> On 2012-02-06 11:19, Oscar Ohlsson wrote: >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: rtcweb-bounces@ietf.org >>>>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund >>>>>> Sent: den 1 februari 2012 23:31 >>>>>> To: rtcweb@ietf.org >>>>>> Subject: [rtcweb] DoS attack despite ICE/STUN consent verification >>>>>> >>>>>> Hi, >>>>>> >>>>>> As I brought up in yesterdays meeting I think there exist an >>>>>> attack that should be considered. I don't think it is super >>>>>> strong, but not without issues. >>>>>> >>>>>> Setting: >>>>>> >>>>>> Webserver is evil and have a target Alice. Alice can be a >>>>>> legacy device, like a SIP/SDP video phone. It knows the >>>>>> target is doing ICE and have Alice's ufrag and password and >>>>>> candidates. The server would like to hammer this target by >>>>>> utilizing its set of connected WebRTC clients (bob, charlie >>>>>> etc.). Thus it would like to ensure that it gets the browser >>>>>> to start sending RTP media when creating a PeerConnection in >>>>>> the clients. >>>>>> >>>>>> So the server gets the client to open PeerConnections towards >>>>>> the ICE parameters from the target (Alice). >>>>>> >>>>>> In default ICE behavior there is an optimization to allow the Offere= r >>>>>> (Alice) to respond to STUN binding requests from Bob without >>>>>> having received an SDP answer from Bob. The STUN binding >>>>>> request must only have the Alice's ufrag and its password. >>>>>> This enables that Webrtc clients can get passed the data >>>>>> consent step with ICE capable end-point for which the ICE >>>>>> parameters can be retrieved. >>>>>> >>>>>> So from Alice perspective this attack will look like its >>>>>> offer got forked to many peers based on the many different >>>>>> peers that send STUN messages. The webserver could even >>>>>> provide SIP/SDP answers to alice with the webclients. But >>>>>> that is not necessary but is one variation of this. >>>>> >>>>> >>>>> Correct me if I'm wrong, but I believe the webserver must provide the >>>> SIP/SDP answers. As far as I can tell there are always two connectivit= y >>>> checks, one for each direction (Section 2.2 RFC 5245): >>>> >>>>> =C2=A0 =C2=A0L =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0R >>>>> =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- >>>>> =C2=A0 =C2=A0STUN request -> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 \ =C2=A0L's >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<- STUN response =C2= =A0/ =C2=A0check >>>>> >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <- STUN request =C2= =A0\ =C2=A0R's >>>>> =C2=A0 =C2=A0STUN response -> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0/ =C2=A0check >>>>> >>>>> Alice would automatically respond to the remote side's check. >>>>> However, in order to genereate her own check (R's check in the >>>>> diagram) she would need to have received the remote side's password. >>>>> According to Section 7.1.2.3. in RFC 5245: >>>>> >>>>> "A connectivity check from R to L utilizes the username LFRAG:RFRAG >>>>> and a password of LPASS." >>>>> >>>>> If this interpretation is correct then counter-measure A below would >>>>> always be a possibility. >>>>> >>>> >>>> Oscar, >>>> >>>> From L's perspective, the process of nomination and validation can >>>> complete without R having succeeded. Thus L (WebRTC Browser) can start >>>> send media to R without R having successfully validated any return pat= h >>>> from R to L. >>>> >>>> Thus, I don't see how A could be made to reliably work as a mitigation= . >>>> >>>> In addition are there anyone who actually have this type of attack >>>> protection in their SIP stacks or SIP proxies? >>>> >>>> Cheers >>>> >>>> Magnus Westerlund >>>> >>>> ---------------------------------------------------------------------- >>>> Multimedia Technologies, Ericsson Research EAB/TVM >>>> ---------------------------------------------------------------------- >>>> Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| P= hone =C2=A0+46 10 7148287 >>>> F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0| Mobile +46 73 0949079 >>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>>> ---------------------------------------------------------------------- >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> >> -- >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Pho= ne =C2=A0+46 10 7148287 >> F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From igor.faynberg@alcatel-lucent.com Tue Mar 13 09:46:33 2012 Return-Path: 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 3B11F21E8047 for ; Tue, 13 Mar 2012 09:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] 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 ZfUgIW2RN+6n for ; Tue, 13 Mar 2012 09:46:32 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4347321E8034 for ; Tue, 13 Mar 2012 09:46:32 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q2DGkV79013441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Mar 2012 11:46:31 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2DGkUhA031218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Mar 2012 11:46:31 -0500 Received: from [135.222.134.168] (USMUYN0L055118.mh.lucent.com [135.222.134.168]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2DGkUkN028989; Tue, 13 Mar 2012 11:46:30 -0500 (CDT) Message-ID: <4F5F79E6.70404@alcatel-lucent.com> Date: Tue, 13 Mar 2012 12:46:30 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F29BD31.9040700@ericsson.com> <4F2FE368.6040207@ericsson.com> <4F5E7BB3.6030803@ericsson.com> In-Reply-To: <4F5E7BB3.6030803@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [rtcweb] DoS attack despite ICE/STUN consent verification X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 16:46:33 -0000 My major question on this thread, which I have been watching with interest: Why do we care about a DoS attack against a single client? (I mean specifically DoS, not any other security attack.) It appears to me that there are somewhat simpler and more effective DoS methods for this case: 1) cut the wire to the client's device or 2) jam WiFi or other wireless signal. Or did I misunderstand the problem? Igor On 3/12/2012 6:41 PM, Magnus Westerlund wrote: > Hi, > > Yes, your understanding appears correct. I was maybe more considering of > using this attack against SIP clients, especially the kind that can't > move out of the way easily. Like call centers etc. In that context being > able to direct a 1 mbps video stream onto a audio receiver works > excellent if your goal is to just DoS the path. > > But I do agree that consent freshness appears to be an important method > for mitigating this. It also seems to create a requirement on that > mechanism. It can't be something that the far end can trick the target > end-point to generate just by default. It needs to be something where > the end-point takes a decision to respond to each. > > Cheers > > Magnus > > On 2012-03-12 22:24, Eric Rescorla wrote: >> I want to make sure I understand this attack correctly. >> >> Alice is making a call to Zed and either Zed is the attacker or the attacker >> somehow captures Alice's media parameters. The attacker then uses >> Alice's offer (and her parameters) to start ICE handshaking on a pile >> of Web browsers that he controls. They all start ICE and since the >> checks with Alice will succeed, then the attacker has apparent consent >> to send as much traffic as he wants to Alice from each machine. >> Do I have this right? >> >> If I understand this correctly, then the severity of the attack seems to >> be limited since Alice has to actually be calling someone that is >> malicious or that has very tight control of the network, and soon >> after Alice hangs up the phone, the problem goes away. (Assuming >> consent freshness). >> >> As Dan notes, the interaction with consent freshness seems like a key >> mitigation here. Moreover, I think this suggests that even if integrity >> is not used, as in draft-muthu, the ufrags should both be present >> (and unmodifiable from the JS). This would allow a client to discard >> ICE associations with ufrags that do not match whichever ICE >> association got selected for the call. >> >> -Ekr >> >> >> On Mon, Feb 6, 2012 at 6:27 AM, Magnus Westerlund >> wrote: >>> On 2012-02-06 11:19, Oscar Ohlsson wrote: >>>> >>>>> -----Original Message----- >>>>> From: rtcweb-bounces@ietf.org >>>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund >>>>> Sent: den 1 februari 2012 23:31 >>>>> To: rtcweb@ietf.org >>>>> Subject: [rtcweb] DoS attack despite ICE/STUN consent verification >>>>> >>>>> Hi, >>>>> >>>>> As I brought up in yesterdays meeting I think there exist an >>>>> attack that should be considered. I don't think it is super >>>>> strong, but not without issues. >>>>> >>>>> Setting: >>>>> >>>>> Webserver is evil and have a target Alice. Alice can be a >>>>> legacy device, like a SIP/SDP video phone. It knows the >>>>> target is doing ICE and have Alice's ufrag and password and >>>>> candidates. The server would like to hammer this target by >>>>> utilizing its set of connected WebRTC clients (bob, charlie >>>>> etc.). Thus it would like to ensure that it gets the browser >>>>> to start sending RTP media when creating a PeerConnection in >>>>> the clients. >>>>> >>>>> So the server gets the client to open PeerConnections towards >>>>> the ICE parameters from the target (Alice). >>>>> >>>>> In default ICE behavior there is an optimization to allow the Offerer >>>>> (Alice) to respond to STUN binding requests from Bob without >>>>> having received an SDP answer from Bob. The STUN binding >>>>> request must only have the Alice's ufrag and its password. >>>>> This enables that Webrtc clients can get passed the data >>>>> consent step with ICE capable end-point for which the ICE >>>>> parameters can be retrieved. >>>>> >>>>> So from Alice perspective this attack will look like its >>>>> offer got forked to many peers based on the many different >>>>> peers that send STUN messages. The webserver could even >>>>> provide SIP/SDP answers to alice with the webclients. But >>>>> that is not necessary but is one variation of this. >>>> >>>> Correct me if I'm wrong, but I believe the webserver must provide the >>> SIP/SDP answers. As far as I can tell there are always two connectivity >>> checks, one for each direction (Section 2.2 RFC 5245): >>> >>>> L R >>>> - - >>>> STUN request -> \ L's >>>> <- STUN response / check >>>> >>>> <- STUN request \ R's >>>> STUN response -> / check >>>> >>>> Alice would automatically respond to the remote side's check. >>>> However, in order to genereate her own check (R's check in the >>>> diagram) she would need to have received the remote side's password. >>>> According to Section 7.1.2.3. in RFC 5245: >>>> >>>> "A connectivity check from R to L utilizes the username LFRAG:RFRAG >>>> and a password of LPASS." >>>> >>>> If this interpretation is correct then counter-measure A below would >>>> always be a possibility. >>>> >>> Oscar, >>> >>> From L's perspective, the process of nomination and validation can >>> complete without R having succeeded. Thus L (WebRTC Browser) can start >>> send media to R without R having successfully validated any return path >>> from R to L. >>> >>> Thus, I don't see how A could be made to reliably work as a mitigation. >>> >>> In addition are there anyone who actually have this type of attack >>> protection in their SIP stacks or SIP proxies? >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> ---------------------------------------------------------------------- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> Färögatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb > From martin.thomson@gmail.com Tue Mar 13 11:02:19 2012 Return-Path: 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 9243121F87C5 for ; Tue, 13 Mar 2012 11:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.791 X-Spam-Level: X-Spam-Status: No, score=-4.791 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 t2DKceln99ql for ; Tue, 13 Mar 2012 11:02:19 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C2E1321F8775 for ; Tue, 13 Mar 2012 11:02:18 -0700 (PDT) Received: by bkuw5 with SMTP id w5so783020bku.31 for ; Tue, 13 Mar 2012 11:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zMOkzVCLiQmiljWWa2gCYbV22QABwf6ZuE2SblpPI9k=; b=RYEjNa5IUoP0NVe1uj359Z7bOew6+X1B5ukR9CS7qTrHPzi/Zbbnc6L2RbEZrCXQVZ KTIfOXgTkpdWIeYHiR8Xkx26ERbDpcZ2ZXgefvKGk5ZcoWnwjMBW32Z/aOOx5yYPFb5A s2HVRszQofp5qefyrnDmytzOf2Vkk+81uABNjKdpjGMGYH1UO5faC63UrqNDnXRYN8Eb gEJoifbRNmGpP3zC4RmKOe3/UOL8+FGzbZzfsJANOQmllzy6elJPpqdo7mMQNRnBT9XG ldScHcfGNI7VrpPbQsXH9KkAYsIOKxNSe8SMJ5xzBjXHUXyaJicPlUM3IE6QXjoMGGNz jvpg== MIME-Version: 1.0 Received: by 10.204.9.205 with SMTP id m13mr6580904bkm.68.1331661737906; Tue, 13 Mar 2012 11:02:17 -0700 (PDT) Received: by 10.204.121.208 with HTTP; Tue, 13 Mar 2012 11:02:17 -0700 (PDT) In-Reply-To: <4F5F79E6.70404@alcatel-lucent.com> References: <4F29BD31.9040700@ericsson.com> <4F2FE368.6040207@ericsson.com> <4F5E7BB3.6030803@ericsson.com> <4F5F79E6.70404@alcatel-lucent.com> Date: Tue, 13 Mar 2012 11:02:17 -0700 Message-ID: From: Martin Thomson To: igor.faynberg@alcatel-lucent.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DoS attack despite ICE/STUN consent verification X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 18:02:19 -0000 On 13 March 2012 09:46, Igor Faynberg wr= ote: > Why do we care about a DoS attack =C2=A0against a single client? =C2=A0(I= mean > specifically DoS, not any other security attack.) The concern here is that it isn't that hard to get someone to visit your website. By the same token, it should be easy to get someone to call (you). Once that "call" is up, you can direct the media anywhere. However, if the source of the media has some incentive to not send media - and browsers certainly do - then they want to check that their media is acceptable before sending it. Hence the consent mechanisms. That adds an another challenge: how do you get the target to consent to receipt of media from your drones? Obviously, if they consent to receiving one call, and you can use that to launch the media from multiple calls toward them, then you have an attack. > It appears to me that there are somewhat simpler and more effective DoS > methods for this case: 1) cut the wire to the client's device or 2) jam W= iFi > or other wireless signal. Stabbing your target with a knife also serves as a reasonable DoS method too. It's all about finding an appropriate defense for plausible threats. From martin.thomson@gmail.com Tue Mar 13 11:30:56 2012 Return-Path: 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 6D5D621F877C for ; Tue, 13 Mar 2012 11:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.767 X-Spam-Level: X-Spam-Status: No, score=-4.767 tagged_above=-999 required=5 tests=[AWL=-1.168, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 JMvqZ7HaAV-n for ; Tue, 13 Mar 2012 11:30:55 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C440E21F876E for ; Tue, 13 Mar 2012 11:30:51 -0700 (PDT) Received: by bkuw5 with SMTP id w5so805392bku.31 for ; Tue, 13 Mar 2012 11:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2kkDq7eb7k2j9i0/Q+C5SidtStVPOL2tzEplBxGDQw8=; b=TeCanHtRrBZXXqSFIxIe8jXRv+V0gJSko9gdSFlu0l/eiU6/qUul5fEsht7NSYyJ/j ihz1gbizUZSD9SVjWqtJIMEJIjyBsZ0Iv4A9Zo1ZR0TQdf/mGzq3F5n0CyxifRnZuEXA 8rylWfgmw5yBHXhVMtYfGraZ83JOhLjcaoZitR+p84l1Avp02ju4JubCvGEI+XrOs7iq GKlAWshZOqXiacZP2fVW5krPDcgMuLLAcDRwChDyjoEFvZC5olPFJo12EMvkYl5GN+3b a3coLMp4+xMY5dpt/z5lgpWJAj89wfrb4pplegM1eYEueEVZlF48VvDfQesL035cP2Na iUng== MIME-Version: 1.0 Received: by 10.204.133.216 with SMTP id g24mr6567479bkt.104.1331663450855; Tue, 13 Mar 2012 11:30:50 -0700 (PDT) Received: by 10.204.121.208 with HTTP; Tue, 13 Mar 2012 11:30:50 -0700 (PDT) Date: Tue, 13 Mar 2012 11:30:50 -0700 Message-ID: From: Martin Thomson To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] Using DTLS for ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 18:30:56 -0000 One concern that I have with rtcweb is the amount of time it takes to start a session. Speaking as an Internet user well accustomed to long round trip times, the fact that it could take up to 7 to get media bothers me a little. It turns out that this is unnecessary, with a few tweaks. I've written a draft on the subject: https://docs.google.com/document/d/1UZjCnqDmHcAOsETLZ4CRTmpHkm97PXMEebiRRqe8nXE/edit I don't want to add to the reviewing burden or distract folks from more important tasks. But I've had some interest. I plan to submit this once draft submissions reopen. --Martin From igor.faynberg@alcatel-lucent.com Tue Mar 13 12:27:39 2012 Return-Path: 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 DC58A21E8066 for ; Tue, 13 Mar 2012 12:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.338 X-Spam-Level: X-Spam-Status: No, score=-9.338 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 OYS7pqfjfKf1 for ; Tue, 13 Mar 2012 12:27:39 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E02F021E804F for ; Tue, 13 Mar 2012 12:27:38 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q2DJRRE9027789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Mar 2012 14:27:28 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2DJRQeM008649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Mar 2012 14:27:27 -0500 Received: from [135.222.134.168] (USMUYN0L055118.mh.lucent.com [135.222.134.168]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2DJRP1L006553; Tue, 13 Mar 2012 14:27:26 -0500 (CDT) Message-ID: <4F5F9F9D.2010408@alcatel-lucent.com> Date: Tue, 13 Mar 2012 15:27:25 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Martin Thomson , Eric Rescorla References: <4F29BD31.9040700@ericsson.com> <4F2FE368.6040207@ericsson.com> <4F5E7BB3.6030803@ericsson.com> <4F5F79E6.70404@alcatel-lucent.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000409030007070702020908" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DoS attack despite ICE/STUN consent verification X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 19:27:40 -0000 This is a multi-part message in MIME format. --------------000409030007070702020908 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/13/2012 2:02 PM, Martin Thomson wrote: > ... > Stabbing your target with a knife also serves as a reasonable DoS > method too. It's all about finding an appropriate defense for > plausible threats. Well, this was one option I decided not to list... :) But, really, I just don't see a reason why anyone would want to waste resources on a DoS attack against a /person/. I am sure I am missing a bigger picture. I am also sure, I will start understanding these things better after a drink or two, or three. To this end, Eric, please count me among the interested parties for the off-line discussion in Paris! Igor --------------000409030007070702020908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 3/13/2012 2:02 PM, Martin Thomson wrote:
...
Stabbing your target with a knife also serves as a reasonable DoS
method too.  It's all about finding an appropriate defense for
plausible threats.


Well, this was one option I decided not to list... :)

But, really, I just don't see a reason why anyone would want to waste resources on a DoS attack against a person. 
I am sure I am missing a bigger picture.  I am also sure, I will start understanding these things better after a drink or two, or three.

To this end, Eric, please count me among the interested parties  for the off-line discussion in Paris!

Igor


--------------000409030007070702020908-- From dwing@cisco.com Wed Mar 14 09:29:56 2012 Return-Path: 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 6141A21F8811 for ; Wed, 14 Mar 2012 09:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.317 X-Spam-Level: X-Spam-Status: No, score=-109.317 tagged_above=-999 required=5 tests=[AWL=1.282, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 SMgjvbI-4Vxj for ; Wed, 14 Mar 2012 09:29:55 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C45EB21F8810 for ; Wed, 14 Mar 2012 09:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1275; q=dns/txt; s=iport; t=1331742596; x=1332952196; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=olcxGfqXSWxLLINKar2hUzGhznhbYDMO6nk0V3maaII=; b=g2zqsTmzeNFu0jGlxsxt5GcjWOSK/qDjj0y8fWlflljMB9BYuT2GnQGR QiG8YzwTLCAIJNhm4WBz41LT6fjrTRuLw1YRnV9P+fqACMnqipjHJvVrk 0sMUa+9WsooxuBYI43R0wTZUYbBZYwkvBHgWA2LGoBirokbKbfMUvq6FA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIHGYE+rRDoH/2dsb2JhbABDpjOPeYEHggkBAQEDAQEBAQUKARcQNBAHAQMCCQ8CBAEBKAcZDhUKCQgBAQQBEgsXh2MEDJxBnyMEkH4EiFeFEZYugWiDBg X-IronPort-AV: E=Sophos;i="4.73,584,1325462400"; d="scan'208";a="33533646" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 14 Mar 2012 16:29:55 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2EGTtOP006419; Wed, 14 Mar 2012 16:29:55 GMT From: "Dan Wing" To: "'Martin Thomson'" , References: In-Reply-To: Date: Wed, 14 Mar 2012 09:29:55 -0700 Message-ID: <022c01cd01ff$b0f4bd90$12de38b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0BR3DGtcz4xbcoRtOfIrEnl3nthAAt/k1Q Content-Language: en-us Subject: Re: [rtcweb] Using DTLS for ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 16:29:56 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Martin Thomson > Sent: Tuesday, March 13, 2012 11:31 AM > To: rtcweb@ietf.org > Subject: [rtcweb] Using DTLS for ICE > > One concern that I have with rtcweb is the amount of time it takes to > start a session. Speaking as an Internet user well accustomed to long > round trip times, the fact that it could take up to 7 to get media > bothers me a little. As EKR commented in your googledocs, the DTLS cookie exchange isn't necessary (or useful) if you're already doing ICE, so the un-optimized case is at least one round-trip less than that. > It turns out that this is unnecessary, with a > few tweaks. > > I've written a draft on the subject: > > > https://docs.google.com/document/d/1UZjCnqDmHcAOsETLZ4CRTmpHkm97PXMEebi > RRqe8nXE/edit It seems like a good idea worth considering. -d > I don't want to add to the reviewing burden or distract folks from > more important tasks. But I've had some interest. I plan to submit > this once draft submissions reopen. > > --Martin > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Wed Mar 14 13:33:48 2012 Return-Path: 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 8C6FD21F8501 for ; Wed, 14 Mar 2012 13:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.393 X-Spam-Level: X-Spam-Status: No, score=-4.393 tagged_above=-999 required=5 tests=[AWL=-1.394, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] 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 Ox6XwoBKNuNB for ; Wed, 14 Mar 2012 13:33:46 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6B421F84E7 for ; Wed, 14 Mar 2012 13:33:46 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1905016bku.31 for ; Wed, 14 Mar 2012 13:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j85fVpZlqWiSzJPQLiDCshSUuZjUW5N9DXCuPcRCf+w=; b=gE+5A2jqcnsvkVzwWGY+W7KjNhtz/hx02LILq+JDOZ77e8kyECD0M1uWGNcv2QqFJn zU4OhkvFUwGt/q86eAM9M2Y3qaYfpqm1203otbRwlixMWmJ8SRyR0bysSLka819cxxfw 4v1+n9TsGKLKmVaWhS4YSveeF8vLUW6craWPO5CxCRBvlUge9jrvcNwJ2i36XyiOhqIf wdFCbH8Kpssl1CplYFzcNkcUN3xEacKYXZsDeebBckoliuLgHA97OOTLOz6DHYTr3h1K Bx5HSNHsjzWa1Okxs37M1fYPc6lSVjMt2shTdGNGF34+Jq6dX+5JlXuI/iIL/SYHIsoY oqjQ== MIME-Version: 1.0 Received: by 10.204.154.144 with SMTP id o16mr1448583bkw.122.1331757225644; Wed, 14 Mar 2012 13:33:45 -0700 (PDT) Received: by 10.204.121.208 with HTTP; Wed, 14 Mar 2012 13:33:45 -0700 (PDT) In-Reply-To: <022c01cd01ff$b0f4bd90$12de38b0$@com> References: <022c01cd01ff$b0f4bd90$12de38b0$@com> Date: Wed, 14 Mar 2012 13:33:45 -0700 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Using DTLS for ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 20:33:48 -0000 On 14 March 2012 09:29, Dan Wing wrote: > As EKR commented in your googledocs, the DTLS cookie exchange isn't > necessary (or useful) if you're already doing ICE, so the un-optimized > case is at least one round-trip less than that. Not you too. As I told EKR, that's mostly just there for effect. And now you've gone an spoiled the effect. But I did think that there is a window of opportunity for DoS if you allow for the possibility of spoofed source IP+port. I mean, that's the scenario that the cookie was invented for, right? After all, you have to store all those ClientHello messages, valid or not. Without the cookie, you have no assurance that they are valid. The STUN messages have MESSAGE-INTEGRITY, but the ClientHello could have come from anyone. I guess that checking source IP+port would be sufficient for most folks. That does mean that you effectively force the attacker to obtain the candidate pair details before he can DoS you, and the window of opportunity is fairly narrow. --Martin From dwing@cisco.com Wed Mar 14 14:14:44 2012 Return-Path: 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 395C721F84F1 for ; Wed, 14 Mar 2012 14:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.031 X-Spam-Level: X-Spam-Status: No, score=-109.031 tagged_above=-999 required=5 tests=[AWL=0.968, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8, 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 O5XfGk3okB2U for ; Wed, 14 Mar 2012 14:14:43 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8564421F84A7 for ; Wed, 14 Mar 2012 14:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2410; q=dns/txt; s=iport; t=1331759683; x=1332969283; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=nj8WHdYNbCXbdBgznuVIXIW3+5GuxJ4fzO6m1LeadA4=; b=OSCDNkRB044mrEufev0+CBOSLgXWG/+z2pIMs2dlgzULMIMc6iRe4fr5 YSog3NLNAUYsSjfnCC/o212G7ZjORlsSPhugbU/bAaa1wEK29j42qks88 C0wEqmkMYD2ac+U6WjYY2JBAyG97pTQhehLvzZwB8Ixo1ucUt43Dp23MW 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPgJYU+rRDoH/2dsb2JhbABDhTqge494gQeCCQEBAQMBCAoBEAdPBQcBAwIJDwIEAQEBAgIjAwICGQgbCgkIAQEEEwsXh2MEmzyNBJItgS+IG4YfgRYEiFeFEZMcgxKBaIMG X-IronPort-AV: E=Sophos;i="4.73,586,1325462400"; d="scan'208";a="36055240" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 14 Mar 2012 21:14:43 +0000 Received: from dwingWS ([10.154.161.192]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2ELEhGr026255; Wed, 14 Mar 2012 21:14:43 GMT From: "Dan Wing" To: "'Martin Thomson'" References: <022c01cd01ff$b0f4bd90$12de38b0$@com> In-Reply-To: Date: Wed, 14 Mar 2012 14:14:41 -0700 Message-ID: <039201cd0227$79d78540$6d868fc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0CIcjSNJBM4FeySXaqJk9Of3Ze5gABHXTQ Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Using DTLS for ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 21:14:44 -0000 > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Wednesday, March 14, 2012 1:34 PM > To: Dan Wing > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Using DTLS for ICE > > On 14 March 2012 09:29, Dan Wing wrote: > > As EKR commented in your googledocs, the DTLS cookie exchange isn't > > necessary (or useful) if you're already doing ICE, so the un- > optimized > > case is at least one round-trip less than that. > > Not you too. As I told EKR, that's mostly just there for effect. And > now you've gone an spoiled the effect. > > But I did think that there is a window of opportunity for DoS if you > allow for the possibility of spoofed source IP+port. I mean, that's > the scenario that the cookie was invented for, right? After all, you > have to store all those ClientHello messages, valid or not. Without > the cookie, you have no assurance that they are valid. The STUN > messages have MESSAGE-INTEGRITY, but the ClientHello could have come > from anyone. > > I guess that checking source IP+port would be sufficient for most > folks. Exactly. After doing ICE with that IP+port, then DTLS handshakes can happen with that IP+port. If ICE hasn't been done with that IP+port, DTLS handshakes should not happen with that IP+port. But it's a nit. I'm not worried about that nit of how ICE and DTLS can work best together. That should be written down somewhere, but it is just background in your document. I don't want to concentrate on that. > That does mean that you effectively force the attacker to > obtain the candidate pair details before he can DoS you, and the > window of opportunity is fairly narrow. You have proposed a useful optimization that reduces the round trips by, essentially, using the initial DTLS handshake messages in lieu of the ICE handshake messages. What you are doing is collapsing the two. I think that is a good optimization, and I would like to pursue it. Another approach, which I would like to discuss/compare with your proposal, is to put the initial DTLS handshake messages into the ICE messages themselves, as new STUN attributes. This changes how DTLS does its handshake, but your proposal changes how ICE does its handshake. There are pros/cons of either change. Might be worth discussing over cookies. EKR likes cookies. -d From hiro.suzuki@d3communications.jp Thu Mar 15 03:14:27 2012 Return-Path: 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 CC4A021F860E for ; Thu, 15 Mar 2012 03:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ysyI13TZVzAW for ; Thu, 15 Mar 2012 03:14:26 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDC521F85EE for ; Thu, 15 Mar 2012 03:14:26 -0700 (PDT) Received: by yenm5 with SMTP id m5so3238619yen.31 for ; Thu, 15 Mar 2012 03:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=d3communications.jp; s=google; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=4msWRQ6A0XDf0LXUNXPMFRafqaYyKODb7+DyvxAnros=; b=pfuzQ8Biv+B41Syccd5/R+P0hWP8Egpxh0nBVnW8rE7xvtCzCgqn4iMZsMQQE9F0pB 5c2hxbC3gsfcvybnej1ihe9fyHsVgEfZHIN5pF188xoo1XXQiOKCxETBqOmCiRliTQ1k RRHv/tzFsV32N8e6X0+DNomJVeSvVRNLB2c2s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=4msWRQ6A0XDf0LXUNXPMFRafqaYyKODb7+DyvxAnros=; b=noPuEStyQOrvmUPv1cUZywYBXDWfLEqSeFcFHvPmqc5c/3FiqnTpRBS60e4zn4yXcR AQHfK3XcJau/ib0amcpZ0uLS0puBfqs9K12Sb2oyCFNNqHJPZXLA1cOBQppdvpc2oDkM aXLwrPDvQEae5Bih+OP2AZPO+YzBVPzEu/Yl9nBfuWqyEpbVhIu1U4xyl1bYIU4uycup qsC9tsid3iQphsepR6XxVrk6RY1WFFkYaVKRShN1z5wIKLmzyoAAdz9kd+7YgiROmqQ3 fbDXYkuwIZYYNhqcgrOBB7y9ftl08zT7Hh2JJT3E4vJLqG+4xikxdj4lM4sbxclK8S/Z JNTw== Received: by 10.68.132.1 with SMTP id oq1mr3903470pbb.137.1331806465529; Thu, 15 Mar 2012 03:14:25 -0700 (PDT) Received: from [192.168.1.8] (p32002-ipngn402hodogaya.kanagawa.ocn.ne.jp. [180.23.153.2]) by mx.google.com with ESMTPS id f8sm1577999pbe.42.2012.03.15.03.14.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 03:14:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_06057822-AB92-4FA6-8963-5D47C125D05E" From: HIro Suzuki In-Reply-To: Date: Thu, 15 Mar 2012 19:14:21 +0900 Message-Id: <6AC2CF83-1D4C-427C-A82C-189ED55FFD0B@d3communications.jp> References: , To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlXACwsF5ZOMxtwoXp9CQtofNLbxBatFzaBRkRM097MLnC+3gqy0lvcFc3fqGsWGEnJPDHc Subject: [rtcweb] "PeerConnection" API would manage mapping information between media streams and DOM elements (Re: I'd like to discuss my proposal (jingle-web) at next WG session) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 10:14:27 -0000 --Apple-Mail=_06057822-AB92-4FA6-8963-5D47C125D05E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Bernard, Jingle extensions are discussed in XSF, and DOM specification would be = discussed in W3C, as you says. But if there are any numbers of media streams between peers, and if = there are any numbers of "
= --Apple-Mail-45--459885433-- From roman@telurix.com Mon Mar 19 11:44:20 2012 Return-Path: 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 E91E921F885D for ; Mon, 19 Mar 2012 11:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.746 X-Spam-Level: X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 odO69zkyjrPG for ; Mon, 19 Mar 2012 11:44:19 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52A8C21F8790 for ; Mon, 19 Mar 2012 11:44:19 -0700 (PDT) Received: by dakl33 with SMTP id l33so11433652dak.31 for ; Mon, 19 Mar 2012 11:44:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=PwJBtJyW/cZ2VtpHqUbnj5s4FE/J8IjucMgVov6m808=; b=oWdyww0eagSTXD454t/pEiQWSSV1fkukQuhN/u9EnkL92S8ApDnlqYIQl3VicMsUq8 6ejW0NxMzRnkJlAHJ6vVwgBZGyAYnyZtQKGWTTZ5QGw3fwIsfRnV+fg0Gmm7ea/EvEkH /1mkQEATnhVSP0ES1mEGyrVcNgBAOc16visH4sHrkI3oM3MhECelwXX+DCDVk2NC5Ay6 wxcF1ceDRbyAT8Z5JknSfRRKEuUlegb0dowicvUDYURebM8y62OF8foxUVpx4bL9wAFV sHM9GzvvgSEVfkpyJbLAnTqeCFI2gdIZ7MiZcv63CNC3ioemndnb4ul7RxHLhDyfNgXZ k2Xg== Received: by 10.68.222.227 with SMTP id qp3mr36663145pbc.137.1332182659137; Mon, 19 Mar 2012 11:44:19 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id f5sm11902357pbe.26.2012.03.19.11.44.18 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 11:44:18 -0700 (PDT) Received: by dakl33 with SMTP id l33so11433619dak.31 for ; Mon, 19 Mar 2012 11:44:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.40 with SMTP id or8mr42379986pbb.34.1332182657639; Mon, 19 Mar 2012 11:44:17 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Mon, 19 Mar 2012 11:44:17 -0700 (PDT) In-Reply-To: <52789D17-F7C7-401B-B2E8-6FE3BC5D7CB7@phonefromhere.com> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <52789D17-F7C7-401B-B2E8-6FE3BC5D7CB7@phonefromhere.com> Date: Mon, 19 Mar 2012 14:44:17 -0400 Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=047d7b10cde315a66804bb9cf221 X-Gm-Message-State: ALoCoQmI1ezmYNSmHr5WPQ0YVhWWpS0Cy+YiVy0n9YXzAI24WPE57aIJaN4t/RA35HoIQRm9WzSW Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:44:20 -0000 --047d7b10cde315a66804bb9cf221 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 19, 2012 at 2:35 PM, Tim Panton wrote: > How many of these plain RTP only legacy devices support password verified > ICE correctly? - I'd be shocked if you found _any_. > > And how many of the SDES-SRTP devices support password verified ICE? I doubt you would find any of them either. So, why is SDES-SRTP is OK and RTP is not? > With JSEP there is nothing to stop the application from encrypting the SDP > blob in javascript before forwarding it to the far end > over HTTP - not my preferred option, but technically possible, and it > would definitely make a firesheep style attack a bit harder to pull off. > > Once again, my point was that application developer would need to properly develop signaling application (ie deliver it over HTTPS; don't put encryption keys into something that can be easily accessable, etc). Unless a lot of care is taken, SDES-SRTP is not secure. Why do we need to support SDES-SRTP at all? I do not understand the arguments that say RTP is bad, but SDES-SRTP is ok. If you need interop, RTP is your best option. If you need security DTLS-SRTP is your answer. SDES-SRTP does not serve either purpose well. _____________ Roman Shpount --047d7b10cde315a66804bb9cf221 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 19, 2012 at 2:= 35 PM, Tim Panton <tim@phonefromhere.com> wrote:
How many of these plain RTP only legacy= devices support password verified ICE correctly? - I'd be shocked if y= ou found _any_.=A0


And how many of the SDES-SRTP devices support p= assword verified ICE? I doubt you would find any of them either. So, why is= SDES-SRTP is OK and RTP is not?

=A0
=
With JSEP there is nothing to stop the application from encrypting the= SDP blob in javascript before forwarding it to the far end=A0
ov= er HTTP - not my preferred option, but technically possible, and it would d= efinitely make a firesheep style attack a bit harder to pull off.


Once again, m= y point was that application developer would need to properly develop signa= ling application (ie deliver it over HTTPS; don't put encryption keys i= nto something that can be easily accessable, etc). Unless a lot of care is = taken, SDES-SRTP is not secure.

Why do we need to support SDES-SRTP at all? I do not understand the arg= uments that say RTP is bad, but SDES-SRTP is ok. If you need interop, RTP i= s your best option. If you need security DTLS-SRTP is your answer. SDES-SRT= P does not serve either purpose well.
_____________
Roman Shpount

--047d7b10cde315a66804bb9cf221-- From igor.faynberg@alcatel-lucent.com Mon Mar 19 11:47:17 2012 Return-Path: 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 1F08721F8879 for ; Mon, 19 Mar 2012 11:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.482 X-Spam-Level: X-Spam-Status: No, score=-9.482 tagged_above=-999 required=5 tests=[AWL=1.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 bahCeQT2CnvN for ; Mon, 19 Mar 2012 11:47:16 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 267A821F8872 for ; Mon, 19 Mar 2012 11:47:16 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q2JIlFbG001688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Mar 2012 13:47:15 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2JIlFfC013279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Mar 2012 13:47:15 -0500 Received: from [135.222.232.245] (USMUYN0L055118.mh.lucent.com [135.222.232.245]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2JIlE7R014442; Mon, 19 Mar 2012 13:47:14 -0500 (CDT) Message-ID: <4F677F3B.3040407@alcatel-lucent.com> Date: Mon, 19 Mar 2012 14:47:23 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F4759DC.7060303@ericsson.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:47:17 -0000 This is the question that I have been asking for a while... I don't expect a complete fireproof answer, of course, and I also understand that the browser today is telling me a few things about the security of a site and warns me when "the site is trying to access the data it should not be accessing." But I also imagine that a rogue site could display a message mimicking the security assurance as though it comes from the browser. So it would be good to have a very clear idea when the determination about the security of the connection and such is made and how the end user can verify that it actually comes from the browser. (To this end, the user MUST trust the browser, of course.) Igor On 3/19/2012 2:15 PM, Roman Shpount wrote: > I guess my question is, when are we going to tell the user that > connection is "secure"?... From ibc@aliax.net Mon Mar 19 12:48:02 2012 Return-Path: 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 DB8CF21E802C for ; Mon, 19 Mar 2012 12:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 luXFt4oLTPn7 for ; Mon, 19 Mar 2012 12:48:02 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC08621E8015 for ; Mon, 19 Mar 2012 12:48:01 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so893363vbb.31 for ; Mon, 19 Mar 2012 12:48:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=g9EvxepFsYycukNBbfk/kFWdMkWNAolB+AmI69pdcqA=; b=ec6tgiO1bkFM6OXa+moDOC6YCNRwMdeRCtz3qt5RGj4iisyI9dTvOjq6+wcfY67/Km J/jIVj2aXyT74rXWpgmXhuevRa3WG3mQErzMzkSAZE+2EpSgSOJoC3Oz+BJIaT63TXT2 qRCXr1+L/0CkP5hVCPz4IQKra2iggzt/DMvPx4ipb6IRTQXE4SFOcVABq3pQrKitd1RU hsSfh7U07qOx0QB4+cjU5HJWqddjQqZiLkNuKdOFAmtkqAuhxhGbl2MKshETyFJukf1g cDHULWsuNWUV79fHRdocS0yk7+/vfHXmLMb61+Y58P1ceIpwoWUU6B7KYTyln4hA8uYW NsBw== Received: by 10.52.90.111 with SMTP id bv15mr6289396vdb.34.1332186481425; Mon, 19 Mar 2012 12:48:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Mon, 19 Mar 2012 12:47:41 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <52789D17-F7C7-401B-B2E8-6FE3BC5D7CB7@phonefromhere.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 19 Mar 2012 20:47:41 +0100 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnu2ik6+I+0AkauniJandbx5/jzUXNpLcXf9Nj8ju4Q7dlqNruK0+kaduSkFEsS/14fKxUd Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 19:48:03 -0000 2012/3/19 Roman Shpount : > Once again, my point was that application developer would need to properl= y > develop signaling application (ie deliver it over HTTPS; don't put > encryption keys into something that can be easily accessable, etc). Unles= s a > lot of care is taken, SDES-SRTP is not secure. Again in the airport with open WiFi: - If you use SDES-SRTP and HTTPS (or secure WebSocket), so SDES keys are not interceptable in the WiFi network, you can be sure that no one in the airport can monitor your media (I assume the server is not hacked by a person in the same airport!). - If you use plain RTP you know that every one in the airport can monitor your media (regardless there is TLS in the signaling path or not). > Why do we need to support SDES-SRTP at all? In conjunction with a secure signaling path (HTTPS or secure WebSocket) IMHO it provides a reasonable security level for avoiding media interception. > I do not understand the > arguments that say RTP is bad, but SDES-SRTP is ok. Replied above. > If you need interop, RTP > is your best option. If you need security DTLS-SRTP is your answer. > SDES-SRTP does not serve either purpose well. I'm not a fan of SDES-SRTP, I just say that IMHO it can provide a good security level. The only I say is that there is no reason for allowing plain RTP other than interop with old/legacy SIP devices (those whose vendors have decided not to implement SRTP, a spec from 2004). Is there any other case in which using plain RTP within WebRTC context is better than using SRTP? Regards. --=20 I=C3=B1aki Baz Castillo From lorenzo@meetecho.com Mon Mar 19 12:55:36 2012 Return-Path: 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 14DFC21E8013 for ; Mon, 19 Mar 2012 12:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3] 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 57PeUeUJUHHL for ; Mon, 19 Mar 2012 12:55:35 -0700 (PDT) Received: from smtplq02.aruba.it (smtplqs-out23.aruba.it [62.149.158.63]) by ietfa.amsl.com (Postfix) with SMTP id 6A9B221E802D for ; Mon, 19 Mar 2012 12:55:34 -0700 (PDT) Received: (qmail 16174 invoked by uid 89); 19 Mar 2012 19:55:31 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq02.aruba.it with SMTP; 19 Mar 2012 19:55:31 -0000 Received: (qmail 24036 invoked by uid 89); 19 Mar 2012 19:55:31 -0000 Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@79.52.20.203) by smtp2.ad.aruba.it with SMTP; 19 Mar 2012 19:55:31 -0000 Date: Mon, 19 Mar 2012 20:52:07 +0100 From: Lorenzo Miniero To: =?UTF-8?B?ScOxYWtp?= Baz Castillo Message-ID: <20120319205207.1133e5b0@rainpc> In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <52789D17-F7C7-401B-B2E8-6FE3BC5D7CB7@phonefromhere.com> Organization: Meetecho X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Rating: smtp2.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 19:55:36 -0000 On Mon, 19 Mar 2012 20:47:41 +0100 I=C3=B1aki Baz Castillo wrote: > 2012/3/19 Roman Shpount : > > Once again, my point was that application developer would need to prope= rly > > develop signaling application (ie deliver it over HTTPS; don't put > > encryption keys into something that can be easily accessable, etc). Unl= ess a > > lot of care is taken, SDES-SRTP is not secure. >=20 > Again in the airport with open WiFi: >=20 > - If you use SDES-SRTP and HTTPS (or secure WebSocket), so SDES keys > are not interceptable in the WiFi network, you can be sure that no one > in the airport can monitor your media (I assume the server is not > hacked by a person in the same airport!). >=20 > - If you use plain RTP you know that every one in the airport can > monitor your media (regardless there is TLS in the signaling path or > not). >=20 >=20 >=20 > > Why do we need to support SDES-SRTP at all? >=20 > In conjunction with a secure signaling path (HTTPS or secure > WebSocket) IMHO it provides a reasonable security level for avoiding > media interception. >=20 >=20 >=20 > > I do not understand the > > arguments that say RTP is bad, but SDES-SRTP is ok. >=20 > Replied above. >=20 >=20 >=20 > > If you need interop, RTP > > is your best option. If you need security DTLS-SRTP is your answer. > > SDES-SRTP does not serve either purpose well. >=20 > I'm not a fan of SDES-SRTP, I just say that IMHO it can provide a good > security level. >=20 > The only I say is that there is no reason for allowing plain RTP other > than interop with old/legacy SIP devices (those whose vendors have > decided not to implement SRTP, a spec from 2004). Is there any other > case in which using plain RTP within WebRTC context is better than > using SRTP? >=20 Large scale public events come to mind. L. >=20 > Regards. >=20 >=20 > --=20 > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From lorenzo@meetecho.com Mon Mar 19 12:58:48 2012 Return-Path: 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 3D1FC21F86E0 for ; Mon, 19 Mar 2012 12:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 NrFSugoZksRC for ; Mon, 19 Mar 2012 12:58:47 -0700 (PDT) Received: from smtplq02.aruba.it (smtplqs-out23.aruba.it [62.149.158.63]) by ietfa.amsl.com (Postfix) with SMTP id 88FA721F86D8 for ; Mon, 19 Mar 2012 12:58:46 -0700 (PDT) Received: (qmail 23783 invoked by uid 89); 19 Mar 2012 19:58:45 -0000 Received: from unknown (HELO smtp5.aruba.it) (62.149.158.225) by smtplq02.aruba.it with SMTP; 19 Mar 2012 19:58:45 -0000 Received: (qmail 10066 invoked by uid 89); 19 Mar 2012 19:58:45 -0000 Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@79.52.20.203) by smtp5.ad.aruba.it with SMTP; 19 Mar 2012 19:58:45 -0000 Date: Mon, 19 Mar 2012 20:55:20 +0100 From: Lorenzo Miniero To: Lorenzo Miniero Message-ID: <20120319205520.491ed951@rainpc> In-Reply-To: <20120319205207.1133e5b0@rainpc> References: <4F4759DC.7060303@ericsson.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <52789D17-F7C7-401B-B2E8-6FE3BC5D7CB7@phonefromhere.com> <20120319205207.1133e5b0@rainpc> Organization: Meetecho X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 19:58:48 -0000 On Mon, 19 Mar 2012 20:52:07 +0100 Lorenzo Miniero wrote: > On Mon, 19 Mar 2012 20:47:41 +0100 > I=C3=B1aki Baz Castillo wrote: >=20 > > 2012/3/19 Roman Shpount : > > > Once again, my point was that application developer would need to pro= perly > > > develop signaling application (ie deliver it over HTTPS; don't put > > > encryption keys into something that can be easily accessable, etc). U= nless a > > > lot of care is taken, SDES-SRTP is not secure. > >=20 > > Again in the airport with open WiFi: > >=20 > > - If you use SDES-SRTP and HTTPS (or secure WebSocket), so SDES keys > > are not interceptable in the WiFi network, you can be sure that no one > > in the airport can monitor your media (I assume the server is not > > hacked by a person in the same airport!). > >=20 > > - If you use plain RTP you know that every one in the airport can > > monitor your media (regardless there is TLS in the signaling path or > > not). > >=20 > >=20 > >=20 > > > Why do we need to support SDES-SRTP at all? > >=20 > > In conjunction with a secure signaling path (HTTPS or secure > > WebSocket) IMHO it provides a reasonable security level for avoiding > > media interception. > >=20 > >=20 > >=20 > > > I do not understand the > > > arguments that say RTP is bad, but SDES-SRTP is ok. > >=20 > > Replied above. > >=20 > >=20 > >=20 > > > If you need interop, RTP > > > is your best option. If you need security DTLS-SRTP is your answer. > > > SDES-SRTP does not serve either purpose well. > >=20 > > I'm not a fan of SDES-SRTP, I just say that IMHO it can provide a good > > security level. > >=20 > > The only I say is that there is no reason for allowing plain RTP other > > than interop with old/legacy SIP devices (those whose vendors have > > decided not to implement SRTP, a spec from 2004). Is there any other > > case in which using plain RTP within WebRTC context is better than > > using SRTP? > >=20 >=20 >=20 > Large scale public events come to mind. >=20 > L. >=20 (even though, thinking about it, they're probably out of scope in here) L. > >=20 > > Regards. > >=20 > >=20 > > --=20 > > I=C3=B1aki Baz Castillo > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > --=20 > Lorenzo Miniero, COB >=20 > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From roman@telurix.com Mon Mar 19 13:08:31 2012 Return-Path: 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 D21DA21F87E9 for ; Mon, 19 Mar 2012 13:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 oWav3E+E0kyo for ; Mon, 19 Mar 2012 13:08:31 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5669021F87ED for ; Mon, 19 Mar 2012 13:08:31 -0700 (PDT) Received: by dakl33 with SMTP id l33so11529714dak.31 for ; Mon, 19 Mar 2012 13:08:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=vxQLKuVv3i6m55/C3tqrd3X8sdGZdU5c6yTuydwuDiY=; b=kyi87SQuUqFpBqd25Xfgrnpd6MXACoD9vddNwpw0v1M/L3MGleJMY9XMYgzGQi6B9S m3p+vUdx8ItfsTlAUdaqGZBXlrIzGB2tAuBiVcXEhPrx+wgu5O4tZ3vvkUkB4GrdnpRU McJgNBU59P6tutWa75POTFF5+wJX+T4GhMLhRgfzd0vRaTZ0IMUrpIevsBY0oRMLiHlG YZsLVqHw77lfzm8CV1nEXk+TO2bjvGRFtyvOi1zH7Lt4bIL1s3nXFIi0+nYeO4UBWvWW kK3b3W7F1X0O+neiSbkM9hN3xVjcUFL1DQ24LG5KNbPIbdgbeYOOPlpIoNVpL4ZryZUE 107A== Received: by 10.68.73.225 with SMTP id o1mr43107228pbv.77.1332187710992; Mon, 19 Mar 2012 13:08:30 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id x1sm12008433pbp.50.2012.03.19.13.08.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 13:08:30 -0700 (PDT) Received: by dakl33 with SMTP id l33so11529679dak.31 for ; Mon, 19 Mar 2012 13:08:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.40 with SMTP id or8mr42920143pbb.34.1332187709417; Mon, 19 Mar 2012 13:08:29 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Mon, 19 Mar 2012 13:08:29 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <52789D17-F7C7-401B-B2E8-6FE3BC5D7CB7@phonefromhere.com> Date: Mon, 19 Mar 2012 16:08:29 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b10cde331a9e004bb9e1f01 X-Gm-Message-State: ALoCoQl/v3UXw1oju9RK8zOGCS6mU7CriyxwzbNmK371fcCddkte/NkcSeGyuD5NdLdvcIFKrKuu Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 20:08:31 -0000 --047d7b10cde331a9e004bb9e1f01 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Mar 19, 2012 at 3:47 PM, I=F1aki Baz Castillo wrote= : > > The only I say is that there is no reason for allowing plain RTP other > than interop with old/legacy SIP devices (those whose vendors have > decided not to implement SRTP, a spec from 2004). Is there any other > case in which using plain RTP within WebRTC context is better than > using SRTP? > > Is there any case in which using SDES-SRTP is better then using DTLS-SRTP, except interop with old/legacy devices? _____________ Roman Shpount --047d7b10cde331a9e004bb9e1f01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 19, 2012 at 3:47 P= M, I=F1aki Baz Castillo <ibc@aliax.net> wrote:

The only I say is that there is no reason for allowing plain RTP other
than interop with old/legacy SIP devices (those whose vendors have
decided not to implement SRTP, a spec from 2004). Is there any other
case in which using plain RTP within WebRTC context is better than
using SRTP?


Is there any case in which using SDES-SRTP is be= tter then using DTLS-SRTP, except interop with old/legacy devices?
_____= ________
Roman Shpount


--047d7b10cde331a9e004bb9e1f01-- From tim@phonefromhere.com Mon Mar 19 13:31:38 2012 Return-Path: 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 A18E821E801C for ; Mon, 19 Mar 2012 13:31:38 -0700 (PDT) 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 i802UXFxn8Im for ; Mon, 19 Mar 2012 13:31:38 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id DC09C21E8017 for ; Mon, 19 Mar 2012 13:31:37 -0700 (PDT) Received: from [192.168.157.66] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id DEC1A37A902; Mon, 19 Mar 2012 20:44:09 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_2D0CA300-5C84-4E09-8A09-CA536713D112" From: Tim Panton In-Reply-To: <20120319205207.1133e5b0@rainpc> Date: Mon, 19 Mar 2012 20:31:39 +0000 Message-Id: <2DDA8FE2-CC30-40C0-9387-35DACBD22072@phonefromhere.com> References: <4F4759DC.7060303@ericsson.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <52789D17-F7C7-401B-B2E8-6FE3BC5D7CB7@phonefromhere.com> <20120319205207.1133e5b0@rainpc> To: Lorenzo Miniero X-Mailer: Apple Mail (2.1257) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 20:31:38 -0000 --Apple-Mail=_2D0CA300-5C84-4E09-8A09-CA536713D112 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Mar 2012, at 19:52, Lorenzo Miniero wrote: >>=20 >> The only I say is that there is no reason for allowing plain RTP = other >> than interop with old/legacy SIP devices (those whose vendors have >> decided not to implement SRTP, a spec from 2004). Is there any other >> case in which using plain RTP within WebRTC context is better than >> using SRTP? >>=20 >=20 >=20 > Large scale public events come to mind. Assuming that you are thinking of the CPU required to encrypt all the = streams,=20 I see no reason you couldn't have all the streams use the same keys, the = you could write a special SRTP stack that encoded exactly once then echoed the = same packets to all the recipients. (Which is close to the case for satellite TV at the moment I believe). T.= --Apple-Mail=_2D0CA300-5C84-4E09-8A09-CA536713D112 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The = only I say is that there is no reason for allowing plain RTP = other
than interop with = old/legacy SIP devices (those whose vendors = have
decided not to implement = SRTP, a spec from 2004). Is there any other
case in which using plain RTP within WebRTC context is = better than
using = SRTP?



Large scale public events come to = mind.

Assuming that you are = thinking of the CPU required to encrypt all the = streams, 
I see no reason you couldn't have all the = streams use the same keys, the you could
write a special SRTP = stack that encoded exactly once then echoed the same packets to all the = recipients.

(Which is close to the case for = satellite TV at the moment I = believe).

T.
= --Apple-Mail=_2D0CA300-5C84-4E09-8A09-CA536713D112-- From ibc@aliax.net Mon Mar 19 14:04:43 2012 Return-Path: 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 14A3921F87FD for ; Mon, 19 Mar 2012 14:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 uLPiMiIhtgp9 for ; Mon, 19 Mar 2012 14:04:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1715421F87FC for ; Mon, 19 Mar 2012 14:04:42 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so8168951vcb.31 for ; Mon, 19 Mar 2012 14:04:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=qnfiDDi5Ak0VUhinRb/+R1MGVWpXAfuO8n2m1POgq0s=; b=mqK03mTWzKM6LbNJKjXxbxNVpW7AYb/WF3NkKxJka8Oga9xSqaUEbT4zOkYP0Yus+m QRMMxlBLTyrUAzdtDZ/P8bijH1HWMZ6Id1rSX7lw2UvLPyv8j5xRzQu/BT/dW7jcwbZV CyYvqmX/+e6M6+n2rdb8yn0SwLo8QAV1pfTyCzA+vwQBUjjEM9Bu/wz/U4T4UVV++C+X hEdFHlUWi5gQ7rX1ixhuSJjpuwHGn84mXg+9RGAOihJdfu+hX5KRFOYXmq8ObLRiM0Yr xQwyE0b5/9ZEmvdvAhvxXtPeW7GNYljcdpjZjjySmSaSYlW8+hkoW8/o4jIpL1GTvt/R HSDQ== Received: by 10.52.65.239 with SMTP id a15mr6341070vdt.51.1332191081381; Mon, 19 Mar 2012 14:04:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Mon, 19 Mar 2012 14:04:21 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <52789D17-F7C7-401B-B2E8-6FE3BC5D7CB7@phonefromhere.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 19 Mar 2012 22:04:21 +0100 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl5UHHUCy+nxXLBdlQn0dLMyaibm5jqgYg9HNriokV8PJL5uVX3eFZrni0+J8WzGJqkwSN2 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 21:04:43 -0000 2012/3/19 Roman Shpount : >> Is there any other >> case in which using plain RTP within WebRTC context is better than >> using SRTP? >> > > Is there any case in which using SDES-SRTP is better then using DTLS-SRTP= , > except interop with old/legacy devices? Mandating DTLS-SRTP (this is, not allowing plain RTP neither SDES-SRTP) is not a problem for me. :) --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Mon Mar 19 14:36:59 2012 Return-Path: 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 5A56221E801C for ; Mon, 19 Mar 2012 14:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] 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 LnARr8-mmOZF for ; Mon, 19 Mar 2012 14:36:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 88FC621F86F8 for ; Mon, 19 Mar 2012 14:36:58 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 19 Mar 2012 17:36:48 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.166]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Mon, 19 Mar 2012 17:36:48 -0400 From: Hadriel Kaplan To: Roman Shpount Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHNBhhj1ILH9o/h5UGJ69qpB5eNrA== Date: Mon, 19 Mar 2012 21:36:47 +0000 Message-ID: <1BA75A62-C828-4A92-A870-D64C8CC9810A@acmepacket.com> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <52789D17-F7C7-401B-B2E8-6FE3BC5D7CB7@phonefromhere.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 21:36:59 -0000 On Mar 19, 2012, at 4:08 PM, Roman Shpount wrote: > Is there any case in which using SDES-SRTP is better then using DTLS-SRTP= , except interop with old/legacy devices? Yup. The other advantages of SDES are: 1) Shorter call-answer-delay, because there're no additional round-trips be= fore media other than ICE 2) Cheaper/less-overhead/better-scaling 3) Fewer interop issues - we don't know what DTLS-SRTP interop issues will = exist, if any, but more code usually means more interop issues, or at least= more "bugs". ICE itself will probably have some issues anyway[*], but mor= e code and complexity won't help matters. And if the Identity-model stuff is mandatory to use for DTLS, you can multi= ply the impact of those factors by some non-zero multiple. -hadriel [*] There are already multiple variants of ICE in the wild, with one implem= entation known not to interop with others. But I don't know if it's an SDP= -specific ICE interop issue or a problem with the connectivity checks or st= ate machine. From HKaplan@acmepacket.com Mon Mar 19 15:23:58 2012 Return-Path: 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 E6F3621F8628 for ; Mon, 19 Mar 2012 15:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] 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 k7geFB+2BCnR for ; Mon, 19 Mar 2012 15:23:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 04C2C21F860E for ; Mon, 19 Mar 2012 15:23:57 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 19 Mar 2012 18:23:56 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.166]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Mon, 19 Mar 2012 18:23:56 -0400 From: Hadriel Kaplan To: Roman Shpount Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHNBh74aMnjJsNUq0eXz+PkH27a4g== Date: Mon, 19 Mar 2012 22:23:55 +0000 Message-ID: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 22:23:59 -0000 While I sympathize with the concern that requiring SRTP (regardless of how = the key is learned) is a burden for those use-cases that literally don't ca= re about SRTP and for which it does not matter, such as a weather announcem= ent service or an IETF meeting broadcast, I really think you're 'throwing o= ut the baby with the bath-water' to propose we either get everything or not= hing. People won't have the identity-stuff for some time, and it won't be = painless to make it work and deployed. So what you're basically saying is = "you only get RTP because you can't prove end-to-end security". But such "= proof" rarely exists even today. Today, when you do Email or IM over HTTPS or SMTPS, that email or IM only g= oes secure to the server you're doing SMTPS or HTTPS with. You have no ass= urance whatsoever that it stays secure from that point on, nor that the ser= ver doesn't log the email/IM in its entirety. But that doesn't mean there'= s no value in using HTTPS/SMTPS to reach that first server. Quite the cont= rary, there's significant value in it. Just like there's value in using HT= TPS to reach a web store-front when purchasing using a credit-card, even th= ough you have no idea what the security is between the web-store and your a= ctual credit-card company. In the WebRTC context, for example, I would expect a quite-popular use-case= for WebRTC to be Business websites, such as web-storefronts, or customer-s= upport sites, or airline/hotel ticket/reservations/upgrades sites, etc. Wh= en connecting to the web-page of those sites, I would expect them to be HTT= PS once I got to some point of the click-flow process, if not from the begi= nning. If I click a "talk to us for help" button, I would expect that to b= e secure as well, as much as the HTTPS portion was anyway. In this context= , only allowing them to use RTP is silly. SDES is reasonably secure in thi= s context, because there is no other domain the call is going to. Yes, the= y have my SRTP key - doesn't matter; yes they can log my call - doesn't mat= ter. But at least my media is secure from my laptop to their server's doma= in - and that does matter, and it's all I ever got from using HTTPS. -hadriel On Mar 19, 2012, at 2:15 PM, Roman Shpount wrote: > I guess my question is, when are we going to tell the user that connectio= n is "secure"? What I really do not want is making the distinction between = secured and unsecured connection so muddy, that a normal user will never be= able to understand the difference and will agree to anything. Because of t= his, I would like to see that if connection is over DTLS-SRTP with a remove= party verified by an identity provider, user would be asked if they would = like to communicate with remote party XYZ. If this is anything else, (DTLS-= SRTP with no identity, SDES-SRTP, or even plain RTP), user should be asked = either to allow unsecure communication with an unknown party, or, completel= y prohibited to do so.=20 >=20 > I do not see the difference, as far as security is concerned, between SDE= S-SRTP and plain RTP. If we allow SDES-SRTP for compatibility reasons, we m= ight as well allow plain RTP. It would be compatible with more devices and = as insecure as SDES-SRTP. There is no requirement that WebRTC application m= ust use HTTPS for signaling. If the application is using HTTP, all the "sit= ting in the airport" examples are as unsecured with SDES-SRTP as they are w= ith plain RTP. >=20 > I do not think we would be able to force WebRTC application developers to= create a secure application unless they would decide to create care and ef= fort to develop it as such. Our goal should be to provide application devel= opers with tools that would allow them to create secure applications and wi= th mechanisms that would allow users to identify when their communications = are actually secure. Everything else is just adding random requirements to = the standard. > _____________ > Roman Shpount >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Jim.Barnett@genesyslab.com Mon Mar 19 15:50:24 2012 Return-Path: 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 63DB621F87C7 for ; Mon, 19 Mar 2012 15:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] 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 U+emY9S43MyF for ; Mon, 19 Mar 2012 15:50:23 -0700 (PDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 52B7321F87C0 for ; Mon, 19 Mar 2012 15:50:23 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q2JMoG5S028237; Mon, 19 Mar 2012 15:50:17 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 15:50:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Mar 2012 15:49:28 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHNBh74aMnjJsNUq0eXz+PkH27a4pZyN+Gg References: <4F4759DC.7060303@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com><6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com><6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> From: "Jim Barnett" To: "Hadriel Kaplan" , "Roman Shpount" X-OriginalArrivalTime: 19 Mar 2012 22:50:17.0428 (UTC) FILETIME=[A79BE940:01CD0622] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 22:50:24 -0000 On the matter of the call center/travel site recording your call: can't the far-end user agent always record your call, no matter what security you use? So in the case of SDES, the call center can record at their SBC/switch/media server (their in-house MITM), which is easier for them, but even with DTLS/SRTP couldn't they always record it at the agent desktop, if they wanted to? - Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, March 19, 2012 6:24 PM To: Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris While I sympathize with the concern that requiring SRTP (regardless of how the key is learned) is a burden for those use-cases that literally don't care about SRTP and for which it does not matter, such as a weather announcement service or an IETF meeting broadcast, I really think you're 'throwing out the baby with the bath-water' to propose we either get everything or nothing. People won't have the identity-stuff for some time, and it won't be painless to make it work and deployed. So what you're basically saying is "you only get RTP because you can't prove end-to-end security". But such "proof" rarely exists even today. Today, when you do Email or IM over HTTPS or SMTPS, that email or IM only goes secure to the server you're doing SMTPS or HTTPS with. You have no assurance whatsoever that it stays secure from that point on, nor that the server doesn't log the email/IM in its entirety. But that doesn't mean there's no value in using HTTPS/SMTPS to reach that first server. Quite the contrary, there's significant value in it. Just like there's value in using HTTPS to reach a web store-front when purchasing using a credit-card, even though you have no idea what the security is between the web-store and your actual credit-card company. In the WebRTC context, for example, I would expect a quite-popular use-case for WebRTC to be Business websites, such as web-storefronts, or customer-support sites, or airline/hotel ticket/reservations/upgrades sites, etc. When connecting to the web-page of those sites, I would expect them to be HTTPS once I got to some point of the click-flow process, if not from the beginning. If I click a "talk to us for help" button, I would expect that to be secure as well, as much as the HTTPS portion was anyway. In this context, only allowing them to use RTP is silly. SDES is reasonably secure in this context, because there is no other domain the call is going to. Yes, they have my SRTP key - doesn't matter; yes they can log my call - doesn't matter. But at least my media is secure from my laptop to their server's domain - and that does matter, and it's all I ever got from using HTTPS. -hadriel On Mar 19, 2012, at 2:15 PM, Roman Shpount wrote: > I guess my question is, when are we going to tell the user that connection is "secure"? What I really do not want is making the distinction between secured and unsecured connection so muddy, that a normal user will never be able to understand the difference and will agree to anything. Because of this, I would like to see that if connection is over DTLS-SRTP with a remove party verified by an identity provider, user would be asked if they would like to communicate with remote party XYZ. If this is anything else, (DTLS-SRTP with no identity, SDES-SRTP, or even plain RTP), user should be asked either to allow unsecure communication with an unknown party, or, completely prohibited to do so.=20 >=20 > I do not see the difference, as far as security is concerned, between SDES-SRTP and plain RTP. If we allow SDES-SRTP for compatibility reasons, we might as well allow plain RTP. It would be compatible with more devices and as insecure as SDES-SRTP. There is no requirement that WebRTC application must use HTTPS for signaling. If the application is using HTTP, all the "sitting in the airport" examples are as unsecured with SDES-SRTP as they are with plain RTP. >=20 > I do not think we would be able to force WebRTC application developers to create a secure application unless they would decide to create care and effort to develop it as such. Our goal should be to provide application developers with tools that would allow them to create secure applications and with mechanisms that would allow users to identify when their communications are actually secure. Everything else is just adding random requirements to the standard. > _____________ > Roman Shpount >=20 >=20 > _______________________________________________ > 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 From roman@telurix.com Mon Mar 19 16:34:25 2012 Return-Path: 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 79D6821F8834 for ; Mon, 19 Mar 2012 16:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 xADyk9dGYqUC for ; Mon, 19 Mar 2012 16:34:24 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8348B21F8826 for ; Mon, 19 Mar 2012 16:34:24 -0700 (PDT) Received: by dakl33 with SMTP id l33so11757153dak.31 for ; Mon, 19 Mar 2012 16:34:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=T89acUoSfnIEB2SChwyJUOUJMiPD5zt8KYwL8exnX88=; b=SKg1fLqoa/GWm5dgvokl2MfsdkDRGIn+cqTUbWPC1K6AyOQQScSROtYzj/fQTw9Pvt 7UIJAMvwZ2iNq8mkmaSouhI/jsiGh7VGw+lvRFmykVjdNQeBq2VXj+f5AqniUp+J4jE0 rTkwRwu7Wp4eNFbadscFERk1sfayxUiz8yXBmynKtrsZxGR7+6nvFR4WCEkGdKdGgCHf 1DwqiqiHIVZlKI7cm7JcwPDDSW+Ql7i6bMcjlywDF8TCR0n+iQ0Rdls7mAFovorDIR2c a3PbjklHn7sKbNKfd2wZWPazhWQUdGuQ55v3cSpMIcTDj+OfNkZ+uA4/wX6FKxTwXvVb mZgQ== Received: by 10.68.190.42 with SMTP id gn10mr26689091pbc.94.1332200058288; Mon, 19 Mar 2012 16:34:18 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id r6sm12300671pbq.56.2012.03.19.16.34.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 16:34:17 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1467387pbb.31 for ; Mon, 19 Mar 2012 16:34:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.201.98 with SMTP id jz2mr44069305pbc.97.1332200056239; Mon, 19 Mar 2012 16:34:16 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Mon, 19 Mar 2012 16:34:16 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Mon, 19 Mar 2012 19:34:16 -0400 Message-ID: From: Roman Shpount To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=047d7b15aee91f344004bba0ffbb X-Gm-Message-State: ALoCoQmPypdsglCLVBvRnvLap06uKCRWKThN8Twi9Cj3X/JMyak/E1Cmj0JEKatakfZ3YIPi5edb Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 23:34:25 -0000 --047d7b15aee91f344004bba0ffbb Content-Type: text/plain; charset=ISO-8859-1 Here are the levels of security that we get right now: 1. DTLS SRTP with Identity provider with signaling over HTTP or HTTPS. As long as identity provider is not compromised, user knows who they are talking to and that conversation is reasonably secure. 2. DTLS SRTP or SDES SRTP with signaling over HTTPS. There are no guarantees on who exactly the user is talking to, but as long we assume that web server and javascript applications are not compromised, conversation is secured to some application selected destination. Cannot tell the user that the call is secure, but probably not going to be something that can be picked up by a script kiddy with a network sniffer. 3. DTLS SRTP or SDES SRTP with signaling over HTTP. There are no guarantees on where the application came from or who exactly you are talking to. The conversation is encrypted, but it can either be listened to by simply capturing the keys (SDES SRTP) or you can spoof DNS and take over the whole web application and make DTLS SRTP talk to some sort of monitoring proxy. No security and probably not much better then plain RTP. So, my question is, are we going to disable WebRTC from HTTP initiated sessions completely and show the appropriate UI confirmations (secure for 1 and unsecure for 2) or do we plan to do something different? If we allow any non identity non DTLS SRTP communications with signaling over HTTP, we might as well allow all of them. All of those communication modes will have the same security downsides, and I would argue that RTP have probably the most upsides. _____________ Roman Shpount --047d7b15aee91f344004bba0ffbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here are the levels of security that we get right now:

1. DTLS SRTP = with Identity provider with signaling over HTTP or HTTPS. As long as identi= ty provider is not compromised, user knows who they are talking to and that= conversation is reasonably secure.

2. DTLS SRTP or SDES SRTP with signaling over HTTPS. There are no guara= ntees on who exactly the user is talking to, but as long we assume that web= server and javascript applications are not compromised, conversation is se= cured to some application selected destination. Cannot tell the user that t= he call is secure, but probably not going to be something that can be picke= d up by a script kiddy with a network sniffer.

3. DTLS SRTP or SDES SRTP with signaling over HTTP. There are no guaran= tees on where the application came from or who exactly you are talking to. = The conversation is encrypted, but it can either be listened to by simply c= apturing the keys (SDES SRTP) or you can spoof DNS and take over the whole = web application and make DTLS SRTP talk to some sort of monitoring proxy. N= o security and probably not much better then plain RTP.

So, my question is, are we going to disable WebRTC from HTTP initiated = sessions completely and show the appropriate UI confirmations (secure for 1= and unsecure for 2) or do we plan to do something different? If we allow a= ny non identity non DTLS SRTP communications with signaling over HTTP, we m= ight as well allow all of them. All of those communication modes will have = the same security downsides, and I would argue that RTP have probably the m= ost upsides.
_____________
Roman Shpount

--047d7b15aee91f344004bba0ffbb-- From ekr@rtfm.com Mon Mar 19 17:19:19 2012 Return-Path: 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 9CD8821F877C for ; Mon, 19 Mar 2012 17:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.177 X-Spam-Level: X-Spam-Status: No, score=-106.177 tagged_above=-999 required=5 tests=[AWL=-3.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 SD-GKVdIq850 for ; Mon, 19 Mar 2012 17:19:19 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0291021F8778 for ; Mon, 19 Mar 2012 17:19:18 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so8317669vcb.31 for ; Mon, 19 Mar 2012 17:19:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=8jkzEXUHYelYq2sbwhKdIweBGf4Rvktpf0iFujDvwSQ=; b=Nac3PEBGazUaBxIYeMVC2rFDLF8zcOEJxeZjZSLK5q5ac0J5c3hBrMVoHwazwsJv1F Wt0hRJFbMO2nMlCm18eY1Pi4YNuM6Tu3jNwytnjTi4gyc/vPYkYP/wQNEIzDkAHJEVWk Nf+Zy5ReSwxBOomgMmVz34ElRO3SdgrETCzhwuhNS9zXc7LTFN34BBuo0+6rIsGdJpKW 0RD/20c0JhGdwUJ80eUxdOMm9DuSijevhQo0DC6FrpBFzq/9aEEQKBVA3DsHyw16VHDl 0OBS/mBtjkdd8/zjPkTlDXDA/xM1eaK9621pbpDtzu6+RckRWNeuLWFnMCqahw+Hz0Ut MikA== Received: by 10.220.224.197 with SMTP id ip5mr5633216vcb.41.1332202758470; Mon, 19 Mar 2012 17:19:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Mon, 19 Mar 2012 17:18:37 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> From: Eric Rescorla Date: Mon, 19 Mar 2012 17:18:37 -0700 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnSk7VW9N6zl6JeyZ+/sTE926MXrLAxvgEVbgiTyxeYFiYh7Okz6JUZMFVJazHZVl41FX7r Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 00:19:19 -0000 On Mon, Mar 19, 2012 at 4:34 PM, Roman Shpount wrote: > Here are the levels of security that we get right now: > > 1. DTLS SRTP with Identity provider with signaling over HTTP or HTTPS. As > long as identity provider is not compromised, user knows who they are > talking to and that conversation is reasonably secure. > > 2. DTLS SRTP or SDES SRTP with signaling over HTTPS. There are no guarantees > on who exactly the user is talking to, but as long we assume that web server > and javascript applications are not compromised, conversation is secured to > some application selected destination. Cannot tell the user that the call is > secure, but probably not going to be something that can be picked up by a > script kiddy with a network sniffer. As discussed in draft-ietf-rtcweb-security, I don't agree that DTLS-SRTP without identity and SDES-SRTP offer the same level of security. Most of what I have to say about that is already said there, but briefly: - DTLS-SRTP is secure against retrospective attack whereas SDES-SRTP is not. - If there is a mechanism such as fingerprints *is* available for checking against MITM, then DTLS-SRTP is secure against active attack as well. Additionally, the existence of fingerprint type mechanisms acts as a partial deterrent against MITM attack by the signaling provider even if only a small number of people check. -Ekr From roman@telurix.com Mon Mar 19 17:59:08 2012 Return-Path: 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 C9F5B21F86F9 for ; Mon, 19 Mar 2012 17:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.759 X-Spam-Level: X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 hSjdspJ-ZWjC for ; Mon, 19 Mar 2012 17:59:08 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 14DEB21F86F7 for ; Mon, 19 Mar 2012 17:59:07 -0700 (PDT) Received: by dakl33 with SMTP id l33so11843434dak.31 for ; Mon, 19 Mar 2012 17:59:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=NbYFtKcRtH1DjGfJrjfdAN+Fao6mZSBgqIM5UTOc4sA=; b=hCYrJe0gKS/h6J35LCPdnfAwPf67UuojBJwbpbNkC6ENaUso7D57W030FuaB22DeCx sC8UtZaKu4rN+XNgl76Tj1WRfheTgxCauGVJ9aOWr3DGKuc+hG5x6sgUsVolpLmmkgi7 Wk2ggNXdHzQGOdvDTw8sKJPj8fFfCy1TtKuFm3O116IOqQI2iXrgfSsfc7A6tQmBXZQt 2wW9J/YkiQEQ8rWBc3MZ9sA364Q8wUMuPwdhFjxffvcawrf3Sa1e/775AksqUJ+qEu6T zGVMY0kbGKg0Yy+SLwwx2mkf/tpSys576ixsavG/X3sOIeUAoENoQ5eFHKhPOn/NPQ87 L/Gw== Received: by 10.68.191.230 with SMTP id hb6mr44712109pbc.87.1332205147844; Mon, 19 Mar 2012 17:59:07 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id p10sm12439587pbo.55.2012.03.19.17.59.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 17:59:06 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1501114pbb.31 for ; Mon, 19 Mar 2012 17:59:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.196.163 with SMTP id in3mr6262441pbc.118.1332205145363; Mon, 19 Mar 2012 17:59:05 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Mon, 19 Mar 2012 17:59:05 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Mon, 19 Mar 2012 20:59:05 -0400 Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=e89a8ff1c65a75157104bba22e00 X-Gm-Message-State: ALoCoQmvaHL3GbNYaCFufpAQyAAFkom+QpYAVYgfWnZrKHRB2hF4pU2mCgHbzAAqtVMAS/89Lnuv Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 00:59:08 -0000 --e89a8ff1c65a75157104bba22e00 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 19, 2012 at 8:18 PM, Eric Rescorla wrote: > As discussed in draft-ietf-rtcweb-security, I don't agree that DTLS-SRTP > without > identity and SDES-SRTP offer the same level of security. Most of what I > have > to say about that is already said there, but briefly: > > - DTLS-SRTP is secure against retrospective attack whereas SDES-SRTP is > not. > - If there is a mechanism such as fingerprints *is* available for > checking against > MITM, then DTLS-SRTP is secure against active attack as well. Additionally, > the existence of fingerprint type mechanisms acts as a partial deterrent > against > MITM attack by the signaling provider even if only a small number of people > check. > > I agree with you on all of those points. I would prefer that instead of SDES SRTP support we spent time optimizing DTLS/ICE handshake (and there are a few drafts on this list related to that). It should be possible to conduct a secure key exchange at the same time as ICE candidate selection with no additional overhead. I also understand the argument that most of the regular users will never check the fingerprint, and this is why I put SDES-SRTP and DTLS-SRTP in the same group. DTLS-SRTP is more secure then SDES-SRTP, but it still not enough to tell the user that communication is secure. But regardless of all these points, if we allow signaling over HTTP all the security considerations go out of the window. For me the ideal solution is: 1. DTLS-SRTP with Identity and any signaling is always allowed and shows notification that communication is with a known party and secure. 2. DTLS-SRTP with signaling over HTTPS shows notification that communication is unsecure and with an unknown party 3. SDES SRTP is not supported at all and DTLS/ICE handshake is optimized instead to reduce call setup time 4. DTLS-SRTP with no ident and RTP with signaling over HTTP are not recommended, but allowed after a big red sign (or require some advanced browser setting to enable). I would also like to have a simplified DTLS specification for DTLS-SRTP, with as many as possible unnecessary features (encryption algorithms, cookies and such) removed and only a few required scenarios supported. For instance, I do not want DTLS on a WebRTC channel start negotiation and end up with anything except SRTP as an encryption protocol. Ideally, I want something were an interop test can be developed with a manageable number of scenarios. P.S. Sending RSA public key in the session description instead of fingerprint and then encrypting the SRTP key using this public key and sending it in the ICE message might be a much simpler call setup mechanism to implement then bringing the whole DTLS into the stack. This should also allow us to setup a secure call with no overhead in addition to ICE. _____________ Roman Shpount --e89a8ff1c65a75157104bba22e00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 19, 2012 at 8:= 18 PM, Eric Rescorla <= ekr@rtfm.com> wrote:
As discussed in draft-ietf-rtcweb-security, I don't agree that DTLS-SRT= P without
identity and SDES-SRTP offer the same level of security. Most of what I hav= e
to say about that is already said there, but briefly:

- DTLS-SRTP is secure against retrospective attack whereas SDES-SRTP is not= .
- If there is a mechanism such as fingerprints *is* available for
checking against
MITM, then DTLS-SRTP is secure against active attack as well. Additionally,=
the existence of fingerprint type mechanisms acts as a partial deterrent ag= ainst
MITM attack by the signaling provider even if only a small number of people=
check.

=A0
I agree with you on all of those point= s. I would prefer that instead of SDES SRTP support we spent time optimizin= g DTLS/ICE handshake (and there are a few drafts on this list related to th= at). It should be possible to conduct a secure key exchange at the same tim= e as ICE candidate selection with no additional overhead. I also understand= the argument that most of the regular users will never check the fingerpri= nt, and this is why I put SDES-SRTP and DTLS-SRTP in the same group. DTLS-S= RTP is more secure then SDES-SRTP, but it still not enough to tell the user= that communication is secure.

But regardless of all these points, if we allow signaling over HTTP all= the security considerations go out of the window.

For me the ideal = solution is:

1. DTLS-SRTP with Identity and any signaling is always = allowed and shows notification that communication is with a known party and= secure.
2. DTLS-SRTP with signaling over HTTPS shows notification that communicatio= n is unsecure and with an unknown party
3. SDES SRTP is not supported at= all and DTLS/ICE handshake is optimized instead to reduce call setup time<= br> 4. DTLS-SRTP with no ident and RTP with signaling over HTTP are not recomme= nded, but allowed after a big red sign (or require some advanced browser se= tting to enable).

I would also like to have a simplified DTLS specif= ication for DTLS-SRTP, with as many as possible unnecessary features (encry= ption algorithms, cookies and such) removed and only a few required scenari= os supported. For instance, I do not want DTLS on a WebRTC channel start ne= gotiation and end up with anything except SRTP as an encryption protocol. I= deally, I want something were an interop test can be developed with a manag= eable number of scenarios.

P.S. Sending RSA public key in the session description instead of finge= rprint and then encrypting the SRTP key using this public key and sending i= t in the ICE message might be a much simpler call setup mechanism to implem= ent then bringing the whole DTLS into the stack. This should also allow us = to setup a secure call with no overhead in addition to ICE.
_____________
Roman Shpount

--e89a8ff1c65a75157104bba22e00-- From pravindran@sonusnet.com Mon Mar 19 18:06:47 2012 Return-Path: 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 B3DE521F87A7 for ; Mon, 19 Mar 2012 18:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.86 X-Spam-Level: X-Spam-Status: No, score=-4.86 tagged_above=-999 required=5 tests=[AWL=1.739, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Ai4Pk4AwE-BV for ; Mon, 19 Mar 2012 18:06:47 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id AB24D21F879A for ; Mon, 19 Mar 2012 18:06:46 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKT2fYJgqYqL2bxnV7dRCrrTkMAEf1qU+6@postini.com; Mon, 19 Mar 2012 18:06:46 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 19 Mar 2012 21:06:59 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 06:36:41 +0530 From: "Ravindran, Parthasarathi" To: Eric Rescorla Thread-Topic: RTCP consent approach comment Thread-Index: Ac0GNb+uCDyCq5LMT2C19AgEYj79Kg== Date: Tue, 20 Mar 2012 01:06:40 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFDFE@inba-mail01.sonusnet.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: [rtcweb] RTCP consent approach comment X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 01:06:47 -0000 Eric, Sec 4.2.3 mentions about RTCP consent approach is not adopted for 1) Small window attack of RTP 2) Tough for legacy non-RTCP endpoint to implement RTCP I think that small window attack of RTP is possible in ICE as well in case = attacker has access to offer SDP and the second reason is funny to recommen= d non-RTCP endpoint to implement ICE instead of implementing RTCP because t= his reason is equivalent of asking the person to buy cake who is struggling= to buy bread. The missing information is that NAT traversal is not possible using RTCP me= chanism. Could you please add "NAT traversal" as the one of the reason for = not adopting RTCP consent approach. Thanks Partha From pravindran@sonusnet.com Mon Mar 19 18:16:02 2012 Return-Path: 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 A0EA621E803F for ; Mon, 19 Mar 2012 18:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.894 X-Spam-Level: X-Spam-Status: No, score=-4.894 tagged_above=-999 required=5 tests=[AWL=1.705, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 OYT+dbbJccol for ; Mon, 19 Mar 2012 18:16:01 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id 79F3D21E801C for ; Mon, 19 Mar 2012 18:16:01 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKT2faUWYAAkwIs1+LdKuL1vBNU3tvyRK8@postini.com; Mon, 19 Mar 2012 18:16:01 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 19 Mar 2012 21:16:14 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 06:45:56 +0530 From: "Ravindran, Parthasarathi" To: Jim Barnett , Hadriel Kaplan , Roman Shpount Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHM8te6ZBG/XYsMg0C4SE+GOqsWNpZtZpyg///nIgCAAAs3AIAASYaAgADU1wCAAESDgIAB8AUAgAAelICAAH0pgIAAChuAgAAC/YCAADCxgIAADEuAgAAOHICAAAWBgIAAAeoAgAAPeYCAAEVigIAAByQAgACETSA= Date: Tue, 20 Mar 2012 01:15:54 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFE23@inba-mail01.sonusnet.com> References: <4F4759DC.7060303@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com><6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com><6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 01:16:02 -0000 Jim, As a customer, you won't really know whether the identity (DTLS-SRTP) of ca= ll center/travel site is agent or SBC. SBC can perform MITM attack easily a= s extending SDES-SRTP to DTLS-SRTP for call center site is feasible. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Jim Barnett >Sent: Tuesday, March 20, 2012 4:19 AM >To: Hadriel Kaplan; Roman Shpount >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris > >On the matter of the call center/travel site recording your call: can't >the far-end user agent always record your call, no matter what security >you use? So in the case of SDES, the call center can record at their >SBC/switch/media server (their in-house MITM), which is easier for them, >but even with DTLS/SRTP couldn't they always record it at the agent >desktop, if they wanted to? > >- Jim > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Hadriel Kaplan >Sent: Monday, March 19, 2012 6:24 PM >To: Roman Shpount >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris > > >While I sympathize with the concern that requiring SRTP (regardless of >how the key is learned) is a burden for those use-cases that literally >don't care about SRTP and for which it does not matter, such as a >weather announcement service or an IETF meeting broadcast, I really >think you're 'throwing out the baby with the bath-water' to propose we >either get everything or nothing. People won't have the identity-stuff >for some time, and it won't be painless to make it work and deployed. >So what you're basically saying is "you only get RTP because you can't >prove end-to-end security". But such "proof" rarely exists even today. > >Today, when you do Email or IM over HTTPS or SMTPS, that email or IM >only goes secure to the server you're doing SMTPS or HTTPS with. You >have no assurance whatsoever that it stays secure from that point on, >nor that the server doesn't log the email/IM in its entirety. But that >doesn't mean there's no value in using HTTPS/SMTPS to reach that first >server. Quite the contrary, there's significant value in it. Just like >there's value in using HTTPS to reach a web store-front when purchasing >using a credit-card, even though you have no idea what the security is >between the web-store and your actual credit-card company. > >In the WebRTC context, for example, I would expect a quite-popular use- >case for WebRTC to be Business websites, such as web-storefronts, or >customer-support sites, or airline/hotel ticket/reservations/upgrades >sites, etc. When connecting to the web-page of those sites, I would >expect them to be HTTPS once I got to some point of the click-flow >process, if not from the beginning. If I click a "talk to us for help" >button, I would expect that to be secure as well, as much as the HTTPS >portion was anyway. In this context, only allowing them to use RTP is >silly. SDES is reasonably secure in this context, because there is no >other domain the call is going to. Yes, they have my SRTP key - doesn't >matter; yes they can log my call - doesn't matter. But at least my >media is secure from my laptop to their server's domain - and that does >matter, and it's all I ever got from using HTTPS. > >-hadriel > > >On Mar 19, 2012, at 2:15 PM, Roman Shpount wrote: > >> I guess my question is, when are we going to tell the user that >connection is "secure"? What I really do not want is making the >distinction between secured and unsecured connection so muddy, that a >normal user will never be able to understand the difference and will >agree to anything. Because of this, I would like to see that if >connection is over DTLS-SRTP with a remove party verified by an identity >provider, user would be asked if they would like to communicate with >remote party XYZ. If this is anything else, (DTLS-SRTP with no identity, >SDES-SRTP, or even plain RTP), user should be asked either to allow >unsecure communication with an unknown party, or, completely prohibited >to do so. >> >> I do not see the difference, as far as security is concerned, between >SDES-SRTP and plain RTP. If we allow SDES-SRTP for compatibility >reasons, we might as well allow plain RTP. It would be compatible with >more devices and as insecure as SDES-SRTP. There is no requirement that >WebRTC application must use HTTPS for signaling. If the application is >using HTTP, all the "sitting in the airport" examples are as unsecured >with SDES-SRTP as they are with plain RTP. >> >> I do not think we would be able to force WebRTC application developers >to create a secure application unless they would decide to create care >and effort to develop it as such. Our goal should be to provide >application developers with tools that would allow them to create secure >applications and with mechanisms that would allow users to identify when >their communications are actually secure. Everything else is just adding >random requirements to the standard. >> _____________ >> Roman Shpount >> >> >> _______________________________________________ >> 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 From pravindran@sonusnet.com Mon Mar 19 18:53:15 2012 Return-Path: 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 E7D2421E801B for ; Mon, 19 Mar 2012 18:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.926 X-Spam-Level: X-Spam-Status: No, score=-4.926 tagged_above=-999 required=5 tests=[AWL=1.673, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 FtUykCiZjxmh for ; Mon, 19 Mar 2012 18:53:14 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with ESMTP id 592D821F8843 for ; Mon, 19 Mar 2012 18:53:09 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT2fjBBLwzaMykdfcwgrN1bCS3ZbeAAYk@postini.com; Mon, 19 Mar 2012 18:53:09 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 19 Mar 2012 21:53:21 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 07:23:03 +0530 From: "Ravindran, Parthasarathi" To: Hadriel Kaplan , Roman Shpount , Eric Rescorla , Ted Hardie , Randell Jesup Thread-Topic: RTP-IPSec vs SRTP-DTLS [was RE: [rtcweb] Resolving RTP/SDES question in Paris] Thread-Index: AQHNBjw4xqpSTETDQUmX7IKNGosvkA== Date: Tue, 20 Mar 2012 01:53:02 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFE49@inba-mail01.sonusnet.com> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: [rtcweb] RTP-IPSec vs SRTP-DTLS [was RE: Resolving RTP/SDES question in Paris] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 01:53:16 -0000 Hi all, Could you please let me know the reason why SRTP-DTLS alone MUST be support= ed by WebRTC web-browser and why not RTP-IPSec. In case my device support I= PSec for all application, why web-browser has to mandated for double encryp= tion. Another assumption here is that web-browser is endpoint (commercial b= rowsers like chrome) which is not required as access entity (like Enterpris= e access router, SBC) shall acts as web-browser. So, web-browser point-to-p= oint connection may be between employee browser to Enterprise access entity= which is not required to be mandated as SRTP-DTLS. Hadriel mentioned large= set of call centre solution wherein web-browser is just the endpoint, one = way to access call centre and there is no need to change whole call centre = architecture for the same WebRTC technology in case RTP-IPSec is supported = by WebRTC browser running in IPSec mobile phone. I disagree with security a= dvocates that all call centre using RTP will be broken as this security sto= ry does not sell well in the industry so far. Also, It is impossible to have the common UI by all web-browser and IETF sp= ecification should not try to find the way to solve that issue.=20 My problem is not mandatory to implement SRTP-DTLS but the issue is at mand= atory to use. IMO, RTP-IPSec should be allowed with user-consent in web-bro= wser and don't argue that all web user in the world are dumb. In case the u= secase is missing for RTP-IPSec as Randell mentioned, let us discuss in IET= F-83 RTCWeb meeting. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Hadriel Kaplan >Sent: Tuesday, March 20, 2012 3:54 AM >To: Roman Shpount >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris > > >While I sympathize with the concern that requiring SRTP (regardless of >how the key is learned) is a burden for those use-cases that literally >don't care about SRTP and for which it does not matter, such as a >weather announcement service or an IETF meeting broadcast, I really >think you're 'throwing out the baby with the bath-water' to propose we >either get everything or nothing. People won't have the identity-stuff >for some time, and it won't be painless to make it work and deployed. >So what you're basically saying is "you only get RTP because you can't >prove end-to-end security". But such "proof" rarely exists even today. > >Today, when you do Email or IM over HTTPS or SMTPS, that email or IM >only goes secure to the server you're doing SMTPS or HTTPS with. You >have no assurance whatsoever that it stays secure from that point on, >nor that the server doesn't log the email/IM in its entirety. But that >doesn't mean there's no value in using HTTPS/SMTPS to reach that first >server. Quite the contrary, there's significant value in it. Just like >there's value in using HTTPS to reach a web store-front when purchasing >using a credit-card, even though you have no idea what the security is >between the web-store and your actual credit-card company. > >In the WebRTC context, for example, I would expect a quite-popular use- >case for WebRTC to be Business websites, such as web-storefronts, or >customer-support sites, or airline/hotel ticket/reservations/upgrades >sites, etc. When connecting to the web-page of those sites, I would >expect them to be HTTPS once I got to some point of the click-flow >process, if not from the beginning. If I click a "talk to us for help" >button, I would expect that to be secure as well, as much as the HTTPS >portion was anyway. In this context, only allowing them to use RTP is >silly. SDES is reasonably secure in this context, because there is no >other domain the call is going to. Yes, they have my SRTP key - doesn't >matter; yes they can log my call - doesn't matter. But at least my >media is secure from my laptop to their server's domain - and that does >matter, and it's all I ever got from using HTTPS. > >-hadriel > > >On Mar 19, 2012, at 2:15 PM, Roman Shpount wrote: > >> I guess my question is, when are we going to tell the user that >connection is "secure"? What I really do not want is making the >distinction between secured and unsecured connection so muddy, that a >normal user will never be able to understand the difference and will >agree to anything. Because of this, I would like to see that if >connection is over DTLS-SRTP with a remove party verified by an identity >provider, user would be asked if they would like to communicate with >remote party XYZ. If this is anything else, (DTLS-SRTP with no identity, >SDES-SRTP, or even plain RTP), user should be asked either to allow >unsecure communication with an unknown party, or, completely prohibited >to do so. >> >> I do not see the difference, as far as security is concerned, between >SDES-SRTP and plain RTP. If we allow SDES-SRTP for compatibility >reasons, we might as well allow plain RTP. It would be compatible with >more devices and as insecure as SDES-SRTP. There is no requirement that >WebRTC application must use HTTPS for signaling. If the application is >using HTTP, all the "sitting in the airport" examples are as unsecured >with SDES-SRTP as they are with plain RTP. >> >> I do not think we would be able to force WebRTC application developers >to create a secure application unless they would decide to create care >and effort to develop it as such. Our goal should be to provide >application developers with tools that would allow them to create secure >applications and with mechanisms that would allow users to identify when >their communications are actually secure. Everything else is just adding >random requirements to the standard. >> _____________ >> Roman Shpount >> >> >> _______________________________________________ >> 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 From roman@telurix.com Mon Mar 19 19:29:19 2012 Return-Path: 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 8777121F87D6 for ; Mon, 19 Mar 2012 19:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.764 X-Spam-Level: X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 l6BqDhi+jaw4 for ; Mon, 19 Mar 2012 19:29:18 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACAD21F87D3 for ; Mon, 19 Mar 2012 19:29:18 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1541654pbb.31 for ; Mon, 19 Mar 2012 19:29:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=CRyZg2BxvTnTO1n6Puew3XGQHhL+vktGqs+dYGW9cq8=; b=cnrqa2ntZTRzOIBjzVJdx6wjNp0TrODB32EsPLAgFkxa5eY9uAX8a2uFfmsoeXwRBm OUrgJDopV9IHy5ajO/4UiVMHKuKD+JYcBFLjJaYcgNUH9kJtHvKLADggBb6LQN1Zes8V X46R2s36UKbSQrhBsJmN/zxsysLaiSISeMXx5nK6ccspzK4CqxD3ck48Aljyc1C8joJl vUrtSdYR85kTxYsyNjEvY1fL5scWUvALZRnfzYau43QtSo1KLo8Yg13wdISJsNn3fFK/ 9k3MvmYe/5Y55mzjqLAovlHr4D+lZpKfdKAiDEVsRqJ0jKyfVp4VF8FHviSAQVNpAqmH roRg== Received: by 10.68.125.168 with SMTP id mr8mr27727976pbb.21.1332210557992; Mon, 19 Mar 2012 19:29:17 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id 6sm132709pbh.65.2012.03.19.19.29.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 19:29:17 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1541639pbb.31 for ; Mon, 19 Mar 2012 19:29:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.40 with SMTP id or8mr45013220pbb.34.1332210555703; Mon, 19 Mar 2012 19:29:15 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Mon, 19 Mar 2012 19:29:15 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFE49@inba-mail01.sonusnet.com> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FFE49@inba-mail01.sonusnet.com> Date: Mon, 19 Mar 2012 22:29:15 -0400 Message-ID: From: Roman Shpount To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=047d7b10cde3f052bd04bba370f9 X-Gm-Message-State: ALoCoQnvl/loJmn+LvLb/mYpR1lamHfldP0OpIMzskJfxfvRonRpSF8YJzouPishQOUstZxEKUOT Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP-IPSec vs SRTP-DTLS [was RE: Resolving RTP/SDES question in Paris] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 02:29:19 -0000 --047d7b10cde3f052bd04bba370f9 Content-Type: text/plain; charset=ISO-8859-1 The reason is quite simple actually -- it is quite difficult to confirm that IPSec is actually present. So browser has no way to determine that it communicating over IPSec or plain IP. On the other hand, I actually agree that if we are dealing with an application on a private IP (like 10.X.X.X) you should be allowed to do whatever you want. This is why I am proposing to support RTP for applications delivered over HTTP. If you are in completely secure environment and you do not want to do encryption, there is no reason why the application should be delivered over HTTPS. If application is delivered over HTTP, you either do no care about security (you are calling a public radio) or security is provided by something else (you are sitting in the bunker on the network not connected to the internet). The large contingent of people on this list are convinced that upsides (security) of requiring encryption outweigh downsides. The mentioned downsides are: 1. Extra resource requirements. This is not really important as far as I am concerned. New Xeon server can encrypt 39.7 GB/sec ( http://www.theregister.co.uk/2012/03/06/intel_xeon_e5_launch_event/) 2. Support for legacy devices. Also not as important since most legacy devices will require a media proxy to support ICE anyway 3. Barrier to entry to develop new services. It is harder to debug and develop new products if you need to develop larger number of protocols at once. The understanding is that web browser will include some sort of hidden setting that will allow plain RTP for debugging and development. 4. Encryption can be illegal or not allowed in some places, such as military or prisons. Proposal is to enable some sort of configuration in the web browser that will force it to send all the media through some sort of recording/monitoring proxy. While, as far as I am concerned, all of those arguments are addressed, my main argument against requiring encryption is that there are scenarios when it is not needed and not actually provided, primarily when application is delivered over HTTP. All I am saying that if application developer does not care about security, the application most likely would not be secure, regardless of what we do. So why force it? Unless developer takes an effort to buy an SSL certificate and deploy an app on a secure server, or gets the certificate and sets up an identity provider, communication is not going to be secure. If I am a high school kid trying to play with real time communications using a free web hosting provider, I do not care about security. All I care is that I can write something that makes a call. What we are effectively doing is making this much more difficult. Innovation does not have to come from serious projects created for serious purposes. It often comes from things that are cobbled together and I want us to enable this, unless it actually breaks something. I want to make WebRTC easier to play with and hope that new exciting things will come out of this. _____________ Roman Shpount On Mon, Mar 19, 2012 at 9:53 PM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Hi all, > > Could you please let me know the reason why SRTP-DTLS alone MUST be > supported by WebRTC web-browser and why not RTP-IPSec. In case my device > support IPSec for all application, why web-browser has to mandated for > double encryption. Another assumption here is that web-browser is endpoint > (commercial browsers like chrome) which is not required as access entity > (like Enterprise access router, SBC) shall acts as web-browser. So, > web-browser point-to-point connection may be between employee browser to > Enterprise access entity which is not required to be mandated as SRTP-DTLS. > Hadriel mentioned large set of call centre solution wherein web-browser is > just the endpoint, one way to access call centre and there is no need to > change whole call centre architecture for the same WebRTC technology in > case RTP-IPSec is supported by WebRTC browser running in IPSec mobile > phone. I disagree with security advocates that all call centre using RTP > will be broken as this security story does not sell well in the industry so > far. > > Also, It is impossible to have the common UI by all web-browser and IETF > specification should not try to find the way to solve that issue. > > My problem is not mandatory to implement SRTP-DTLS but the issue is at > mandatory to use. IMO, RTP-IPSec should be allowed with user-consent in > web-browser and don't argue that all web user in the world are dumb. In > case the usecase is missing for RTP-IPSec as Randell mentioned, let us > discuss in IETF-83 RTCWeb meeting. > > Thanks > Partha > --047d7b10cde3f052bd04bba370f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The reason is quite simple actually -- it is quite difficult to confirm tha= t IPSec is actually present. So browser has no way to determine that it com= municating over IPSec or plain IP.

On the other hand, I actually agr= ee that if we are dealing with an application on a private IP (like 10.X.X.= X) you should be allowed to do whatever you want. This is why I am proposin= g to support RTP for applications delivered over HTTP. If you are in comple= tely secure environment and you do not want to do encryption, there is no r= eason why the application should be delivered over HTTPS. If application is= delivered over HTTP, you either do no care about security (you are calling= a public radio) or security is provided by something else (you are sitting= in the bunker on the network not connected to the internet).

The large contingent of people on this list are convinced that upsides = (security) of requiring encryption outweigh downsides. The mentioned downsi= des are:
1. Extra resource requirements. This is not really important as= far as I am concerned. New Xeon server can encrypt 39.7 GB/sec (http:= //www.theregister.co.uk/2012/03/06/intel_xeon_e5_launch_event/)
2. Support for legacy devices. Also not as important since most legacy devi= ces will require a media proxy to support ICE anyway
3. Barrier to entry= to develop new services. It is harder to debug and develop new products if= you need to develop larger number of protocols at once. The understanding = is that web browser will include some sort of hidden setting that will allo= w plain RTP for debugging and development.
4. Encryption can be illegal or not allowed in some places, such as militar= y or prisons. Proposal is to enable some sort of configuration in the web b= rowser that will force it to send all the media through some sort of record= ing/monitoring proxy.

While, as far as I am concerned, all of those arguments are addressed, = my main argument against requiring encryption is that there are scenarios w= hen it is not needed and not actually provided, primarily when application = is delivered over HTTP. All I am saying that if application developer does = not care about security, the application most likely would not be secure, r= egardless of what we do. So why force it? Unless developer takes an effort = to buy an SSL certificate and deploy an app on a secure server, or gets the= certificate and sets up an identity provider, communication is not going t= o be secure. If I am a high school kid trying to play with real time commun= ications using a free web hosting provider, I do not care about security. A= ll I care is that I can write something that makes a call. What we are effe= ctively doing is making this much more difficult. Innovation does not have = to come from serious projects created for serious purposes. It often comes = from things that are cobbled together and I want us to enable this, unless = it actually breaks something. I want to make WebRTC easier to play with and= hope that new exciting things will come out of this.
_____________
Roman Shpount


On Mon, Mar 19, 2012 at 9:53 PM, Ravindr= an, Parthasarathi <pravindran@sonusnet.com> wrote:
Hi all,

Could you please let me know the reason why SRTP-DTLS alone MUST be support= ed by WebRTC web-browser and why not RTP-IPSec. In case my device support I= PSec for all application, why web-browser has to mandated for double encryp= tion. Another assumption here is that web-browser is endpoint (commercial b= rowsers like chrome) which is not required as access entity (like Enterpris= e access router, SBC) shall acts as web-browser. So, web-browser point-to-p= oint connection may be between employee browser to Enterprise access entity= which is not required to be mandated as SRTP-DTLS. Hadriel mentioned large= set of call centre solution wherein web-browser is just the endpoint, one = way to access call centre and there is no need to change whole call centre = architecture for the same WebRTC technology in case RTP-IPSec is supported = by WebRTC browser running in IPSec mobile phone. I disagree with security a= dvocates that all call centre using RTP will be broken as this security sto= ry does not sell well in the industry so far.

Also, It is impossible to have the common UI by all web-browser and IETF sp= ecification should not try to find the way to solve that issue.

My problem is not mandatory to implement SRTP-DTLS but the issue is at mand= atory to use. IMO, RTP-IPSec should be allowed with user-consent in web-bro= wser and don't argue that all web user in the world are dumb. In case t= he usecase is missing for RTP-IPSec as Randell mentioned, let us discuss in= IETF-83 RTCWeb meeting.

Thanks
Partha

--047d7b10cde3f052bd04bba370f9-- From HKaplan@acmepacket.com Mon Mar 19 20:20:50 2012 Return-Path: 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 E8AE821F8829 for ; Mon, 19 Mar 2012 20:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] 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 ueus+xJd6eGP for ; Mon, 19 Mar 2012 20:20:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2124021F8826 for ; Mon, 19 Mar 2012 20:20:49 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 19 Mar 2012 23:20:48 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.166]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Mon, 19 Mar 2012 23:20:47 -0400 From: Hadriel Kaplan To: "Ravindran, Parthasarathi" Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHNBkhwRk3x+jQ7ZUSzaNmeu+7o6g== Date: Tue, 20 Mar 2012 03:20:46 +0000 Message-ID: <2E10EB15-7E2E-47B9-80D1-5244DDE5FDF7@acmepacket.com> References: <4F4759DC.7060303@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com><6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com><6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FFE23@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFE23@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 03:20:51 -0000 And, it should be noted, they *want* it that way. They don't generally wan= t you to know which agent picked up the call, or that the call got transfer= red from an IVR to a specific agent, or got put in a queue with elevator-mu= sic announcement server, or any of that. You "called" Travel Co., and they= answered. What goes on behind that SBC is equivalent to the back-end data= base stuff that goes on between the web server and back-end systems, while = all you see is the web-server your browser happens to be connected to. =20 The "identity" you'll get is www.travel.co, which you already had when your= browser did HTTPS cert verification of their web-server. HTTPS became the= key-exchange transport for the SRTP key. Since they already proved they o= wn the cert for www.travel.co, having them claim to be www.travel.co should= n't require yet more verification. -hadriel On Mar 19, 2012, at 9:15 PM, Ravindran, Parthasarathi wrote: > Jim, >=20 > As a customer, you won't really know whether the identity (DTLS-SRTP) of = call center/travel site is agent or SBC. SBC can perform MITM attack easily= as extending SDES-SRTP to DTLS-SRTP for call center site is feasible. >=20 > Thanks > Partha From pravindran@sonusnet.com Tue Mar 20 01:52:21 2012 Return-Path: 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 E660321F8841 for ; Tue, 20 Mar 2012 01:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 rSJ0y2w9KnDl for ; Tue, 20 Mar 2012 01:52:21 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECF321F883E for ; Tue, 20 Mar 2012 01:52:20 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKT2hFRNBvnL4U61lD7LgEs7hP9bn+/nHn@postini.com; Tue, 20 Mar 2012 01:52:20 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 20 Mar 2012 04:52:33 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 14:22:14 +0530 From: "Ravindran, Parthasarathi" To: Bernard Aboba , "ibc@aliax.net" Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHM8te6ZBG/XYsMg0C4SE+GOqsWNpZtZpyg///nIgCAAAs3AIAASYaAgADU1wCAAESDgIAB8AUAgAAelICAAH0pgIAAChuAgABm2RA= Date: Tue, 20 Mar 2012 08:52:13 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E2000F9@inba-mail01.sonusnet.com> References: <4F4759DC.7060303@ericsson.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com>, , , , , , , <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.61] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E2000F9inbamail01sonus_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 08:52:22 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E2000F9inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, In case you expect SRTP-DTLS implementation will be prevalent during RTCWeb= specification publication, I seriously doubt it. Thanks Partha From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Bernard Aboba Sent: Monday, March 19, 2012 5:44 PM To: ibc@aliax.net Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris > Which ones? I just see one: interoperability with legacy SIP devices. [BA] Agreed. And as we've already seen, SDES/SRTP support is prevalent eno= ugh among legacy devices that the legacy use case does not require RTP. > Even if you use an VPN for your enterprise WebRTC application there is NO= problem at all in using SRTP > over the VPN. [BA] And in fact, this is exactly the NSA "Secure VoIP" architecture (with = SDES/SRTP, by the way). > I can make business with my legacy and not secure SIP devices, > those that don't implement SRTP regardless SRTP was designed for SIP". [BA] At this point, support for SRTP is an expected feature on legacy equip= ment. For example, all the leading PSTN gateway vendors support SRTP already. By the= time RTCWEB specs are final, SRTP support will be very prevalent. --_000_387F9047F55E8C42850AD6B3A7A03C6C0E2000F9inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernard,

 <= /p>

In case you expect SRTP-D= TLS implementation will be prevalent during RTCWeb specification publicatio= n, I seriously doubt it.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Monday, March 19, 2012 5:44 PM
To: ibc@aliax.net
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris

 

> Which ones? I just see one: interop= erability with legacy SIP devices.

[BA] Agreed.  And as we've already seen, SDES/SRTP support is prevalen= t enough among legacy devices that the legacy use case does not require RTP= .

> Even if you use an VPN for your enterprise WebRTC application there is= NO problem at all in using SRTP

> over= the VPN.

[BA] And in fact, this is exactly the NSA "Secure VoIP" architect= ure (with SDES/SRTP, by the way).

> I can make business with my legacy and not secure SIP devices,
> those that don't implement SRTP regardless SRTP was designed for SIP&q= uot;.

[BA] At this point, support for SRTP is an expected feature on legacy equip= ment.  For
example, all the leading PSTN gateway vendors support SRTP already.  B= y the time
RTCWEB specs are final, SRTP support will be very prevalent.








--_000_387F9047F55E8C42850AD6B3A7A03C6C0E2000F9inbamail01sonus_-- From salvatore.loreto@ericsson.com Tue Mar 20 01:55:42 2012 Return-Path: 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 A67AB21F8715 for ; Tue, 20 Mar 2012 01:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.007 X-Spam-Level: X-Spam-Status: No, score=-110.007 tagged_above=-999 required=5 tests=[AWL=0.592, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 VTKRYinuRkBj for ; Tue, 20 Mar 2012 01:55:42 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B8AFA21F870A for ; Tue, 20 Mar 2012 01:55:41 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-43-4f68460c34c5 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 81.FC.27041.C06486F4; Tue, 20 Mar 2012 09:55:40 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Tue, 20 Mar 2012 09:55:40 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 324092320 for ; Tue, 20 Mar 2012 10:55:40 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3AB4B52635 for ; Tue, 20 Mar 2012 10:55:40 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C0D585260E for ; Tue, 20 Mar 2012 10:55:39 +0200 (EET) Message-ID: <4F68460B.8060200@ericsson.com> Date: Tue, 20 Mar 2012 09:55:39 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] ICE and draft-ietf-mmusic-sctp-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 08:55:43 -0000 Hi Cullen, On 3/19/12 3:00 PM, Cullen Jennings wrote: > I like draft-ietf-mmusic-sctp-sdp but I'd like to see it have more stuff in it. Specifically I would like it to > > 1) clearly define how to do the SDP for use of SCTP over DTLS over UPD with ICE. This is the use case we need to solve right, in Quebec we decided not to specify the ICE usage for *plain* SCTP in this draft... but for sure we have to define the usage of SCTP over DTLS with ICE in the draft > > 2) make sure it works with bundle +1 > > 3) SCTP has sub addresses (SCTP Channels), I think these need to be negotiated as well in some cases so I would like to see an optional way of negotiating and signaling the channels including correlation with some sort of application defined label yep, we can define a way to signal/negotiate the number of channels we want initially in the association vs having this number configured; and eventually even go further e.g. negotiate the addition of channels, and perhaps some sort of correlation of a channel with an application defined label Salvatore -- Salvatore Loreto, PhD www.sloreto.com From andrew.hutton@siemens-enterprise.com Tue Mar 20 03:06:55 2012 Return-Path: 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 C191721F85D4 for ; Tue, 20 Mar 2012 03:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] 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 fxNwP46QNGCW for ; Tue, 20 Mar 2012 03:06:54 -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 63E8621F85CE for ; Tue, 20 Mar 2012 03:06:54 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id F16AF1EB8463; Tue, 20 Mar 2012 11:06:52 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 20 Mar 2012 11:06:53 +0100 From: "Hutton, Andrew" To: Hadriel Kaplan , "Ravindran, Parthasarathi" Date: Tue, 20 Mar 2012 11:06:51 +0100 Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHNBkhwRk3x+jQ7ZUSzaNmeu+7o6pZy7hYg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296AE222A@MCHP058A.global-ad.net> References: <4F4759DC.7060303@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com><6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com><6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FFE23@inba-mail01.sonusnet.com> <2E10EB15-7E2E-47B9-80D1-5244DDE5FDF7@acmepacket.com> In-Reply-To: <2E10EB15-7E2E-47B9-80D1-5244DDE5FDF7@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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 10:06:55 -0000 Hi, Completely agree with Hadriel's statement below. In addition to wanting to know that you are connected to "www.travel.co" or= "www.mybank.co" you as a consumer and the company really want/need the med= ia to be recorded by the companies system for your own protection. This is = going to involve some kind of MITM or as we call it in SIPREC a Session Rec= ording Client (SRC) to be able to intercept the media and route it to a Ses= sion Recording Server (SRS).=20 The agent's desktop device could act as the SRC but more likely it will be = some kind of B2BUA that does this. =20 In these scenario's you as a consumer using this service really want the me= dia to be secure at least as far as reaching the bank but after that like a= ny existing web based system you have to trust the bank with your data this= is no different whether that data is speech or text that you entered on a = web page. The recording system should be able to work with DTLS-SRTP but it will most= likely act as a MITM so will change the DTLS fingerprint. I don't see that= as a problem. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: 20 March 2012 03:21 > To: Ravindran, Parthasarathi > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris >=20 >=20 > And, it should be noted, they *want* it that way. They don't generally > want you to know which agent picked up the call, or that the call got > transferred from an IVR to a specific agent, or got put in a queue with > elevator-music announcement server, or any of that. You "called" > Travel Co., and they answered. What goes on behind that SBC is > equivalent to the back-end database stuff that goes on between the web > server and back-end systems, while all you see is the web-server your > browser happens to be connected to. >=20 > The "identity" you'll get is www.travel.co, which you already had when > your browser did HTTPS cert verification of their web-server. HTTPS > became the key-exchange transport for the SRTP key. Since they already > proved they own the cert for www.travel.co, having them claim to be > www.travel.co shouldn't require yet more verification. >=20 > -hadriel >=20 >=20 > On Mar 19, 2012, at 9:15 PM, Ravindran, Parthasarathi wrote: >=20 > > Jim, > > > > As a customer, you won't really know whether the identity (DTLS-SRTP) > of call center/travel site is agent or SBC. SBC can perform MITM attack > easily as extending SDES-SRTP to DTLS-SRTP for call center site is > feasible. > > > > Thanks > > Partha >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Tue Mar 20 03:19:44 2012 Return-Path: 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 D8DCE21F8650 for ; Tue, 20 Mar 2012 03:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 dISqmX7V5hmw for ; Tue, 20 Mar 2012 03:19:44 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0B421F8611 for ; Tue, 20 Mar 2012 03:19:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 48FFD39E132; Tue, 20 Mar 2012 11:19:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrqctEtRy-q1; Tue, 20 Mar 2012 11:19:42 +0100 (CET) Received: from [78.65.120.97] (host-78-65-120-97.homerun.telia.com [78.65.120.97]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id F404839E0E7; Tue, 20 Mar 2012 11:19:39 +0100 (CET) Message-ID: <4F6859B5.8060603@alvestrand.no> Date: Tue, 20 Mar 2012 11:19:33 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "Ravindran, Parthasarathi" References: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFDFE@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFDFE@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCP consent approach comment X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 10:19:45 -0000 On 03/20/2012 02:06 AM, Ravindran, Parthasarathi wrote: > Eric, > > Sec 4.2.3 mentions about RTCP consent approach is not adopted for > > 1) Small window attack of RTP > 2) Tough for legacy non-RTCP endpoint to implement RTCP > > I think that small window attack of RTP is possible in ICE as well in case attacker has access to offer SDP and the second reason is funny to recommend non-RTCP endpoint to implement ICE instead of implementing RTCP because this reason is equivalent of asking the person to buy cake who is struggling to buy bread. > > The missing information is that NAT traversal is not possible using RTCP mechanism. Could you please add "NAT traversal" as the one of the reason for not adopting RTCP consent approach. Ravindran, the section already limits itself to "... cases where the legacy endpoint has a public address...." - in those cases, NAT traversal is not necessary, so I don't believe your comment applies. Can you explain why you see a window of attack in the ICE case? I don't understand that comment. > Thanks > Partha > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Tue Mar 20 03:30:51 2012 Return-Path: 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 C569B21F8694 for ; Tue, 20 Mar 2012 03:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Xps5Jt6ZSlpa for ; Tue, 20 Mar 2012 03:30:51 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2D59E21F866B for ; Tue, 20 Mar 2012 03:30:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6567839E132; Tue, 20 Mar 2012 11:30:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgYBOXq5NgNr; Tue, 20 Mar 2012 11:30:35 +0100 (CET) Received: from [78.65.120.97] (host-78-65-120-97.homerun.telia.com [78.65.120.97]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 89A2F39E0E7; Tue, 20 Mar 2012 11:30:35 +0100 (CET) Message-ID: <4F685C45.5080106@alvestrand.no> Date: Tue, 20 Mar 2012 11:30:29 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDES vs DTLS-SRTP revisited X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 10:30:51 -0000 On 03/17/2012 04:35 AM, Hadriel Kaplan wrote: > On Mar 16, 2012, at 6:32 PM, Eric Rescorla wrote: >> Yes, I think the fingerprint mismatch in case 1 serves as a stronger indication >> that something was wrong, because there is no technical reason for the >> fingerprint not to match if both sides believe they are doing DTLS. I.e., >> it always indicates either a software defect or a man in the middle. >> And the suspicious user of course should hang up, but they should also >> post pictures to /., which, I would think, serves >> as a pretty significant deterrent to providers tampering with people's calls! >> By contrast, with SDES, the attack scenario and the legitimate scenario >> look the same. > I don't think you can jump to the conclusion that there's either a software defect or a MitM. Imagine if WebRTC user Alice calls Bob through provider-A, using Bob's telephone number. Provider-A supports DTLS-SRTP on its PSTN gateway, so it handles that and generates a call into the PSTN for Bob, who happens to use Provider-B. Bob is currently on a WebRTC client connected to Provider-B, and Provider-B happens to also support DTLS-SRTP on its PSTN gateway. So both Alice and Bob see "DTLS-SRTP", but different fingerprints. It's not a software defect. You could argue it's a MitM (the PSTN gateways doing what they do), and certainly there may *be* someone recording the call in the middle for all you know - but you really don't know either way. Alice dialed Bob, and got the best case scenario given the situation. I don't get this scenario. If Alice calls Bob using two different gateways, won't she go through a credentials and fingerprint exchange with the gateways? In that case, wouldn't the fingerprint belong to the gateway? > The good news is the media is secure from the browsers to the PSTN, which is not an insignificant accomplishment. If we're worried about WiFi - and I am, for at least marketing/perception reasons if nothing else - then we've alleviated that concern. > > So then there's slashdot. If Alice or Bob posts to slashdot, it's bad news. But we can hardly blame Provider-A or Provider-B, since they had no alternative. It wouldn't be the first time someone posted a story on slashdot that got the facts wrong... > Ironically, if WebRTC supported SDES, then Provider-A and B could do that instead, and make it clear/explicit no end-to-end guarantee can be made for the call - while *still* avoiding the main concern, which is the WiFi problem. In some sense *we*, the IETF/W3C, would be more honest if we allowed SDES (over HTTPS) for gateway cases, since that's actually the level of security being provided. Mandating DTLS-SRTP provides a false sense of security, and false sense of insecurity if it fails. > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Tue Mar 20 03:41:37 2012 Return-Path: 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 DAB9721F8658 for ; Tue, 20 Mar 2012 03:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 ZsSuTp7RBKNr for ; Tue, 20 Mar 2012 03:41:37 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3112821F8627 for ; Tue, 20 Mar 2012 03:41:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6FBA139E132; Tue, 20 Mar 2012 11:41:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qex7KxaIuecK; Tue, 20 Mar 2012 11:41:35 +0100 (CET) Received: from [78.65.120.97] (host-78-65-120-97.homerun.telia.com [78.65.120.97]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CFCEF39E0E7; Tue, 20 Mar 2012 11:41:35 +0100 (CET) Message-ID: <4F685ED9.2050109@alvestrand.no> Date: Tue, 20 Mar 2012 11:41:29 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> In-Reply-To: <4F64FE98.3070605@alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------020905000402050109040802" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 10:41:38 -0000 This is a multi-part message in MIME format. --------------020905000402050109040802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/17/2012 10:14 PM, Igor Faynberg wrote: > .. > > On 3/17/2012 4:45 PM, Martin Thomson wrote: >> ... Then I explicitly place a trust anchor for that >> certificate in your browser. > > How? I thought the browser would never allow that to happen. (I > assumed it would come provisioned with anchors, or would allow anchor > provision through some different channel.) > Igor, in Chrome, go to chrome://settings/certificates, choose the "authorities" tab, and note the presence of the "import" button. All browsers (as far as I know) have similar mechanisms. "Owning" your computer will achieve this goal both in its corporate meaning and in its hacker meaning. --------------020905000402050109040802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/17/2012 10:14 PM, Igor Faynberg wrote:
..

On 3/17/2012 4:45 PM, Martin Thomson wrote:
... Then I explicitly place a trust anchor for that
certificate in your browser.

How?  I thought the browser would never allow that to happen. (I assumed it would come provisioned with anchors,  or would allow anchor provision through some different channel.)

Igor,

in Chrome, go to chrome://settings/certificates, choose the "authorities" tab, and note the presence of the "import" button.

All browsers (as far as I know) have similar mechanisms.
"Owning" your computer will achieve this goal both in its corporate meaning and in its hacker meaning.


--------------020905000402050109040802-- From harald@alvestrand.no Tue Mar 20 03:53:00 2012 Return-Path: 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 EFA6021F86E3 for ; Tue, 20 Mar 2012 03:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 XMxWOWMKzXPc for ; Tue, 20 Mar 2012 03:53:00 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B56E721F86E1 for ; Tue, 20 Mar 2012 03:52:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BC75139E132; Tue, 20 Mar 2012 11:52:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpLNm5LMIM+4; Tue, 20 Mar 2012 11:52:57 +0100 (CET) Received: from [78.65.120.97] (host-78-65-120-97.homerun.telia.com [78.65.120.97]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C58AA39E0E7; Tue, 20 Mar 2012 11:52:57 +0100 (CET) Message-ID: <4F686183.6040201@alvestrand.no> Date: Tue, 20 Mar 2012 11:52:51 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <4F4759DC.7060303@ericsson.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4F677F3B.3040407@alcatel-lucent.com> In-Reply-To: <4F677F3B.3040407@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: [rtcweb] Telling the user the connection is secure (Re: Resolving RTP/SDES question in Paris) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 10:53:01 -0000 I believe I have said this before, but... We should never tell the user the connection is secure. We should tell the user when we know he's exposed to risks that he usually isn't. Thus - we should not give any indication that we're using DTLS-SRTP with verified identities (if that's what we normally support). We SHOULD give a warning saying "hey, since the gateway you've connected to isn't doing normal authentication procedures, but instead insists on exchanging keys on the signalling channel, you are less sure who you're talking to than usual, and there are more boxes that might record your call in the way, but the script kiddie on your hotel WLAN still can't see your packets (translation: legacy SDES key exchange is in use, but SRTP is still on). All this will of course be iconified into a single cryptic graphic probably involving a padlock :-) On 03/19/2012 07:47 PM, Igor Faynberg wrote: > This is the question that I have been asking for a while... I don't > expect a complete fireproof answer, of course, and I also understand > that the browser today is telling me a few things about the security > of a site and warns me when "the site is trying to access the data it > should not be accessing." > > But I also imagine that a rogue site could display a message > mimicking the security assurance as though it comes from the browser. > > So it would be good to have a very clear idea when the determination > about the security of the connection and such is made and how the end > user can verify that it actually comes from the browser. > > (To this end, the user MUST trust the browser, of course.) > > Igor > > On 3/19/2012 2:15 PM, Roman Shpount wrote: >> I guess my question is, when are we going to tell the user that >> connection is "secure"?... > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From stefan.lk.hakansson@ericsson.com Tue Mar 20 03:58:31 2012 Return-Path: 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 1511A21F8656 for ; Tue, 20 Mar 2012 03:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.829 X-Spam-Level: X-Spam-Status: No, score=-9.829 tagged_above=-999 required=5 tests=[AWL=0.770, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 YYpuIf6nYwcu for ; Tue, 20 Mar 2012 03:58:30 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 25BBF21F8650 for ; Tue, 20 Mar 2012 03:58:29 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-57-4f6862d52fc4 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.B5.17856.5D2686F4; Tue, 20 Mar 2012 11:58:29 +0100 (CET) Received: from [150.132.142.245] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Tue, 20 Mar 2012 11:58:28 +0100 Message-ID: <4F6862D4.7040407@ericsson.com> Date: Tue, 20 Mar 2012 11:58:28 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Avasarala, Ranjit" References: <1F2A2C70609D9E41844A2126145FC09804BC4CE1F2@HKGMBOXPRD22.polycom.com> In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804BC4CE1F2@HKGMBOXPRD22.polycom.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "Banerjee, Atin" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Use-case document - additional recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 10:58:31 -0000 Hi Ranjit, recording was discussed at length last fall (and is to some extent captured in the document) without really concluding. This fact, and the fact that there was really no support for your proposal makes me think we should not add this use-case (at least not now). Br, Stefan On 03/07/2012 07:07 AM, Avasarala, Ranjit wrote: > Hi Stefan > > Could we add a use case related to session recording? The use case would be > > 4.2. x Simple Video Recording Service > > 4.2. x.1 Description > > The user who has joined a video communication service wants to record the communication data from the web browser. > > 4.2.x.1.1 Derived requirements > > TBD > > I also feel there is a need for a API requirement - the Web API should provide a means to record the incoming media - both audio& video or audio only or video only > > Regards > Ranjit > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK > Sent: Tuesday, March 06, 2012 2:59 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Use-case document > > Hi! > > The Use-case document > () > will expire in early April. > > The editors propose to add a new use-case when updating to -07. The new use-case is about large sessions and is inspired by input made earlier by Arno Bakker > (http://www.ietf.org/mail-archive/web/rtcweb/current/msg00530.html) and recently by Harald Alvestrand (http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0066.html). > > Proposed text for the new use-case: > > On-line lecture > =============== > > A lecture is given on-line by a very popular lecturer. The attendance is very large. Because of this it is not really feasible to have direct audiovisual feedback (for e.g. questions) for every participant, instead participants can request the floor by clicking a button, and gets a signal when audio and video has been set up (and the lecturer is ready to take the question). The question is heard by all participants (not only the lecturer). > > Participants can join and leave the lecture at any time (i.e. they do not need to be there at the start to be able to connect). > > The service is operated by the university of the lecturer. It is set up such that all participants connect to a central node. The university can not invest much in HW, so the processing required (per participant) must be minimized. > > > New requirement: > > - It must be possible to set up media streams and encryption in such a way that processing in a central node is minimized (no transcoding required, no decryption/re-encryption for every outgoing flow - just simple forwarding). > > > Let us know what you think. If there is support we will add this use-case, if not we will just make a new revision of the document (with no major changes to the content). > > Stefan for the editors > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Tue Mar 20 03:59:52 2012 Return-Path: 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 3AA2221F85F9 for ; Tue, 20 Mar 2012 03:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.872 X-Spam-Level: X-Spam-Status: No, score=-9.872 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Wxr41YO71Y7i for ; Tue, 20 Mar 2012 03:59:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 341D621F85F8 for ; Tue, 20 Mar 2012 03:59:51 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-f2-4f68632616d9 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5D.1B.27041.623686F4; Tue, 20 Mar 2012 11:59:50 +0100 (CET) Received: from [150.132.142.245] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Tue, 20 Mar 2012 11:59:49 +0100 Message-ID: <4F686325.2000007@ericsson.com> Date: Tue, 20 Mar 2012 11:59:49 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F55D8BF.1040703@ericsson.com> <4F58CC75.7080803@ericsson.com> In-Reply-To: <4F58CC75.7080803@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Use-case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 10:59:52 -0000 On 03/08/2012 04:12 PM, Stefan Hakansson LK wrote: > On 03/06/2012 02:01 PM, Eric Rescorla wrote: >> Obviously, this is an interesting use case, but it's not clear to me that >> it's something you would want to address entirely via WebRTC >> >> 1. It seems likely that the lecturer will be using something >> rather more sophisticated than a Web browser in many cases >> (often these lecturers are actually joint on-line and in-person >> so you need microphone control in the room as well; see for >> instance the popular Sandel Justice lecturers out of Harvard). >> >> 2. You also probably want to actually support not just real-time >> viewing but also podcasting, time-shifting, etc., as well as >> support for people who don't have WebRTC. >> >> When you put these together, it might well be natural to have >> a one-way stream via Flash, HTML5 video, etc., and then individual >> WebRTC uplinks which get mixed into that single stream as necessary. >> That makes questions about transcoding, re-encryption, etc. a lot >> simpler. > > I agree to that the use-case proposed was perhaps not that well selected > for the reasons you give above. > > What we were really after was to enable multi-party with really low cost > for the central node (given that you're not doing a mesh). If you have > to decrypt, alter RTP parameters, and then re-encrypt you quickly get > into a situation where the central node needs a lot of processing power. > > If the packets simply can be forwarded you're much better off - and this > is what we wanted to capture. It is also a way to in the use-case and > requirement document reflect a bit of what JSEP enables; if the > application can *set* certain parts of the media settings used by the > browser, the app can set it up such that central node would not have to > alter anything - just forward. We thought it would be nice to have a > JSEP related req in the document! > > Stefan I hear no support for this, and will not add it to the use-case document at this stage. Stefan > >> >> -Ekr >> >> >> On Tue, Mar 6, 2012 at 1:28 AM, Stefan Hakansson LK >> wrote: >>> Hi! >>> >>> The Use-case document >>> () >>> will expire in early April. >>> >>> The editors propose to add a new use-case when updating to -07. The new >>> use-case is about large sessions and is inspired by input made earlier >>> by Arno Bakker >>> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg00530.html) and >>> recently by Harald Alvestrand >>> (http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0066.html). >>> >>> Proposed text for the new use-case: >>> >>> On-line lecture >>> =============== >>> >>> A lecture is given on-line by a very popular lecturer. The attendance is >>> very large. Because of this it is not really feasible to have >>> direct audiovisual feedback (for e.g. questions) for every participant, >>> instead participants can request the floor by clicking a button, and >>> gets a signal when audio and video has been set up (and the lecturer is >>> ready to take the question). The question is heard by all participants >>> (not only the lecturer). >>> >>> Participants can join and leave the lecture at any time (i.e. they do >>> not need to be there at the start to be able to connect). >>> >>> The service is operated by the university of the lecturer. It is set up such >>> that all participants connect to a central node. The university can not >>> invest much in HW, so the processing required (per participant) must be >>> minimized. >>> >>> >>> New requirement: >>> >>> - It must be possible to set up media streams and encryption in such a >>> way that processing in a central node is minimized (no transcoding >>> required, no decryption/re-encryption for every outgoing flow - just >>> simple forwarding). >>> >>> >>> Let us know what you think. If there is support we will add this use-case, >>> if not we will just make a new revision of the document (with no major >>> changes to the content). >>> >>> Stefan for the editors >>> _______________________________________________ >>> 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 From bernard_aboba@hotmail.com Tue Mar 20 04:03:19 2012 Return-Path: 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 6046D21F865F for ; Tue, 20 Mar 2012 04:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.129 X-Spam-Level: X-Spam-Status: No, score=-102.129 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 V-Pb8UYSDs9e for ; Tue, 20 Mar 2012 04:03:18 -0700 (PDT) Received: from blu0-omc2-s30.blu0.hotmail.com (blu0-omc2-s30.blu0.hotmail.com [65.55.111.105]) by ietfa.amsl.com (Postfix) with ESMTP id BF5C221F8622 for ; Tue, 20 Mar 2012 04:03:18 -0700 (PDT) Received: from BLU169-W14 ([65.55.111.71]) by blu0-omc2-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 04:03:17 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_190eeef6-b397-46e1-9cf2-2cdbb7645224_" X-Originating-IP: [99.32.177.175] From: Bernard Aboba To: Date: Tue, 20 Mar 2012 04:03:17 -0700 Importance: Normal In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31296AE222A@MCHP058A.global-ad.net> References: <4F4759DC.7060303@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com><6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com><6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>, , , <387F9047F55E8C42850AD6B3A7A03C6C0E1FFE23@inba-mail01.sonusnet.com>, <2E10EB15-7E2E-47B9-80D1-5244DDE5FDF7@acmepacket.com>, <101C6067BEC68246B0C3F6843BCCC1E31296AE222A@MCHP058A.global-ad.net> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Mar 2012 11:03:17.0919 (UTC) FILETIME=[0E0642F0:01CD0689] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 11:03:19 -0000 --_190eeef6-b397-46e1-9cf2-2cdbb7645224_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Any said:=20 > The recording system should be able to work with DTLS-SRTP but it will mo= st likely act as a MITM so will change the DTLS fingerprint. I don't see th= at as a problem. [BA] One of the questions I have had about the usage of DTLS-SRTP contempla= ted in RTCWEB is whether it will be interoperable with the SIP usage of DTL= S-SRTP. =20 In the SIP framework it is possible to do RFC 4474 re-signing in the B2BUA = if the destination is an E.164 number.=20 However=2C the DTLS-SRTP/IdP framework seems to assume that the identities = are email-style addresses. =20 = --_190eeef6-b397-46e1-9cf2-2cdbb7645224_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Any said:

>=3B The recording system should be able to work w= ith DTLS-SRTP but it will most likely act as a MITM so will change the DTLS= fingerprint. I don't see that as a problem.

[BA] One of the questio= ns I have had about the usage of DTLS-SRTP contemplated in RTCWEB is whethe= r it will be interoperable with the SIP usage of DTLS-SRTP. =3B
In the SIP framework it is possible to do RFC 4474 re-signing in the B2BUA= if the destination is an E.164 number.

However=2C the DTLS-SRTP/Id= P framework seems to assume that the identities are email-style addresses.&= nbsp=3B


= --_190eeef6-b397-46e1-9cf2-2cdbb7645224_-- From ibc@aliax.net Tue Mar 20 04:20:33 2012 Return-Path: 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 8B86921F8655 for ; Tue, 20 Mar 2012 04:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 YfQ1SUxvSHvm for ; Tue, 20 Mar 2012 04:20:32 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E29B321F860F for ; Tue, 20 Mar 2012 04:20:31 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so8761852vcb.31 for ; Tue, 20 Mar 2012 04:20:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=zye9UXJvN1NEsFVji1/ud1O3oOEWPx0tARwGmKqyR0g=; b=ZHm0mfjS97nIsPPa8hATzm45m2XaRSfI3xNbUt0drytgDMNVTlYbw9tXwu6+ZBCDGd vNh9vu2DkVLFsQlpuRLlTpAhGPZqBeYGsycFot6xXQ1n7X102lUs29VPoO5p0IWc1krz MumCuwxqxowGERj8P0/eFk2KKWhP65puT4jxP/0Cl6azSsC1DASG4+ZOpovBBhGy4zOF 0Gnp4KavGBlUJVu5scmUYD3kjCeSa5X/h7BgcB4Bn/iINjUywa39CUnz958C7em+b9Em VGyCpxWJaXj7IPcd1xTcQrfFB40A9ZKZjr4rZB3V1nx2S/IO9oi8RSDYGaihJGsgGf0N YxNQ== Received: by 10.220.152.205 with SMTP id h13mr7108554vcw.12.1332242431304; Tue, 20 Mar 2012 04:20:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 20 Mar 2012 04:20:10 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 20 Mar 2012 12:20:10 +0100 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmKf8NMzEjGwhxC5DpTOLShCpJxTPaTPYZNcu0mZLOu58tKvzrIhBhz/Yd9MI/wj7WqLFoF Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 11:20:33 -0000 2012/3/20 Roman Shpount : > I would also like to have a simplified DTLS specification for DTLS-SRTP, > with as many as possible unnecessary features (encryption algorithms, > cookies and such) removed and only a few required scenarios supported. Fo= r > instance, I do not want DTLS on a WebRTC channel start negotiation and en= d > up with anything except SRTP as an encryption protocol. Ideally, I want > something were an interop test can be developed with a manageable number = of > scenarios. > > P.S. Sending RSA public key in the session description instead of > fingerprint and then encrypting the SRTP key using this public key and > sending it in the ICE message might be a much simpler call setup mechanis= m > to implement then bringing the whole DTLS into the stack. This should als= o > allow us to setup a secure call with no overhead in addition to ICE. Would this DTLS-SRTP simplification interoperate with other technologies also implementing DTLS-SRTP+SDP? AFAIK there are (not yet) SIP devices supporting DTLS-SRTP (maybe I'm wrong), however my question is: once there are SIP implementations (or Jingle ones implementing DTLS-SRTP) would those implementations interoperate with your simplified version of DTLS for WebRTC? Regards. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Tue Mar 20 06:40:40 2012 Return-Path: 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 E52F221F871A for ; Tue, 20 Mar 2012 06:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.769 X-Spam-Level: X-Spam-Status: No, score=-2.769 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 SK9dZAhtv72j for ; Tue, 20 Mar 2012 06:40:40 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 23B7C21F8643 for ; Tue, 20 Mar 2012 06:40:40 -0700 (PDT) Received: by dakl33 with SMTP id l33so43983dak.31 for ; Tue, 20 Mar 2012 06:40:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=o+71R0qa0pr+3AAGr3dbDCtdjImTsHyKpLAmHBPtxw4=; b=I9i0hCnWkL38LMxW3J6/1nbaQg2hoyugsPDHDXNoVv2dckgo5E0F6aJbYyisoC/35g fQMrfh2CbV5q7oXHTuKajX4T9gPcN5BtbnEOmNUiG9f7VkrXSjdkf7DJnV/tvzJHquXv oN5vlH4slxa1M3LqdIMV2D8N9rVB3SvWRne3cXwskyaJ+9k4RTXo0+sfhN0ts/li+dwG 2hlaAjTgDMlMXkN/400k+051l/3XGnvYBx1HwXy+xjVUXiC6rr5oftZ415gb8YtThzyH 2/jwrtCgQMGOGNNUm5l5KWJgFaBWRVNdCpK4pOnKvmiBPlPuFOjDkttksK5+gRblLjhu cwoA== Received: by 10.68.136.228 with SMTP id qd4mr1167743pbb.141.1332250839917; Tue, 20 Mar 2012 06:40:39 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id o2sm1334989pbb.45.2012.03.20.06.40.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 06:40:39 -0700 (PDT) Received: by dakl33 with SMTP id l33so43927dak.31 for ; Tue, 20 Mar 2012 06:40:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.40 with SMTP id pp8mr1502217pbb.13.1332250837423; Tue, 20 Mar 2012 06:40:37 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Tue, 20 Mar 2012 06:40:37 -0700 (PDT) In-Reply-To: <4F685ED9.2050109@alvestrand.no> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> Date: Tue, 20 Mar 2012 09:40:37 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7b10d17bea946f04bbacd1bd X-Gm-Message-State: ALoCoQnHumhiXVRBjgOIBF3USNt3ratrTIunyJufIdZlnvHOfExjj2h7gpUe11tEIt+yw4J2MutQ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 13:40:41 -0000 --047d7b10d17bea946f04bbacd1bd Content-Type: text/plain; charset=ISO-8859-1 Once again, I understand how this helps in case of HTTPS, but how would this help in case of WebRTC? Media description is carried in some sort of application defined protocol (can even be transmitted over an encrypted SCTP data channel or encrypted in javaScript), so monitoring proxy cannot reliably modify it. I understand how it can be allowed to fake the signature on modified SDP by inserting a certificate in the browser, but how would the proxy get to the SDP in the first place? _____________ Roman Shpount On Tue, Mar 20, 2012 at 6:41 AM, Harald Alvestrand wrote: > ** > On 03/17/2012 10:14 PM, Igor Faynberg wrote: > > .. > > On 3/17/2012 4:45 PM, Martin Thomson wrote: > > ... Then I explicitly place a trust anchor for that > certificate in your browser. > > > How? I thought the browser would never allow that to happen. (I assumed > it would come provisioned with anchors, or would allow anchor provision > through some different channel.) > > Igor, > > in Chrome, go to chrome://settings/certificates, choose the "authorities" > tab, and note the presence of the "import" button. > > All browsers (as far as I know) have similar mechanisms. > "Owning" your computer will achieve this goal both in its corporate > meaning and in its hacker meaning. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b10d17bea946f04bbacd1bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Once again, I understand how this helps in case of HTTPS, but how would thi= s help in case of WebRTC? Media description is carried in some sort of appl= ication defined protocol (can even be transmitted over an encrypted SCTP da= ta channel or encrypted in javaScript), so monitoring proxy cannot reliably= modify it. I understand how it can be allowed to fake the signature on mod= ified SDP by inserting a certificate in the browser, but how would the prox= y get to the SDP in the first place?
_____________
Roman Shpount


On Tue, Mar 20, 2012 at 6:41 AM, Harald = Alvestrand <ha= rald@alvestrand.no> wrote:
=20 =20 =20
On 03/17/2012 10:14 PM, Igor Faynberg wrote:
..

On 3/17/2012 4:45 PM, Martin Thomson wrote:
... Then I explicitly place a trust anchor for that
certificate in your browser.

How?=A0 I thought the browser would never allow that to happen. (I assumed it would come provisioned with anchors,=A0 or would allow anchor provision through some different channel.)

Igor,

in Chrome, go to chrome://settings/certificates, choose the "authorities" tab, and note the presence of the "impor= t" button.

All browsers (as far as I know) have similar mechanisms.
"Owning" your computer will achieve this goal both in its corporate meaning and in its hacker meaning.



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


--047d7b10d17bea946f04bbacd1bd-- From ibc@aliax.net Tue Mar 20 06:48:54 2012 Return-Path: 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 9419B21F8618 for ; Tue, 20 Mar 2012 06:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 jXmn2mzecVGO for ; Tue, 20 Mar 2012 06:48:54 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0709D21F858F for ; Tue, 20 Mar 2012 06:48:53 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so20748vbb.31 for ; Tue, 20 Mar 2012 06:48:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=P8k04JhPSNAImc2bx2ypLTUUWv6X9LXMQyKGFgc6JT8=; b=lVxLlojRYlXDwxAYj+sx/CGI7qdiWItmPqLUjCiTAPGB5t7kl1GwH8WASi9o8orlPK 6nKRoho9VWrWPPa1nbaL7gi0Lu8XpzMQlS/OuTrE9wNi8dqXNKFHtIEEtBSEMfaq+a1I gidROWw8uNFSd/NHIMtzs0/abECT8ngnnaAipGybwKeE9ExIGRHUXuUgnpUzs+gOyI+X 3iApBjXJEq5VMPuKxhlUcYA6dBkkPgb243QcUvVdVaT8tkJnObxXsgzqhHRKyybJxtRP iCfW+Q/RkIg4cE1Y/KhjyNV9iquVylwW/A6wZ1bRnDW1WFGkbVpnN8kOcThHW8s8Ehxl gUXA== Received: by 10.52.27.1 with SMTP id p1mr7681150vdg.17.1332251333511; Tue, 20 Mar 2012 06:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 20 Mar 2012 06:48:33 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 20 Mar 2012 14:48:33 +0100 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmsoeW2IilKNqCoJIp2ewiZ6iE54FUfCfEiUaGuQSLVxpuKLUXBWtVaZWQU4hI1DXabqD7y Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 13:48:54 -0000 2012/3/20 Roman Shpount : > Once again, I understand how this helps in case of HTTPS, but how would t= his > help in case of WebRTC? Media description is carried in some sort of > application defined protocol (can even be transmitted over an encrypted S= CTP > data channel or encrypted in javaScript), so monitoring proxy cannot > reliably modify it. I understand how it can be allowed to fake the signat= ure > on modified SDP by inserting a certificate in the browser, but how would = the > proxy get to the SDP in the first place? That's up to the implementor, is not? This is: if a WebRTC provider wants to monitor the media by modifying the SDP it should design some system in which the SDP is carried by its systems (i.e. via HTTP(s) or WebSocket). --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Tue Mar 20 06:50:44 2012 Return-Path: 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 A058221F867D for ; Tue, 20 Mar 2012 06:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 U3qr0naeCj8A for ; Tue, 20 Mar 2012 06:50:43 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCD9021F86D9 for ; Tue, 20 Mar 2012 06:50:43 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so118493pbb.31 for ; Tue, 20 Mar 2012 06:50:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=uhf8ZWlnvZQRUnjSBJVkIfV13aLvJEb9D/Tw/FrBM4c=; b=kIJrMgpL0NkJsfBYOutL1VFOWk1Cknbj9dHldCPuWPmaqoLPXcMH4rzQiWu7CdLtd0 Qx/MlaIknPk+DuTVqYww/zC4kRDc+LBxCjBVbxzGlMJw4NdB26Bzt/RlaDXpZhoJptkv J0eziaxc+9beXdezfNu9Q8iWS6MXyGXXM0Yt89KAF2uJDBHQhp8lEHa5lrGzZiMD/LLw wTmh589cyuAC7C2RXxaKzAFB2LHV3OKBeOa3XLJFblX/IS+Tk5x+nNs+9o7z8v5KD4YR QMfKO2E/mQ9BWfLtrFGT1+j7UL2lhaYlS7cvcF57RrfVdBeLgZSNMW0XGT7QJH/JQ5Za scHA== Received: by 10.68.74.197 with SMTP id w5mr1280279pbv.129.1332251441294; Tue, 20 Mar 2012 06:50:41 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id f7sm1370077pbr.3.2012.03.20.06.50.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 06:50:40 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so118456pbb.31 for ; Tue, 20 Mar 2012 06:50:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.230.99 with SMTP id sx3mr1493778pbc.55.1332251439700; Tue, 20 Mar 2012 06:50:39 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Tue, 20 Mar 2012 06:50:39 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Tue, 20 Mar 2012 09:50:39 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b2edf03d09baf04bbacf58b X-Gm-Message-State: ALoCoQkf+HWKIu1/Qw+JOGZvPAKzLjsVCP4zlx5qM6YTGdKTNnYV2Y2PogCWaKV7UnPsLPbTRxfC Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 13:50:44 -0000 --047d7b2edf03d09baf04bbacf58b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 20, 2012 at 7:20 AM, I=F1aki Baz Castillo wrote= : > 2012/3/20 Roman Shpount : > > I would also like to have a simplified DTLS specification for DTLS-SRTP= , > > with as many as possible unnecessary features (encryption algorithms, > > cookies and such) removed and only a few required scenarios supported. > For > > instance, I do not want DTLS on a WebRTC channel start negotiation and > end > > up with anything except SRTP as an encryption protocol. Ideally, I want > > something were an interop test can be developed with a manageable numbe= r > of > > scenarios. > > > > P.S. Sending RSA public key in the session description instead of > > fingerprint and then encrypting the SRTP key using this public key and > > sending it in the ICE message might be a much simpler call setup > mechanism > > to implement then bringing the whole DTLS into the stack. This should > also > > allow us to setup a secure call with no overhead in addition to ICE. > > Would this DTLS-SRTP simplification interoperate with other > technologies also implementing DTLS-SRTP+SDP? > > AFAIK there are (not yet) SIP devices supporting DTLS-SRTP (maybe I'm > wrong), however my question is: once there are SIP implementations (or > Jingle ones implementing DTLS-SRTP) would those implementations > interoperate with your simplified version of DTLS for WebRTC? > > There are actually two different options that I am proposing here. Simplified DTLS-SRTP is just a clarification on what encryption protocols and features are supported. Interop would be no different then interop with DTLS-SRTP implementation which would require certificate validation. If one of the parties request the feature not supported by the other, DTLS handshake fails and connection would not be established. The other proposal was not to use DTLS at all, since it is an overkill both complexity and feature wise. DTLS is designed the way it is primarily to extend TLS to UDP. DTLS-SRTP is a bolt on of SRTP into DTLS. So we actually got a protocol twice reused with design goals changing dramatically in the process. The desired attribute of DTLS-SRTP is that encryption keys are not transmitted in clear text. The rest (security handshake separated from signaling and ICE handshake, support for data encryption schemes other then SRTP, support for certificate validation, etc) is actually just a liability. All of those things imply slower setup and interop problems. So, my second proposal was not to use DTLS at all, just include the public keys for supported key exchange protocols in the SDP and send the encrypted SRTP private key in the ICE message. Or something similar to that. This will definitely not interop with DTLS, but will make implementation of encryption very simple. _____________ Roman Shpount --047d7b2edf03d09baf04bbacf58b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 20, 2012 a= t 7:20 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2012/3/20 Roman Shpount <roman@telu= rix.com>:
> I would also like to have a simplified DTLS specific= ation for DTLS-SRTP,
> with as many as possible unnecessary features (encryption algorithms,<= br> > cookies and such) removed and only a few required scenarios supported.= For
> instance, I do not want DTLS on a WebRTC channel start negotiation and= end
> up with anything except SRTP as an encryption protocol. Ideally, I wan= t
> something were an interop test can be developed with a manageable numb= er of
> scenarios.
>
> P.S. Sending RSA public key in the session description instead of
> fingerprint and then encrypting the SRTP key using this public key and=
> sending it in the ICE message might be a much simpler call setup mecha= nism
> to implement then bringing the whole DTLS into the stack. This should = also
> allow us to setup a secure call with no overhead in addition to ICE.
Would this DTLS-SRTP simplification interoperate with other
technologies also implementing DTLS-SRTP+SDP?

AFAIK there are (not yet) SIP devices supporting DTLS-SRTP (maybe I'm wrong), however my question is: once there are SIP implementations (or
Jingle ones implementing DTLS-SRTP) would those implementations
interoperate with your simplified version of DTLS for WebRTC?


There are actually two different options that I = am proposing here. Simplified DTLS-SRTP is just a clarification on what enc= ryption protocols and features are supported. Interop would be no different= then interop with DTLS-SRTP implementation which would require certificate= validation. If one of the parties request the feature not supported by the= other, DTLS handshake fails and connection would not be established.

The other proposal was not to use DTLS at all, since it is an overkill = both complexity and feature wise. DTLS is designed the way it is primarily = to extend TLS to UDP. DTLS-SRTP is a bolt on of SRTP into DTLS. So we actua= lly got a protocol twice reused with design goals changing dramatically in = the process. The desired attribute of DTLS-SRTP is that encryption keys are= not transmitted in clear text. The rest (security handshake separated from= signaling and ICE handshake, support for data encryption schemes other the= n SRTP, support for certificate validation, etc) is actually just a liabili= ty. All of those things imply slower setup and interop problems. So, my sec= ond proposal was not to use DTLS at all, just include the public keys for s= upported key exchange protocols in the SDP and send the encrypted SRTP priv= ate key in the ICE message. Or something similar to that. This will definit= ely not interop with DTLS, but will make implementation of encryption very = simple.
_____________
Roman Shpount

--047d7b2edf03d09baf04bbacf58b-- From roman@telurix.com Tue Mar 20 06:56:53 2012 Return-Path: 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 D76A421F8720 for ; Tue, 20 Mar 2012 06:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 yNdzwos9xQ3w for ; Tue, 20 Mar 2012 06:56:53 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF6321F8711 for ; Tue, 20 Mar 2012 06:56:53 -0700 (PDT) Received: by dakl33 with SMTP id l33so62452dak.31 for ; Tue, 20 Mar 2012 06:56:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=MTDi5x+SLCnt134fI6DKs3rEB8jYHyUz8jMY9iZFWuc=; b=BaxIbn96hApnJjThGXIwEJsiatEqIzMA296gUcwnxQ7asBR+8OxDEJEHqyd4ThgmQ0 vv98oRofSdQm81fYsrgzD88qFKD17g9nc50fqnIFMY1jsb2We7CwY1MN8qOoBdXXVbwW bG4ltaBDCXL8EbJczBB1xzyL5SvwP2ESdnwN7QrTpkreCgmDuaK/jcN7M93wmHRR9ARB ODtFP0GZBcs5Ci243i53+mlh7KZ+7HNIyJZBlI0rgcrF2W80EFpH32prvYjf5uVSPJnf N2YSYmiuTQrC4IZm6iJuNq8YQuC58dgVzG0VTPmch4OfrdACcze/uxOxgU3jtGUaQjo9 Ef3g== Received: by 10.68.194.227 with SMTP id hz3mr1653613pbc.23.1332251812964; Tue, 20 Mar 2012 06:56:52 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id y2sm1352630pbe.67.2012.03.20.06.56.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 06:56:52 -0700 (PDT) Received: by dakl33 with SMTP id l33so62414dak.31 for ; Tue, 20 Mar 2012 06:56:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.230.99 with SMTP id sx3mr1546665pbc.55.1332251811424; Tue, 20 Mar 2012 06:56:51 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Tue, 20 Mar 2012 06:56:51 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> Date: Tue, 20 Mar 2012 09:56:51 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b2edf03f8a91204bbad0b7d X-Gm-Message-State: ALoCoQlyD9vHV7se/e/Xyl4FJCMLyBMXxqv+TGrNOdn4yeXCeohosDU60zwgO3lMWY0NEvAoVjF4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 13:56:54 -0000 --047d7b2edf03f8a91204bbad0b7d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 20, 2012 at 9:48 AM, I=F1aki Baz Castillo wrote= : > 2012/3/20 Roman Shpount : > > Once again, I understand how this helps in case of HTTPS, but how would > this > > help in case of WebRTC? Media description is carried in some sort of > > application defined protocol (can even be transmitted over an encrypted > SCTP > > data channel or encrypted in javaScript), so monitoring proxy cannot > > reliably modify it. I understand how it can be allowed to fake the > signature > > on modified SDP by inserting a certificate in the browser, but how woul= d > the > > proxy get to the SDP in the first place? > > That's up to the implementor, is not? This is: if a WebRTC provider > wants to monitor the media by modifying the SDP it should design some > system in which the SDP is carried by its systems (i.e. via HTTP(s) or > WebSocket). > > We got one group of people designing browsers, another group of people designing monitoring proxies and the third group designing WebRTC application. For the monitoring proxy to work it would need some sort of network protocol to communicate with the browser (similar how HTTP proxy needs a network protocol to work with the browser). I would expect what's needed is some sort of network based protocol to send the SDP to a proxy, get modified SDP back and pass it to JavaScript (or take the SDP from JavaScript, through the proxy and to the media stack). I do not think this is up to implementer, this is typically what the standards are for. _____________ Roman Shpount --047d7b2edf03f8a91204bbad0b7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Mar 20, 2012 at 9:= 48 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2012/3/20 Roman Shpount <roman@telu= rix.com>:
> Once again, I understand how this helps in case of H= TTPS, but how would this
> help in case of WebRTC? Media description is carried in some sort of > application defined protocol (can even be transmitted over an encrypte= d SCTP
> data channel or encrypted in javaScript), so monitoring proxy cannot > reliably modify it. I understand how it can be allowed to fake the sig= nature
> on modified SDP by inserting a certificate in the browser, but how wou= ld the
> proxy get to the SDP in the first place?

That's up to the implementor, is not? This is: if a WebRTC provid= er
wants to monitor the media by modifying the SDP it should design some
system in which the SDP is carried by its systems (i.e. via HTTP(s) or
WebSocket).


We got one group of people= designing browsers, another group of people designing monitoring proxies a= nd the third group designing WebRTC application. For the monitoring proxy t= o work it would need some sort of network protocol to communicate with the = browser (similar how HTTP proxy needs a network protocol to work with the b= rowser). I would expect what's needed is some sort of network based pro= tocol to send the SDP to a proxy, get modified SDP back and pass it to Java= Script (or take the SDP from JavaScript, through the proxy and to the media= stack). I do not think this is up to implementer, this is typically what t= he standards are for.
_____________
Roman Shpount

--047d7b2edf03f8a91204bbad0b7d-- From roman@telurix.com Tue Mar 20 07:03:49 2012 Return-Path: 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 17B6C21F85AC for ; Tue, 20 Mar 2012 07:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 beEVEtJzqSx9 for ; Tue, 20 Mar 2012 07:03:48 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 404C921F85A5 for ; Tue, 20 Mar 2012 07:03:48 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so124496pbb.31 for ; Tue, 20 Mar 2012 07:03:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=jdtgK0y+0966S0ZmdnAvqk6w1WkGhex0dpycvxx/Ufk=; b=XXnY22B7HDVM0MXhYOfj0ZGBfOKEttbqQKkPD4rzw3Z+Yctv45M1m9C0KW63q73IC/ atZ9DFr1tCiTv8NI3cdfo+U4w+riLu20Rd6uxkvv92LlCG1Tj7FpR4k3gr81I7CI4XtO 8FSJzcK3EXGx2Yozs6YsyvgOa0pZhokWgCHUOL5FPZPqCO99ZobAJG8m7IDPEQjulws0 8pG0t44SMvmEQ25OWi+4tSZ2fy/8alWNMXlGGiUf87PdL4rzVfyKuazwRCbrKZicdtM9 W/2cAO5VrbjfOIQRuJHFv58e/om+yHEaYhpJpuSrqKptjIdAUeU8JgtyRE4QsoQ6CezU AW/Q== Received: by 10.68.191.230 with SMTP id hb6mr1507796pbc.87.1332252228017; Tue, 20 Mar 2012 07:03:48 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id h6sm1373799pbj.44.2012.03.20.07.03.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 07:03:47 -0700 (PDT) Received: by dakl33 with SMTP id l33so70256dak.31 for ; Tue, 20 Mar 2012 07:03:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.191.161 with SMTP id gz1mr1566556pbc.76.1332252226378; Tue, 20 Mar 2012 07:03:46 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Tue, 20 Mar 2012 07:03:46 -0700 (PDT) In-Reply-To: <4F686183.6040201@alvestrand.no> References: <4F4759DC.7060303@ericsson.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4F677F3B.3040407@alcatel-lucent.com> <4F686183.6040201@alvestrand.no> Date: Tue, 20 Mar 2012 10:03:46 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=e89a8ff1c35eb45aa904bbad24f3 X-Gm-Message-State: ALoCoQki9J/7ovmc8j4wI4c2rBjuKx0SomFXyUOWPntktFjOlQ0KJK/4bMPPArSIoynBAct80cV0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Telling the user the connection is secure (Re: Resolving RTP/SDES question in Paris) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 14:03:49 -0000 --e89a8ff1c35eb45aa904bbad24f3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 20, 2012 at 6:52 AM, Harald Alvestrand wrote: > I believe I have said this before, but... > > We should never tell the user the connection is secure. > We should tell the user when we know he's exposed to risks that he usually > isn't. > > Thus - we should not give any indication that we're using DTLS-SRTP with > verified identities (if that's what we normally support). We SHOULD give a > warning saying "hey, since the gateway you've connected to isn't doing > normal authentication procedures, but instead insists on exchanging keys on > the signalling channel, you are less sure who you're talking to than usual, > and there are more boxes that might record your call in the way, but the > script kiddie on your hotel WLAN still can't see your packets (translation: > legacy SDES key exchange is in use, but SRTP is still on). > > All this will of course be iconified into a single cryptic graphic > probably involving a padlock :-) > > What we actually got here has to be iconified into padlocks of different size and degree of openness. In case of DTLS-SRTP with verified identities we still need to inform the user of the indentity of the person they are communicating with. It has to come from the browser, so that it can be presented with some degree of trust. Since we do not trust web server or the javascript app, we should be asking for user consent to get access to microphone and camera for each call anyway. When asking for this consent, we should be either telling the identity of the remote party or give a warning that remote party is unknown. _____________ Roman Shpount --e89a8ff1c35eb45aa904bbad24f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 20, 2012 at 6:52 A= M, Harald Alvestrand <harald@alvestrand.no> wrote:
I believe I have said this before, but...

We should never tell the user the connection is secure.
We should tell the user when we know he's exposed to risks that he usua= lly isn't.

Thus - we should not give any indication that we're using DTLS-SRTP wit= h verified identities (if that's what we normally support). We SHOULD g= ive a warning saying "hey, since the gateway you've connected to i= sn't doing normal authentication procedures, but instead insists on exc= hanging keys on the signalling channel, you are less sure who you're ta= lking to than usual, and there are more boxes that might record your call i= n the way, but the script kiddie on your hotel WLAN still can't see you= r packets (translation: legacy SDES key exchange is in use, but SRTP is sti= ll on).

All this will of course be iconified into a single cryptic graphic probably= involving a padlock :-)


What we actually got here has to be iconified in= to padlocks of different size and degree of openness.

In case of DTL= S-SRTP with verified identities we still need to inform the user of the ind= entity of the person they are communicating with. It has to come from the b= rowser, so that it can be presented with some degree of trust. Since we do = not trust web server or the javascript app, we should be asking for user co= nsent to get access to microphone and camera for each call anyway. When ask= ing for this consent, we should be either telling the identity of the remot= e party or give a warning that remote party is unknown.
_____________
Roman Shpount


--e89a8ff1c35eb45aa904bbad24f3-- From ibc@aliax.net Tue Mar 20 07:16:33 2012 Return-Path: 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 EFEBD21F8702 for ; Tue, 20 Mar 2012 07:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 Y3hQo1AZZsyr for ; Tue, 20 Mar 2012 07:16:32 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0EACE21F8720 for ; Tue, 20 Mar 2012 07:16:31 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so34312vbb.31 for ; Tue, 20 Mar 2012 07:16:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=FuuNtKPmbHX66/3djahVglPM9v/HSVEWpAvAnyX+vX8=; b=M82iqKsP2vOX0yyWMVpIJbelj7480p3mTnlm2++fbaz/JUM9Tx6axkat0H4OaIUoId wB1xqQiYFMP8IIKXeJrOyDIlUKyZ/wpcrmIDOv9d2po7VXhC5zhQcZlLc4Cli62LP4sz R/OAg3iF8yR0J8SLBQ6o/T6lnt0a82pBWN0hH1GC02g+a0aiCA8kK1w3YnDCAjzWIt50 ycNIP7GQw2kyl2I+VtiVO3nxxvz/f980rNpxRqDioqC7g/o7I1B2viHfhwVCiKCNuUeZ tnuoDPplg8yA+zphcSV6+yYiPcUu9Yv9CQtrYyWcGH0W8YO2tp3gXWqQPCo9cBB6xmfw moDg== Received: by 10.220.152.205 with SMTP id h13mr36722vcw.12.1332252991488; Tue, 20 Mar 2012 07:16:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 20 Mar 2012 07:16:11 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 20 Mar 2012 15:16:11 +0100 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkVjc+9S2B8TD/NiuQSOUnTi2zF/MMfj2B6eegB/7K9ztYCQPlJTZ6oHoZ/hY1uLZSBbHDM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 14:16:33 -0000 2012/3/20 Roman Shpount : > The other proposal was not to use DTLS at all, since it is an overkill bo= th > complexity and feature wise. DTLS is designed the way it is primarily to > extend TLS to UDP. DTLS-SRTP is a bolt on of SRTP into DTLS. So we actual= ly > got a protocol twice reused with design goals changing dramatically in th= e > process. The desired attribute of DTLS-SRTP is that encryption keys are n= ot > transmitted in clear text. The rest (security handshake separated from > signaling and ICE handshake, support for data encryption schemes other th= en > SRTP, support for certificate validation, etc) is actually just a liabili= ty. > All of those things imply slower setup and interop problems. So, my secon= d > proposal was not to use DTLS at all, just include the public keys for > supported key exchange protocols in the SDP and send the encrypted SRTP > private key in the ICE message. Or something similar to that. This will > definitely not interop with DTLS, but will make implementation of encrypt= ion > very simple. So that proposal would modify even ICE protocol, am I right? Too much dramatic IMHO :) Ok, given the fact that DTLS is still an utopia (all the people know about it but it seems that nobody has seen it in action), why not to leave it for a future version of WebRTC and go now with SDES + encrypted signaling path? In this way: - We get interoperability with other technologies *already* implementing SDES+SRTP (so ***tested***). - DTLS can be added once it's mature/tested/widely-implemented and we can learn from other implementations (what do they implement, interop problems, bugs...?). - Adding DTLS later to WebRTC does not break nothing since its usage would be still negotiable during the session initiation. Yes, I do know that SDES+SRTP is not the best solution, but I've never seen a scenario in which all the cool and fantastic features of DTLS are required. Given the comments about DTLS in this long thread it seems that choosing DTLS would be a risk (WebRTC would become a DTLS beta-tester...). Regards. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Tue Mar 20 07:24:28 2012 Return-Path: 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 9DB7121F85A1 for ; Tue, 20 Mar 2012 07:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 MCODZZizzaJE for ; Tue, 20 Mar 2012 07:24:28 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8276C21F85A0 for ; Tue, 20 Mar 2012 07:24:27 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKT2iTGusgzGMBhSU7KTcr0bEa/FhtMJXg@postini.com; Tue, 20 Mar 2012 07:24:27 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 20 Mar 2012 10:24:40 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 19:54:22 +0530 From: "Ravindran, Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Roman Shpount Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHM8te6ZBG/XYsMg0C4SE+GOqsWNpZtZpyg///nIgCAAAs3AIAASYaAgADU1wCAAESDgIAB8AUAgAAelICAAH0pgIAAChuAgAAC/YCAADCxgIAADEuAgAAOHICAAAWBgIAAAeoAgAAPeYCAAEVigIAAE6gAgAAMZICAAAtPgIAArYcAgAAqDICAAAcigIAAXZUg Date: Tue, 20 Mar 2012 14:24:21 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E2012AD@inba-mail01.sonusnet.com> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Leon Portman , "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 14:24:28 -0000 QWRkaW5nIG9uZSBhbm90aGVyIGlzc3VlIGZhY2VkIGluIFNSVFAtRFRMUyBpbXBsZW1lbnRhdGlv biAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcHJlYy9jdXJyZW50L21z ZzAzMTk5Lmh0bWwpLg0KDQpJbmNsdWRpbmcgTGVvbiBpbiB0aGlzIG1haWwgdGhyZWFkIGZvciBt b3JlIGluZm8uIA0KDQpUaGFua3MNClBhcnRoYSANCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+RnJvbTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+T2YgScOxYWtpIEJheiBDYXN0aWxsbw0KPlNlbnQ6IFR1 ZXNkYXksIE1hcmNoIDIwLCAyMDEyIDc6NDYgUE0NCj5UbzogUm9tYW4gU2hwb3VudA0KPkNjOiBy dGN3ZWJAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3J0Y3dlYl0gUmVzb2x2aW5nIFJUUC9TREVT IHF1ZXN0aW9uIGluIFBhcmlzDQo+DQo+MjAxMi8zLzIwIFJvbWFuIFNocG91bnQgPHJvbWFuQHRl bHVyaXguY29tPjoNCj4+IFRoZSBvdGhlciBwcm9wb3NhbCB3YXMgbm90IHRvIHVzZSBEVExTIGF0 IGFsbCwgc2luY2UgaXQgaXMgYW4gb3ZlcmtpbGwNCj4+IGJvdGggY29tcGxleGl0eSBhbmQgZmVh dHVyZSB3aXNlLiBEVExTIGlzIGRlc2lnbmVkIHRoZSB3YXkgaXQgaXMNCj4+IHByaW1hcmlseSB0 byBleHRlbmQgVExTIHRvIFVEUC4gRFRMUy1TUlRQIGlzIGEgYm9sdCBvbiBvZiBTUlRQIGludG8N Cj4+IERUTFMuIFNvIHdlIGFjdHVhbGx5IGdvdCBhIHByb3RvY29sIHR3aWNlIHJldXNlZCB3aXRo IGRlc2lnbiBnb2Fscw0KPj4gY2hhbmdpbmcgZHJhbWF0aWNhbGx5IGluIHRoZSBwcm9jZXNzLiBU aGUgZGVzaXJlZCBhdHRyaWJ1dGUgb2YNCj4+IERUTFMtU1JUUCBpcyB0aGF0IGVuY3J5cHRpb24g a2V5cyBhcmUgbm90IHRyYW5zbWl0dGVkIGluIGNsZWFyIHRleHQuDQo+PiBUaGUgcmVzdCAoc2Vj dXJpdHkgaGFuZHNoYWtlIHNlcGFyYXRlZCBmcm9tIHNpZ25hbGluZyBhbmQgSUNFDQo+PiBoYW5k c2hha2UsIHN1cHBvcnQgZm9yIGRhdGEgZW5jcnlwdGlvbiBzY2hlbWVzIG90aGVyIHRoZW4gU1JU UCwNCj5zdXBwb3J0IGZvciBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uLCBldGMpIGlzIGFjdHVhbGx5 IGp1c3QgYSBsaWFiaWxpdHkuDQo+PiBBbGwgb2YgdGhvc2UgdGhpbmdzIGltcGx5IHNsb3dlciBz ZXR1cCBhbmQgaW50ZXJvcCBwcm9ibGVtcy4gU28sIG15DQo+PiBzZWNvbmQgcHJvcG9zYWwgd2Fz IG5vdCB0byB1c2UgRFRMUyBhdCBhbGwsIGp1c3QgaW5jbHVkZSB0aGUgcHVibGljDQo+PiBrZXlz IGZvciBzdXBwb3J0ZWQga2V5IGV4Y2hhbmdlIHByb3RvY29scyBpbiB0aGUgU0RQIGFuZCBzZW5k IHRoZQ0KPj4gZW5jcnlwdGVkIFNSVFAgcHJpdmF0ZSBrZXkgaW4gdGhlIElDRSBtZXNzYWdlLiBP ciBzb21ldGhpbmcgc2ltaWxhciB0bw0KPj4gdGhhdC4gVGhpcyB3aWxsIGRlZmluaXRlbHkgbm90 IGludGVyb3Agd2l0aCBEVExTLCBidXQgd2lsbCBtYWtlDQo+PiBpbXBsZW1lbnRhdGlvbiBvZiBl bmNyeXB0aW9uIHZlcnkgc2ltcGxlLg0KPg0KPlNvIHRoYXQgcHJvcG9zYWwgd291bGQgbW9kaWZ5 IGV2ZW4gSUNFIHByb3RvY29sLCBhbSBJIHJpZ2h0PyBUb28gbXVjaA0KPmRyYW1hdGljIElNSE8g OikNCj4NCj5PaywgZ2l2ZW4gdGhlIGZhY3QgdGhhdCBEVExTIGlzIHN0aWxsIGFuIHV0b3BpYSAo YWxsIHRoZSBwZW9wbGUga25vdw0KPmFib3V0IGl0IGJ1dCBpdCBzZWVtcyB0aGF0IG5vYm9keSBo YXMgc2VlbiBpdCBpbiBhY3Rpb24pLCB3aHkgbm90IHRvDQo+bGVhdmUgaXQgZm9yIGEgZnV0dXJl IHZlcnNpb24gb2YgV2ViUlRDIGFuZCBnbyBub3cgd2l0aCBTREVTICsgZW5jcnlwdGVkDQo+c2ln bmFsaW5nIHBhdGg/IEluIHRoaXMgd2F5Og0KPg0KPi0gV2UgZ2V0IGludGVyb3BlcmFiaWxpdHkg d2l0aCBvdGhlciB0ZWNobm9sb2dpZXMgKmFscmVhZHkqIGltcGxlbWVudGluZw0KPlNERVMrU1JU UCAoc28gKioqdGVzdGVkKioqKS4NCj4NCj4tIERUTFMgY2FuIGJlIGFkZGVkIG9uY2UgaXQncyBt YXR1cmUvdGVzdGVkL3dpZGVseS1pbXBsZW1lbnRlZCBhbmQgd2UNCj5jYW4gbGVhcm4gZnJvbSBv dGhlciBpbXBsZW1lbnRhdGlvbnMgKHdoYXQgZG8gdGhleSBpbXBsZW1lbnQsIGludGVyb3ANCj5w cm9ibGVtcywgYnVncy4uLj8pLg0KPg0KPi0gQWRkaW5nIERUTFMgbGF0ZXIgdG8gV2ViUlRDIGRv ZXMgbm90IGJyZWFrIG5vdGhpbmcgc2luY2UgaXRzIHVzYWdlDQo+d291bGQgYmUgc3RpbGwgbmVn b3RpYWJsZSBkdXJpbmcgdGhlIHNlc3Npb24gaW5pdGlhdGlvbi4NCj4NCj4NCj5ZZXMsIEkgZG8g a25vdyB0aGF0IFNERVMrU1JUUCBpcyBub3QgdGhlIGJlc3Qgc29sdXRpb24sIGJ1dCBJJ3ZlIG5l dmVyDQo+c2VlbiBhIHNjZW5hcmlvIGluIHdoaWNoIGFsbCB0aGUgY29vbCBhbmQgZmFudGFzdGlj IGZlYXR1cmVzIG9mIERUTFMgYXJlDQo+cmVxdWlyZWQuIEdpdmVuIHRoZSBjb21tZW50cyBhYm91 dCBEVExTIGluIHRoaXMgbG9uZyB0aHJlYWQgaXQgc2VlbXMNCj50aGF0IGNob29zaW5nIERUTFMg d291bGQgYmUgYSByaXNrIChXZWJSVEMgd291bGQgYmVjb21lIGEgRFRMUyBiZXRhLQ0KPnRlc3Rl ci4uLikuDQo+DQo+DQo+UmVnYXJkcy4NCj4NCj4tLQ0KPknDsWFraSBCYXogQ2FzdGlsbG8NCj48 aWJjQGFsaWF4Lm5ldD4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj5ydGN3ZWJAaWV0Zi5vcmcNCj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From ekr@rtfm.com Tue Mar 20 08:02:28 2012 Return-Path: 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 9143D21F85ED for ; Tue, 20 Mar 2012 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.889 X-Spam-Level: X-Spam-Status: No, score=-102.889 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 4jyEzfQKsWRW for ; Tue, 20 Mar 2012 08:02:28 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D79D521F85DB for ; Tue, 20 Mar 2012 08:02:27 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so140137vcb.31 for ; Tue, 20 Mar 2012 08:02:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=ygv21MzQr7XCvNFSSaZIlFBuxQNYbmPDb/gAQKqMSzo=; b=IwDTaWG8Pkzl1t/Gy+jaiqsSVNVT19mw+yD6EMBDKV4NskjYol/ERZ2qw7kq2i3Fhj wqNfseIq9TD7dnU6GUc8JCgQjNeNYONc7bdBLr4NHgc8ePsv8uT4ZXqkVPRjQXXvMsLP oVPa5CmeXq709cqzKFcfs3TOb7mm0wp2HU94yZ4Fib4Qxm10y58cWXijNzVY8imiJhj7 e2nYaTjEFD24YCh2ijFWtfoDodhpss/hR0A454Wrxxz6fDGpSen2FV/74lN1C2bvjSRR FBtgmbnWv82Lt8gfzt0ZIhrgjcDu4jKgjiOEzaS4S4KxeEoWgWz5uWQCws3poEH8vo2h D3dw== Received: by 10.220.151.67 with SMTP id b3mr54926vcw.51.1332255747294; Tue, 20 Mar 2012 08:02:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Tue, 20 Mar 2012 08:01:43 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> From: Eric Rescorla Date: Tue, 20 Mar 2012 08:01:43 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQms8JCcf4Y4rtb1btxZNgP2CPqL4FUfkhEz64d/mwQ1WObjoog5Tu4dj/C8Xj+cuAd0a/qd Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 15:02:28 -0000 On Tue, Mar 20, 2012 at 7:16 AM, I=F1aki Baz Castillo wrote= : > 2012/3/20 Roman Shpount : >> The other proposal was not to use DTLS at all, since it is an overkill b= oth >> complexity and feature wise. DTLS is designed the way it is primarily to >> extend TLS to UDP. DTLS-SRTP is a bolt on of SRTP into DTLS. So we actua= lly >> got a protocol twice reused with design goals changing dramatically in t= he >> process. The desired attribute of DTLS-SRTP is that encryption keys are = not >> transmitted in clear text. The rest (security handshake separated from >> signaling and ICE handshake, support for data encryption schemes other t= hen >> SRTP, support for certificate validation, etc) is actually just a liabil= ity. >> All of those things imply slower setup and interop problems. So, my seco= nd >> proposal was not to use DTLS at all, just include the public keys for >> supported key exchange protocols in the SDP and send the encrypted SRTP >> private key in the ICE message. Or something similar to that. This will >> definitely not interop with DTLS, but will make implementation of encryp= tion >> very simple. > > So that proposal would modify even ICE protocol, am I right? Too much > dramatic IMHO :) > > Ok, given the fact that DTLS is still an utopia (all the people know > about it but it seems that nobody has seen it in action), This is not true for DTLS in general. It's been in stacks for a while now and is widely used in VPNs. There certainly is rather less use of DTLS-SRTP, but it isn't unknown either, as I believe Cullen has mentioned on the list before. -Ekr From harald@alvestrand.no Tue Mar 20 08:40:05 2012 Return-Path: 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 5EA8021F85A0 for ; Tue, 20 Mar 2012 08:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 vTq4EFncusoB for ; Tue, 20 Mar 2012 08:40:04 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 51DED21F8598 for ; Tue, 20 Mar 2012 08:40:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8DAAA39E132; Tue, 20 Mar 2012 16:40:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vga9TdMn6cV6; Tue, 20 Mar 2012 16:40:02 +0100 (CET) Received: from [78.65.120.97] (host-78-65-120-97.homerun.telia.com [78.65.120.97]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 867D539E0E7; Tue, 20 Mar 2012 16:40:02 +0100 (CET) Message-ID: <4F68A4CC.9090306@alvestrand.no> Date: Tue, 20 Mar 2012 16:39:56 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Roman Shpount References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010107050405090001030409" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 15:40:05 -0000 This is a multi-part message in MIME format. --------------010107050405090001030409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/20/2012 02:40 PM, Roman Shpount wrote: > Once again, I understand how this helps in case of HTTPS, but how > would this help in case of WebRTC? Media description is carried in > some sort of application defined protocol (can even be transmitted > over an encrypted SCTP data channel or encrypted in javaScript), so > monitoring proxy cannot reliably modify it. I understand how it can be > allowed to fake the signature on modified SDP by inserting a > certificate in the browser, but how would the proxy get to the SDP in > the first place? "this" = inserting a trust root in the browser? Once you trust the root I inserted, I can intercept all your HTTPS connections, and thus I can replace all the Javascript you think you are loading from your trusted provider with Javascript of my choice. Once your browser is running my Javascript, I can do anything the original application could - with the privilleges you granted to that application. I think that's more or less "game over" when it comes to security. > _____________ > Roman Shpount > > > On Tue, Mar 20, 2012 at 6:41 AM, Harald Alvestrand > > wrote: > > On 03/17/2012 10:14 PM, Igor Faynberg wrote: >> .. >> >> On 3/17/2012 4:45 PM, Martin Thomson wrote: >>> ... Then I explicitly place a trust anchor for that >>> certificate in your browser. >> >> How? I thought the browser would never allow that to happen. (I >> assumed it would come provisioned with anchors, or would allow >> anchor provision through some different channel.) >> > Igor, > > in Chrome, go to chrome://settings/certificates, choose the > "authorities" tab, and note the presence of the "import" button. > > All browsers (as far as I know) have similar mechanisms. > "Owning" your computer will achieve this goal both in its > corporate meaning and in its hacker meaning. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --------------010107050405090001030409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/20/2012 02:40 PM, Roman Shpount wrote:
Once again, I understand how this helps in case of HTTPS, but how would this help in case of WebRTC? Media description is carried in some sort of application defined protocol (can even be transmitted over an encrypted SCTP data channel or encrypted in javaScript), so monitoring proxy cannot reliably modify it. I understand how it can be allowed to fake the signature on modified SDP by inserting a certificate in the browser, but how would the proxy get to the SDP in the first place?

"this" = inserting a trust root in the browser?

Once you trust the root I inserted, I can intercept all your HTTPS connections, and thus I can replace all the Javascript you think you are loading from your trusted provider with Javascript of my choice.

Once your browser is running my Javascript, I can do anything the original application could - with the privilleges you granted to that application.

I think that's more or less "game over" when it comes to security.


_____________
Roman Shpount


On Tue, Mar 20, 2012 at 6:41 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
On 03/17/2012 10:14 PM, Igor Faynberg wrote:
..

On 3/17/2012 4:45 PM, Martin Thomson wrote:
... Then I explicitly place a trust anchor for that
certificate in your browser.

How?  I thought the browser would never allow that to happen. (I assumed it would come provisioned with anchors,  or would allow anchor provision through some different channel.)

Igor,

in Chrome, go to chrome://settings/certificates, choose the "authorities" tab, and note the presence of the "import" button.

All browsers (as far as I know) have similar mechanisms.
"Owning" your computer will achieve this goal both in its corporate meaning and in its hacker meaning.



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



--------------010107050405090001030409-- From igor.faynberg@alcatel-lucent.com Tue Mar 20 08:41:50 2012 Return-Path: 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 3638A21F85AD for ; Tue, 20 Mar 2012 08:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.402 X-Spam-Level: X-Spam-Status: No, score=-7.402 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 rHTvTmHHKKzo for ; Tue, 20 Mar 2012 08:41:49 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 48BF521F85AA for ; Tue, 20 Mar 2012 08:41:49 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q2KFfgmk025635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Mar 2012 10:41:43 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2KFfgSv010172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Mar 2012 10:41:42 -0500 Received: from [135.244.33.178] (faynberg.lra.lucent.com [135.244.33.178]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2KFfgO3004532; Tue, 20 Mar 2012 10:41:42 -0500 (CDT) Message-ID: <4F68A535.8010809@alcatel-lucent.com> Date: Tue, 20 Mar 2012 11:41:41 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Harald Alvestrand References: <4F4759DC.7060303@ericsson.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4F677F3B.3040407@alcatel-lucent.com> <4F686183.6040201@alvestrand.no> In-Reply-To: <4F686183.6040201@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Telling the user the connection is secure (Re: Resolving RTP/SDES question in Paris) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 15:41:50 -0000 +1 Igor On 3/20/2012 6:52 AM, Harald Alvestrand wrote: > I believe I have said this before, but... > > We should never tell the user the connection is secure. > We should tell the user when we know he's exposed to risks that he > usually isn't. > > Thus - we should not give any indication that we're using DTLS-SRTP > with verified identities (if that's what we normally support). We > SHOULD give a warning saying "hey, since the gateway you've connected > to isn't doing normal authentication procedures, but instead insists > on exchanging keys on the signalling channel, you are less sure who > you're talking to than usual, and there are more boxes that might > record your call in the way, but the script kiddie on your hotel WLAN > still can't see your packets (translation: legacy SDES key exchange is > in use, but SRTP is still on). > > All this will of course be iconified into a single cryptic graphic > probably involving a padlock :-) > > On 03/19/2012 07:47 PM, Igor Faynberg wrote: >> This is the question that I have been asking for a while... I don't >> expect a complete fireproof answer, of course, and I also understand >> that the browser today is telling me a few things about the security >> of a site and warns me when "the site is trying to access the data it >> should not be accessing." >> >> But I also imagine that a rogue site could display a message >> mimicking the security assurance as though it comes from the browser. >> >> So it would be good to have a very clear idea when the determination >> about the security of the connection and such is made and how the end >> user can verify that it actually comes from the browser. >> >> (To this end, the user MUST trust the browser, of course.) >> >> Igor >> >> On 3/19/2012 2:15 PM, Roman Shpount wrote: >>> I guess my question is, when are we going to tell the user that >>> connection is "secure"?... >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > From HKaplan@acmepacket.com Tue Mar 20 08:44:19 2012 Return-Path: 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 DD02C21F849C for ; Tue, 20 Mar 2012 08:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] 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 IebHh2p8KM2r for ; Tue, 20 Mar 2012 08:44:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B03CE21F849B for ; Tue, 20 Mar 2012 08:44:18 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Mar 2012 11:44:13 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.166]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Tue, 20 Mar 2012 11:44:13 -0400 From: Hadriel Kaplan To: Harald Alvestrand Thread-Topic: [rtcweb] SDES vs DTLS-SRTP revisited Thread-Index: AQHNBrBMt2nXjUficU+l0rMM5dLpPA== Date: Tue, 20 Mar 2012 15:44:12 +0000 Message-ID: References: <4F685C45.5080106@alvestrand.no> In-Reply-To: <4F685C45.5080106@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7D951FF277F55D4EA70475EB0318BD74@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDES vs DTLS-SRTP revisited X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 15:44:20 -0000 On Mar 20, 2012, at 6:30 AM, Harald Alvestrand wrote: > I don't get this scenario. If Alice calls Bob using two different gateway= s, won't she go through a credentials and fingerprint exchange with the gat= eways? > In that case, wouldn't the fingerprint belong to the gateway? Yes, but the statement being made was in the context of Alice calling Bob, = them seeing their browsers claim DTLS-SRTP "secured" or whatever, and them = being super-geeks and checking the detailed info of what the actual DTLS fi= ngerprints were, and finding they don't both see the same fingerprints... a= nd that they would thus believe there was either a software bug or a malici= ous middleman. So my point was that's not a good conclusion to jump to, since both caller = and called parties can see DTLS-SRTP "secured" mode lock-icon, but with dif= ferent fingerprints, and yet it being neither a software bug nor a maliciou= s middleman. I realize no distinction can be made between a PSTN-gateway a= nd a malicious MitM, by design, but that's not a good thing - because it me= ans people will simply learn to ignore the warnings generated by the browse= r, because from a user perspective they'll all be false positives. -hadriel From harald@alvestrand.no Tue Mar 20 09:01:02 2012 Return-Path: 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 D8B4721F861D for ; Tue, 20 Mar 2012 09:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Nre-EFaw8YOI for ; Tue, 20 Mar 2012 09:01:02 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 129C321F860F for ; Tue, 20 Mar 2012 09:01:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4EC4939E132; Tue, 20 Mar 2012 17:01:01 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnrijC6fdCqI; Tue, 20 Mar 2012 17:01:00 +0100 (CET) Received: from [78.65.120.97] (host-78-65-120-97.homerun.telia.com [78.65.120.97]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 92EFF39E0E7; Tue, 20 Mar 2012 17:01:00 +0100 (CET) Message-ID: <4F68A9B6.2050101@alvestrand.no> Date: Tue, 20 Mar 2012 17:00:54 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Hadriel Kaplan References: <4F685C45.5080106@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDES vs DTLS-SRTP revisited X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 16:01:03 -0000 On 03/20/2012 04:44 PM, Hadriel Kaplan wrote: > On Mar 20, 2012, at 6:30 AM, Harald Alvestrand wrote: > >> I don't get this scenario. If Alice calls Bob using two different gateways, won't she go through a credentials and fingerprint exchange with the gateways? >> In that case, wouldn't the fingerprint belong to the gateway? > Yes, but the statement being made was in the context of Alice calling Bob, them seeing their browsers claim DTLS-SRTP "secured" or whatever, and them being super-geeks and checking the detailed info of what the actual DTLS fingerprints were, and finding they don't both see the same fingerprints... and that they would thus believe there was either a software bug or a malicious middleman. So we've uncovered a requirement here: When a fingerprint is shown, it should clearly identify what it is the fingerprint of - in this case, the gateway that relays the call to Bob, not Bob. > So my point was that's not a good conclusion to jump to, since both caller and called parties can see DTLS-SRTP "secured" mode lock-icon, but with different fingerprints, and yet it being neither a software bug nor a malicious middleman. I realize no distinction can be made between a PSTN-gateway and a malicious MitM, by design, but that's not a good thing - because it means people will simply learn to ignore the warnings generated by the browser, because from a user perspective they'll all be false positives. So in this case, the browser needs to not warn; it needs to say "connected to gateway in order to reach Bob". From roman@telurix.com Tue Mar 20 09:10:21 2012 Return-Path: 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 5880021F85AE for ; Tue, 20 Mar 2012 09:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.78 X-Spam-Level: X-Spam-Status: No, score=-2.78 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 J24LzRPHM414 for ; Tue, 20 Mar 2012 09:10:20 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id AFC8221F8595 for ; Tue, 20 Mar 2012 09:10:20 -0700 (PDT) Received: by dakl33 with SMTP id l33so212997dak.31 for ; Tue, 20 Mar 2012 09:10:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Ofyoq0ssUvEVVcD+RPli7aiqYRMQWu332TvlMIs32gA=; b=gcJ+UTToWtZQ7OVqppUEIR639rLYoW1DZTkwwDarJA7oRAdtdM5250sOqvAK1zgqj7 iLIe9JhjFVXdzNjskRgluDb0VN17Q9k537HO3gwRdDkLnLNLkRBn6TPDPQvEIqvZDIlI 0p/odUkm3IQmVE4T/gfOhT6pS16HdHZPvd3ClbDhrHVsYETEBUld2Lukr0HzExyRcIrW pKm42FVDExmF0vo4KUhG55okB65BKD/sGZ+fOkyLq7gjogWyZ4t4IqvlEdUYSFU1LFKI 2RKtZVh8gPiaN22ToPUCIdRg6vYtUkhItyoPzk2gmoB4qwiYpA54wVb0iLF6eEVOTHed 3H4A== Received: by 10.68.191.230 with SMTP id hb6mr2544126pbc.87.1332259820512; Tue, 20 Mar 2012 09:10:20 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id l1sm1587553pbs.34.2012.03.20.09.10.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 09:10:19 -0700 (PDT) Received: by dakl33 with SMTP id l33so212942dak.31 for ; Tue, 20 Mar 2012 09:10:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.99 with SMTP id ot3mr2318826pbb.160.1332259818376; Tue, 20 Mar 2012 09:10:18 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Tue, 20 Mar 2012 09:10:18 -0700 (PDT) In-Reply-To: <4F68A4CC.9090306@alvestrand.no> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> Date: Tue, 20 Mar 2012 12:10:18 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7b15a68b390dda04bbaee97b X-Gm-Message-State: ALoCoQlrAPf1QOybdKW9ofyUbyz0eNFDDtH8ewkBeB86Jc4X99VCxI9OdT4S4+a+NSJChW06Y6kz Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 16:10:21 -0000 --047d7b15a68b390dda04bbaee97b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 20, 2012 at 11:39 AM, Harald Alvestrand wrote: > ** > On 03/20/2012 02:40 PM, Roman Shpount wrote: > > Once again, I understand how this helps in case of HTTPS, but how would > this help in case of WebRTC? Media description is carried in some sort of > application defined protocol (can even be transmitted over an encrypted > SCTP data channel or encrypted in javaScript), so monitoring proxy cannot > reliably modify it. I understand how it can be allowed to fake the > signature on modified SDP by inserting a certificate in the browser, but > how would the proxy get to the SDP in the first place? > > > "this" = inserting a trust root in the browser? > > Once you trust the root I inserted, I can intercept all your HTTPS > connections, and thus I can replace all the Javascript you think you are > loading from your trusted provider with Javascript of my choice. > > Once your browser is running my Javascript, I can do anything the original > application could - with the privilleges you granted to that application. > > I think that's more or less "game over" when it comes to security. > > "this" is inserting the root certificate. It is a game over as far as security is concerned, but the rest of your email completely missing my point. If, as an owner of a computer, you want to enable media monitoring with an existing standard you need to know exactly how each application is implemented. This is a solution for hacker but not the normal enterprise. In order to have monitoring support in the enterprise environment you need an ability to force the browser to proxy all the media through a monitoring application without any application modification, via browser settings alone. _____________ Roman Shpount --047d7b15a68b390dda04bbaee97b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 20, 2012 at 11:39 = AM, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 03/20/2012 02:40 PM, Roman Shpount wrote:
Once again, I understand how this helps in ca= se of HTTPS, but how would this help in case of WebRTC? Media description is carried in some sort of application defined protocol (can even be transmitted over an encrypted SCTP data channel or encrypted in javaScript), so monitoring proxy cannot reliably modify it. I understand how it can be allowed to fake the signature on modified SDP by inserting a certificate in the browser, but how would the proxy get to the SDP in the first place?

"this" =3D inserting a trust root in the browser?

Once you trust the root I inserted, I can intercept all your HTTPS connections, and thus I can replace all the Javascript you think you are loading from your trusted provider with Javascript of my choice.
Once your browser is running my Javascript, I can do anything the original application could - with the privilleges you granted to that application.

I think that's more or less "game over" when it comes to = security.


"thi= s" is inserting the root certificate. It is a game over as far as secu= rity is concerned, but the rest of your email completely missing my point.<= br>
If, as an owner of a computer, you want to enable media monitoring with= an existing standard you need to know exactly how each application is impl= emented. This is a solution for hacker but not the normal enterprise. In or= der to have monitoring support in the enterprise environment you need an ab= ility to force the browser to proxy all the media through a monitoring appl= ication without any application modification, via browser settings alone. _____________
Roman Shpount


--047d7b15a68b390dda04bbaee97b-- From igor.faynberg@alcatel-lucent.com Tue Mar 20 11:46:21 2012 Return-Path: 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 D43F021F8557 for ; Tue, 20 Mar 2012 11:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.312 X-Spam-Level: X-Spam-Status: No, score=-7.312 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 lktyWwn7pBvR for ; Tue, 20 Mar 2012 11:46:21 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0FA21F8555 for ; Tue, 20 Mar 2012 11:46:21 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q2KIkHQi028527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Mar 2012 13:46:18 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2KIkHlO005920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Mar 2012 13:46:17 -0500 Received: from [135.244.33.178] (faynberg.lra.lucent.com [135.244.33.178]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2KIkFxF000632; Tue, 20 Mar 2012 13:46:16 -0500 (CDT) Message-ID: <4F68D077.8060803@alcatel-lucent.com> Date: Tue, 20 Mar 2012 14:46:15 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Harald Alvestrand References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> In-Reply-To: <4F685ED9.2050109@alvestrand.no> Content-Type: multipart/alternative; boundary="------------040506050507000604020604" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 18:46:21 -0000 This is a multi-part message in MIME format. --------------040506050507000604020604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Harald, Many thanks! I did just what you suggested, and spent happy three hours figuring out what is going on. I found something that claims to be my own certificate, allegedly signed by me (which I swear I have never done) as well as many other certificates from the authorities I never knew (nor could find any information about). On top of all, I found two certificates that allege being issued by Microsoft, while they are marked as fraudulent. (So somenone is checking this stuff and takes action?) The above report speaks for itself. The key finding though is that the browser interface in NOT the only way to get the certificates in. Anyone can put them in a directory, and this a big problem for the "hacker meaning." Incidentally, this is not only the browser matter--same holds for the OS. If root certificates were to be installed only through the browser administrative interface, I imagine the browser could send me a warning or even deny the installation. I know there is a lot to think through on how to bootstrap this process, but I think it should be possible to achieve. But in this case it appears to me that the browser would need to have its own independent file system controlled only through the administrative interface. It also appears to me that the interface should be password-protected so that only the legitimate owner (including corporate) can control the installation of root certificates. If the hacker who does not know the administrative password just got access to my computer (say, via JS), there is no way for this hacker to install the certificate. I know that this issue takes off on a tangent from the RTCWeb discussion, so I don't want to start that. But I wanted to acknowledge your message and thank you for responding. Maybe we could talk about this with you, Hui-Lan, and Eric off-line. Igor On 3/20/2012 6:41 AM, Harald Alvestrand wrote: > Igor, > > > in Chrome, go to chrome://settings/certificates, choose the > "authorities" tab, and note the presence of the "import" button. > > All browsers (as far as I know) have similar mechanisms. > "Owning" your computer will achieve this goal both in its corporate > meaning and in its hacker meaning. > > --------------040506050507000604020604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Harald,

Many thanks!  I did just what you suggested, and spent happy three hours figuring out what is going on.  I found something that claims to be my own certificate, allegedly signed by me (which I swear I have never done) as well as many other certificates from the authorities I never knew (nor could find any information about).  On top of all, I found two certificates that allege being issued by Microsoft, while they are marked as fraudulent. (So somenone is checking this stuff and takes action?)

The above report speaks for itself.

The key finding though is that the browser interface in NOT the only way to get the certificates in.  Anyone can put them in a directory, and this a big problem for the "hacker meaning."   Incidentally, this is not only the browser matter--same holds for the OS.

If root certificates were to be installed only through the browser administrative interface, I imagine the browser could send me a warning or even deny the installation.  I know there is a lot to think through on how to bootstrap this process, but I think it should  be possible to achieve.  But in this case it appears to me that the browser would need to have its own independent file system controlled only through the administrative interface.

It also appears to me that the interface should be password-protected so that only the legitimate owner (including corporate) can control the installation of root certificates. If the hacker who does not know the administrative password just got  access to my computer (say, via JS), there is no way for this hacker to  install the certificate.

I know that this issue takes off on a tangent from the RTCWeb discussion, so I don't want to start that. But I wanted to acknowledge your message and thank you for responding.  Maybe we could talk about this with you, Hui-Lan, and Eric off-line.

Igor

On 3/20/2012 6:41 AM, Harald Alvestrand wrote:
Igor,


in Chrome, go to chrome://settings/certificates, choose the "authorities" tab, and note the presence of the "import" button.

All browsers (as far as I know) have similar mechanisms.
"Owning" your computer will achieve this goal both in its corporate meaning and in its hacker meaning.


--------------040506050507000604020604-- From Jim.Barnett@genesyslab.com Wed Mar 21 06:47:47 2012 Return-Path: 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 A0F4121F8603 for ; Wed, 21 Mar 2012 06:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] 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 N9FCh+UEleAH for ; Wed, 21 Mar 2012 06:47:46 -0700 (PDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id D258F21F84D3 for ; Wed, 21 Mar 2012 06:47:46 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q2LDliwj020417; Wed, 21 Mar 2012 06:47:44 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 06:47:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Mar 2012 06:47:37 -0700 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31296AE222A@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHNBkhwRk3x+jQ7ZUSzaNmeu+7o6pZy7hYggAHUYoA= References: <4F4759DC.7060303@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com><6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com><6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com><387F9047F55E8C42850AD6B3A7A03C6C0E1FFE23@inba-mail01.sonusnet.com><2E10EB15-7E2E-47B9-80D1-5244DDE5FDF7@acmepacket.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE222A@MCHP058A.global-ad.net> From: "Jim Barnett" To: "Hutton, Andrew" , "Hadriel Kaplan" , "Ravindran, Parthasarathi" X-OriginalArrivalTime: 21 Mar 2012 13:47:44.0380 (UTC) FILETIME=[314E7BC0:01CD0769] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 13:47:47 -0000 One way to look at this case would be to say that it's the server at the boundary of www.travel.co that is the RTCWeb endpoint, _not_ the agent desktop. The boundary server is acting as an RTCWeb-to-corporate network gateway, and systems inside the corporate network are not affected. Callers see themselves as connected to www.travel.co, rather than having a direct RTCWeb-all-the-way connection to the agent. I'm pretty sure that call centers would like to do things this way since it doesn't require any changes to their corporate infrastructure. (They can add/upgrade the gateway without changing their recording systems or agent desktops, etc.) I don't see anything like this in the use case document. Is this a use case we want to support? =20 - Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Tuesday, March 20, 2012 6:07 AM To: Hadriel Kaplan; Ravindran, Parthasarathi Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris Hi, Completely agree with Hadriel's statement below. In addition to wanting to know that you are connected to "www.travel.co" or "www.mybank.co" you as a consumer and the company really want/need the media to be recorded by the companies system for your own protection. This is going to involve some kind of MITM or as we call it in SIPREC a Session Recording Client (SRC) to be able to intercept the media and route it to a Session Recording Server (SRS).=20 The agent's desktop device could act as the SRC but more likely it will be some kind of B2BUA that does this. =20 In these scenario's you as a consumer using this service really want the media to be secure at least as far as reaching the bank but after that like any existing web based system you have to trust the bank with your data this is no different whether that data is speech or text that you entered on a web page. The recording system should be able to work with DTLS-SRTP but it will most likely act as a MITM so will change the DTLS fingerprint. I don't see that as a problem. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 > Behalf Of Hadriel Kaplan > Sent: 20 March 2012 03:21 > To: Ravindran, Parthasarathi > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris >=20 >=20 > And, it should be noted, they *want* it that way. They don't=20 > generally want you to know which agent picked up the call, or that the > call got transferred from an IVR to a specific agent, or got put in a=20 > queue with elevator-music announcement server, or any of that. You "called" > Travel Co., and they answered. What goes on behind that SBC is=20 > equivalent to the back-end database stuff that goes on between the web > server and back-end systems, while all you see is the web-server your=20 > browser happens to be connected to. >=20 > The "identity" you'll get is www.travel.co, which you already had when > your browser did HTTPS cert verification of their web-server. HTTPS=20 > became the key-exchange transport for the SRTP key. Since they=20 > already proved they own the cert for www.travel.co, having them claim=20 > to be www.travel.co shouldn't require yet more verification. >=20 > -hadriel >=20 >=20 > On Mar 19, 2012, at 9:15 PM, Ravindran, Parthasarathi wrote: >=20 > > Jim, > > > > As a customer, you won't really know whether the identity=20 > > (DTLS-SRTP) > of call center/travel site is agent or SBC. SBC can perform MITM=20 > attack easily as extending SDES-SRTP to DTLS-SRTP for call center site > is feasible. > > > > Thanks > > Partha >=20 > _______________________________________________ > 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 From pravindran@sonusnet.com Wed Mar 21 06:51:15 2012 Return-Path: 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 555D821F86A5 for ; Wed, 21 Mar 2012 06:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 paqr9quZ2Gfo for ; Wed, 21 Mar 2012 06:51:14 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9F92021F865B for ; Wed, 21 Mar 2012 06:51:13 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKT2nc0cQOXZDV3Mo39fmBhQqyN4x/vmut@postini.com; Wed, 21 Mar 2012 06:51:13 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 21 Mar 2012 09:51:27 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 21 Mar 2012 19:21:08 +0530 From: "Ravindran, Parthasarathi" To: Jim Barnett , "Hutton, Andrew" , Hadriel Kaplan Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHM8te6ZBG/XYsMg0C4SE+GOqsWNpZtZpyg///nIgCAAAs3AIAASYaAgADU1wCAAESDgIAB8AUAgAAelICAAH0pgIAAChuAgAAC/YCAADCxgIAADEuAgAAOHICAAAWBgIAAAeoAgAAPeYCAAEVigIAAByQAgACETSD//8eAAIAAcXWAgAHQA4CAAFzq0A== Date: Wed, 21 Mar 2012 13:51:07 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E201725@inba-mail01.sonusnet.com> References: <4F4759DC.7060303@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com><6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com><6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com><387F9047F55E8C42850AD6B3A7A03C6C0E1FFE23@inba-mail01.sonusnet.com><2E10EB15-7E2E-47B9-80D1-5244DDE5FDF7@acmepacket.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE222A@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 13:51:15 -0000 It will be good to add this CallCenter WebRTC usecase. Thanks Partha >-----Original Message----- >From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com] >Sent: Wednesday, March 21, 2012 7:18 PM >To: Hutton, Andrew; Hadriel Kaplan; Ravindran, Parthasarathi >Cc: rtcweb@ietf.org >Subject: RE: [rtcweb] Resolving RTP/SDES question in Paris > >One way to look at this case would be to say that it's the server at the >boundary of www.travel.co that is the RTCWeb endpoint, _not_ the agent >desktop. The boundary server is acting as an RTCWeb-to-corporate network >gateway, and systems inside the corporate network are not affected. >Callers see themselves as connected to www.travel.co, rather than having >a direct RTCWeb-all-the-way connection to the agent. I'm pretty sure >that call centers would like to do things this way since it doesn't >require any changes to their corporate infrastructure. (They can >add/upgrade the gateway without changing their recording systems or >agent desktops, etc.) > >I don't see anything like this in the use case document. Is this a use >case we want to support? > >- Jim > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Hutton, Andrew >Sent: Tuesday, March 20, 2012 6:07 AM >To: Hadriel Kaplan; Ravindran, Parthasarathi >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris > >Hi, > >Completely agree with Hadriel's statement below. > >In addition to wanting to know that you are connected to "www.travel.co" >or "www.mybank.co" you as a consumer and the company really want/need >the media to be recorded by the companies system for your own >protection. This is going to involve some kind of MITM or as we call it >in SIPREC a Session Recording Client (SRC) to be able to intercept the >media and route it to a Session Recording Server (SRS). > >The agent's desktop device could act as the SRC but more likely it will >be some kind of B2BUA that does this. > >In these scenario's you as a consumer using this service really want the >media to be secure at least as far as reaching the bank but after that >like any existing web based system you have to trust the bank with your >data this is no different whether that data is speech or text that you >entered on a web page. > >The recording system should be able to work with DTLS-SRTP but it will >most likely act as a MITM so will change the DTLS fingerprint. I don't >see that as a problem. > >Regards >Andy > > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Hadriel Kaplan >> Sent: 20 March 2012 03:21 >> To: Ravindran, Parthasarathi >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris >> >> >> And, it should be noted, they *want* it that way. They don't >> generally want you to know which agent picked up the call, or that the > >> call got transferred from an IVR to a specific agent, or got put in a >> queue with elevator-music announcement server, or any of that. You >"called" >> Travel Co., and they answered. What goes on behind that SBC is >> equivalent to the back-end database stuff that goes on between the web > >> server and back-end systems, while all you see is the web-server your >> browser happens to be connected to. >> >> The "identity" you'll get is www.travel.co, which you already had when > >> your browser did HTTPS cert verification of their web-server. HTTPS >> became the key-exchange transport for the SRTP key. Since they >> already proved they own the cert for www.travel.co, having them claim >> to be www.travel.co shouldn't require yet more verification. >> >> -hadriel >> >> >> On Mar 19, 2012, at 9:15 PM, Ravindran, Parthasarathi wrote: >> >> > Jim, >> > >> > As a customer, you won't really know whether the identity >> > (DTLS-SRTP) >> of call center/travel site is agent or SBC. SBC can perform MITM >> attack easily as extending SDES-SRTP to DTLS-SRTP for call center site > >> is feasible. >> > >> > Thanks >> > Partha >> >> _______________________________________________ >> 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 From igor.faynberg@alcatel-lucent.com Wed Mar 21 07:58:21 2012 Return-Path: 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 C17BB21E800E for ; Wed, 21 Mar 2012 07:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.441 X-Spam-Level: X-Spam-Status: No, score=-9.441 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 aupv2iAXsROW for ; Wed, 21 Mar 2012 07:58:17 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 01B6A21F871E for ; Wed, 21 Mar 2012 07:58:12 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q2LEwCur026710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 21 Mar 2012 09:58:12 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2LEwBqF016788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Mar 2012 09:58:12 -0500 Received: from [135.222.232.245] (USMUYN0L055118.mh.lucent.com [135.222.232.245]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2LEwBYj024791; Wed, 21 Mar 2012 09:58:11 -0500 (CDT) Message-ID: <4F69EC83.8080509@alcatel-lucent.com> Date: Wed, 21 Mar 2012 10:58:11 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F4759DC.7060303@ericsson.com><6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com><387F9047F55E8C42850AD6B3A7A03C6C0E1FFE23@inba-mail01.sonusnet.com><2E10EB15-7E2E-47B9-80D1-5244DDE5FDF7@acmepacket.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE222A@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E201725@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E201725@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 14:58:21 -0000 +1 Indeed, this is the only way call centers could work. Igor On 3/21/2012 9:51 AM, Ravindran, Parthasarathi wrote: > It will be good to add this CallCenter WebRTC usecase. > > Thanks > Partha > >> -----Original Message----- >> From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com] >> Sent: Wednesday, March 21, 2012 7:18 PM >> To: Hutton, Andrew; Hadriel Kaplan; Ravindran, Parthasarathi >> Cc: rtcweb@ietf.org >> Subject: RE: [rtcweb] Resolving RTP/SDES question in Paris >> >> One way to look at this case would be to say that it's the server at the >> boundary of www.travel.co that is the RTCWeb endpoint, _not_ the agent >> desktop. The boundary server is acting as an RTCWeb-to-corporate network >> gateway, and systems inside the corporate network are not affected. >> Callers see themselves as connected to www.travel.co, rather than having >> a direct RTCWeb-all-the-way connection to the agent. I'm pretty sure >> that call centers would like to do things this way since it doesn't >> require any changes to their corporate infrastructure. (They can >> add/upgrade the gateway without changing their recording systems or >> agent desktops, etc.) >> >> I don't see anything like this in the use case document. Is this a use >> case we want to support? >> >> - Jim >> >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Hutton, Andrew >> Sent: Tuesday, March 20, 2012 6:07 AM >> To: Hadriel Kaplan; Ravindran, Parthasarathi >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris >> >> Hi, >> >> Completely agree with Hadriel's statement below. >> >> In addition to wanting to know that you are connected to "www.travel.co" >> or "www.mybank.co" you as a consumer and the company really want/need >> the media to be recorded by the companies system for your own >> protection. This is going to involve some kind of MITM or as we call it >> in SIPREC a Session Recording Client (SRC) to be able to intercept the >> media and route it to a Session Recording Server (SRS). >> >> The agent's desktop device could act as the SRC but more likely it will >> be some kind of B2BUA that does this. >> >> In these scenario's you as a consumer using this service really want the >> media to be secure at least as far as reaching the bank but after that >> like any existing web based system you have to trust the bank with your >> data this is no different whether that data is speech or text that you >> entered on a web page. >> >> The recording system should be able to work with DTLS-SRTP but it will >> most likely act as a MITM so will change the DTLS fingerprint. I don't >> see that as a problem. >> >> Regards >> Andy >> >> >> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>> Behalf Of Hadriel Kaplan >>> Sent: 20 March 2012 03:21 >>> To: Ravindran, Parthasarathi >>> Cc: rtcweb@ietf.org >>> Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris >>> >>> >>> And, it should be noted, they *want* it that way. They don't >>> generally want you to know which agent picked up the call, or that the >>> call got transferred from an IVR to a specific agent, or got put in a >>> queue with elevator-music announcement server, or any of that. You >> "called" >>> Travel Co., and they answered. What goes on behind that SBC is >>> equivalent to the back-end database stuff that goes on between the web >>> server and back-end systems, while all you see is the web-server your >>> browser happens to be connected to. >>> >>> The "identity" you'll get is www.travel.co, which you already had when >>> your browser did HTTPS cert verification of their web-server. HTTPS >>> became the key-exchange transport for the SRTP key. Since they >>> already proved they own the cert for www.travel.co, having them claim >>> to be www.travel.co shouldn't require yet more verification. >>> >>> -hadriel >>> >>> >>> On Mar 19, 2012, at 9:15 PM, Ravindran, Parthasarathi wrote: >>> >>>> Jim, >>>> >>>> As a customer, you won't really know whether the identity >>>> (DTLS-SRTP) >>> of call center/travel site is agent or SBC. SBC can perform MITM >>> attack easily as extending SDES-SRTP to DTLS-SRTP for call center site >>> is feasible. >>>> Thanks >>>> Partha >>> _______________________________________________ >>> 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 From ldecicco@gmail.com Wed Mar 21 12:53:08 2012 Return-Path: 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 BBC4D21E80EE for ; Wed, 21 Mar 2012 12:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 5IaNS1Nj2MV3 for ; Wed, 21 Mar 2012 12:53:07 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 90C0321E80D6 for ; Wed, 21 Mar 2012 12:53:05 -0700 (PDT) Received: by dakl33 with SMTP id l33so2129686dak.31 for ; Wed, 21 Mar 2012 12:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fR/MS38xCHGFaG9h+wfo12sF22yYG7rcl5CYoqcasvI=; b=evpHbvb3USjlm8I6uXMY02w37aKSYkoNzTD6j+m6RWt4p5fz/tftn0hbCGolV4TXmO 6IRbbwcKOvCC5iA6oc4Y9DCKl9eQw0AJhWJdJB5qvScJdjihjqLnjTuGhL9z4S7C8pkL P1RGNvhVvBoRWw2BMXh5Ds05PdHGVaSv4SHZwjU/WPJgLBNemlHe2VLGT3PVLIG8hBR4 P6rfx0eHSx6cMwKttiTZeEW3sXEwksqhV+SCIbJZluGujlzO87P8NRpIpaq6kkwvCPz1 c7iUqujd3sxjTMTE5AjREgr1bIxr4gRc+KkGp3G7feW8LQdO++Ab93reUL9x7Jz/joF4 DRNA== MIME-Version: 1.0 Received: by 10.68.211.135 with SMTP id nc7mr13966259pbc.113.1332359585387; Wed, 21 Mar 2012 12:53:05 -0700 (PDT) Received: by 10.68.14.133 with HTTP; Wed, 21 Mar 2012 12:53:05 -0700 (PDT) Date: Wed, 21 Mar 2012 20:53:05 +0100 Message-ID: From: Luca De Cicco To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Modular Congestion Control in 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:53:08 -0000 Dear all, is there any plan to make the congestion control algorithm modular for multimedia transmission via PeerConnections? A particular congestion control module could be selected by the connecting peers at the establishment of the PeerConnection similarly to DCCP. Best regards, -- Luca De Cicco, PhD, Eng. Politecnico di Bari Dipartimento di Elettrotecnica ed Elettronica Via Re David, 200 - Bari - ITALY Office: +39 080 596 3851 From harald@alvestrand.no Thu Mar 22 00:00:47 2012 Return-Path: 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 9708521E8036 for ; Thu, 22 Mar 2012 00:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.455 X-Spam-Level: X-Spam-Status: No, score=-110.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 owGcQVDAb4+3 for ; Thu, 22 Mar 2012 00:00:47 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F0C2221E8026 for ; Thu, 22 Mar 2012 00:00:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35CB239E245; Thu, 22 Mar 2012 08:00:45 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhhAVgWx2Y0C; Thu, 22 Mar 2012 08:00:44 +0100 (CET) Received: from [192.168.11.107] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DB28B39E33A; Thu, 22 Mar 2012 08:00:09 +0100 (CET) Message-ID: <4F6ACDF9.2050701@alvestrand.no> Date: Thu, 22 Mar 2012 08:00:09 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Luca De Cicco References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Modular Congestion Control in 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 07:00:47 -0000 On 03/21/2012 08:53 PM, Luca De Cicco wrote: > Dear all, > > is there any plan to make the congestion control algorithm > modular for multimedia transmission via PeerConnections? > > A particular congestion control module could be selected > by the connecting peers at the establishment of the > PeerConnection similarly to DCCP. So far, the discussions (which have mainly been done on the rtp-congestion@alvestrand.no list) have focused on making a mechanism for reporting bandwidth estimates available, and on discussing one particular new congestion control mechanism based on delay estimation. It's implicit that we'd like to try out more than one estimation mechanism. But it's not clear to me that this translates to "modular algorithms". Please join the discussion! Harald From harald@alvestrand.no Thu Mar 22 02:11:44 2012 Return-Path: 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 60E7721F863B for ; Thu, 22 Mar 2012 02:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.515 X-Spam-Level: X-Spam-Status: No, score=-110.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 mB6eaLF8hRzZ for ; Thu, 22 Mar 2012 02:11:43 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 779FD21F8631 for ; Thu, 22 Mar 2012 02:11:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AEB2439E18C; Thu, 22 Mar 2012 10:11:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFtG3rC3lRMJ; Thu, 22 Mar 2012 10:11:34 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B9A0639E01E; Thu, 22 Mar 2012 10:11:34 +0100 (CET) Message-ID: <4F6AECC6.8020004@alvestrand.no> Date: Thu, 22 Mar 2012 10:11:34 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Roman Shpount References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090404050608040300080802" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 09:11:44 -0000 This is a multi-part message in MIME format. --------------090404050608040300080802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/20/2012 05:10 PM, Roman Shpount wrote: > > On Tue, Mar 20, 2012 at 11:39 AM, Harald Alvestrand > > wrote: > > On 03/20/2012 02:40 PM, Roman Shpount wrote: >> Once again, I understand how this helps in case of HTTPS, but how >> would this help in case of WebRTC? Media description is carried >> in some sort of application defined protocol (can even be >> transmitted over an encrypted SCTP data channel or encrypted in >> javaScript), so monitoring proxy cannot reliably modify it. I >> understand how it can be allowed to fake the signature on >> modified SDP by inserting a certificate in the browser, but how >> would the proxy get to the SDP in the first place? > > "this" = inserting a trust root in the browser? > > Once you trust the root I inserted, I can intercept all your HTTPS > connections, and thus I can replace all the Javascript you think > you are loading from your trusted provider with Javascript of my > choice. > > Once your browser is running my Javascript, I can do anything the > original application could - with the privilleges you granted to > that application. > > I think that's more or less "game over" when it comes to security. > > > "this" is inserting the root certificate. It is a game over as far as > security is concerned, but the rest of your email completely missing > my point. > > If, as an owner of a computer, you want to enable media monitoring > with an existing standard you need to know exactly how each > application is implemented. This is a solution for hacker but not the > normal enterprise. In order to have monitoring support in the > enterprise environment you need an ability to force the browser to > proxy all the media through a monitoring application without any > application modification, via browser settings alone. OK, you're worried about supporting the interceptor, not about preventing the interception... right? My gut feeling is that the legitimate interceptor has to be able to say "only these apps are used for business purposes" - for those, he should be able to know how to do it. I don't think it's possible even in theory to intercept all possible applications, even with your own root-cert in the user's browser. It's probably even possible to prove it by showing that it's equivalent to solving the halting problem. So I guess administrators who have the need just have to say "these applications and no other". Harald --------------090404050608040300080802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/20/2012 05:10 PM, Roman Shpount wrote:

On Tue, Mar 20, 2012 at 11:39 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
On 03/20/2012 02:40 PM, Roman Shpount wrote:
Once again, I understand how this helps in case of HTTPS, but how would this help in case of WebRTC? Media description is carried in some sort of application defined protocol (can even be transmitted over an encrypted SCTP data channel or encrypted in javaScript), so monitoring proxy cannot reliably modify it. I understand how it can be allowed to fake the signature on modified SDP by inserting a certificate in the browser, but how would the proxy get to the SDP in the first place?

"this" = inserting a trust root in the browser?

Once you trust the root I inserted, I can intercept all your HTTPS connections, and thus I can replace all the Javascript you think you are loading from your trusted provider with Javascript of my choice.

Once your browser is running my Javascript, I can do anything the original application could - with the privilleges you granted to that application.

I think that's more or less "game over" when it comes to security.


"this" is inserting the root certificate. It is a game over as far as security is concerned, but the rest of your email completely missing my point.

If, as an owner of a computer, you want to enable media monitoring with an existing standard you need to know exactly how each application is implemented. This is a solution for hacker but not the normal enterprise. In order to have monitoring support in the enterprise environment you need an ability to force the browser to proxy all the media through a monitoring application without any application modification, via browser settings alone.

OK, you're worried about supporting the interceptor, not about preventing the interception... right?

My gut feeling is that the legitimate interceptor has to be able to say "only these apps are used for business purposes" - for those, he should be able to know how to do it.

I don't think it's possible even in theory to intercept all possible applications, even with your own root-cert in the user's browser. It's probably even possible to prove it by showing that it's equivalent to solving the halting problem.

So I guess administrators who have the need just have to say "these applications and no other".

                  Harald


--------------090404050608040300080802-- From roman@telurix.com Thu Mar 22 07:19:02 2012 Return-Path: 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 30DC421F85EA for ; Thu, 22 Mar 2012 07:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.784 X-Spam-Level: X-Spam-Status: No, score=-2.784 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 pkvzDvZo56le for ; Thu, 22 Mar 2012 07:19:01 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E52621F8595 for ; Thu, 22 Mar 2012 07:19:01 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1983376ghb.31 for ; Thu, 22 Mar 2012 07:19:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/GKX/voNZJ46YvwUUx+XFUbQpzegDIHCYKs/Oxy9gRI=; b=MVaVqOT9uW/nmYHakR+obtrvMF/uDL3JtJErSDHEifmblO0+GSzavEJx6o73K9VLq3 eePKpP5080w60FKeOqGupw4wcgCHFsBOCKi+GqfoUXlB2ySVT85FNTTveLRU6oJ3YCfX jPnhrlAjuu7/6+EWJy5/bP8ZtZPdzEmfDWBdmbXYdJVWy9SUzrV7rpnr+kFFp91hGmXh ad/eQ0m14AWhl5ChqBCyVig2lAwF6RkKmC67S828OJ9DDziWoa+bvRYwU0eWACGuwLdR uct7jYyqmXVETaoEKObc9c4t7u++d3g4wqM18PifshwZRt9EBveg/IF3oYfDlxnEHS4e CYCQ== Received: by 10.50.88.134 with SMTP id bg6mr1846823igb.29.1332425940592; Thu, 22 Mar 2012 07:19:00 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id b11sm2101526igq.7.2012.03.22.07.18.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 07:18:59 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1763204pbb.31 for ; Thu, 22 Mar 2012 07:18:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.191.161 with SMTP id gz1mr15108379pbc.76.1332425937556; Thu, 22 Mar 2012 07:18:57 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 22 Mar 2012 07:18:56 -0700 (PDT) In-Reply-To: <4F6AECC6.8020004@alvestrand.no> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> Date: Thu, 22 Mar 2012 10:18:56 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=e89a8ff1c35eb2941a04bbd5968e X-Gm-Message-State: ALoCoQnmwQmHLXA9E2FaaXVK7xCkzmux6jbFu69wPniG6smq4WPVHjujtsEPmmGs4kfeknrLSjLp Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:19:02 -0000 --e89a8ff1c35eb2941a04bbd5968e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 22, 2012 at 5:11 AM, Harald Alvestrand wrote: > ** > OK, you're worried about supporting the interceptor, not about preventing > the interception... right? > > My gut feeling is that the legitimate interceptor has to be able to say > "only these apps are used for business purposes" - for those, he should be > able to know how to do it. > > I don't think it's possible even in theory to intercept all possible > applications, even with your own root-cert in the user's browser. It's > probably even possible to prove it by showing that it's equivalent to > solving the halting problem. > > So I guess administrators who have the need just have to say "these > applications and no other". > > Yes, I was worried about supporting the interceptor. This is all related to my question of support of WebRTC applications in military, prisons, or financial organizations. I think WebRTC would be completely disabled in such locations unless web browser can be configured to confirm to some sort of communications and monitoring policy. I do not think enabling only certain applications is a sustainable solution, since application can only be enabled based on its URL, but this in no way implies that the actual protocol used for signaling exchange by this application will stay the same. In the best case this will result in tens of specialized monitoring rules that will need to be maintained. In the worst case, WebRTC would be simply disabled. At this point the only workable solution that I see is some sort of media proxy protocol. _____________ Roman Shpount --e89a8ff1c35eb2941a04bbd5968e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 22, 2012 at 5:11 A= M, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20 =20
OK, you're = worried about supporting the interceptor, not about preventing the interception... right?

My gut feeling is that the legitimate interceptor has to be able to say "only these apps are used for business purposes" - for th= ose, he should be able to know how to do it.

I don't think it's possible even in theory to intercept all pos= sible applications, even with your own root-cert in the user's browser. It's probably even possible to prove it by showing that it's equivalent to solving the halting problem.

So I guess administrators who have the need just have to say "thes= e applications and no other".


Yes, I was worried about suppor= ting the interceptor. This is all related to my question of support of WebR= TC applications in military, prisons, or financial organizations. I think W= ebRTC would be completely disabled in such locations unless web browser can= be configured to confirm to some sort of communications and monitoring pol= icy. I do not think enabling only certain applications is a sustainable sol= ution, since application can only be enabled based on its URL, but this in = no way implies that the actual protocol used for signaling exchange by this= application will stay the same. In the best case this will result in tens = of specialized monitoring rules that will need to be maintained. In the wor= st case, WebRTC would be simply disabled. At this point the only workable s= olution that I see is some sort of media proxy protocol.
_____________
Roman Shpount


--e89a8ff1c35eb2941a04bbd5968e-- From martin.thomson@gmail.com Thu Mar 22 08:33:36 2012 Return-Path: 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 EDCA421F8622 for ; Thu, 22 Mar 2012 08:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.63 X-Spam-Level: X-Spam-Status: No, score=-4.63 tagged_above=-999 required=5 tests=[AWL=-1.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 VJQyREH3ZXyh for ; Thu, 22 Mar 2012 08:33:35 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3400021F860B for ; Thu, 22 Mar 2012 08:33:35 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2141052bku.31 for ; Thu, 22 Mar 2012 08:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NmXIbPLnLwePEv59UciycD4k1BASVd6OrZforxS8BsM=; b=exvboXfltqtVcqd2FbqaQS64S18uQvk4+2tRy6HPzrBVAV903dxAvefBfDmPIR7iSb AV2wSOTN6CgxzqoHdhxdBHlz273Vgon9n3gpLbpqXSCsyhe6z6Vsp8VZsi3DsY7bF/nT 7d40AuIAXjlR8mgAY9Rh8WoutJrimseXonorninwcobo0c+2OYdHcQPtCQMKBdloB7S6 xNUcetpKS0wvvNV6rzOwsQNxWlc8CwUQWqCqGtlqypkOj0wKQ+9ZfKuK5an3hSsdlt/p JEltvV2Hke9ZIQbIdkvDaKRH1d70xUAuPgUVDJr09nLaruoSCwmpDw12ZINSmm73SIGm vbUw== MIME-Version: 1.0 Received: by 10.204.132.79 with SMTP id a15mr3107041bkt.86.1332430414329; Thu, 22 Mar 2012 08:33:34 -0700 (PDT) Received: by 10.204.121.208 with HTTP; Thu, 22 Mar 2012 08:33:31 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> Date: Thu, 22 Mar 2012 08:33:31 -0700 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:33:36 -0000 On 22 March 2012 07:18, Roman Shpount wrote: > Yes, I was worried about supporting the interceptor. Please see: http://tools.ietf.org/html/rfc2804 From roman@telurix.com Thu Mar 22 08:40:02 2012 Return-Path: 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 032F721F85A1 for ; Thu, 22 Mar 2012 08:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 uriK3an3omW4 for ; Thu, 22 Mar 2012 08:39:57 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id CE3FA21F85AF for ; Thu, 22 Mar 2012 08:39:56 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so836186wib.1 for ; Thu, 22 Mar 2012 08:39:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ShpxqHzdz/FfOs9O0pfDrmMl84EF8Gute8wRtSNTPVQ=; b=I9XQUco3QnAAWiui09+CPQLVdQ/5P4q5RRqlE0mTFC6Co1GvTng4cKQvZJGD6+r9gx 4gqTJQscihFrgFEsm4DR2M3Ouf5ZYPzDKmQsZcRSylD/2Z5F/BA3/uX+lEj4utzeXKKk oUEM4Vxh6aFSsv2Fhx2bwYqE8/Cd3Idqcdpf5uErB2B9YGSxTdKcJMjIla2Ad1/iBiwa nW/70UgozU/WWScGBV0kO5IILI63omllJlbsQKn0PbxjdHdNyFrFvCU3N7Yt8Uq9gwK6 D0dsSR6/qfyN7FNuVhL29Vpzdl7oZhnhY+JVe5h3/cSM9qYpJ+1TbhD+H7+fdBs5yfHb ZEXw== Received: by 10.50.153.193 with SMTP id vi1mr2231895igb.2.1332430785435; Thu, 22 Mar 2012 08:39:45 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id ut8sm2265939igc.11.2012.03.22.08.39.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 08:39:44 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1815892pbb.31 for ; Thu, 22 Mar 2012 08:39:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.40 with SMTP id pp8mr21441941pbb.13.1332430782474; Thu, 22 Mar 2012 08:39:42 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 22 Mar 2012 08:39:42 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> Date: Thu, 22 Mar 2012 11:39:42 -0400 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b10d17b7a286804bbd6b7c1 X-Gm-Message-State: ALoCoQkNPJfIwd3oCQBL4O/cdrtrc3zFgjnE/4KC/++8SazizqyUoPomerXbV1ZeVDwi2M2EwMZy Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:40:02 -0000 --047d7b10d17b7a286804bbd6b7c1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 22, 2012 at 11:33 AM, Martin Thomson wrote: > On 22 March 2012 07:18, Roman Shpount wrote: > > Yes, I was worried about supporting the interceptor. > > Please see: http://tools.ietf.org/html/rfc2804 > And I did see it. I suggest you do the same. I am not talking about providing a back door into the system to allow wiretapping. I am talking about a user voluntarily enabling network based recording of its own WebRTC traffic. So, if I am an enterprise, and I own the computer, I should be able to enforce a recording and communications policy on it. Enterprise can do it now with HTTP/HTTPS, why not WebRTC? _____________ Roman Shpount --047d7b10d17b7a286804bbd6b7c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 22, 2012 at 11= :33 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 22 March 2012 07:18, Roman Shpount <roman@telurix.com> wrote:
> Yes, I was worried about supporting the interceptor.

Please see: http://tools.ietf.org/html/rfc2804

And I did see it. I suggest you do the same. I am no= t talking about providing a back door into the system to allow wiretapping.= I am talking about a user voluntarily enabling network based recording of = its own WebRTC traffic. So, if I am an enterprise, and I own the computer, = I should be able to enforce a recording and communications policy on it. En= terprise can do it now with HTTP/HTTPS, why not WebRTC?
_____________
Roman Shpount

--047d7b10d17b7a286804bbd6b7c1-- From martin.thomson@gmail.com Thu Mar 22 08:55:31 2012 Return-Path: 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 61E0421F864F for ; Thu, 22 Mar 2012 08:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.613 X-Spam-Level: X-Spam-Status: No, score=-4.613 tagged_above=-999 required=5 tests=[AWL=-1.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 A-7+t7U4XEcj for ; Thu, 22 Mar 2012 08:55:30 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B09E21F8528 for ; Thu, 22 Mar 2012 08:55:30 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2162066bku.31 for ; Thu, 22 Mar 2012 08:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UbZp7pcVVrQHpNJX6fIvPSVaaSEeXmuUAwXMSgJt/+A=; b=sW5lObAonAt3fybvz+zo1skAONlMWOyXgWpoRrFSQnWaJgXTbHKXKtZpDq+fB3DZUJ plWnbzixCVAQYOU9HUOd7gXJ9ZeCYtdK8Lx4qiY7JyEVbT9Ur938XyZ5RdLw3r8MfmnU JIiuzXUWvRLitpKZO0wXZoSNWzRiSCPSqQj96vZaxTdIUkd6fPKf6QEJIreLOlE1GVVz CZQ1H1aK44BSUsY7oLQU92TNzUSjMKYGEKHh9WU0zrTz8OhN4v5RftR6A7KEy/XcOjSr 9CbmcYDf2iQanW+nBVwmuODxjROVkqUN6UX/7kcOCL/8CD6AeM7fu+d35oygoFlukWJC NsnA== MIME-Version: 1.0 Received: by 10.204.133.216 with SMTP id g24mr3151097bkt.104.1332431729637; Thu, 22 Mar 2012 08:55:29 -0700 (PDT) Received: by 10.204.121.208 with HTTP; Thu, 22 Mar 2012 08:55:29 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> Date: Thu, 22 Mar 2012 08:55:29 -0700 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:55:31 -0000 On 22 March 2012 08:39, Roman Shpount wrote: > So, if I am an enterprise, and I own the computer, I should be able > to enforce a recording and communications policy on it. Enterprise can do it > now with HTTP/HTTPS, why not WebRTC? If you can install trust anchors, what more do you need? A set of instructions? From roman@telurix.com Thu Mar 22 09:13:40 2012 Return-Path: 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 2443521F85ED for ; Thu, 22 Mar 2012 09:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 65Ydn8OeVrA8 for ; Thu, 22 Mar 2012 09:13:39 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 79DEF21F856F for ; Thu, 22 Mar 2012 09:13:39 -0700 (PDT) Received: by iazz13 with SMTP id z13so3880003iaz.31 for ; Thu, 22 Mar 2012 09:13:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=zsx6Grx05ULQ8KXGAn7uwBQD4bWGOXjaWrtwemmxNd0=; b=M3FJEw5jQfRPAmRwxh4T3t1H1mGd0vLnOmx4+WRCf+wm/i9UYNuWy59Lps2bjO+d3u SBNmvoWbLKGhicsljRbnE04NrbrGk/+QB/S5MsnUITneWAORJNqfo4pacaI5Nwp0wv/6 3LBKD8pZeT04836h5GJGAuGvKgiPkJSJAZmS2jIx3yUssGbCnuhJDaeB4VhJoDnJDx5i pPrzJE38KsRf49iPWNfWIopaLaNMzQyhVwUhcjNQrFARyUKF8yKzfJHnBWLh8EncUs0/ DFqrxOQ4ZHHG4/pJPm0cdTkW5lPzVE9TCzI0Fo8BWaUH8e05n/bpxryzu8JxVOCH44Mu dDdw== Received: by 10.43.52.138 with SMTP id vm10mr5238843icb.31.1332432818507; Thu, 22 Mar 2012 09:13:38 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id t8sm1668162igw.0.2012.03.22.09.13.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 09:13:36 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1837225pbb.31 for ; Thu, 22 Mar 2012 09:13:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.40 with SMTP id pp8mr21649510pbb.13.1332432813733; Thu, 22 Mar 2012 09:13:33 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 22 Mar 2012 09:13:33 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> Date: Thu, 22 Mar 2012 12:13:33 -0400 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b10d17b8cb87504bbd7305c X-Gm-Message-State: ALoCoQnHaWuGblfPD+sQKjiULiMsNnnUiCwBAXqRI+pLOmuMJQXCtZBXzDi/sDhpxMcc3QNpH6FG Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 16:13:40 -0000 --047d7b10d17b8cb87504bbd7305c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 22, 2012 at 11:55 AM, Martin Thomson wrote: > On 22 March 2012 08:39, Roman Shpount wrote: > > So, if I am an enterprise, and I own the computer, I should be able > > to enforce a recording and communications policy on it. Enterprise can > do it > > now with HTTP/HTTPS, why not WebRTC? > > If you can install trust anchors, what more do you need? A set of > instructions? > Ok, repeating my previous email: If, as an owner of a computer, you want to enable media monitoring with an existing standard you need to know exactly how each application is implemented. This is a solution for hacker but not the normal enterprise. In order to have monitoring support in the enterprise environment you need an ability to force the browser to proxy all the media through a monitoring application without any application modification, via browser settings alone. For the monitoring proxy to work it would need some sort of network protocol to communicate with the browser (similar how HTTP proxy needs a network protocol to work with the browser). I would expect what's needed is some sort of network based protocol to send the SDP to a proxy, get modified SDP back and pass it to JavaScript (or take the SDP from JavaScript, through the proxy and to the media stack). _____________ Roman Shpount --047d7b10d17b8cb87504bbd7305c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 22, 2012 at 11:55 = AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 22 March 2012 08:39, Roman Shpount <roman@telurix.com> wrote:
> So, if I am an enterprise, and I own the computer, I should be able > to enforce a recording and communications policy on it. Enterprise can= do it
> now with HTTP/HTTPS, why not WebRTC?

If you can install trust anchors, what more do you need? =A0A set of = instructions?

Ok, repeating my previous email:

If, as an ow= ner of a computer, you want to enable media monitoring with=20 an existing standard you need to know exactly how each application is=20 implemented. This is a solution for hacker but not the normal=20 enterprise. In order to have monitoring support in the enterprise=20 environment you need an ability to force the browser to proxy all the=20 media through a monitoring application without any application=20 modification, via browser settings alone. For the monitoring proxy to work = it would need some sort of network=20 protocol to communicate with the browser (similar how HTTP proxy needs a network protocol to work with the browser). I would expect what's=20 needed is some sort of network based protocol to send the SDP to a=20 proxy, get modified SDP back and pass it to JavaScript (or take the SDP=20 from JavaScript, through the proxy and to the media stack).
____________= _
Roman Shpount


--047d7b10d17b8cb87504bbd7305c-- From ted.ietf@gmail.com Thu Mar 22 09:24:54 2012 Return-Path: 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 8C5C121F85C0 for ; Thu, 22 Mar 2012 09:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.694 X-Spam-Level: X-Spam-Status: No, score=-3.694 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 l-Sx7ZVo6Q48 for ; Thu, 22 Mar 2012 09:24:54 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAF3721F8573 for ; Thu, 22 Mar 2012 09:24:53 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2599920vcb.31 for ; Thu, 22 Mar 2012 09:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MCpQQCcFyF9lPw2aZ5XrydjEORQkjRnJT86DBpKLIDA=; b=k+tNrUSkCYguKHR86Bni1SbJIwubI/dfuXncsDW0j+IeQq+/h4EE0u1wSetRSo3e02 DF0w7aeS3xxvtr5I9R1d5IKxnlamMnLTIdcTC27D0AmhWHPhZuHPqpcx7KA66RUEnQaY S6PQ63OTj1PoA6FVifVTMewxqInzOTjYPSQZOAsMI9lkR3JhRbf2UOOD0To1gNyfjhnR 6/GiznV9svPT8CCysYzt0B0KixfwEisrstygLMclEeiw5TioqQ1N1rERSLeOa8CAIKdf dPCCP2xedmbY4Fs8HcCqaRqIdJGk0Px2QTbnITSh2JBjmBDFkkMZqJ7CdmFeFKsE3OR1 FVSw== MIME-Version: 1.0 Received: by 10.52.99.6 with SMTP id em6mr2756791vdb.116.1332433493514; Thu, 22 Mar 2012 09:24:53 -0700 (PDT) Received: by 10.52.162.99 with HTTP; Thu, 22 Mar 2012 09:24:53 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> Date: Thu, 22 Mar 2012 09:24:53 -0700 Message-ID: From: Ted Hardie To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 16:24:54 -0000 On Thu, Mar 22, 2012 at 9:13 AM, Roman Shpount wrote: > > >> If you can install trust anchors, what more do you need? =A0A set of >> instructions? > > > Ok, repeating my previous email: > > If, as an owner of a computer, you want to enable media monitoring with a= n > existing standard you need to know exactly how each application is > implemented. Given that we are talking about downloadable applications, this is going to require some doing. You're not going to know how each application is implemented without vetting them in some way, which seems to result in the whitelisting exercise that Harald pointed at earlier. >This is a solution for hacker but not the normal enterprise. In > order to have monitoring support in the enterprise environment you need a= n > ability to force the browser to proxy all the media through a monitoring > application without any application modification, via browser settings > alone. But you are not suggesting, I hope, that all browsers must have such a setting, and clearly we would not suggest that it must always be on. In the environment you describe you're basically going to have to have both a trust anchor that allows you to man-in-the-middle all traffic and a network configuration that makes the path through the man-in-the-middle the most effective one. Neither of those is within the charter of this working group, in my personal opinion. If you would like me to caucus with the other chairs to see whether it is our opinion with our hats on, please let me know. regards, Ted Hardie From roman@telurix.com Thu Mar 22 09:37:02 2012 Return-Path: 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 AFE1421F860B for ; Thu, 22 Mar 2012 09:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Wrnsk814AmG2 for ; Thu, 22 Mar 2012 09:37:02 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3FFC21F85EC for ; Thu, 22 Mar 2012 09:37:01 -0700 (PDT) Received: by iazz13 with SMTP id z13so3906586iaz.31 for ; Thu, 22 Mar 2012 09:37:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=aYN+jmhyV464D3EYXTviEkjpdHTePu+oO2syNBdVhXs=; b=fEQmawJYQVO7+9r4Qnf/DmvJbOIcwDI9ZgzmGFfPvSqO7UMpdDA9beR1UsJv6ONzt8 W2Fuo9iaZ0YmMeCIDFJwF82VOw8+JLp1zDR6peM+/ARYBpMbtj1s7GatVePbS9+s3m2y a0Pd+X9+YjSrFbi9VxwpPJDa9NBhBaGlNgItnCqZ9IG/+UT/SYGSmnB3QcJ0AZNbw3/a yPeYtlBT7ZR6zVqyT9oH0jkU6W+v16mzsibU9qGvMT/At6jdsmY46AUELfZ6sRS3EiIv HQrJw7U3OGs84O+Wx3DHFdUt6GgJzHWdYD3/c0qc3sVJXq9kQxnQnWOPLe++9gnmZw6P S8dA== Received: by 10.43.126.68 with SMTP id gv4mr5270941icc.30.1332434221503; Thu, 22 Mar 2012 09:37:01 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id vr4sm3981936igb.1.2012.03.22.09.36.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 09:37:01 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1852245pbb.31 for ; Thu, 22 Mar 2012 09:36:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.99 with SMTP id ot3mr21411243pbb.160.1332434218712; Thu, 22 Mar 2012 09:36:58 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 22 Mar 2012 09:36:58 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> Date: Thu, 22 Mar 2012 12:36:58 -0400 Message-ID: From: Roman Shpount To: Ted Hardie Content-Type: multipart/alternative; boundary=047d7b15a68b4aff0a04bbd78473 X-Gm-Message-State: ALoCoQmzLoAtu1a+w+eCBHGSDy5fa/ZeVWko0A4znYwXt8CwtlwO8J2Lr6NSsdFS7zOkingB9Qgk Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 16:37:02 -0000 --047d7b15a68b4aff0a04bbd78473 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 22, 2012 at 12:24 PM, Ted Hardie wrote: > > But you are not suggesting, I hope, that all browsers must have such a > setting, and clearly we would not suggest that it must always be on. > In the environment you describe you're basically going to have to have > both a trust anchor that allows you to man-in-the-middle all traffic > and a network configuration that makes the path through the > man-in-the-middle the most effective one. Neither of those is within > the charter of this working group, in my personal opinion. If you > would like me to caucus with the other chairs to see whether it is our > opinion with our hats on, please let me know. > > What I am suggesting is that there is a need for some sort of network protocol to enable an external network element to monitor/modify SDP media descriptions being passed to and from WebRTC. I would assume that implementation and use of this protocol would be optional to a web browser (similar how implementation and use of a SOCKS HTTP proxy is optional to a web browser). In a sense, this should not be any different then any of the HTTP proxy protocols. I do agree that the whole trust anchor issue is outside of the group charter, especially since it is already supported and implemented by the web browsers, but I would like to ask the chairs to see if media proxy protocol actually falls under the WebRTC charter. Thank You, _____________ Roman Shpount --047d7b15a68b4aff0a04bbd78473 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 22, 2012 at 12:24 = PM, Ted Hardie <= ted.ietf@gmail.com> wrote:

But you are not suggesting, I hope, that all browsers must have such a
setting, and clearly we would not suggest that it must always be on.
In the environment you describe you're basically going to have to have<= br> both a trust anchor that allows you to man-in-the-middle all traffic
and a network configuration that makes the path through the
man-in-the-middle the most effective one. =A0Neither of those is within
the charter of this working group, in my personal opinion. =A0If you
would like me to caucus with the other chairs to see whether it is our
opinion with our hats on, please let me know.


What I am suggesting is that there is a need for= some sort of network protocol to enable an external network element to mon= itor/modify SDP media descriptions being passed to and from WebRTC. I would= assume that implementation and use of this protocol would be optional to a= web browser (similar how implementation and use of a SOCKS HTTP proxy is o= ptional to a web browser). In a sense, this should not be any different the= n any of the HTTP proxy protocols. I do agree that the whole trust anchor i= ssue is outside of the group charter, especially since it is already suppor= ted and implemented by the web browsers, but I would like to ask the chairs= to see if media proxy protocol actually falls under the WebRTC charter.
Thank You,
_____________
Roman Shpount


--047d7b15a68b4aff0a04bbd78473-- From igor.faynberg@alcatel-lucent.com Thu Mar 22 10:22:59 2012 Return-Path: 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 8C59921F85A3 for ; Thu, 22 Mar 2012 10:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.873 X-Spam-Level: X-Spam-Status: No, score=-8.873 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8] 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 pKQ80PEoATer for ; Thu, 22 Mar 2012 10:22:59 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 14E4C21F856A for ; Thu, 22 Mar 2012 10:22:58 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q2MHMvIB024533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Mar 2012 12:22:57 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2MHMujC015371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Mar 2012 12:22:57 -0500 Received: from [135.222.232.245] (USMUYN0L055118.mh.lucent.com [135.222.232.245]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2MHMsxv001206; Thu, 22 Mar 2012 12:22:55 -0500 (CDT) Message-ID: <4F6B5FEE.9060706@alcatel-lucent.com> Date: Thu, 22 Mar 2012 13:22:54 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "rtcweb@ietf.org" Subject: [rtcweb] IdP in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 17:22:59 -0000 Eric, A question: For the case of BrowserID, I understand that a client gets a certificate from an IdP. If so, why you and I would not use the certificates from our respective IdPs in order to authenticate each other in DTLS? Igor From ted.ietf@gmail.com Thu Mar 22 10:30:16 2012 Return-Path: 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 552FB21F85E3 for ; Thu, 22 Mar 2012 10:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.692 X-Spam-Level: X-Spam-Status: No, score=-3.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 y3Hxsp0I1ZJr for ; Thu, 22 Mar 2012 10:30:15 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58B7A21F85CF for ; Thu, 22 Mar 2012 10:30:15 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1303377vbb.31 for ; Thu, 22 Mar 2012 10:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=szTOubLOq09UhwaaTLKqKnRa1hGEn4B4rdF85sn7Bg4=; b=Rdnzec2IsYiKpUka8uF5AoWQKtABJiDYRbltwQhqLU+zE4yqnncQADYaY9M/c136YC aQAwBS10CI3pxbdgygic7oTL5YJ8cu/vQBiBCUzepqasBE67NVFh/7ne8zfYk8LzMQSk +UbcsvSj/0Q9ekBgd49zHkTHsq8/W7CWduxNwbP8Rum1Sa/rbLdTDZJvewqCn0hZQS2d /3NinYB7jKZ+GTBZFBIMfClhasZM8p4wTF2xe/RPSQF2tZORCh8na+0I50nTIfEeVLsB 9gdD48d9QlEUu9nFemeEf3mjCdcO5saFfhuWewq7cXi1IxOMLj5vnW67ylxXIBTeS9ng kDQQ== MIME-Version: 1.0 Received: by 10.52.99.6 with SMTP id em6mr2837717vdb.116.1332437414923; Thu, 22 Mar 2012 10:30:14 -0700 (PDT) Received: by 10.52.162.99 with HTTP; Thu, 22 Mar 2012 10:30:14 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> Date: Thu, 22 Mar 2012 10:30:14 -0700 Message-ID: From: Ted Hardie To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 17:30:16 -0000 On Thu, Mar 22, 2012 at 9:36 AM, Roman Shpount wrote: > I do agree that the whole trust anchor issue is > outside of the group charter, especially since it is already supported and > implemented by the web browsers, but I would like to ask the chairs to see > if media proxy protocol actually falls under the WebRTC charter. > Okay, what language in the current charter do you see as covering this activity? regards, Ted Hardie From ekr@rtfm.com Thu Mar 22 10:54:42 2012 Return-Path: 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 B71F121F85F3 for ; Thu, 22 Mar 2012 10:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 OevTNXUm2jzc for ; Thu, 22 Mar 2012 10:54:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C84921F851B for ; Thu, 22 Mar 2012 10:54:42 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2704437vcb.31 for ; Thu, 22 Mar 2012 10:54:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=XdOAKYid8LT6ZwHS/+Vp37pUXZ4g45nceR6oyeK7cZo=; b=aMNvxmrOOhQi1iDyuSKR8boYxA3qETw6FXCZRiAka/QOz5pSJX6/XbNILpBHqhjxjv mIBjdiiBeIU88VWOCNjSFr3sz+RMjAW4KcVhraWMc9o8JVWV/t5uVEJI4hsZ9ZUTFosh EVJ/LDVhocAHv6hi7ru1wOaJSR39j0kyH/ShAyQIia9v7fMbfq197oLrFfe6t+nSWbqc TPD+TQ+8mJB5j+OUlc685cR3OQBOOoRXTy+QzfMKu6HeC59lke3nRHDvUE8ONuRSbEz1 kL/eWeBvjEziAhJC6U5js6Rlaf6caHc7HPVSD1pWrSiz9LXs8v5nyrLUjZ1/Aczd7EqX yHMA== Received: by 10.52.67.11 with SMTP id j11mr3477727vdt.40.1332438881316; Thu, 22 Mar 2012 10:54:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Thu, 22 Mar 2012 10:53:42 -0700 (PDT) X-Originating-IP: [81.253.52.0] In-Reply-To: <4F6B5FEE.9060706@alcatel-lucent.com> References: <4F6B5FEE.9060706@alcatel-lucent.com> From: Eric Rescorla Date: Thu, 22 Mar 2012 18:53:42 +0100 Message-ID: To: igor.faynberg@alcatel-lucent.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlgTJ6Gv7hRl7jfCmRPmOaHTuafrHxAf/glhdO2W1EP6F6lFKQW/7KeetVVakEttMIb/h3r Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] IdP in 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 17:54:42 -0000 Good question. 1. BrowserID certificates aren't X.509, and that's all the TLS/DTLS will do= . 2. This lets us be agnostic about IdP mechanisms without having to change TLS every time we add a new one. -Ekr On Thu, Mar 22, 2012 at 6:22 PM, Igor Faynberg wrote: > Eric, > > A question: =A0For the case of BrowserID, I understand that a client gets= a > certificate from an IdP. =A0 If so, why you and I would not use the > certificates from our respective IdPs in order to authenticate each other > =A0in DTLS? > > Igor > > > From igor.faynberg@alcatel-lucent.com Thu Mar 22 11:18:03 2012 Return-Path: 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 5B9D921F8597 for ; Thu, 22 Mar 2012 11:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.546 X-Spam-Level: X-Spam-Status: No, score=-7.546 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 bar1WTlI1oCK for ; Thu, 22 Mar 2012 11:18:02 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id C6D7821F8596 for ; Thu, 22 Mar 2012 11:18:02 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q2MIHx3r007932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Mar 2012 13:18:00 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2MIHxVg015555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Mar 2012 13:17:59 -0500 Received: from [135.222.232.245] (USMUYN0L055118.mh.lucent.com [135.222.232.245]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2MIHxZv015165; Thu, 22 Mar 2012 13:17:59 -0500 (CDT) Message-ID: <4F6B6CD6.2070801@alcatel-lucent.com> Date: Thu, 22 Mar 2012 14:17:58 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eric Rescorla References: <4F6B5FEE.9060706@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] IdP in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 18:18:03 -0000 Thanks! Now I understand. My only follow-up question (and that could probably wait until the next week) is why not make BrowserID certificate adhere to X.509. If we issue self-signed X.509 certificates ourselves, what is in the way of any IdP doing just that? Igor On 3/22/2012 1:53 PM, Eric Rescorla wrote: > Good question. > > 1. BrowserID certificates aren't X.509, and that's all the TLS/DTLS will do. > 2. This lets us be agnostic about IdP mechanisms without having to change > TLS every time we add a new one. > > -Ekr > > > On Thu, Mar 22, 2012 at 6:22 PM, Igor Faynberg > wrote: >> Eric, >> >> A question: For the case of BrowserID, I understand that a client gets a >> certificate from an IdP. If so, why you and I would not use the >> certificates from our respective IdPs in order to authenticate each other >> in DTLS? >> >> Igor >> >> >> From dwing@cisco.com Thu Mar 22 15:44:34 2012 Return-Path: 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 E822221F845B for ; Thu, 22 Mar 2012 15:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.382 X-Spam-Level: X-Spam-Status: No, score=-109.382 tagged_above=-999 required=5 tests=[AWL=1.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 kHpM8BdZlNMs for ; Thu, 22 Mar 2012 15:44:34 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D6B9621F845A for ; Thu, 22 Mar 2012 15:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1820; q=dns/txt; s=iport; t=1332456270; x=1333665870; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=HCkSZ9AbXS3vqdmsY9PZS5L9rMXqA1K42uFQYIcfRsI=; b=SycHTGPKfOD5U8jeAKW1DX2H9dQw1b+pE4VlG3ZxkE5VxFo20PeNkCri d9LBboSY1JsCo3qXobWcb6yg+kkVBmS2c1bZZcsu0+tQU4l3lHs937av+ ZqwMYxrxfSZNXJCHilR0QBCyOzXbE84W2rcqXs/zoJgq/12kRgYoz8Rgp 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFANqqa0+rRDoJ/2dsb2JhbABEp2SPWYEHggkBAQEECAoBFxA/DAEDAgkPAgQBASgHGSMKCQgBAQQBEgsQB4dnmRyNUZE6kGQEiFaFE5Y2gWiDBw X-IronPort-AV: E=Sophos;i="4.73,633,1325462400"; d="scan'208";a="37304583" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 22 Mar 2012 22:44:29 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2MMiTBP026833; Thu, 22 Mar 2012 22:44:29 GMT From: "Dan Wing" To: "'Roman Shpount'" , "'Harald Alvestrand'" , "'Ted Hardie'" References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> In-Reply-To: Date: Thu, 22 Mar 2012 15:44:29 -0700 Message-ID: <03fa01cd087d$57899120$069cb360$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0INr3Z1+RYf6xDTCirryldOl72eAARbPMA Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 22:44:35 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Roman Shpount > Sent: Thursday, March 22, 2012 7:19 AM > To: Harald Alvestrand > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris ... > Yes, I was worried about supporting the interceptor. This is all > related to my question of support of WebRTC applications in military, > prisons, or financial organizations. I think WebRTC would be completely > disabled in such locations unless web browser can be configured to > confirm to some sort of communications and monitoring policy. I do not > think enabling only certain applications is a sustainable solution, > since application can only be enabled based on its URL, but this in no > way implies that the actual protocol used for signaling exchange by > this application will stay the same. In the best case this will result > in tens of specialized monitoring rules that will need to be > maintained. In the worst case, WebRTC would be simply disabled. At this > point the only workable solution that I see is some sort of media proxy > protocol. The SIPREC working group, formed in March 2010, has solutions for this problem. The problem is not created by RTCWEB. Disabling encryption is not necessary -- nor desirable. "Jails" get brought up in this context often, so using that same example, consider a prisoner at a jail communicating with their lawyer. The prisoner needs secure communications with their lawyer without the risk of the communications being leaked to the press by anyone along the media path. For details see http://tools.ietf.org/wg/siprec/ We will have a brietf presentation on SIPREC during my session at RTCWEB, explaining how it can work with RTCWEB. -d From roman@telurix.com Thu Mar 22 18:31:24 2012 Return-Path: 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 F047921E8013 for ; Thu, 22 Mar 2012 18:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 pTdl7qaIt9ex for ; Thu, 22 Mar 2012 18:31:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42AA821E8024 for ; Thu, 22 Mar 2012 18:31:24 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2643978ggm.31 for ; Thu, 22 Mar 2012 18:31:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=shG2V1uv2lOCwK13oBH97H6rL/qCNEbyWcZvXtOHWYg=; b=fm2ijsSYvQ8ckWJ7AmCb533Edb6drZBery/xqRhgoissC/GEuegPkpcr7PDZDqlzoL hFHugBhH38KOsw3WG7s7XSX/n8fdebw6TQS73Oa5g+E7uK729tRxgP4dKYlGd18Qdfwa VKeXn9xTGhaKFbuCRKaqQC/ZbHYf2gab/aJ2zVMKjALkDvQ/hfnP/6+555O4StRrg0GS oleQ0NMNwkgVHwiN9S4WSakZPgKYMSjAwYpnH8qxvaysGCr5J6LBgDTtth2o7yd1p9ic jZrAvRt9SGsDBaSccmhmUYTZtObJqaBw3DLJ1icdtrrJDX6iqpJZ5MWdus2uMok7gugS ob2g== Received: by 10.236.37.132 with SMTP id y4mr10556232yha.10.1332466283805; Thu, 22 Mar 2012 18:31:23 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id n24sm17376880yhj.13.2012.03.22.18.31.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 18:31:22 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2643965ggm.31 for ; Thu, 22 Mar 2012 18:31:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.201.98 with SMTP id jz2mr24614850pbc.97.1332466281817; Thu, 22 Mar 2012 18:31:21 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 22 Mar 2012 18:31:21 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> Date: Thu, 22 Mar 2012 21:31:21 -0400 Message-ID: From: Roman Shpount To: Ted Hardie Content-Type: multipart/alternative; boundary=047d7b15aee96726bd04bbdefbd1 X-Gm-Message-State: ALoCoQm6EyY18Mihv4Ms/yEIb1IlqtHnHHfD78vLRvBvRhyA2sEfrY1k7eh6SojNdOPvQNumLzbT Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 01:31:25 -0000 --047d7b15aee96726bd04bbdefbd1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 22, 2012 at 1:30 PM, Ted Hardie wrote: > Okay, what language in the current charter do you see as covering > this activity? > > I would say that this activity would be covered by: 2. Define a security model that describes the security and privacy goals and specifies the security protocol mechanisms necessary to achieve those goals. 3. Define the solution - protocols and API requirements - for firewall and NAT traversal. I do consider ability to enforce the enterprise or location communications policy on WebRTC clients to be one of the requirements for security and privacy. I expect that unless ability to enforce such communication policy within enterprises or other organizations is provided, WebRTC would be simply disabled. In practical terms, I expect that an organization that enforces a communication policy disables routing to public internet and only allows communications via a company controlled HTTP proxy. Such setup would effectively prevent WebRTC from operations. What I am suggesting is to provide a complimentary protocol for inspection and modification of WebRTC SDP messages which would allow WebRTC enabled browser to control an enterprise edge media proxy and would allow WebRTC media traffic to traverse the enterprise firewall and to operate in such environment. I do consider such functionality as installing trust anchors, SDP resigning, media re-encoding and media recording by the edge proxy to be implementation details and to be outside of the scope of this chapter. _____________ Roman Shpount --047d7b15aee96726bd04bbdefbd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 22, 2012 at 1:30 P= M, Ted Hardie <t= ed.ietf@gmail.com> wrote:
Okay, what language in the current charter do you see as =A0covering
this activity?


I would say that this activity would be covered = by:

2. Define a security model that describes the security and pr= ivacy
goals and specifies the security protocol mechanisms necessa= ry
to achieve those goals.

3. Define the solution - protocols and API requirements - for firewall and NAT traversal.

I do consider ability to enforce = the enterprise or location communications policy on WebRTC clients to be on= e of the requirements for security and privacy. I expect that unless abilit= y to enforce such communication policy within enterprises or other organiza= tions is provided, WebRTC would be simply disabled.

In practical terms, I expect that an organization that enforces a commu= nication policy disables routing to public internet and only allows communi= cations via a company controlled HTTP proxy. Such setup would effectively p= revent WebRTC from operations. What I am suggesting is to provide a complim= entary protocol for inspection and modification of WebRTC SDP messages whic= h would allow WebRTC enabled browser to control an enterprise edge media pr= oxy and would allow WebRTC media traffic to traverse the enterprise firewal= l and to operate in such environment.

I do consider such functionality as installing trust anchors, SDP resig= ning, media re-encoding and media recording by the edge proxy to be impleme= ntation details and to be outside of the scope of this chapter.
________= _____
Roman Shpount

--047d7b15aee96726bd04bbdefbd1-- From HKaplan@acmepacket.com Thu Mar 22 21:29:08 2012 Return-Path: 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 6B23021F8484 for ; Thu, 22 Mar 2012 21:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] 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 JFg7p9GdKbkh for ; Thu, 22 Mar 2012 21:29:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2D14821F8480 for ; Thu, 22 Mar 2012 21:29:06 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 23 Mar 2012 00:29:05 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Fri, 23 Mar 2012 00:29:05 -0400 From: Hadriel Kaplan To: Roman Shpount Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHNCK16ypv2rWTuBE2/yYvnMpOpsQ== Date: Fri, 23 Mar 2012 04:29:04 +0000 Message-ID: <13C620B3-1297-4212-B61C-5643E08E9748@acmepacket.com> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9674BA9C486CF54AA8BE80518582A862@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 04:29:08 -0000 comments inline=85 On Mar 22, 2012, at 9:31 PM, Roman Shpount wrote: > I would say that this activity would be covered by: Did you mean to have a #1 before #2 below? Your email was missing a #1. > 2. Define a security model that describes the security and privacy > goals and specifies the security protocol mechanisms necessary > to achieve those goals.=20 We've got that: http://tools.ietf.org/html/draft-ietf-rtcweb-security http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch > 3. Define the solution - protocols and API requirements - for > firewall and NAT traversal. We've got that, though not in one doc: http://tools.ietf.org/html/draft-ietf-rtcweb-overview http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements http://tools.ietf.org/html/draft-ietf-rtcweb-jsep > I do consider ability to enforce the enterprise or location communication= s policy on WebRTC clients to be one of the requirements for security and p= rivacy. OK, so what you're really saying is we have #2 and #3, but you don't agree = they cover the needs, and you want more added to #2 (and ultimately #3), ri= ght? > I expect that unless ability to enforce such communication policy within = enterprises or other organizations is provided, WebRTC would be simply disa= bled.=20 > In practical terms, I expect that an organization that enforces a communi= cation policy disables routing to public internet and only allows communica= tions via a company controlled HTTP proxy. Such setup would effectively pre= vent WebRTC from operations. What I am suggesting is to provide a complimen= tary protocol for inspection and modification of WebRTC SDP messages which = would allow WebRTC enabled browser to control an enterprise edge media prox= y and would allow WebRTC media traffic to traverse the enterprise firewall = and to operate in such environment. Well... if they really can't enforce their policies, then by definition the= y *should* disable it. That's a feature, not a bug. And luckily it *can* = be disabled, which is also a feature of WebRTC. =20 Having said that, I don't understand why you think an organization that has= strict monitoring policies can't monitor and enforce WebRTC traffic, both = the HTTP *and* the media/data channels. They *can* do it. It's just not "= automagic", and not cheap. But that's ok - I don't think we need to optimi= ze the deployment complexity or cost structure for that model. -hadriel From HKaplan@acmepacket.com Thu Mar 22 21:45:27 2012 Return-Path: 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 32E5921F847C for ; Thu, 22 Mar 2012 21:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] 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 x2va3ZeMmhwn for ; Thu, 22 Mar 2012 21:45:24 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id D96BE21E8045 for ; Thu, 22 Mar 2012 21:45:22 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 23 Mar 2012 00:45:15 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Fri, 23 Mar 2012 00:45:15 -0400 From: Hadriel Kaplan To: Harald Alvestrand Thread-Topic: [rtcweb] SDES vs DTLS-SRTP revisited Thread-Index: AQHNCK+9SrtHmQaTeUW0LPb8el1DRw== Date: Fri, 23 Mar 2012 04:45:15 +0000 Message-ID: References: <4F685C45.5080106@alvestrand.no> <4F68A9B6.2050101@alvestrand.no> In-Reply-To: <4F68A9B6.2050101@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <96F7CB57484A9E42995C736A4FF3BBD7@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDES vs DTLS-SRTP revisited X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 04:45:28 -0000 On Mar 20, 2012, at 12:00 PM, Harald Alvestrand wrote: > On 03/20/2012 04:44 PM, Hadriel Kaplan wrote: >> On Mar 20, 2012, at 6:30 AM, Harald Alvestrand wrote: >>=20 >>> I don't get this scenario. If Alice calls Bob using two different gatew= ays, won't she go through a credentials and fingerprint exchange with the g= ateways? >>> In that case, wouldn't the fingerprint belong to the gateway? >> Yes, but the statement being made was in the context of Alice calling Bo= b, them seeing their browsers claim DTLS-SRTP "secured" or whatever, and th= em being super-geeks and checking the detailed info of what the actual DTLS= fingerprints were, and finding they don't both see the same fingerprints..= . and that they would thus believe there was either a software bug or a mal= icious middleman. > So we've uncovered a requirement here: When a fingerprint is shown, it sh= ould clearly identify what it is the fingerprint of - in this case, the gat= eway that relays the call to Bob, not Bob. Yup. So long as no gateways are named "Bob", of course, or no humans are n= amed "Gateway". ;) -hadriel From HKaplan@acmepacket.com Thu Mar 22 22:39:45 2012 Return-Path: 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 B5C7421F849B for ; Thu, 22 Mar 2012 22:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] 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 tchorTA9dv9c for ; Thu, 22 Mar 2012 22:39:44 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAC521F849A for ; Thu, 22 Mar 2012 22:39:44 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 23 Mar 2012 01:39:36 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Fri, 23 Mar 2012 01:39:36 -0400 From: Hadriel Kaplan To: Roman Shpount Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHNCLdUIa8zbswfEEuejG7/Z9fuSQ== Date: Fri, 23 Mar 2012 05:39:35 +0000 Message-ID: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="Windows-1252" Content-ID: <47FB1B26E5C6344AB24B44D5B828317C@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 05:39:45 -0000 On Mar 20, 2012, at 9:40 AM, Roman Shpount wrote: > Once again, I understand how this helps in case of HTTPS, but how would t= his help in case of WebRTC? Media description is carried in some sort of ap= plication defined protocol (can even be transmitted over an encrypted SCTP = data channel or encrypted in javaScript), so monitoring proxy cannot reliab= ly modify it. I understand how it can be allowed to fake the signature on m= odified SDP by inserting a certificate in the browser, but how would the pr= oxy get to the SDP in the first place? I was trying to follow this thread backwards from today, to try to grok how= you got to the conclusion that an organization with strict media monitorin= g policies wouldn't be able to do so for WebRTC. I think the above email i= s where I get disconnected form the train of thought. If, as in another email you sent, an organization such as the military or j= ail or whatever controls its network such that they use the whitelist model= of only authorized applications allowed our of their network, and everythi= ng goes through the HTTP proxy, then the above statement of: > Media description is carried in some sort of application defined protocol= (can even be transmitted over an encrypted SCTP data channel or encrypted = in javaScript), so monitoring proxy cannot reliably modify it. =85 makes no sense to me. If you were preventing unknown applications, you would not allow unknown UD= P or TCP destination ports to be used to get out of the network. The HTTP = Proxy has to (1) know your web application wants to use another set of port= s, and (2) has to allow it. Ergo, there can be no "encrypted SCTP data cha= nnel" that was not previously authorized; nor would encrypting SDP-type-inf= o in Javascript help you one iota, because you won't be able to actually us= e it to send media, since the HTTP proxy is not opening new ports for you t= o reach the Internet. So I don't understand what the problem is. If you run a super-tight networ= k like that and you *do not* want WebRTC to work because you can't monitor = it, then by design it won't work. If you run a super-tight network like th= at and you *do* want WebRTC to work, then you either have to be willing to = install custom browsers/apps, or your HTTP Proxy has to be able to see the = HTTP traffic and correctly parse the Javascript-passed data and be a media = b2bua. That's a really nasty set of constraints, especially trying to grok= the javascript enough to be a media b2bua, and undoubtedly means it won't = work for many WebRTC websites. But that's arguably the right thing to happ= en - downloading javascript is akin to downloading a new application for ea= ch website, and again by definition this is a network that only wants to al= low applications it wants to allow, so that's what it gets: per-application= control, and thus requires per-application knowledge/support. Anything yo= ur proxy doesn't understand doesn't work, but again that's kinda the point = of a super-tight policy. Personally, if I were running such an org, and I don't know if it's possibl= e, but I'd go get some form of rootkit/kernel-mod to intercept audio/video/= keystrokes well below the user layer, so that you wouldn't have to worry wh= at application was running - just intercept the audio/screen/keyboard somew= here near the drivers. Presumably some companies make such things, for jus= t such organizations? (sort of like the equivalent of CarrierIQ) That way = it doesn't matter whether it's WebRTC, Flash, or native apps. -hadriel From pravindran@sonusnet.com Thu Mar 22 23:40:12 2012 Return-Path: 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 90B2221E8013 for ; Thu, 22 Mar 2012 23:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[AWL=1.612, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 qDr-Vv4JwSCO for ; Thu, 22 Mar 2012 23:40:12 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id 15E0821E804E for ; Thu, 22 Mar 2012 23:40:05 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKT2waxZAL1tOXWj5+GBXa2XzTflnlZwdB@postini.com; Thu, 22 Mar 2012 23:40:06 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 23 Mar 2012 02:40:20 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 12:10:00 +0530 From: "Ravindran, Parthasarathi" To: Dan Wing , 'Roman Shpount' , "'Harald Alvestrand'" , 'Ted Hardie' Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHM8te6ZBG/XYsMg0C4SE+GOqsWNpZtZpyg///nIgCAAAs3AIAASYaAgADU1wCAAESDgIAACAYAgAQGRYCAADINgIAAIVYAgAAIfACAAq+sAIAAVeAAgACNQICAANeboA== Date: Fri, 23 Mar 2012 06:40:17 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E21E8F5@inba-mail01.sonusnet.com> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> <03fa01cd087d$57899120$069cb360$@com> In-Reply-To: <03fa01cd087d$57899120$069cb360$@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 06:40:12 -0000 Even in case disabling encryption is not the desired behavior, I don't see = the problem in using RTP-IPSec instead of SRTP-DTLS. I understand that web-= browser has no standard way to identify whether plain IP or IPsec in Layer = 3. So, it shall be configured by browser-user and it shall be considered as= user consent. This approach helps in case in avoiding double encryption te= chnically wherein IPSec is mandated. I know the argument that double encryp= tion is not problem in the endpoint as it has huge CPU and memory resources= but in case web-browser as part of access devices, it will have impact on = performance. My issue is with mandating to use SRTP-DTLS in WebRTC and not = with mandate to implement SRTP-DTLS. Also, AFAIK HTTPS certificate is not free of cost. Whereever the cost matte= rs like social welfare site, educational site and some free blogs, the tend= ency will be towards HTTP and user of those sites will have the consent to = use RTP.=20 Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Dan Wing >Sent: Friday, March 23, 2012 4:14 AM >To: 'Roman Shpount'; 'Harald Alvestrand'; 'Ted Hardie' >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Roman Shpount >> Sent: Thursday, March 22, 2012 7:19 AM >> To: Harald Alvestrand >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris >... >> Yes, I was worried about supporting the interceptor. This is all >> related to my question of support of WebRTC applications in military, >> prisons, or financial organizations. I think WebRTC would be >> completely disabled in such locations unless web browser can be >> configured to confirm to some sort of communications and monitoring >> policy. I do not think enabling only certain applications is a >> sustainable solution, since application can only be enabled based on >> its URL, but this in no way implies that the actual protocol used for >> signaling exchange by this application will stay the same. In the best >> case this will result in tens of specialized monitoring rules that >> will need to be maintained. In the worst case, WebRTC would be simply >> disabled. At this point the only workable solution that I see is some >> sort of media proxy protocol. > >The SIPREC working group, formed in March 2010, has solutions for this >problem. The problem is not created by RTCWEB. Disabling encryption is >not necessary -- nor desirable. "Jails" get brought up in this context >often, so using that same example, consider a prisoner at a jail >communicating with their lawyer. The prisoner needs secure >communications with their lawyer without the risk of the communications >being leaked to the press by anyone along the media path. For details >see http://tools.ietf.org/wg/siprec/ > >We will have a brietf presentation on SIPREC during my session at >RTCWEB, explaining how it can work with RTCWEB. > >-d > > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Fri Mar 23 04:11:36 2012 Return-Path: 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 1C47A21F8564 for ; Fri, 23 Mar 2012 04:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.91 X-Spam-Level: X-Spam-Status: No, score=-9.91 tagged_above=-999 required=5 tests=[AWL=0.689, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 iV2ouRTYXVyp for ; Fri, 23 Mar 2012 04:11:32 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id CE5AC21F8568 for ; Fri, 23 Mar 2012 04:11:28 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-ab-4f6c5a5f7593 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.DA.17856.F5A5C6F4; Fri, 23 Mar 2012 12:11:27 +0100 (CET) Received: from [150.132.142.245] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Mar 2012 12:11:27 +0100 Message-ID: <4F6C5A5E.6050100@ericsson.com> Date: Fri, 23 Mar 2012 12:11:26 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 11:11:36 -0000 I think most agrees to that it would be advantageous if there could be an agreement on mandatory to implement codecs (at least one for audio and at least one for video), for interoperability between implementations (among other things). I would like to discuss a bit on mandatory to implement video codec support. There are many factors to consider, three of them are: 1. Coding efficiency: As more and more of the available capacity on the Internet is consumed by video, I think that codecs that are clearly inferior to the state of art regarding compression efficiency should not be considered. 2. Implementation status: Another factor to consider is the implementation status in end user equipment, and, especially for battery powered devices, to what extend platforms have (optimized/HW accelerated) implementations. 3. Interoperability with existing services (it can be argued that webrtc is a green field, but on the other hand there seems to be a lot of people wanting interoperability). To me, h.264 is a good candidate considering the factors above. It is competitive regarding compression efficiency, it is widely implemented (in all kinds of devices and platforms) and is the by far mostly used video codec currently. Notably, a recent study ([1]) says that h.264 is the leading format also for the html video element. In addition, licensing for h.264 seems straightforward, and the large number of implementations in commercial use indicates that vendors do not perceive the risk for licensing/patent issues down the road as being unacceptable big (this is an observation from the outside; I'm not a lawyer and I don't deal with licensing). So, I propose that h.264 should be mandatory to implement. Stefan [1] http://blog.mefeedia.com/html5-dec-2011 From harald@alvestrand.no Fri Mar 23 04:22:53 2012 Return-Path: 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 4447D21F8575 for ; Fri, 23 Mar 2012 04:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.519 X-Spam-Level: X-Spam-Status: No, score=-110.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 XizQvIVS-HVb for ; Fri, 23 Mar 2012 04:22:49 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C2BA921F84F3 for ; Fri, 23 Mar 2012 04:22:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B755439E112; Fri, 23 Mar 2012 12:22:47 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+mqNM8VTCXZ; Fri, 23 Mar 2012 12:22:43 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 164CC39E0C0; Fri, 23 Mar 2012 12:22:43 +0100 (CET) Message-ID: <4F6C5D02.6010800@alvestrand.no> Date: Fri, 23 Mar 2012 12:22:42 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <4F6B5FEE.9060706@alcatel-lucent.com> <4F6B6CD6.2070801@alcatel-lucent.com> In-Reply-To: <4F6B6CD6.2070801@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] IdP in 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 11:22:53 -0000 On 03/22/2012 07:17 PM, Igor Faynberg wrote: > Thanks! Now I understand. > > My only follow-up question (and that could probably wait until the > next week) is why not make BrowserID certificate adhere to X.509. If > we issue self-signed X.509 certificates ourselves, what is in the way > of any IdP doing just that? The BrowserID specification is the work item of a group that is entirely outside of this group. You can certainly go there (browserid.org) to argue that they should change to X.509 certificates, but we can't decide in the RTCWEB WG that they should change. > > Igor > > On 3/22/2012 1:53 PM, Eric Rescorla wrote: >> Good question. >> >> 1. BrowserID certificates aren't X.509, and that's all the TLS/DTLS >> will do. >> 2. This lets us be agnostic about IdP mechanisms without having to >> change >> TLS every time we add a new one. >> >> -Ekr >> >> >> On Thu, Mar 22, 2012 at 6:22 PM, Igor Faynberg >> wrote: >>> Eric, >>> >>> A question: For the case of BrowserID, I understand that a client >>> gets a >>> certificate from an IdP. If so, why you and I would not use the >>> certificates from our respective IdPs in order to authenticate each >>> other >>> in DTLS? >>> >>> Igor >>> >>> >>> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From tterriberry@mozilla.com Fri Mar 23 04:40:41 2012 Return-Path: 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 B7AAD21F8514 for ; Fri, 23 Mar 2012 04:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vORjUMacEYfv for ; Fri, 23 Mar 2012 04:40:41 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 37E0421F850B for ; Fri, 23 Mar 2012 04:40:41 -0700 (PDT) Received: from [10.250.5.141] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id C74614AEDA6; Fri, 23 Mar 2012 04:40:40 -0700 (PDT) Message-ID: <4F6C6138.6010908@mozilla.com> Date: Fri, 23 Mar 2012 04:40:40 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120305 SeaMonkey/2.7.1 MIME-Version: 1.0 To: Stefan Hakansson LK References: <4F6C5A5E.6050100@ericsson.com> In-Reply-To: <4F6C5A5E.6050100@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 11:40:41 -0000 Stefan Hakansson LK wrote: > So, I propose that h.264 should be mandatory to implement. Mozilla strongly opposes such a proposal. Many will be familiar with our announcements regarding our use of platform codecs on B2G and possibly Android last week. The primary reasoning behind that decision, i.e. the one factor that was not in our power to change, was the availability of content on websites. This is not a problem for WebRTC, as browsers control both ends of the communication. What _is_ a problem is licensing and distributing encoders in an open-source project. This is quite a bit different than using system decoders, as outside of mobile, encoders are usually not available, and even if they were, they might not have particularly good quality, nor the features to control latency, loss robustness, and other aspects necessary for real-time communication. If you thought that a concession in one place would make Mozilla more likely to compromise in others, I assure you the opposite is true. Maintaining the use of RF codecs in WebRTC is now even more important than it was before. See the words directly from Mozilla's CTO: http://groups.google.com/group/mozilla.dev.platform/msg/53892ad3ea9eeb98 From lorenzo@meetecho.com Fri Mar 23 04:48:12 2012 Return-Path: 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 E357321F8527 for ; Fri, 23 Mar 2012 04:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 7KsJYWEtBIb5 for ; Fri, 23 Mar 2012 04:48:08 -0700 (PDT) Received: from smtplq04.aruba.it (smtplqs-out21.aruba.it [62.149.158.61]) by ietfa.amsl.com (Postfix) with SMTP id 2F05621F8518 for ; Fri, 23 Mar 2012 04:48:07 -0700 (PDT) Received: (qmail 25593 invoked by uid 89); 23 Mar 2012 11:48:05 -0000 Received: from unknown (HELO smtp7.aruba.it) (62.149.158.227) by smtplq04.aruba.it with SMTP; 23 Mar 2012 11:48:05 -0000 Received: (qmail 21484 invoked by uid 89); 23 Mar 2012 11:47:47 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.180) by smtp7.ad.aruba.it with SMTP; 23 Mar 2012 11:47:47 -0000 Date: Fri, 23 Mar 2012 12:47:44 +0100 From: Lorenzo Miniero To: "Timothy B. Terriberry" Message-ID: <20120323124744.38484fe1@lminiero-acer> In-Reply-To: <4F6C6138.6010908@mozilla.com> References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp7.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 11:48:13 -0000 +1, L. Il giorno Fri, 23 Mar 2012 04:40:40 -0700 "Timothy B. Terriberry" ha scritto: > Stefan Hakansson LK wrote: > > So, I propose that h.264 should be mandatory to implement. > > Mozilla strongly opposes such a proposal. Many will be familiar with > our announcements regarding our use of platform codecs on B2G and > possibly Android last week. The primary reasoning behind that > decision, i.e. the one factor that was not in our power to change, > was the availability of content on websites. This is not a problem > for WebRTC, as browsers control both ends of the communication. > > What _is_ a problem is licensing and distributing encoders in an > open-source project. This is quite a bit different than using system > decoders, as outside of mobile, encoders are usually not available, > and even if they were, they might not have particularly good quality, > nor the features to control latency, loss robustness, and other > aspects necessary for real-time communication. > > If you thought that a concession in one place would make Mozilla more > likely to compromise in others, I assure you the opposite is true. > Maintaining the use of RF codecs in WebRTC is now even more important > than it was before. See the words directly from Mozilla's CTO: > http://groups.google.com/group/mozilla.dev.platform/msg/53892ad3ea9eeb98 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From Markus.Isomaki@nokia.com Fri Mar 23 05:15:15 2012 Return-Path: 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 1006B21F8543 for ; Fri, 23 Mar 2012 05:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dlZJ+1c5h+uB for ; Fri, 23 Mar 2012 05:15:11 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id D1A6121F851A for ; Fri, 23 Mar 2012 05:15:10 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2NCExKe011689; Fri, 23 Mar 2012 14:15:02 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 14:14:59 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.120]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Fri, 23 Mar 2012 13:14:59 +0100 From: To: , Thread-Topic: [rtcweb] On video codec for rtcweb Thread-Index: AQHNCOW9xHGnLMQce02yRQCfJU+p3ZZ3sPwAgAAXY/A= Date: Fri, 23 Mar 2012 12:14:59 +0000 Message-ID: References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> In-Reply-To: <4F6C6138.6010908@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.81.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Mar 2012 12:15:00.0029 (UTC) FILETIME=[918566D0:01CD08EE] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 12:15:15 -0000 Hi, Timothy B. Terriberry wrote: > >The primary reasoning behind that decision, i.e. the one >factor that was not in our power to change, was the availability of conten= t on >websites. This is not a problem for WebRTC, as browsers control both ends = of >the communication. > In WebRTC context what is somewhat analogous is the interconnect to existin= g non-web video systems. What codecs are used in them is not under browser = control. I believe those mostly use H.264. It's probably possible to use tr= anscoders but so it is between browsers too. I'd say that even if couldn't = mandate a single video codec (as it has seemed to me since the beginning), = in practice H.264 support would be highly RECOMMENDED (a SHOULD). There mig= ht be good reasons not to follow that SHOULD, as it seems to be the case fo= r Mozilla. =20 Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Timothy B. Terriberry >Sent: 23 March, 2012 13:41 >To: Stefan Hakansson LK >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] On video codec for rtcweb > >Stefan Hakansson LK wrote: >> So, I propose that h.264 should be mandatory to implement. > >Mozilla strongly opposes such a proposal. Many will be familiar with our >announcements regarding our use of platform codecs on B2G and possibly >Android last week. The primary reasoning behind that decision, i.e. the on= e >factor that was not in our power to change, was the availability of conten= t on >websites. This is not a problem for WebRTC, as browsers control both ends = of >the communication. > >What _is_ a problem is licensing and distributing encoders in an open-sour= ce >project. This is quite a bit different than using system decoders, as outs= ide of >mobile, encoders are usually not available, and even if they were, they mi= ght >not have particularly good quality, nor the features to control latency, l= oss >robustness, and other aspects necessary for real-time communication. > >If you thought that a concession in one place would make Mozilla more like= ly >to compromise in others, I assure you the opposite is true. >Maintaining the use of RF codecs in WebRTC is now even more important than >it was before. See the words directly from Mozilla's CTO: >http://groups.google.com/group/mozilla.dev.platform/msg/53892ad3ea9eeb >98 >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From tterriberry@mozilla.com Fri Mar 23 05:34:17 2012 Return-Path: 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 5063F21F851A for ; Fri, 23 Mar 2012 05:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.307 X-Spam-Level: X-Spam-Status: No, score=-5.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] 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 IKyexSRQ3fi5 for ; Fri, 23 Mar 2012 05:34:16 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id DDE0821F8452 for ; Fri, 23 Mar 2012 05:34:16 -0700 (PDT) Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id AD8994AEDC0 for ; Fri, 23 Mar 2012 05:34:09 -0700 (PDT) Message-ID: <4F6C6DC1.7020606@mozilla.com> Date: Fri, 23 Mar 2012 05:34:09 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 CC: rtcweb@ietf.org References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 12:34:17 -0000 Markus.Isomaki@nokia.com wrote: > control. I believe those mostly use H.264. It's probably possible to use > transcoders but so it is between browsers too. I'd say that even if couldn't With a direct browser-to-browser connection, there is nothing sitting between them to do the transcoding. In the DTLS-SRTP case with identity verification, which I think a number of people here view as highly important, you are in fact _guaranteeing_ that nothing but the browser can encode or decode the video. As for existing non-web video systems, I am happy to send them G.711, and no more, if all they wish to support is H.264. To me, interoperation beyond that is no more than a "nice to have". WebRTC was meant to be much more expansive than traditional telephony. If all WebRTC turns out to be is another vehicle for old-world video conferencing style systems, then we will have failed. From chris.cavigioli@intel.com Fri Mar 23 05:35:04 2012 Return-Path: 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 D4B9E21F851C for ; Fri, 23 Mar 2012 05:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 lMzPioa4m6dl for ; Fri, 23 Mar 2012 05:35:00 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id A1B7821F851D for ; Fri, 23 Mar 2012 05:35:00 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 23 Mar 2012 05:35:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="143930319" Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87]) by fmsmga002.fm.intel.com with ESMTP; 23 Mar 2012 05:35:00 -0700 Received: from orsmsx102.amr.corp.intel.com (10.22.225.129) by orsmsx604.amr.corp.intel.com (10.22.226.87) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 23 Mar 2012 05:35:00 -0700 Received: from orsmsx104.amr.corp.intel.com ([169.254.3.46]) by ORSMSX102.amr.corp.intel.com ([169.254.1.160]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 05:34:59 -0700 From: "Cavigioli, Chris" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] On video codec for rtcweb Thread-Index: AQHNCOW4qdGE9rDhK0ycRlr7QB08T5Z4NxgAgAAJl4D//4zM0A== Date: Fri, 23 Mar 2012 12:34:59 +0000 Message-ID: References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 12:35:05 -0000 Let's be clear on profiles. If we seek widest mobile hardware footprint: - ITU-T H.264 Constrained Baseline Profile is probably the most ubiquitous = hardware video codec today with reasonable power/performance ratio - ITU-T G.711, both u_law (North America) and A_law (Europe) formats, can b= e supported by everyone with very trivial software burden -chris -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Markus.Isomaki@nokia.com Sent: Friday, March 23, 2012 5:15 AM To: tterriberry@mozilla.com; stefan.lk.hakansson@ericsson.com Cc: rtcweb@ietf.org Subject: Re: [rtcweb] On video codec for rtcweb Hi, Timothy B. Terriberry wrote: > >The primary reasoning behind that decision, i.e. the one >factor that was not in our power to change, was the availability of conten= t on >websites. This is not a problem for WebRTC, as browsers control both ends = of >the communication. > In WebRTC context what is somewhat analogous is the interconnect to existin= g non-web video systems. What codecs are used in them is not under browser = control. I believe those mostly use H.264. It's probably possible to use tr= anscoders but so it is between browsers too. I'd say that even if couldn't = mandate a single video codec (as it has seemed to me since the beginning), = in practice H.264 support would be highly RECOMMENDED (a SHOULD). There mig= ht be good reasons not to follow that SHOULD, as it seems to be the case fo= r Mozilla. =20 Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Timothy B. Terriberry >Sent: 23 March, 2012 13:41 >To: Stefan Hakansson LK >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] On video codec for rtcweb > >Stefan Hakansson LK wrote: >> So, I propose that h.264 should be mandatory to implement. > >Mozilla strongly opposes such a proposal. Many will be familiar with our >announcements regarding our use of platform codecs on B2G and possibly >Android last week. The primary reasoning behind that decision, i.e. the on= e >factor that was not in our power to change, was the availability of conten= t on >websites. This is not a problem for WebRTC, as browsers control both ends = of >the communication. > >What _is_ a problem is licensing and distributing encoders in an open-sour= ce >project. This is quite a bit different than using system decoders, as outs= ide of >mobile, encoders are usually not available, and even if they were, they mi= ght >not have particularly good quality, nor the features to control latency, l= oss >robustness, and other aspects necessary for real-time communication. > >If you thought that a concession in one place would make Mozilla more like= ly >to compromise in others, I assure you the opposite is true. >Maintaining the use of RF codecs in WebRTC is now even more important than >it was before. See the words directly from Mozilla's CTO: >http://groups.google.com/group/mozilla.dev.platform/msg/53892ad3ea9eeb >98 >_______________________________________________ >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 From Markus.Isomaki@nokia.com Fri Mar 23 06:05:50 2012 Return-Path: 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 5D09021F850C for ; Fri, 23 Mar 2012 06:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dYgvOYhZRggF for ; Fri, 23 Mar 2012 06:05:49 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id AC40421F849C for ; Fri, 23 Mar 2012 06:05:48 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2ND5bR9028852; Fri, 23 Mar 2012 15:05:39 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 15:05:36 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.120]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Fri, 23 Mar 2012 14:05:36 +0100 From: To: Thread-Topic: [rtcweb] On video codec for rtcweb Thread-Index: AQHNCOW9xHGnLMQce02yRQCfJU+p3ZZ3sPwAgAAXY/D///eOgIAAEsHw Date: Fri, 23 Mar 2012 13:05:35 +0000 Message-ID: References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <4F6C6DC1.7020606@mozilla.com> In-Reply-To: <4F6C6DC1.7020606@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.81.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Mar 2012 13:05:36.0895 (UTC) FILETIME=[A3A260F0:01CD08F5] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 13:05:50 -0000 Hi Timothy B. Terriberry wrote: > >Markus.Isomaki@nokia.com wrote: >> control. I believe those mostly use H.264. It's probably possible to >> use transcoders but so it is between browsers too. I'd say that even >> if couldn't > >With a direct browser-to-browser connection, there is nothing sitting >between them to do the transcoding. In the DTLS-SRTP case with identity >verification, which I think a number of people here view as highly importa= nt, >you are in fact _guaranteeing_ that nothing but the browser can encode or >decode the video. > Understood. So it would be important to agree on a common codec. However, I= 'm just wondering if forcing the decision would be wise for the IETF. I hav= e heard many people say that if X was chosen, they wouldn't still suport it= . My opinion is that a codec should only be mandated if there is clear cons= ensus about it. Exaggerating a bit but not much that would probably leave u= s with G.711. >As for existing non-web video systems, I am happy to send them G.711, and >no more, if all they wish to support is H.264.=20 Indeed :-) That's fine, but for some other people video support in that sce= nario could be more important.=20 >To me, interoperation beyond >that is no more than a "nice to have". WebRTC was meant to be much more >expansive than traditional telephony. If all WebRTC turns out to be is ano= ther >vehicle for old-world video conferencing style systems, then we will have >failed. > Here we are in full agreement. I don't think either that the "legacy" inter= connect is the highest priority. I don't find the current video call market= that impressive that we should somehow limit ourselves to serve it. Markus From abu_hurayrah@hidayahonline.org Fri Mar 23 06:24:48 2012 Return-Path: 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 D952421F84A7 for ; Fri, 23 Mar 2012 06:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] 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 qYpgmQm3cP9p for ; Fri, 23 Mar 2012 06:24:47 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id E4F7621F84A6 for ; Fri, 23 Mar 2012 06:24:46 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 94FDB65246E for ; Fri, 23 Mar 2012 09:24:45 -0400 (EDT) Message-ID: <4F6C7997.3080603@hidayahonline.org> Date: Fri, 23 Mar 2012 09:24:39 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=5AF4B362 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 13:24:49 -0000 On 03/23/2012 08:34 AM, Cavigioli, Chris wrote: > Let's be clear on profiles. If we seek widest mobile hardware footprint: > - ITU-T H.264 Constrained Baseline Profile is probably the most ubiquitous hardware video codec today with reasonable power/performance ratio > - ITU-T G.711, both u_law (North America) and A_law (Europe) formats, can be supported by everyone with very trivial software burden > -chris Seeking the widest mobile hardware footprint is a very narrow view considering the scope of WebRTC. WebRTC is a technology with browsers as the main endpoints. While mobile devices make up a significant portion of that population, they are by no means the only one, and there are no guarantees that this will be the major use case of WebRTC in the future. Time and again, success and adoption of standards across all markets, devices, and platforms has been rooted in the usage of a open, royalty-free formats. Mandating H.264 for this or any other purpose while it remains unlicensable for usage in free/open source software projects invalidates the universality of WebRTC. This would setup the protocol to be yet another proprietary system that claims to be open but in practice will be limited to usage solely by existing MPEG-LA licensors/licensees and other existing players in the telecommunications market. This makes the project, and the standard, dead in the water as far as a lot of the players interested in this project are concerned. Having said that, WebRTC at this point remains open and free, and to ensure that, the only technologies that should be included are those that are royalty free and licensed for use within free/open-source software project. This is the *only* way for WebRTC to be successful and to achieve the goals of its (intended) open nature. From tterriberry@mozilla.com Fri Mar 23 06:28:21 2012 Return-Path: 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 63E0121F84D9 for ; Fri, 23 Mar 2012 06:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PehUr3qD6npl for ; Fri, 23 Mar 2012 06:28:17 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 16A1621F84A7 for ; Fri, 23 Mar 2012 06:28:17 -0700 (PDT) Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 072354AED89 for ; Fri, 23 Mar 2012 06:28:10 -0700 (PDT) Message-ID: <4F6C7A69.3050303@mozilla.com> Date: Fri, 23 Mar 2012 06:28:09 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <4F6C6DC1.7020606@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 13:28:21 -0000 Markus.Isomaki@nokia.com wrote: > My opinion is that a codec should only be mandated if there is clear > consensus about it. Exaggerating a bit but not much that would probably leave > us with G.711. We've had this conversation on this list before. See http://www.ietf.org/mail-archive/web/rtcweb/current/msg03047.html wherein you find that even Stephan _Wenger_ and I managed to agree that your standard is too strong. Such consensus is a rare thing indeed. From bernard_aboba@hotmail.com Fri Mar 23 07:24:54 2012 Return-Path: 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 B4B4C21F8466 for ; Fri, 23 Mar 2012 07:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.406 X-Spam-Level: X-Spam-Status: No, score=-101.406 tagged_above=-999 required=5 tests=[AWL=1.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xX5reboDD9SC for ; Fri, 23 Mar 2012 07:24:54 -0700 (PDT) Received: from blu0-omc3-s10.blu0.hotmail.com (blu0-omc3-s10.blu0.hotmail.com [65.55.116.85]) by ietfa.amsl.com (Postfix) with ESMTP id DE42A21F846E for ; Fri, 23 Mar 2012 07:24:53 -0700 (PDT) Received: from BLU169-W85 ([65.55.116.72]) by blu0-omc3-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 07:24:53 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_6fa0bf81-9f22-465b-8a03-e993800d6472_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Date: Fri, 23 Mar 2012 07:24:53 -0700 Importance: Normal In-Reply-To: <4F6C6DC1.7020606@mozilla.com> References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com>, , <4F6C6DC1.7020606@mozilla.com> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Mar 2012 14:24:53.0373 (UTC) FILETIME=[B6B752D0:01CD0900] Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:24:54 -0000 --_6fa0bf81-9f22-465b-8a03-e993800d6472_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tim said:=20 > As for existing non-web video systems=2C I am happy to send them G.711=2C= =20 > and no more=2C if all they wish to support is H.264. To me=2C interoperat= ion=20 > beyond that is no more than a "nice to have". WebRTC was meant to be=20 > much more expansive than traditional telephony. If all WebRTC turns out=20 > to be is another vehicle for old-world video conferencing style systems= =2C=20 > then we will have failed. [BA] While "old-world video conferencing" systems (H.323) are still widely= used=2C I think it is fair to say that there is a strong trend towards adoption of = SIP in a=20 wide range of markets=2C including government=2C educational=2C medical=2C = financials=2C etc.=20 I have talked to customers in many of those markets=2C and one of the consi= stently repeated requests is for interoperability between mobile video and video conferencing platforms=2C *without the need for transcoding*. The reason = why transcoding is unacceptable is that the cost of transcoding gateways is hig= h on a per user basis=2C and for organizations where high use of video is ant= icipated=2C the cost of transcoding (as opposed to a signaling gateway) is a major prob= lem. =20 Another frequently cited issue is the ability to use hardware encode/decode= on mobile devices=2C so as to save power. In scenarios such as emergency services=2C this can lite= rally be a matter of life and death.=20 Given that mobile devices and video conferencing systems overwhelmingly sup= port=20 H.264 encode/decode in hardware=2C and that we do not yet have general hard= ware support for encode/decode operations=2C the answer to customer requests can only be= provided by H.264 at this time=2C or perhaps by H.265 (which is likely to be rapidly ad= opted once it is ratified in early 2013). =20 While I understand the reasons why browser vendors might not want to include software implementations of encumbered codecs=2C so they can remain= free to users=2C=20 that logic does not extend to a refusal to rely on operating system or hard= ware support=2C which would presumably come without cost to the browser vendors.= =20 My discussions with customers indicate that support for underlying encode/d= ecode capabilities is considered an important enough feature that it will cause t= hose customers to switch to browsers that support it.=20 = --_6fa0bf81-9f22-465b-8a03-e993800d6472_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Tim said:

>=3B As for existing non-web video systems=2C I am= happy to send them G.711=2C
>=3B and no more=2C if all they wish to = support is H.264. To me=2C interoperation
>=3B beyond that is no more= than a "nice to have". WebRTC was meant to be
>=3B much more expansi= ve than traditional telephony. If all WebRTC turns out
>=3B to be is = another vehicle for old-world video conferencing style systems=2C
>= =3B then we will have failed.

[BA] =3B While "old-world video co= nferencing" systems (H.323) are still widely used=2C
I think it is fair = to say that there is a strong trend towards adoption of SIP in a
wide r= ange of markets=2C including government=2C educational=2C medical=2C financ= ials=2C etc.

I have talked to customers in many of those markets=2C= and one of the consistently
repeated requests is for interoperability b= etween mobile video and video
conferencing platforms=2C *without the nee= d for transcoding*.  =3B The reason why
transcoding is unacceptable = is that the cost of transcoding gateways is high
on a per user basis=2C = and for organizations where high use of video is anticipated=2C
the cost= of transcoding (as opposed to a signaling gateway) is a major problem.&nbs= p=3B =3B
Another frequently cited issue is the ability to use hardw= are encode/decode on mobile devices=2C so
as to save power. =3B In s= cenarios such as emergency services=2C this can literally be a
matter of= life and death.

Given that mobile devices and video conferencing s= ystems overwhelmingly support
H.264 encode/decode in hardware=2C and th= at we do not yet have general hardware support
for encode/decode operati= ons=2C the answer to customer requests can only be provided by
H.264 at = this time=2C or perhaps by H.265 (which is likely to be rapidly adopted onc= e it is
ratified in early 2013). =3B

While I understand the = reasons why browser vendors might not want to
include software implement= ations of encumbered codecs=2C so they can remain free to users=2C
that= logic does not extend to a refusal to rely on operating system or hardware=
support=2C which would presumably come without cost to the browser vend= ors.

My discussions with customers indicate that support for underl= ying encode/decode
capabilities is considered an important enough featur= e that it will cause those customers to
switch to browsers that support = it.
= --_6fa0bf81-9f22-465b-8a03-e993800d6472_-- From matthew.kaufman@skype.net Fri Mar 23 07:35:41 2012 Return-Path: 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 1C42921F851A for ; Fri, 23 Mar 2012 07:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 PRV1i31DQJVO for ; Fri, 23 Mar 2012 07:35:40 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1BF21F8518 for ; Fri, 23 Mar 2012 07:35:40 -0700 (PDT) Received: from mail43-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Fri, 23 Mar 2012 14:35:31 +0000 Received: from mail43-ch1 (localhost [127.0.0.1]) by mail43-ch1-R.bigfish.com (Postfix) with ESMTP id B3CE3340491; Fri, 23 Mar 2012 14:35:30 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh87h2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail43-ch1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail43-ch1 (localhost.localdomain [127.0.0.1]) by mail43-ch1 (MessageSwitch) id 1332513328266212_15352; Fri, 23 Mar 2012 14:35:28 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail43-ch1.bigfish.com (Postfix) with ESMTP id 3C9CD200A6; Fri, 23 Mar 2012 14:35:28 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 23 Mar 2012 14:35:27 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.175]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0283.004; Fri, 23 Mar 2012 14:35:34 +0000 From: Matthew Kaufman To: "Timothy B. Terriberry" , Stefan Hakansson LK Thread-Topic: [rtcweb] On video codec for rtcweb Thread-Index: AQHNCOW/6tQYWDYT5EeDEbhq8k2ZXJZ3wb8AgAAvjqA= Date: Fri, 23 Mar 2012 14:35:34 +0000 Message-ID: References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> In-Reply-To: <4F6C6138.6010908@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:35:41 -0000 Timothy B. Terriberry: "Mozilla strongly opposes such a proposal. Many will be familiar with our a= nnouncements regarding our use of platform codecs on B2G and possibly Andro= id last week. The primary reasoning behind that decision, i.e. the one fact= or that was not in our power to change, was the availability of content on = websites. This is not a problem for WebRTC, as browsers control both ends o= f the communication." While I understand the reasons for disliking a codec that isn't available r= oyalty-free, I have to say that the above argument is exactly backwards. While a website that wished to offer content to two different browsers with= different codecs could simply transcode and store the video in two formats= (albeit at some cost in storage, which is getting cheaper all the time), a= website that wishes to offer RTC capabilities to users with differing brow= sers would be forced to stand up servers, in-path, transcoding in real time= ... a much more onerous requirement in order to achieve interoperability. While browsers "control both ends of the communication" in RTCWEB, the site= s offering RTC services don't necessarily "control both ends of the communi= cation" insofar as choosing what browsers their users use to visit... or ra= ther, in order to achieve interoperable communication without the cost (and= security concerns) of transcoding sites will in fact start to deny service= to particular users based on their choice of browser. Matthew Kaufman From tterriberry@mozilla.com Fri Mar 23 07:47:13 2012 Return-Path: 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 9516E21F8541 for ; Fri, 23 Mar 2012 07:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 qucVlxsuL-oi for ; Fri, 23 Mar 2012 07:47:12 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id C642221F84D1 for ; Fri, 23 Mar 2012 07:47:12 -0700 (PDT) Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 362E64AEDD1 for ; Fri, 23 Mar 2012 07:47:12 -0700 (PDT) Message-ID: <4F6C8CEF.7030008@mozilla.com> Date: Fri, 23 Mar 2012 07:47:11 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com>, , <4F6C6DC1.7020606@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:47:13 -0000 Bernard Aboba wrote: > While I understand the reasons why browser vendors might not want to > include software implementations of encumbered codecs, so they can > remain free to users, > that logic does not extend to a refusal to rely on operating system or > hardware > support, which would presumably come without cost to the browser vendors. Oh, but it does. My understanding is that even Windows 7 does not ship with a licensed encoder. Even if it did, nearly a plurality of Mozilla's users still run Windows XP. I would like those users to be able to talk to each other, and with mobile devices, and I view not supporting an encumbered codec as the best route to ensuring that support for a free one is deployed and working on all of these systems. From tterriberry@mozilla.com Fri Mar 23 07:51:31 2012 Return-Path: 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 3532221F853A for ; Fri, 23 Mar 2012 07:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 NGla02ZxyIAe for ; Fri, 23 Mar 2012 07:51:30 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id CA16D21F851A for ; Fri, 23 Mar 2012 07:51:30 -0700 (PDT) Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id AB9B54AEDCA for ; Fri, 23 Mar 2012 07:51:30 -0700 (PDT) Message-ID: <4F6C8DF2.4050804@mozilla.com> Date: Fri, 23 Mar 2012 07:51:30 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:51:31 -0000 Matthew Kaufman wrote: > or rather, in order to achieve interoperable communication without the cost > (and security concerns) of transcoding sites will in fact start to deny > service to particular users based on their choice of browser. I agree this is an excellent argument for having _a_ mandatory to implement codec. But it's an argument against having that codec be an encumbered codec. Much better to have it be a free one that everyone is able to deploy. Even Microsoft (via Skype) now deploys VP8. From tterriberry@mozilla.com Fri Mar 23 07:51:39 2012 Return-Path: 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 D5B5021F857D for ; Fri, 23 Mar 2012 07:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 De-nqGHW-LFd for ; Fri, 23 Mar 2012 07:51:39 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id BB06521F8575 for ; Fri, 23 Mar 2012 07:51:39 -0700 (PDT) Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 7E4954AEDD1 for ; Fri, 23 Mar 2012 07:51:11 -0700 (PDT) Message-ID: <4F6C8DDF.8000403@mozilla.com> Date: Fri, 23 Mar 2012 07:51:11 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:51:40 -0000 Matthew Kaufman wrote: > or rather, in order to achieve interoperable communication without the cost > (and security concerns) of transcoding sites will in fact start to deny > service to particular users based on their choice of browser. I agree this is an excellent argument for having _a_ mandatory to implement codec. But it's an argument against having that codec be an encumbered codec. Much better to have it be a free one that everyone is able to deploy. Even Microsoft (via Skype) now deploys VP8. From andrew.hutton@siemens-enterprise.com Fri Mar 23 07:54:38 2012 Return-Path: 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 9D1CF21F851A for ; Fri, 23 Mar 2012 07:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] 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 YGKfMdeTYOnK for ; Fri, 23 Mar 2012 07:54:34 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 37A4E21F844C for ; Fri, 23 Mar 2012 07:54:34 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id ABA3C23F04CA; Fri, 23 Mar 2012 15:54:32 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 23 Mar 2012 15:54:32 +0100 From: "Hutton, Andrew" To: Dan Wing , 'Roman Shpount' , 'Harald Alvestrand' , 'Ted Hardie' Date: Fri, 23 Mar 2012 15:54:31 +0100 Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: Ac0INr3Z1+RYf6xDTCirryldOl72eAARbPMAACGHm/A= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296B58E75@MCHP058A.global-ad.net> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> <03fa01cd087d$57899120$069cb360$@com> In-Reply-To: <03fa01cd087d$57899120$069cb360$@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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:54:38 -0000 Hi Dan, I don't think SIPREC has a solution to the particular problem that Roman is= talking about and it would probably not be within scope of SIPREC to solve= this even assuming that there is some SIP involved. If the prison deployed its own RTCWeb application and restricted the prison= er to using only this application then of course there would be no problem = with intercepting the media and a SIPREC type solution could be deployed wi= th some kind of B2BUA which has access to both signaling and media initiati= ng the media recording and of course informing the prisoner that they are b= eing recorded. However if the prisoner is allowed to access their lawyers RTCWeb applicati= on and download the JavaScript from there then SIPREC does not help the pri= son record the resulting media exchanged. Regards Andy=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Dan Wing > Sent: 22 March 2012 22:44 > To: 'Roman Shpount'; 'Harald Alvestrand'; 'Ted Hardie' > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris >=20 > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of Roman Shpount > > Sent: Thursday, March 22, 2012 7:19 AM > > To: Harald Alvestrand > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris > ... > > Yes, I was worried about supporting the interceptor. This is all > > related to my question of support of WebRTC applications in military, > > prisons, or financial organizations. I think WebRTC would be > completely > > disabled in such locations unless web browser can be configured to > > confirm to some sort of communications and monitoring policy. I do > not > > think enabling only certain applications is a sustainable solution, > > since application can only be enabled based on its URL, but this in > no > > way implies that the actual protocol used for signaling exchange by > > this application will stay the same. In the best case this will > result > > in tens of specialized monitoring rules that will need to be > > maintained. In the worst case, WebRTC would be simply disabled. At > this > > point the only workable solution that I see is some sort of media > proxy > > protocol. >=20 > The SIPREC working group, formed in March 2010, has solutions for > this problem. The problem is not created by RTCWEB. Disabling > encryption is not necessary -- nor desirable. "Jails" get brought up > in this context often, so using that same example, consider a prisoner > at a jail communicating with their lawyer. The prisoner needs secure > communications with their lawyer without the risk of the > communications being leaked to the press by anyone along the media > path. For details see http://tools.ietf.org/wg/siprec/ >=20 > We will have a brietf presentation on SIPREC during my session > at RTCWEB, explaining how it can work with RTCWEB. >=20 > -d >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dwing@cisco.com Fri Mar 23 08:02:04 2012 Return-Path: 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 2076C21F857F for ; Fri, 23 Mar 2012 08:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.407 X-Spam-Level: X-Spam-Status: No, score=-109.407 tagged_above=-999 required=5 tests=[AWL=1.192, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 RthhL8-XQ7N4 for ; Fri, 23 Mar 2012 08:01:59 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id CB74D21F8572 for ; Fri, 23 Mar 2012 08:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5600; q=dns/txt; s=iport; t=1332514919; x=1333724519; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=fbPp4rlyGPC7jUufDOzIMpeePiEM9zZnsKV5Prw2eKE=; b=jliJ5ujvEPoJcXPMUHCTayEBhofR3x6VeGFCgBl9OdYsZnH3Kq6EXF72 qH2Oz80K6yc6yAaqNRFsOPzH5Jrmxb72Eo66OeU4HIzQO7fxvWYW1mX0V KmyqkRV3NOKtlRDGTP/UnBrfYJBSZnoFLpwZqOrBAkZA7mzgsDrfEORGQ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADCQbE+rRDoI/2dsb2JhbAA7Cqgjj2WBB4IJAQEBAwEBAQEFCgEXEC4GCwUHAQMCCQ8CBAEBKAcZDhUKAwEFCAIEARILEAeHYwQMmgGNUZE2ilqGKwSIV4UTljqBaIMH X-IronPort-AV: E=Sophos;i="4.73,636,1325462400"; d="scan'208";a="34807195" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 23 Mar 2012 15:01:58 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2NF1vKO025683; Fri, 23 Mar 2012 15:01:57 GMT From: "Dan Wing" To: "'Ravindran, Parthasarathi'" , "'Roman Shpount'" , "'Harald Alvestrand'" , "'Ted Hardie'" References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> <03fa01cd087d$57899120$069cb360$@com> <387F9047F55E8C42850AD6B3A7A03C6C0E21E8F5@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E21E8F5@inba-mail01.sonusnet.com> Date: Fri, 23 Mar 2012 08:01:57 -0700 Message-ID: <062901cd0905$e48bb520$ada31f60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHM8te6ZBG/XYsMg0C4SE+GOqsWNpZtZpyg///nIgCAAAs3AIAASYaAgADU1wCAAESDgIAACAYAgAQGRYCAADINgIAAIVYAgAAIfACAAq+sAIAAVeAAgACNQICAANeboIAAkS2w Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 15:02:04 -0000 > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: Thursday, March 22, 2012 11:40 PM > To: Dan Wing; 'Roman Shpount'; 'Harald Alvestrand'; 'Ted Hardie' > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] Resolving RTP/SDES question in Paris > > Even in case disabling encryption is not the desired behavior, I don't > see the problem in using RTP-IPSec instead of SRTP-DTLS. Several. IPsec ESP tunnel or transport mode? With NAT-T support? Is there an API for applications to determine if the underlying OS provides IPsec ESP for that flow (I know for Cisco IOS, the answer to that API question is 'no'. And that was my understanding in the version of Windows Server that we used to use for our call control system, although of course that could have changed with Windows 7 or 8). RTP over IPsec breaks link header compression (cRTP and ROHC), which are used by some networks. > I understand > that web-browser has no standard way to identify whether plain IP or > IPsec in Layer 3. So, it shall be configured by browser-user and it > shall be considered as user consent. This approach helps in case in > avoiding double encryption technically wherein IPSec is mandated. I > know the argument that double encryption is not problem in the endpoint > as it has huge CPU and memory resources but in case web-browser as part > of access devices, it will have impact on performance. My issue is with > mandating to use SRTP-DTLS in WebRTC and not with mandate to implement > SRTP-DTLS. 'Double encryption' is done because it's the only way to achieve security at various layers. Let's take a simple example: someone is using their PC at a coffee shop or a conference, and (because the person is using a possibly-hostile network, and the person is ostensibly working) they bring up a VPN. All of the person's traffic goes into their VPN. The person then accesses paypal (or gmail, or hundreds of other example sites), which forces them to use HTTPS. They are now "double encrypted". Can you see the difficulty in removing the HTTPS connection to Paypal (or gmail, etc.). Can you see the difficulty in the PC determining the HTTPS connection is "good enough" and routing that outside the VPN -- it can't be done simply by port number or else someone could accidentally run un-encrypted traffic on port 443. And this person may well even be triple encryption, if the WiFi access point uses wireless encryption. Taking your argument further, if we are running IPsec we should have a way to disable the WiFi encryption? But the WiFi encryption is being used to protect that layer -- just like the IPsec is used in the VPN to protect that layer and the HTTPS to PayPal is used to protect that layer. > Also, AFAIK HTTPS certificate is not free of cost. Whereever the cost > matters like social welfare site, educational site and some free blogs, > the tendency will be towards HTTP Ok. (Separate problem.) > and user of those sites will have the > consent to use RTP. I don't see why those sites cannot use SRTP. -d > Thanks > Partha > > >-----Original Message----- > >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf > >Of Dan Wing > >Sent: Friday, March 23, 2012 4:14 AM > >To: 'Roman Shpount'; 'Harald Alvestrand'; 'Ted Hardie' > >Cc: rtcweb@ietf.org > >Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris > > > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Roman Shpount > >> Sent: Thursday, March 22, 2012 7:19 AM > >> To: Harald Alvestrand > >> Cc: rtcweb@ietf.org > >> Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris > >... > >> Yes, I was worried about supporting the interceptor. This is all > >> related to my question of support of WebRTC applications in > military, > >> prisons, or financial organizations. I think WebRTC would be > >> completely disabled in such locations unless web browser can be > >> configured to confirm to some sort of communications and monitoring > >> policy. I do not think enabling only certain applications is a > >> sustainable solution, since application can only be enabled based on > >> its URL, but this in no way implies that the actual protocol used > for > >> signaling exchange by this application will stay the same. In the > best > >> case this will result in tens of specialized monitoring rules that > >> will need to be maintained. In the worst case, WebRTC would be > simply > >> disabled. At this point the only workable solution that I see is > some > >> sort of media proxy protocol. > > > >The SIPREC working group, formed in March 2010, has solutions for this > >problem. The problem is not created by RTCWEB. Disabling encryption > is > >not necessary -- nor desirable. "Jails" get brought up in this > context > >often, so using that same example, consider a prisoner at a jail > >communicating with their lawyer. The prisoner needs secure > >communications with their lawyer without the risk of the > communications > >being leaked to the press by anyone along the media path. For details > >see http://tools.ietf.org/wg/siprec/ > > > >We will have a brietf presentation on SIPREC during my session at > >RTCWEB, explaining how it can work with RTCWEB. > > > >-d > > > > > > > >_______________________________________________ > >rtcweb mailing list > >rtcweb@ietf.org > >https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Fri Mar 23 08:22:00 2012 Return-Path: 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 04CBF21F84EA for ; Fri, 23 Mar 2012 08:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.596 X-Spam-Level: X-Spam-Status: No, score=-4.596 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 mSkOx02Y5aPt for ; Fri, 23 Mar 2012 08:21:59 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 49AF621F84D1 for ; Fri, 23 Mar 2012 08:21:59 -0700 (PDT) Received: by bkuw5 with SMTP id w5so3038030bku.31 for ; Fri, 23 Mar 2012 08:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fR7qWGWMiyvh2FfQlucdJ0+rqLIqitNeVhZWhSptAB8=; b=w4fZ+K8nRB5w//MiS6o+Jn7BnFe7nlyTZ2rAY+MyovFLtVaP5/6gYQijCYtor7YF8N tNUKKhISxj8W1gwSqiLvVAMi1xsPGrTqLF1fD4fSBVAYEBiKNBllqM5ovO1yumLXg+gU EZSKho2382JEDumQMik7kWcwOItZ31R6TJp6KGxkT+3NNi6y6JbAoip+uZbcIZLTSrsF pU11iS0SmvMJOoJY7I5UrNY2OrS4D0I41h3bQX5FKVNtN0H2XwP9boLgch5CCUFdoh56 /4embsV/VvJWqmtX00ZjL3B7wlIWQQ+K2LRyhXovmAPvAUvB5lk3L8INCmRWlrtvaqyw iclQ== MIME-Version: 1.0 Received: by 10.204.154.210 with SMTP id p18mr1592684bkw.122.1332516118414; Fri, 23 Mar 2012 08:21:58 -0700 (PDT) Received: by 10.204.121.208 with HTTP; Fri, 23 Mar 2012 08:21:58 -0700 (PDT) In-Reply-To: <4F6C6DC1.7020606@mozilla.com> References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <4F6C6DC1.7020606@mozilla.com> Date: Fri, 23 Mar 2012 08:21:58 -0700 Message-ID: From: Martin Thomson To: "Timothy B. Terriberry" Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 15:22:00 -0000 On 23 March 2012 05:34, Timothy B. Terriberry wrote: > With a direct browser-to-browser connection, there is nothing sitting > between them to do the transcoding. In the DTLS-SRTP case with identity > verification, which I think a number of people here view as highly > important, you are in fact _guaranteeing_ that nothing but the browser can > encode or decode the video. This is incorrect. The browser can implement the DTLS handshake and crypto renegotiation, plus the SRTP shim. It is possible for the browser to perform the crypto without performing encode or decode if the source is capable of providing RTP. From RFC 3711: [...] Conceptually, we consider SRTP to be a "bump in the stack" implementation which resides between the RTP application and the transport layer. SRTP intercepts RTP packets and then forwards an equivalent SRTP packet on the sending side, and intercepts SRTP packets and passes an equivalent RTP packet up the stack on the receiving side. From matthew.kaufman@skype.net Fri Mar 23 08:27:08 2012 Return-Path: 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 9CE0D21F8453 for ; Fri, 23 Mar 2012 08:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 cx9ytjuV0Inj for ; Fri, 23 Mar 2012 08:27:08 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id BEFE121F84D3 for ; Fri, 23 Mar 2012 08:27:07 -0700 (PDT) Received: from mail47-db3-R.bigfish.com (10.3.81.253) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 23 Mar 2012 15:26:57 +0000 Received: from mail47-db3 (localhost [127.0.0.1]) by mail47-db3-R.bigfish.com (Postfix) with ESMTP id 8E77AA057B; Fri, 23 Mar 2012 15:24:37 +0000 (UTC) X-SpamScore: -9 X-BigFish: VS-9(zz1432N98dKzz1202hzzz2fh87h2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail47-db3: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail47-db3 (localhost.localdomain [127.0.0.1]) by mail47-db3 (MessageSwitch) id 1332516275119866_20522; Fri, 23 Mar 2012 15:24:35 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.245]) by mail47-db3.bigfish.com (Postfix) with ESMTP id 17DB24A012F; Fri, 23 Mar 2012 15:24:35 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 23 Mar 2012 15:24:33 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.175]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0283.004; Fri, 23 Mar 2012 15:24:23 +0000 From: Matthew Kaufman To: "Timothy B. Terriberry" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] On video codec for rtcweb Thread-Index: AQHNCOW/6tQYWDYT5EeDEbhq8k2ZXJZ3wb8AgAAvjqCAAAWtgIAACG1g Date: Fri, 23 Mar 2012 15:24:22 +0000 Message-ID: References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <4F6C8DDF.8000403@mozilla.com> In-Reply-To: <4F6C8DDF.8000403@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 15:27:08 -0000 Timothy B. Terriberry: > Matthew Kaufman wrote: > > or rather, in order to achieve interoperable communication without the= cost > (and security concerns) of transcoding sites will in fact start to= deny > service to particular users based on their choice of browser. > I agree this is an excellent argument for having _a_ mandatory to impleme= nt codec. But it's an argument against having that codec be an encumbered c= odec. Much better to have it be a free one that everyone is able to deploy.= Even Microsoft (via Skype) now deploys VP8. I wasn't commenting on that part, just that if Mozilla is going to soften u= p on H.264 you'd think it'd happen to RTCWEB first, VOD second... not the r= everse. As for VP8, we don't actually know if it falls into the set "a free one tha= t everyone is able to deploy", do we? Matthew Kaufman From abu_hurayrah@hidayahonline.org Fri Mar 23 08:52:47 2012 Return-Path: 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 228A121F85A0 for ; Fri, 23 Mar 2012 08:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] 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 y2qMRxQUWIQl for ; Fri, 23 Mar 2012 08:52:41 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 586E921F8597 for ; Fri, 23 Mar 2012 08:52:41 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id C67646524A5 for ; Fri, 23 Mar 2012 11:52:40 -0400 (EDT) Message-ID: <4F6C9C46.9040802@hidayahonline.org> Date: Fri, 23 Mar 2012 11:52:38 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <4F6C8DDF.8000403@mozilla.com> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=5AF4B362 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 15:52:47 -0000 On 03/23/2012 11:24 AM, Matthew Kaufman wrote: > Timothy B. Terriberry: > > >> Matthew Kaufman wrote: > > > or rather, in order to achieve interoperable communication without the cost > (and security concerns) of transcoding sites will in fact start to deny > service to particular users based on their choice of browser. > >> I agree this is an excellent argument for having _a_ mandatory to implement codec. But it's an argument against having that codec be an encumbered codec. Much better to have it be a free one that everyone is able to deploy. Even Microsoft (via Skype) now deploys VP8. > I wasn't commenting on that part, just that if Mozilla is going to soften up on H.264 you'd think it'd happen to RTCWEB first, VOD second... not the reverse. > > As for VP8, we don't actually know if it falls into the set "a free one that everyone is able to deploy", do we? > > Matthew Kaufman With all due respect, this is FUD that is baseless. A blog post[1], an abandoned patent pool[2], and vague comments by Steve Jobs[3] are all that really stand as doubt as to the royalty-free basis on VP8. What we do know is that On2 had some patents on VP8, and these have been licensed for royalty-free usage after their acquisition by Google. Google themselves have deployed VP8 widely on YouTube via the WebM format and implemented and distributed it on Android, which is quite a large surface area to expose if they had doubts about its safety. Patent licensing targets don't get much more juicy than Google. As for implementation, any choice of format will come with challenges, and the licensing on H.264 vs. VP8 make it clear that VP8 can receive a much wider adoption in the long run, especially one that does not unnecessarily restrict this forthcoming standard only to existing players in the telecommunications market. There are already plenty of hardware chips that natively support VP8 decoding and encoding[4], and that will grow over time, as well, because many parties are strongly interested in a royalty-free alternative to H.264. Let alone there are ARM implementations of VP8 as well[5]. Where is the legitimate doubt, then, that VP8 is not an acceptable, royalty-free format that can be used for the purposes of WebRTC? We're talking initial deployment. Technology is always changed, and WebRTC 2 is free to adopt Daala[6] when it is released. Believe me, the developers would love to ensure it is suitable for WebRTC, amongst other things. [1] http://x264dev.multimedia.cx/archives/377#more-377 [2] http://www.mpegla.org/main/pages/CurrentPools_LightBox.aspx (note, it's not listed there!) [3] http://www.theregister.co.uk/2010/05/20/jobs_on_vp8/ [4] http://wiki.webmproject.org/hardware/arm-socs [5] http://www.webmproject.org/tools/vp8-sdk/changelog.html [6] https://www.xiph.org/daala/ From roman@telurix.com Fri Mar 23 09:48:34 2012 Return-Path: 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 8238C21F85A0 for ; Fri, 23 Mar 2012 09:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 fH6xzaFA9nUa for ; Fri, 23 Mar 2012 09:48:34 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EDC4521F8597 for ; Fri, 23 Mar 2012 09:48:33 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3249959ggm.31 for ; Fri, 23 Mar 2012 09:48:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=YjQ6huDF80gS9aUdbozeNaCRYUSickGIdWl5CYBvOUs=; b=HFjLGjLZh84fujPSqX7FDfhDi7/OTNmaZsEI7/HG6nHSwwT5nOhawSrTozfFz435+K xipENmyexzJZw+K183DFpkIo79s7MWQ1arEqdjIT0nwA2hbaV6oHn6eNN/h+ULP9a1VZ bdTGYUfFd6URV1wFv+qaTLmiXftBMQrdt/VCxFyAAU5bLdky4GG0UpcPo4pIxP/pxc6R tuHQIez/8IRCnbSivqRZPX1lAZ8h4+U1b6jifq3wLVSbooxheXg974lToAnBond2010q QyNrxbsW6IwqlNMZKuTOBh0B8ksBGagz3kKsXIKgtYQcNOCheFI8rqUnag561moNUjOV 8EWw== Received: by 10.236.156.34 with SMTP id l22mr12793697yhk.118.1332521313251; Fri, 23 Mar 2012 09:48:33 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id g7sm22757632yhm.5.2012.03.23.09.48.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 09:48:32 -0700 (PDT) Received: by yhkk25 with SMTP id k25so3217626yhk.31 for ; Fri, 23 Mar 2012 09:48:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.99 with SMTP id ot3mr30303527pbb.160.1332521310949; Fri, 23 Mar 2012 09:48:30 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Fri, 23 Mar 2012 09:48:30 -0700 (PDT) In-Reply-To: <4F6C6DC1.7020606@mozilla.com> References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <4F6C6DC1.7020606@mozilla.com> Date: Fri, 23 Mar 2012 12:48:30 -0400 Message-ID: From: Roman Shpount To: "Timothy B. Terriberry" Content-Type: multipart/alternative; boundary=047d7b15a68b6510fe04bbebcb04 X-Gm-Message-State: ALoCoQlpWE7MyHf2D0TSO2oHMsa5OxRPvxMRjFiiN5kZA6p4ibih0UhefQbzoT3MH606Mmc/KEw2 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 16:48:34 -0000 --047d7b15a68b6510fe04bbebcb04 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 23, 2012 at 8:34 AM, Timothy B. Terriberry < tterriberry@mozilla.com> wrote: > With a direct browser-to-browser connection, there is nothing sitting > between them to do the transcoding. In the DTLS-SRTP case with identity > verification, which I think a number of people here view as highly > important, you are in fact _guaranteeing_ that nothing but the browser can > encode or decode the video. > This is not technically correct. You can still build a system that implements a media proxy that does nothing but handling ICE, encryption, and identity verification without ever transcoding the content. The cost of re-encrypting the media is low (ie single E5 Xeon CPU can probably do about 10GB/s), but the cost of transcoding video, or even audio is huge in comparison. Because of this, supporting a comprehensive set of codecs is highly desirable. _____________ Roman Shpount --047d7b15a68b6510fe04bbebcb04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Mar 23, 2012 at 8:= 34 AM, Timothy B. Terriberry <tterriberry@mozilla.com> wrote:
With a direct browser-to-browser connection, there is nothing sitting betwe= en them to do the transcoding. In the DTLS-SRTP case with identity verifica= tion, which I think a number of people here view as highly important, you a= re in fact _guaranteeing_ that nothing but the browser can encode or decode= the video.

This is not technically correct. You can still build = a system that implements a media proxy that does nothing but handling ICE, = encryption, and identity verification without ever transcoding the content.= The cost of re-encrypting the media is low (ie single E5 Xeon CPU can prob= ably do about 10GB/s), but the cost of transcoding video, or even audio is = huge in comparison. Because of this, supporting a comprehensive set of code= cs is highly desirable.
_____________
Roman Shpount
--047d7b15a68b6510fe04bbebcb04-- From roman@telurix.com Fri Mar 23 10:14:35 2012 Return-Path: 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 4B19221F8602 for ; Fri, 23 Mar 2012 10:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.805 X-Spam-Level: X-Spam-Status: No, score=-2.805 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 sAhiVQjuxa-7 for ; Fri, 23 Mar 2012 10:14:31 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 121F121F858B for ; Fri, 23 Mar 2012 10:14:30 -0700 (PDT) Received: by yenm5 with SMTP id m5so3262903yen.31 for ; Fri, 23 Mar 2012 10:14:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=gExAO6g7+v85B5l+005RkrAP+W/nxh8lYL/l1r956ss=; b=m8vacbFPZiwUR0wKt3eQagS0IgIzuoT8X3POkizVZ9305hc5bYb+XnkLDBZPk6ScLc BM83wjJEky1ilODTzfbkb1ufBjx0EQItvKZOL41eBXf/oc7GYglw1BDELXyVfhmAdAuI HDxEyqVUavu9/0+nkoDpxQvff/CRYUhGB0bkawCz5kLhMBV+99W5p17Is2QNSrCjHQ+g M0hT5vUxnHr4seMsWCb4JnpJeV+XFCF9zmMXNiwmVxC+wglKZmEq44LLVdjkQYLB7NDt 43gk2Ox1khOtScBVaf1Q4OcOZMfzYM/ZtLqq9Zl4b9+km83G3FxHbm5UI6DYknSnkVBq lwSg== Received: by 10.236.173.195 with SMTP id v43mr13309098yhl.40.1332522865645; Fri, 23 Mar 2012 10:14:25 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id i7sm11011060ani.17.2012.03.23.10.14.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 10:14:24 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3276564ggm.31 for ; Fri, 23 Mar 2012 10:14:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.40 with SMTP id pp8mr30833380pbb.13.1332522862750; Fri, 23 Mar 2012 10:14:22 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Fri, 23 Mar 2012 10:14:22 -0700 (PDT) In-Reply-To: <13C620B3-1297-4212-B61C-5643E08E9748@acmepacket.com> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> <13C620B3-1297-4212-B61C-5643E08E9748@acmepacket.com> Date: Fri, 23 Mar 2012 13:14:22 -0400 Message-ID: From: Roman Shpount To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=047d7b10d17be3aa9b04bbec2761 X-Gm-Message-State: ALoCoQkkR3eP6aDSX+mq0Vza/51PVgG1mAPycKBlIUDWKUQXineJHhkyO7+Sv13kBmZxYBJn8K/7 Cc: "" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:14:35 -0000 --047d7b10d17be3aa9b04bbec2761 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable inline On Fri, Mar 23, 2012 at 12:29 AM, Hadriel Kaplan wr= ote: > comments inline=85 > > On Mar 22, 2012, at 9:31 PM, Roman Shpount wrote: > > > I would say that this activity would be covered by: > > Did you mean to have a #1 before #2 below? Your email was missing a #1. > > No, I did not mean to have #1 before #2 and #3. I was quoting the exact language in the chapter definition that should cover the activity related to WebRTC specific proxy. > > 2. Define a security model that describes the security and privacy > > goals and specifies the security protocol mechanisms necessary > > to achieve those goals. > > We've got that: > http://tools.ietf.org/html/draft-ietf-rtcweb-security > http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch > > These documents do not cover scenario when organization forces all the traffic to go through HTTP proxy to enforce its communication policy. > 3. Define the solution - protocols and API requirements - for > > firewall and NAT traversal. > > We've got that, though not in one doc: > http://tools.ietf.org/html/draft-ietf-rtcweb-overview > http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep > > Once again, these documents do not cover scenario when organization forces all the traffic to go through HTTP proxy. In such cases WebRTC simply will not work. At best, we can advise such organizations to deploy their own TURN server, but this allow all traffic to traverse into public internet, not just webrtc related one, which might be undesirable. > > I do consider ability to enforce the enterprise or location > communications policy on WebRTC clients to be one of the requirements for > security and privacy. > > OK, so what you're really saying is we have #2 and #3, but you don't agre= e > they cover the needs, and you want more added to #2 (and ultimately #3), > right? > I think we are currently missing one of the common network deployment scenarios for web browsers, where web browsers are deployed on a network non-routable to public internet with an HTTP proxy used to allow access to the web. I believe that we should add capabilities necessary to support such deployments. > > I expect that unless ability to enforce such communication policy withi= n > enterprises or other organizations is provided, WebRTC would be simply > disabled. > > In practical terms, I expect that an organization that enforces a > communication policy disables routing to public internet and only allows > communications via a company controlled HTTP proxy. Such setup would > effectively prevent WebRTC from operations. What I am suggesting is to > provide a complimentary protocol for inspection and modification of WebRT= C > SDP messages which would allow WebRTC enabled browser to control an > enterprise edge media proxy and would allow WebRTC media traffic to > traverse the enterprise firewall and to operate in such environment. > > Well... if they really can't enforce their policies, then by definition > they *should* disable it. That's a feature, not a bug. And luckily it > *can* be disabled, which is also a feature of WebRTC. > > Having said that, I don't understand why you think an organization that > has strict monitoring policies can't monitor and enforce WebRTC traffic, > both the HTTP *and* the media/data channels. They *can* do it. It's jus= t > not "automagic", and not cheap. But that's ok - I don't think we need to > optimize the deployment complexity or cost structure for that model. > The reason is that with custom signaling protocols implementing monitoring or enforcing policies would be very hard. BTW, this is not only and not primarily about recording traffic. This can be used to force all the traffic outside of the enterprise to be DTLS-SRTP only, but still allow DES-SRTP (or RTP if WebRTC will support it) within the enterprise network. _____________ Roman Shpount --047d7b10d17be3aa9b04bbec2761 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
inline

On Fri, Mar 23, = 2012 at 12:29 AM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:
comments inline=85

On Mar 22, 2012, at 9:31 PM, Roman Shpount wrote:

> I would say that this activity would be covered by:

Did you mean to have a #1 before #2 below? =A0Your email was missing = a #1.


No, I did not mean to hav= e #1 before #2 and #3. I was quoting the exact language in the chapter defi= nition that should cover the activity related to WebRTC specific proxy.
=A0
> 2. Define a security model that describes the security and privacy
> goals and specifies the security protocol mechanisms necessary
> to achieve those goals.

We've got that:
http://tools.ietf.org/html/draft-ietf-rtcweb-security
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch

> 3. Define the solution - protocols and API requirements - for
> firewall and NAT traversal.

We've got that, though not in one doc:
http://tools.ietf.org/html/draft-ietf-rtcweb-overview
http://tools.ietf.org/html/draft-ietf-rtcweb-use= -cases-and-requirements
http://tools.ietf.org/html/draft-ietf-rtcweb-jsep


Once again, these documen= ts do not cover scenario when organization forces all the traffic to go thr= ough HTTP proxy. In such cases WebRTC simply will not work. At best, we can= advise such organizations to deploy their own TURN server, but this allow = all traffic to traverse into public internet, not just webrtc related one, = which might be undesirable.
=A0
=A0
<= div class=3D"im"> > I do consider ability to enforce the enterprise or location communicat= ions policy on WebRTC clients to be one of the requirements for security an= d privacy.

OK, so what you're really saying is we have #2 and #3, but you do= n't agree they cover the needs, and you want more added to #2 (and ulti= mately #3), right?

I think= we are currently missing one of the common network deployment scenarios fo= r web browsers, where web browsers are deployed on a network non-routable t= o public internet with an HTTP proxy used to allow access to the web. I bel= ieve that we should add capabilities necessary to support such deployments.=
=A0
> I expect that unless ability to enforce such communication policy with= in enterprises or other organizations is provided, WebRTC would be simply d= isabled.
> In practical terms, I expect that an organization that enforces a comm= unication policy disables routing to public internet and only allows commun= ications via a company controlled HTTP proxy. Such setup would effectively = prevent WebRTC from operations. What I am suggesting is to provide a compli= mentary protocol for inspection and modification of WebRTC SDP messages whi= ch would allow WebRTC enabled browser to control an enterprise edge media p= roxy and would allow WebRTC media traffic to traverse the enterprise firewa= ll and to operate in such environment.

Well... if they really can't enforce their policies, then by defi= nition they *should* disable it. =A0That's a feature, not a bug. =A0And= luckily it *can* be disabled, which is also a feature of WebRTC.

Having said that, I don't understand why you think an organization that= has strict monitoring policies can't monitor and enforce WebRTC traffi= c, both the HTTP *and* the media/data channels. =A0They *can* do it. =A0It&= #39;s just not "automagic", and not cheap. =A0But that's ok -= I don't think we need to optimize the deployment complexity or cost st= ructure for that model.

The reason is that with custom signaling prot= ocols implementing monitoring or enforcing policies would be very hard. BTW= , this is not only and not primarily about recording traffic. This can be u= sed to force all the traffic outside of the enterprise to be DTLS-SRTP only= , but still allow DES-SRTP (or RTP if WebRTC will support it) within the en= terprise network.
_____________
Roman Shpount
--047d7b10d17be3aa9b04bbec2761-- From roman@telurix.com Fri Mar 23 10:29:56 2012 Return-Path: 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 BE17821F85E0 for ; Fri, 23 Mar 2012 10:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.808 X-Spam-Level: X-Spam-Status: No, score=-2.808 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 oMQ70EArhMt2 for ; Fri, 23 Mar 2012 10:29:56 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 149FA21F85DB for ; Fri, 23 Mar 2012 10:29:55 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3291398ggm.31 for ; Fri, 23 Mar 2012 10:29:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=3y16O56Y4yHUeK3LN/+vAaWY1ofFJtQWtep55Q+k5kA=; b=IWFaUjABUaN0ExTkN9xrW1+sXJjRuvlvd+jiHXfxmFIW1P1fc1YbOl2Bg6sGzaY1mS /WEUbT8TUgdoSlZzXxinoxhg7WCEYXxVQNQfi4lpPFbqwI2j/JC2gGIMkLf+sTYZjdEm YGoq/8v0wC5SHLDkindtcPYuktxV0abko5n+BtkOHyb3dgtq5/YIStT/JP5P1Xa66ooy OAxUVcLGFgbR5FUxDOBIAJSZYg/ODpmkoKKnFK3lvfkTFGCMnPO8YWnQe0Lsq+Hva2Af f2erRknsUB/XVSOeMHfbCKxDw5pjCD2KxwIXfVlhRWajR2R9RKuE+D6sGaeVAvtdU8Sj 5rAA== Received: by 10.68.216.6 with SMTP id om6mr31221661pbc.117.1332523794679; Fri, 23 Mar 2012 10:29:54 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id k3sm6233964pbd.17.2012.03.23.10.29.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 10:29:54 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2902882pbb.31 for ; Fri, 23 Mar 2012 10:29:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.201.98 with SMTP id jz2mr30748601pbc.97.1332523792813; Fri, 23 Mar 2012 10:29:52 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Fri, 23 Mar 2012 10:29:52 -0700 (PDT) In-Reply-To: <062901cd0905$e48bb520$ada31f60$@com> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> <03fa01cd087d$57899120$069cb360$@com> <387F9047F55E8C42850AD6B3A7A03C6C0E21E8F5@inba-mail01.sonusnet.com> <062901cd0905$e48bb520$ada31f60$@com> Date: Fri, 23 Mar 2012 13:29:52 -0400 Message-ID: From: Roman Shpount To: Dan Wing Content-Type: multipart/alternative; boundary=047d7b15aee9534f2304bbec5f21 X-Gm-Message-State: ALoCoQnJ5A6ju2L7tKNrPvI79hzk5QhpQ5ppqQY6NmnRI9bIMfzXjlyN1c6+glPsQWQ6XYIU5SwI Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:29:56 -0000 --047d7b15aee9534f2304bbec5f21 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 23, 2012 at 11:01 AM, Dan Wing wrote: > > 'Double encryption' is done because it's the only way to achieve > security at various layers. > > Probably a side note, but double encryption is often done since each encryption layer serves completely different purposes. In case of organizations that care about security of their communications (such as NSA), it is not only the content of the communication, but the fact that communication took place between certain parties is a secret. For example, the fact that president is calling Israeli prime minister in the middle of the night usually means that something significant is about to happen and normally is a national secret, even if the content of such conversation is unknown. To prevent eavesdropping on the communication parties, some sort of VPN protocol such IPsec is used. On the other hand, parties that are involved in the secure communication need to confirm each others identities and ensure that only identified parties will receive contents of the communication. This is insured by HTTPS with SRTP in case of WebRTC, or by SIPS with SRTP in case of NSA deployment. Bottom line, in most cases double encryption is a required feature and not a bug. _____________ Roman Shpount --047d7b15aee9534f2304bbec5f21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 23, 2012 at 11:01 = AM, Dan Wing <dwing= @cisco.com> wrote:

'Double encryption' is done because it's the only way to achiev= e
security at various layers.


Probably a side note, but double encryption is o= ften done since each encryption layer serves completely different purposes.=

In case of organizations that care about security of their communi= cations (such as NSA), it is not only the content of the communication, but= the fact that communication took place between certain parties is a secret= . For example, the fact that president is calling Israeli prime minister in= the middle of the night usually means that something significant is about = to happen and normally is a national secret, even if the content of such co= nversation is unknown. To prevent eavesdropping on the communication partie= s, some sort of VPN protocol such IPsec is used.

On the other hand, parties that are involved in the secure communicatio= n need to confirm each others identities and ensure that only identified pa= rties will receive contents of the communication. This is insured by HTTPS = with SRTP in case of WebRTC, or by SIPS with SRTP in case of NSA deployment= .

Bottom line, in most cases double encryption is a required feature and = not a bug.
_____________
Roman Shpount


--047d7b15aee9534f2304bbec5f21-- From snandaku@cisco.com Fri Mar 23 10:32:29 2012 Return-Path: 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 B314021F860F for ; Fri, 23 Mar 2012 10:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.811 X-Spam-Level: X-Spam-Status: No, score=-8.811 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 rPzJIjDEl1zB for ; Fri, 23 Mar 2012 10:32:25 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B28D021F8615 for ; Fri, 23 Mar 2012 10:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=snandaku@cisco.com; l=1027; q=dns/txt; s=iport; t=1332523945; x=1333733545; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=E3xBx2EXVuN4iNnq7g9gAnZIX4vhZeKfrLvwVv/9I64=; b=A/trFOShCzGMbMJeSv8pCq+ncwxmezsbIP9S/4kzyuiXVLWoYHOY+mV6 gYh0ZgRQh2i56YeVcSPt6ozW71/Rb5Jfht77rb2VJDUU7+dcsbEDmpiIi z1vTjlOHFFRtRSSuLRgHz5l08AsjCsc8eJequb4Sv1FPjP1G57HjSnueu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADezbE+tJV2b/2dsb2JhbABFgka0SniBB4IACwEEEgEqTwgDAQIDgRQGNYdomGSBJ559jWGDJASIV4Uqh1+ORIFogwc X-IronPort-AV: E=Sophos;i="4.73,637,1325462400"; d="scan'208,217";a="68939656" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 23 Mar 2012 17:32:25 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2NHWP8r004320 for ; Fri, 23 Mar 2012 17:32:25 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 12:32:25 -0500 Received: from 10.21.88.243 ([10.21.88.243]) by XMB-RCD-212.cisco.com ([72.163.62.219]) with Microsoft Exchange Server HTTP-DAV ; Fri, 23 Mar 2012 17:31:44 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 23 Mar 2012 10:31:44 -0700 From: snandaku To: Message-ID: Thread-Topic: rtcweb Digest, Vol 13, Issue 51 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415343504_14619595" X-OriginalArrivalTime: 23 Mar 2012 17:32:25.0066 (UTC) FILETIME=[E93F6CA0:01CD091A] Subject: Re: [rtcweb] rtcweb Digest, Vol 13, Issue 51 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:32:29 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3415343504_14619595 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I will be on official travel from 3/23 - 4/02 and will be slow in responding to your messages. For Kalliste questions please contact Susie Wee For RTCWeb questions please contact Ethan Hugg. --B_3415343504_14619595 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: rtcweb Digest, Vol 13, Issue 51 I will be on official travel from 3/23 - 4/02 and will be s= low in responding to your messages.
For Kalliste questions please contact Susie Wee
For RTCWeb questions please contact Ethan Hugg. --B_3415343504_14619595-- From dwing@cisco.com Fri Mar 23 10:35:32 2012 Return-Path: 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 B195E21F861E for ; Fri, 23 Mar 2012 10:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.42 X-Spam-Level: X-Spam-Status: No, score=-109.42 tagged_above=-999 required=5 tests=[AWL=1.179, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 WSXEmb-hhrq6 for ; Fri, 23 Mar 2012 10:35:28 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 10BE621F861B for ; Fri, 23 Mar 2012 10:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5442; q=dns/txt; s=iport; t=1332524128; x=1333733728; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Od54snahOTt2JlzJ0YlpPxtrrRNnr/sO0b1zoH4+lU8=; b=irz8+AhSVoa8BzfeJVpfgrchcg187opwwktZgSsuE5Lq0nv3Gi2Hm3NA PJpKhJqVzEE/ZsdtdIRIWB1Hbs9c5BnbRfSTGRFO24fSwP9w4r99eppWj x8YBtw9x5DP+VBbIHic9oT0E0pkQiPFkofrgkpwoXlK9787D3Sg+NrpSO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGezbE+rRDoJ/2dsb2JhbAA5Cagsj2WBB4IJAQEBAwEBAQEFCgEXEDQLBQcBAwIJDwIEAQEoBxkOFQoJCAEBBAESCxAHhW+BdAQMnlmNUYlGiluGKgSIV4UTkymDEYFogweBPA X-IronPort-AV: E=Sophos;i="4.73,637,1325462400"; d="scan'208";a="34828166" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 23 Mar 2012 17:35:25 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2NHZO5E014074; Fri, 23 Mar 2012 17:35:24 GMT From: "Dan Wing" To: "'Hutton, Andrew'" , "'Roman Shpount'" , "'Harald Alvestrand'" , "'Ted Hardie'" References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> <03fa01cd087d$57899120$069cb360$@com> <101C6067BEC68246B0C3F6843BCCC1E31296B58E75@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31296B58E75@MCHP058A.global-ad.net> Date: Fri, 23 Mar 2012 10:35:24 -0700 Message-ID: <06dc01cd091b$54aaa950$fdfffbf0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0INr3Z1+RYf6xDTCirryldOl72eAARbPMAACGHm/AAAvHbUA== Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:35:32 -0000 > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: Friday, March 23, 2012 7:55 AM > To: Dan Wing; 'Roman Shpount'; 'Harald Alvestrand'; 'Ted Hardie' > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] Resolving RTP/SDES question in Paris > > Hi Dan, > > I don't think SIPREC has a solution to the particular problem that > Roman is talking about and it would probably not be within scope of > SIPREC to solve this even assuming that there is some SIP involved. > > If the prison deployed its own RTCWeb application and restricted the > prisoner to using only this application then of course there would be > no problem with intercepting the media and a SIPREC type solution could > be deployed with some kind of B2BUA which has access to both signaling > and media initiating the media recording and of course informing the > prisoner that they are being recorded. If recording by the jail is necessary, the identity provider would need to the jail when you're in jail. Or, if working at a company that needs to record, that company would be your identity provider. I work for Cisco, and my email address is dwing@cisco.com -- Cisco clearly owns my @cisco.com identity. The identity provider can do many things. For WEBRTC, the identity provider can force themselves into being able to decrypt the SRTP session, and they can prevent a session from being established if the end user (dwing@cisco.com) refuses to allow that decryption. > However if the prisoner is allowed to access their lawyers RTCWeb > application and download the JavaScript from there then SIPREC does not > help the prison record the resulting media exchanged. Putting RTCWEB aside for a moment, Javascript can establish a Diffie-Hellman exchange between a client and server. After the DH exchange, the prisoner can now securely communicate with their lawyer -- but has to type and read (tomorrow, with RTCWEB, the prisoner could speak and listen). If the lawyer or prisoner were worried the DH exchange or the Javascript itself might be compromised, they can use out of band techniques (exchanging pieces of paper) to verify the DH exchange and checksum the Javascript. Javascript could also be used to operate a one-time-pad encryption system. I think the problem with 'jails' is not new to RTCWEB, and the problem exists if the problem space includes a prisoner with has access to a computer that can run code obtained from outside the jail, such as from the Internet, such as any Javascript. If the concern is Javascript providing a stenography channel, that problem is unsolvable. That Javascript could, for all we know, send SRTP with RTCWEB, or encrypted text messages without RTCWEB, over any channel it wants -- including over DNS, for example. There is code available that sends IP over DNS, such as http://code.kryo.se/iodine) -d > Regards > Andy > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of Dan Wing > > Sent: 22 March 2012 22:44 > > To: 'Roman Shpount'; 'Harald Alvestrand'; 'Ted Hardie' > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris > > > > > -----Original Message----- > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > > Behalf Of Roman Shpount > > > Sent: Thursday, March 22, 2012 7:19 AM > > > To: Harald Alvestrand > > > Cc: rtcweb@ietf.org > > > Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris > > ... > > > Yes, I was worried about supporting the interceptor. This is all > > > related to my question of support of WebRTC applications in > military, > > > prisons, or financial organizations. I think WebRTC would be > > completely > > > disabled in such locations unless web browser can be configured to > > > confirm to some sort of communications and monitoring policy. I do > > not > > > think enabling only certain applications is a sustainable solution, > > > since application can only be enabled based on its URL, but this in > > no > > > way implies that the actual protocol used for signaling exchange by > > > this application will stay the same. In the best case this will > > result > > > in tens of specialized monitoring rules that will need to be > > > maintained. In the worst case, WebRTC would be simply disabled. At > > this > > > point the only workable solution that I see is some sort of media > > proxy > > > protocol. > > > > The SIPREC working group, formed in March 2010, has solutions for > > this problem. The problem is not created by RTCWEB. Disabling > > encryption is not necessary -- nor desirable. "Jails" get brought up > > in this context often, so using that same example, consider a > prisoner > > at a jail communicating with their lawyer. The prisoner needs secure > > communications with their lawyer without the risk of the > > communications being leaked to the press by anyone along the media > > path. For details see http://tools.ietf.org/wg/siprec/ > > > > We will have a brietf presentation on SIPREC during my session > > at RTCWEB, explaining how it can work with RTCWEB. > > > > -d > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Fri Mar 23 10:45:13 2012 Return-Path: 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 A894721F85FF for ; Fri, 23 Mar 2012 10:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 e39Iye7tlDWM for ; Fri, 23 Mar 2012 10:45:12 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A462621F857A for ; Fri, 23 Mar 2012 10:45:12 -0700 (PDT) Received: by yenm5 with SMTP id m5so3291658yen.31 for ; Fri, 23 Mar 2012 10:45:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=1V0SvDD8VK7PkNZm8EcVlKRw+hvtt1S4iDBcx1Cg6Jw=; b=pIs7EYyqmrjwem7h2TDj4WJz9a8J4oxo2Jih7OLlX2vmHMo1XKZPreIoPUU+D0WkFZ OAhwL38gDtTxUq7I7D7+kr0isoUxA6VJSMn0nDVeOPVYBTXiw8528gH6K65d3ssqH2/c QBn2dsN32rpVCQluyxqeRH/YAZU8WM/eG2anhS241Sw6xsxDrrAVNbDb4b/WEwLYKCfZ 7fYoS1mh5n4MWyiB8X16I3cJJKM/rEjYtoWtoh2Jo343RkbrwLtAE6WLXQ8ZGmMyx+uc qffHu3cxhT1QCQbcp1u7ijPyDv4urUectqCdjiJ42CL+SS57wfEroRiAjgmUU5TY6uay q53g== Received: by 10.236.201.233 with SMTP id b69mr5301829yho.71.1332524711968; Fri, 23 Mar 2012 10:45:11 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id k35sm11131775ani.3.2012.03.23.10.45.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 10:45:11 -0700 (PDT) Received: by yenm5 with SMTP id m5so3291629yen.31 for ; Fri, 23 Mar 2012 10:45:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.221.10 with SMTP id qa10mr30110358pbc.139.1332524710553; Fri, 23 Mar 2012 10:45:10 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Fri, 23 Mar 2012 10:45:10 -0700 (PDT) In-Reply-To: References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> Date: Fri, 23 Mar 2012 13:45:10 -0400 Message-ID: From: Roman Shpount To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=e89a8ff2480106e68104bbec961f X-Gm-Message-State: ALoCoQmD84cl8XPNvUtvm2ZucR2Fu9I0DCAoLlSVDls/sVTCvhUidBEXF+snZQBgXZ6aWD5Nvcx6 Cc: "" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:45:13 -0000 --e89a8ff2480106e68104bbec961f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Mar 23, 2012 at 1:39 AM, Hadriel Kaplan wro= te: > > I was trying to follow this thread backwards from today, to try to grok > how you got to the conclusion that an organization with strict media > monitoring policies wouldn't be able to do so for WebRTC. I think the > above email is where I get disconnected form the train of thought. > > If, as in another email you sent, an organization such as the military or > jail or whatever controls its network such that they use the whitelist > model of only authorized applications allowed our of their network, and > everything goes through the HTTP proxy, then the above statement of: > > > Media description is carried in some sort of application defined > protocol (can even be transmitted over an encrypted SCTP data channel or > encrypted in javaScript), so monitoring proxy cannot reliably modify it. > > =85 makes no sense to me. > > If you were preventing unknown applications, you would not allow unknown > UDP or TCP destination ports to be used to get out of the network. The > HTTP Proxy has to (1) know your web application wants to use another set = of > ports, and (2) has to allow it. Ergo, there can be no "encrypted SCTP da= ta > channel" that was not previously authorized; nor would encrypting > SDP-type-info in Javascript help you one iota, because you won't be able = to > actually use it to send media, since the HTTP proxy is not opening new > ports for you to reach the Internet. > So I don't understand what the problem is. If you run a super-tight > network like that and you *do not* want WebRTC to work because you can't > monitor it, then by design it won't work. If you run a super-tight netwo= rk > like that and you *do* want WebRTC to work, then you either have to be > willing to install custom browsers/apps, or your HTTP Proxy has to be abl= e > to see the HTTP traffic and correctly parse the Javascript-passed data an= d > be a media b2bua. That's a really nasty set of constraints, especially > trying to grok the javascript enough to be a media b2bua, and undoubtedly > means it won't work for many WebRTC websites. But that's arguably the > right thing to happen - downloading javascript is akin to downloading a n= ew > application for each website, and again by definition this is a network > that only wants to allow applications it wants to allow, so that's what i= t > gets: per-application control, and thus requires per-application > knowledge/support. Anything your proxy doesn't understand doesn't work, > but again that's kinda the point of a super-tight policy. > > My problem with all of this that as far as communication policies are concerned, for all the practical purposes managing WebRTC becomes just a big on/off switch. It is not practical to reverse engineer JavaScript application to enable media proxy/ B2BUA to work transparently just by monitoring HTTP communications. Even if such HTTP proxy based B2BUA can be developed, it will break after the first javascript application update. The solution you describe is possible but is extremely brittle. > Personally, if I were running such an org, and I don't know if it's > possible, but I'd go get some form of rootkit/kernel-mod to intercept > audio/video/keystrokes well below the user layer, so that you wouldn't ha= ve > to worry what application was running - just intercept the > audio/screen/keyboard somewhere near the drivers. Presumably some > companies make such things, for just such organizations? (sort of like th= e > equivalent of CarrierIQ) That way it doesn't matter whether it's WebRTC, > Flash, or native apps. > > Unfortunately this does not always work. What you are looking for is a way to enforceme that all the devices on the organizational network either confirms to organization communication policy or not allowed to communicate. This also applies to other devices that are being brought to your organization (ie lawyer laptop in prison). Organization cannot force everybody to install a key logger to their computers that they bring in, but they can force all the communications coming from within the organization to go through some sort of proxy or not to be allowed to communicate. _____________ Roman Shpount --e89a8ff2480106e68104bbec961f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 23, 2012 at 1:39 AM, Hadriel Kap= lan <HKaplan= @acmepacket.com> wrote:

I was trying to follow this thread backwards from today, to try to grok how= you got to the conclusion that an organization with strict media monitorin= g policies wouldn't be able to do so for WebRTC. =A0I think the above e= mail is where I get disconnected form the train of thought.

If, as in another email you sent, an organization such as the military or j= ail or whatever controls its network such that they use the whitelist model= of only authorized applications allowed our of their network, and everythi= ng goes through the HTTP proxy, then the above statement of:

> Media description is carried in some sort of application defined proto= col (can even be transmitted over an encrypted SCTP data channel or encrypt= ed in javaScript), so monitoring proxy cannot reliably modify it.

=85 makes no sense to me.

If you were preventing unknown applications, you would not allow unknown UD= P or TCP destination ports to be used to get out of the network. =A0The HTT= P Proxy has to (1) know your web application wants to use another set of po= rts, and (2) has to allow it. =A0Ergo, there can be no "encrypted SCTP= data channel" that was not previously authorized; nor would encryptin= g SDP-type-info in Javascript help you one iota, because you won't be a= ble to actually use it to send media, since the HTTP proxy is not opening n= ew ports for you to reach the Internet.
So I don't understand what the problem is. =A0If you run a super-tight = network like that and you *do not* want WebRTC to work because you can'= t monitor it, then by design it won't work. =A0If you run a super-tight= network like that and you *do* want WebRTC to work, then you either have t= o be willing to install custom browsers/apps, or your HTTP Proxy has to be = able to see the HTTP traffic and correctly parse the Javascript-passed data= and be a media b2bua. =A0That's a really nasty set of constraints, esp= ecially trying to grok the javascript enough to be a media b2bua, and undou= btedly means it won't work for many WebRTC websites. =A0But that's = arguably the right thing to happen - downloading javascript is akin to down= loading a new application for each website, and again by definition this is= a network that only wants to allow applications it wants to allow, so that= 's what it gets: per-application control, and thus requires per-applica= tion knowledge/support. =A0Anything your proxy doesn't understand doesn= 't work, but again that's kinda the point of a super-tight policy.<= br>

My problem with all of this that as far as communication policies are=20 concerned, for all the practical purposes managing WebRTC becomes just a big on/off switch. It is not practical to reverse engineer JavaScript=20 application to enable media proxy/ B2BUA to work transparently just by=20 monitoring=A0 HTTP communications. Even if such HTTP proxy based B2BUA can be developed, it will break after the first javascript application=20 update. The solution you describe is possible but is extremely brittle.
=A0
Personally, if I were running such an org, and I don't know if it's= possible, but I'd go get some form of rootkit/kernel-mod to intercept = audio/video/keystrokes well below the user layer, so that you wouldn't = have to worry what application was running - just intercept the audio/scree= n/keyboard somewhere near the drivers. =A0Presumably some companies make su= ch things, for just such organizations? (sort of like the equivalent of Car= rierIQ) =A0That way it doesn't matter whether it's WebRTC, Flash, o= r native apps.

=A0
Unfortun= ately this does not always work. What you are looking for is a way to enfor= ceme that all the devices on the organizational network either confirms to = organization communication policy or not allowed to communicate. This also = applies to other devices that are being brought to your organization (ie la= wyer laptop in prison). Organization cannot force everybody to install a ke= y logger to their computers that they bring in, but they can force all the = communications coming from within the organization to go through some sort = of proxy or not to be allowed to communicate.
_____________
Roman Shpount
--e89a8ff2480106e68104bbec961f-- From sergel@google.com Fri Mar 23 11:23:27 2012 Return-Path: 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 9FBFD21F862F for ; Fri, 23 Mar 2012 11:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.71 X-Spam-Level: X-Spam-Status: No, score=-100.71 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 JjAL6YJCbETV for ; Fri, 23 Mar 2012 11:23:23 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62FFE21F8629 for ; Fri, 23 Mar 2012 11:23:23 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3342870ggm.31 for ; Fri, 23 Mar 2012 11:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :x-system-of-record; bh=i3gzrb6g+LjbaYJq62p2bv3K54sYhkrkOXFR3snw0is=; b=SommVj2VK1nHRNCeE+nULKc4SkRwUZBUlMYAwQU1ZOjKN9LFlMcqRthOkSVwXCzxDV KhGlsPfOCUR8TlMa2WySfUgD5oOmWcYzXmnBa4NpoyhWDJ8KD0cZbc860aO7k9HwBEep pKyvz6TLDCSE5bRwWmVecoK+MkvraHU6I1TwIXzhBmc29EurExKt5dxC8vhaky207RNI pBJ0HSbvIZxKtP4NSxpoz3md718yzbfOjW2vmi/Dg7cbegvgGR08n+T4EwUYf1PvJCtZ SiIVr32ilYJHo17ntC0H0CwfXD9HJfKtkOydqkmd+xaGB8AFadjSbzF8OOjHUjK5uKYp nQUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=i3gzrb6g+LjbaYJq62p2bv3K54sYhkrkOXFR3snw0is=; b=H06dtMXTHyYrlymNyUdgLB7ow4/24x5zWT91qdPbeL/gk1otIHrcxnIr4CAs1vaKjG cRsOPuu6rscM1QUf56bly1lZlusYbqslso1Ln+5EnK4U449MCq8r/AaOVuBonSuqE5y8 +Ji+gf9W/z5kz2noHjOucd4OEKG6Gf5ri0KEelAXyhAONAPfaaqdyRdwS8J+GqvsTDC0 /EjIrnx8lPq7xBsXydGL8Pww4s2Mx92VPopsUW+dwZW2RDNJSoqwHyvyF6OvX61pyGFl ya6FidUSIPhm0RAg9JN5qoOwJ7eunca0j3L06G193ENDM9pFu9h3mukwLg+m+W+oeraQ uKzw== Received: by 10.60.28.33 with SMTP id y1mr11149134oeg.62.1332527002759; Fri, 23 Mar 2012 11:23:22 -0700 (PDT) Received: by 10.60.28.33 with SMTP id y1mr11149126oeg.62.1332527002659; Fri, 23 Mar 2012 11:23:22 -0700 (PDT) MIME-Version: 1.0 Sender: sergel@google.com Received: by 10.182.69.226 with HTTP; Fri, 23 Mar 2012 11:22:52 -0700 (PDT) In-Reply-To: <4F6C6138.6010908@mozilla.com> References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> From: Serge Lachapelle Date: Fri, 23 Mar 2012 19:22:52 +0100 X-Google-Sender-Auth: LIwQn18EfiYkwQpaVmJVSDpA75A Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb1fffaa5aaa904bbed1e13 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnRrLf+1cnaCpcHbdC6SYR9KfJWZBTWkhlpwM/P+DCzPrFZGQAuPe4KfnGSMevBtfjgGy2PXdEwqZFn2lqolAHl7Gv7/9lnu4fNMTMe2ZX3MbFEvdwVFwG50BCkC4zzylSVPipC Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 18:23:27 -0000 --e89a8fb1fffaa5aaa904bbed1e13 Content-Type: text/plain; charset=ISO-8859-1 Chrome's WebRTC stack will only include the VP8 codec. Best Regards, /Serge On Fri, Mar 23, 2012 at 12:40, Timothy B. Terriberry < tterriberry@mozilla.com> wrote: > Stefan Hakansson LK wrote: > >> So, I propose that h.264 should be mandatory to implement. >> > > Mozilla strongly opposes such a proposal. Many will be familiar with our > announcements regarding our use of platform codecs on B2G and possibly > Android last week. The primary reasoning behind that decision, i.e. the one > factor that was not in our power to change, was the availability of content > on websites. This is not a problem for WebRTC, as browsers control both > ends of the communication. > > What _is_ a problem is licensing and distributing encoders in an > open-source project. This is quite a bit different than using system > decoders, as outside of mobile, encoders are usually not available, and > even if they were, they might not have particularly good quality, nor the > features to control latency, loss robustness, and other aspects necessary > for real-time communication. > > If you thought that a concession in one place would make Mozilla more > likely to compromise in others, I assure you the opposite is true. > Maintaining the use of RF codecs in WebRTC is now even more important than > it was before. See the words directly from Mozilla's CTO: > http://groups.google.com/**group/mozilla.dev.platform/** > msg/53892ad3ea9eeb98 > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880 > > Apparently, this footer is required in Europe. Apologies. This email may > be confidential or privileged. If you received this communication by > mistake, please don't forward it to anyone else,please erase all copies and > attachments, and please let me know that it went to the wrong person. > Thanks. > --e89a8fb1fffaa5aaa904bbed1e13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Chrome's WebRTC stack will only include the VP8 codec.
=

Best Regards,=A0

=
/Serge

On Fri, Mar 23, 2012 = at 12:40, Timothy B. Terriberry <tterriberry@mozilla.com> wrote:
Stefan Hakansson LK wrote:=
So, I propose that h.264 should be mandatory to implement.

Mozilla strongly opposes such a proposal. Many will be familiar with our an= nouncements regarding our use of platform codecs on B2G and possibly Androi= d last week. The primary reasoning behind that decision, i.e. the one facto= r that was not in our power to change, was the availability of content on w= ebsites. This is not a problem for WebRTC, as browsers control both ends of= the communication.

What _is_ a problem is licensing and distributing encoders in an open-sourc= e project. This is quite a bit different than using system decoders, as out= side of mobile, encoders are usually not available, and even if they were, = they might not have particularly good quality, nor the features to control = latency, loss robustness, and other aspects necessary for real-time communi= cation.

If you thought that a concession in one place would make Mozilla more likel= y to compromise in others, I assure you the opposite is true. Maintaining t= he use of RF codecs in WebRTC is now even more important than it was before= . See the words directly from Mozilla's CTO: http://groups.google.com/group/mozilla.dev.platform/msg/538= 92ad3ea9eeb98

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
Google Sweden AB | K= ungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880=A0

Apparentl= y, this footer is required in Europe. Apologies. This email may be confiden= tial or privileged. =A0If you received this communication by mistake, pleas= e don't forward it to anyone else,please erase all copies and attachmen= ts, and please let me know that it went to the wrong person. =A0Thanks.
--e89a8fb1fffaa5aaa904bbed1e13-- From harald@alvestrand.no Fri Mar 23 11:39:12 2012 Return-Path: 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 EC28E21E801C for ; Fri, 23 Mar 2012 11:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.52 X-Spam-Level: X-Spam-Status: No, score=-110.52 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 Vsj79nQyIIJr for ; Fri, 23 Mar 2012 11:39:09 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 94A4D21E8013 for ; Fri, 23 Mar 2012 11:39:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A042B39E112; Fri, 23 Mar 2012 19:39:07 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bndLQFBa8SGo; Fri, 23 Mar 2012 19:39:03 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 06F5139E0C0; Fri, 23 Mar 2012 19:39:03 +0100 (CET) Message-ID: <4F6CC346.9000703@alvestrand.no> Date: Fri, 23 Mar 2012 19:39:02 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Roman Shpount References: <4F4759DC.7060303@ericsson.com> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> <13C620B3-1297-4212-B61C-5643E08E9748@acmepacket.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070305000507050201060107" Cc: "" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 18:39:13 -0000 This is a multi-part message in MIME format. --------------070305000507050201060107 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 03/23/2012 06:14 PM, Roman Shpount wrote: > > > 3. Define the solution - protocols and API requirements - for > > firewall and NAT traversal. > > We've got that, though not in one doc: > http://tools.ietf.org/html/draft-ietf-rtcweb-overview > http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep > > > Once again, these documents do not cover scenario when organization > forces all the traffic to go through HTTP proxy. Roman, It seems to me that you are arguing that the scenarios in section 4.1 of the use cases document do not cover that specific case, and I think you are right in that; the list is: The following considerations are applicable to all use cases: o Clients can be on IPv4-only o Clients can be on IPv6-only o Clients can be on dual-stack o Clients can be on wideband (10s of Mbits/sec) o Clients can be on narrowband (10s to 100s of Kbits/sec) o Clients can be on variable-media-quality networks (wireless) o Clients can be on congested networks o Clients can be on firewalled networks with no UDP allowed o Clients can be on networks with cone NAT o Clients can be on networks with symmetric NAT Now, there are two ways to interpret this omission: - The WG did not think of that use case when the list was created - The WG does not want that use case on the list because it constrains the solution space too much If (re)opening this issue, I think I'd find myself in the "do not want that use case" camp. Harald --------------070305000507050201060107 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/23/2012 06:14 PM, Roman Shpount wrote:

> 3. Define the solution - protocols and API requirements - for
> firewall and NAT traversal.

We've got that, though not in one doc:
http://tools.ietf.org/html/draft-ietf-rtcweb-overview
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements
http://tools.ietf.org/html/draft-ietf-rtcweb-jsep


Once again, these documents do not cover scenario when organization forces all the traffic to go through HTTP proxy.
Roman,
It seems to me that you are arguing that the scenarios in section 4.1 of the use cases document do not cover that specific case, and I think you are right in that; the list is:

   The following considerations are applicable to all use cases:
   o  Clients can be on IPv4-only
   o  Clients can be on IPv6-only
   o  Clients can be on dual-stack
   o  Clients can be on wideband (10s of Mbits/sec)
   o  Clients can be on narrowband (10s to 100s of Kbits/sec)
   o  Clients can be on variable-media-quality networks (wireless)
   o  Clients can be on congested networks
   o  Clients can be on firewalled networks with no UDP allowed
   o  Clients can be on networks with cone NAT
   o  Clients can be on networks with symmetric NAT

Now, there are two ways to interpret this omission:

- The WG did not think of that use case when the list was created
- The WG does not want that use case on the list because it constrains the solution space too much

If (re)opening this issue, I think I'd find myself in the "do not want that use case" camp.

            Harald


--------------070305000507050201060107-- From harald@alvestrand.no Fri Mar 23 11:41:13 2012 Return-Path: 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 E00AC21E804D for ; Fri, 23 Mar 2012 11:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.522 X-Spam-Level: X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 kcQLwbnGAR8h for ; Fri, 23 Mar 2012 11:41:09 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7B49621E8048 for ; Fri, 23 Mar 2012 11:41:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B70C539E112; Fri, 23 Mar 2012 19:41:08 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzLIrIaoGG+u; Fri, 23 Mar 2012 19:41:04 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 360FD39E0C0; Fri, 23 Mar 2012 19:41:04 +0100 (CET) Message-ID: <4F6CC3BF.4040903@alvestrand.no> Date: Fri, 23 Mar 2012 19:41:03 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Roman Shpount References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090700050207020603030500" Cc: "" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 18:41:14 -0000 This is a multi-part message in MIME format. --------------090700050207020603030500 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 03/23/2012 06:45 PM, Roman Shpount wrote: > > Unfortunately this does not always work. What you are looking for is a > way to enforceme that all the devices on the organizational network > either confirms to organization communication policy or not allowed to > communicate. This also applies to other devices that are being brought > to your organization (ie lawyer laptop in prison). Organization cannot > force everybody to install a key logger to their computers that they > bring in, but they can force all the communications coming from within > the organization to go through some sort of proxy or not to be allowed > to communicate. > I think you are looking for http://tools.ietf.org/wg/nea/charters, not RTCWEB. --------------090700050207020603030500 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/23/2012 06:45 PM, Roman Shpount wrote:

 
Unfortunately this does not always work. What you are looking for is a way to enforceme that all the devices on the organizational network either confirms to organization communication policy or not allowed to communicate. This also applies to other devices that are being brought to your organization (ie lawyer laptop in prison). Organization cannot force everybody to install a key logger to their computers that they bring in, but they can force all the communications coming from within the organization to go through some sort of proxy or not to be allowed to communicate.


I think you are looking for http://tools.ietf.org/wg/nea/charters, not RTCWEB.


--------------090700050207020603030500-- From igor.faynberg@alcatel-lucent.com Fri Mar 23 11:53:41 2012 Return-Path: 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 583B821E804E for ; Fri, 23 Mar 2012 11:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.275 X-Spam-Level: X-Spam-Status: No, score=-9.275 tagged_above=-999 required=5 tests=[AWL=1.324, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 o+1vWSnhHyDv for ; Fri, 23 Mar 2012 11:53:37 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3E421F861F for ; Fri, 23 Mar 2012 11:53:37 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q2NIrYlT022356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Mar 2012 13:53:34 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2NIrXO6003290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Mar 2012 13:53:34 -0500 Received: from [135.244.32.113] (faynberg.lra.lucent.com [135.244.32.113]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2NIrWg5004679; Fri, 23 Mar 2012 13:53:32 -0500 (CDT) Message-ID: <4F6CC6B6.7060903@alcatel-lucent.com> Date: Fri, 23 Mar 2012 14:53:42 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Harald Alvestrand References: <4F6B5FEE.9060706@alcatel-lucent.com> <4F6B6CD6.2070801@alcatel-lucent.com> <4F6C5D02.6010800@alvestrand.no> In-Reply-To: <4F6C5D02.6010800@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] IdP in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 18:53:41 -0000 Now I understand and agree that we cannot change their specification. But... do we need to use it? Igor On 3/23/2012 7:22 AM, Harald Alvestrand wrote: > On 03/22/2012 07:17 PM, Igor Faynberg wrote: >> Thanks! Now I understand. >> >> My only follow-up question (and that could probably wait until the >> next week) is why not make BrowserID certificate adhere to X.509. If >> we issue self-signed X.509 certificates ourselves, what is in the way >> of any IdP doing just that? > The BrowserID specification is the work item of a group that is > entirely outside of this group. > You can certainly go there (browserid.org) to argue that they should > change to X.509 certificates, but we can't decide in the RTCWEB WG > that they should change. > >> >> Igor >> >> On 3/22/2012 1:53 PM, Eric Rescorla wrote: >>> Good question. >>> >>> 1. BrowserID certificates aren't X.509, and that's all the TLS/DTLS >>> will do. >>> 2. This lets us be agnostic about IdP mechanisms without having to >>> change >>> TLS every time we add a new one. >>> >>> -Ekr >>> >>> >>> On Thu, Mar 22, 2012 at 6:22 PM, Igor Faynberg >>> wrote: >>>> Eric, >>>> >>>> A question: For the case of BrowserID, I understand that a client >>>> gets a >>>> certificate from an IdP. If so, why you and I would not use the >>>> certificates from our respective IdPs in order to authenticate each >>>> other >>>> in DTLS? >>>> >>>> Igor >>>> >>>> >>>> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > From snandaku@cisco.com Fri Mar 23 11:56:18 2012 Return-Path: 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 CBEE721F8623 for ; Fri, 23 Mar 2012 11:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.941 X-Spam-Level: X-Spam-Status: No, score=-8.941 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 ugI9CfgEaHyY for ; Fri, 23 Mar 2012 11:56:14 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CF1D121F85F4 for ; Fri, 23 Mar 2012 11:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1027; q=dns/txt; s=iport; t=1332528974; x=1333738574; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=Pc5vDzUNdyD2p42FfS5sPj07RWC9lkDeKVplpSD1fX0=; b=Gicj2yzauspyrelHtaEnggdBblCPs9+ITJZKBGVhECAWfAN2McDwFQpx vp6UHT8D8KNPlrO6aWyWO7/AMwwwzjyabuUpUEFwKRlb0akaUWS4VCktY IXlOx/GlWwCTtqQZfC7SL4ti22BognqWVKKLCfq5Y3U0okP8VYI7lFdQ4 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOTGbE+tJXG8/2dsb2JhbABFgka0VHiBB4IACwEEEgEqTwgDAQIDgRQGNYdomF6BJ557jWGDJASIV4Uqh1+ORIFogwc X-IronPort-AV: E=Sophos;i="4.73,637,1325462400"; d="scan'208,217";a="65947515" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 23 Mar 2012 18:56:14 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2NIuEKm010641 for ; Fri, 23 Mar 2012 18:56:14 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 13:56:14 -0500 Received: from 10.21.90.237 ([10.21.90.237]) by XMB-RCD-212.cisco.com ([72.163.62.219]) with Microsoft Exchange Server HTTP-DAV ; Fri, 23 Mar 2012 18:55:16 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 23 Mar 2012 11:55:15 -0700 From: snandaku To: Message-ID: Thread-Topic: rtcweb Digest, Vol 13, Issue 52 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415348516_14784083" X-OriginalArrivalTime: 23 Mar 2012 18:56:14.0114 (UTC) FILETIME=[9ECB4020:01CD0926] Subject: Re: [rtcweb] rtcweb Digest, Vol 13, Issue 52 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 18:56:18 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3415348516_14784083 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I will be on official travel from 3/23 - 4/02 and will be slow in responding to your messages. For Kalliste questions please contact Susie Wee For RTCWeb questions please contact Ethan Hugg. --B_3415348516_14784083 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: rtcweb Digest, Vol 13, Issue 52 I will be on official travel from 3/23 - 4/02 and will be s= low in responding to your messages.
For Kalliste questions please contact Susie Wee
For RTCWeb questions please contact Ethan Hugg. --B_3415348516_14784083-- From abu_hurayrah@hidayahonline.org Fri Mar 23 12:01:05 2012 Return-Path: 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 D534A21F866D for ; Fri, 23 Mar 2012 12:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] 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 hA67pMQIVdth for ; Fri, 23 Mar 2012 12:01:05 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3F01021F8698 for ; Fri, 23 Mar 2012 12:01:02 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 8ADC96524DC for ; Fri, 23 Mar 2012 15:01:01 -0400 (EDT) Message-ID: <4F6CC86A.3090107@hidayahonline.org> Date: Fri, 23 Mar 2012 15:00:58 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <4F6C6DC1.7020606@mozilla.com> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=5AF4B362 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 19:01:06 -0000 On 03/23/2012 12:48 PM, Roman Shpount wrote: > On Fri, Mar 23, 2012 at 8:34 AM, Timothy B. Terriberry > > wrote: > > With a direct browser-to-browser connection, there is nothing > sitting between them to do the transcoding. In the DTLS-SRTP case > with identity verification, which I think a number of people here > view as highly important, you are in fact _guaranteeing_ that > nothing but the browser can encode or decode the video. > > > This is not technically correct. You can still build a system that > implements a media proxy that does nothing but handling ICE, > encryption, and identity verification without ever transcoding the > content. The cost of re-encrypting the media is low (ie single E5 Xeon > CPU can probably do about 10GB/s), but the cost of transcoding video, > or even audio is huge in comparison. Because of this, supporting a > comprehensive set of codecs is highly desirable. While perhaps technically desirable for those already knee-deep in the existing telecommunications, it will serve to lock-out any WebRTC implementations that either choose to or cannot implement an encumbered format, such as free/open source software developers and companies. As of right now, there *are* no official complete WebRTC implementations to inconvenience by choosing a mandatory-to-implement codec. It would be only an inconvenience to existing infrastructure, but because of the free and open nature of the proposed format, adding support for it in software would be a minimal effort, especially as it would standardized. The reference implementation of VP8 (libvpx) is also licensed in such as a way as to be equally available to all types of software. From snandaku@cisco.com Fri Mar 23 12:02:21 2012 Return-Path: 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 D6C7321F8680 for ; Fri, 23 Mar 2012 12:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.007 X-Spam-Level: X-Spam-Status: No, score=-9.007 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 Yy3bnXlDgBBy for ; Fri, 23 Mar 2012 12:02:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D846621F8670 for ; Fri, 23 Mar 2012 12:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=snandaku@cisco.com; l=1027; q=dns/txt; s=iport; t=1332529338; x=1333738938; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=GvnqKl2S/IdA4Tk7TVfgdJ+jok74hCAhIlZJWtOy2JI=; b=V0IQxjZxkq/c45eHUrtE1GFS1KKERUYpRwo79CSvW26ruAx46buc5IGa VWHglN8CQSFPePuNZFMsJswpvAZJApTrsXLDl9PG2Hn9J/aACiwkfKDpY 2MvhB2tafNN8SpyrwOdZ0kNvh+XZUlUa0y+yfqNCd8G+5YzeaTL2pQ+sz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADbIbE+tJV2Z/2dsb2JhbABFgka0VHiBB4IACwEEEgEqTwgDAQIDgRQGNYdomGWBJ558jWGDJASIV4Uqh1+ORIFogwc X-IronPort-AV: E=Sophos;i="4.73,637,1325462400"; d="scan'208,217";a="68985873" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 23 Mar 2012 19:02:17 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2NJ2HGf020718 for ; Fri, 23 Mar 2012 19:02:17 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 14:02:17 -0500 Received: from 10.21.90.237 ([10.21.90.237]) by XMB-RCD-212.cisco.com ([72.163.62.219]) with Microsoft Exchange Server HTTP-DAV ; Fri, 23 Mar 2012 19:01:29 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 23 Mar 2012 12:01:29 -0700 From: snandaku To: Message-ID: Thread-Topic: rtcweb Digest, Vol 13, Issue 53 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415348889_14823230" X-OriginalArrivalTime: 23 Mar 2012 19:02:17.0312 (UTC) FILETIME=[7746DE00:01CD0927] Subject: Re: [rtcweb] rtcweb Digest, Vol 13, Issue 53 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 19:02:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3415348889_14823230 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I will be on official travel from 3/23 - 4/02 and will be slow in responding to your messages. For Kalliste questions please contact Susie Wee For RTCWeb questions please contact Ethan Hugg. --B_3415348889_14823230 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: rtcweb Digest, Vol 13, Issue 53 I will be on official travel from 3/23 - 4/02 and will be s= low in responding to your messages.
For Kalliste questions please contact Susie Wee
For RTCWeb questions please contact Ethan Hugg. --B_3415348889_14823230-- From ds@ti.com Fri Mar 23 15:38:50 2012 Return-Path: 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 5F4C021F85D3 for ; Fri, 23 Mar 2012 15:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ki1QpqYaZkDe for ; Fri, 23 Mar 2012 15:38:49 -0700 (PDT) Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by ietfa.amsl.com (Postfix) with ESMTP id 74F7C21F856C for ; Fri, 23 Mar 2012 15:38:48 -0700 (PDT) Received: from dlep26.itg.ti.com ([157.170.170.121]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id q2NMcmMx013147; Fri, 23 Mar 2012 17:38:48 -0500 Received: from DFLE70.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id q2NMcmH4014599; Fri, 23 Mar 2012 17:38:48 -0500 (CDT) Received: from DLEE08.ent.ti.com ([fe80::8145:89a6:94e5:8cad]) by DFLE70.ent.ti.com ([fe80::db3:609a:aa62:e1ec%22]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 17:38:47 -0500 From: "Schleef, David" To: "chris.cavigioli@intel.com" Thread-Topic: [rtcweb] On video codec for rtcweb Thread-Index: Ac0JHgA8Dirv+pElTfm4dOmisEvpPwAJ7Ryc Date: Fri, 23 Mar 2012 22:38:46 +0000 Message-ID: <1332542323.27047.37.camel@ula0273821> References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.170.170.90] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 23:01:21 -0000 VGhlcmUgYXJlIHNldmVyYWwga2V5IGZhY3RvcnMgYWJvdXQgbW9iaWxlIGRldmljZXMgdGhhdCBt YWtlIHlvdXIKY29uY2x1c2lvbiBvbiBILjI2NCBCYXNlbGluZSBhIGxvdCBsZXNzIHN0cm9uZyB0 aGFuIG9uZSBtaWdodCB0aGluay4KClBvd2VyIGNvbnN1bXB0aW9uIGZvciBhIFZDIGFwcGxpY2F0 aW9uIGluIGN1cnJlbnQgZ2VuZXJhdGlvbiBtb2JpbGUKZGV2aWNlcyBpcyBtb3N0bHkgZHVlIHRv IHJ1bm5pbmcgdGhlIGNhbWVyYSwgdGhlIGRpc3BsYXksIGFuZCB0aGUgNEcgb3IKd2lmaSByYWRp by4gIEVuY29kaW5nL2RlY29kaW5nLCB3aGlsZSBvYnZpb3VzbHkgbWFraW5nICpzb21lKgpjb250 cmlidXRpb24sIGlzIG5vdCByZWFsbHkgc2lnbmlmaWNhbnQgYXQgVkMgc2l6ZXMgYW5kIGJpdHJh dGVzLiAgQW5kCmVuY29kaW5nL2RlY29kaW5nIGluIHNvZnR3YXJlIGRvZXNuJ3QgY29udHJpYnV0 ZSBtdWNoIG1vcmUuCgpTZWNvbmRseSwgImhhcmR3YXJlIGNvZGVjIiBjYW4gbWVhbiBhIGxvdCBv ZiBkaWZmZXJlbnQgdGhpbmdzLiAgSXQncwphbG1vc3QgYWx3YXlzIHNvbWUgZm9ybSBvZiBEU1Ag b3IgbWljcm9jb250cm9sbGVyIGRvaW5nIHRoZSBzZXF1ZW5jaW5nCm9mIHRpZ2h0bHktY291cGxl ZCBoYXJkd2FyZSBibG9ja3MgdGhhdCBvZmZsb2FkIHNvbWUgb2YgdGhlIGhlYXZ5CmxpZnRpbmcu ICBTb2Z0d2FyZSBjb2RlY3Mgb24gQ1BVcyBhcmUganVzdCBvbmUgZW5kIG9mIHRoaXMuICBTb21l CnZlbmRvcnMgb24gdGhlIERTUCBlbmQgYWxyZWFkeSBzdXBwb3J0IFZQOCBlbmNvZGluZy9kZWNv ZGluZyBpbiBleGlzdGluZwpwcm9kdWN0cy4gIEFzIGl0IGhhcyBmb3IgSC4yNjQsIFZQOCB3aWxs IGluZXZpdGFibHkgcHJvZ3Jlc3MgdG93YXJkIG1vcmUKaGFyZHdhcmUvbGVzcyBwcm9jZXNzb3Ig aW4gdXBjb21pbmcgZ2VuZXJhdGlvbnMsIGFuZCB0aHVzIGxvd2VyIHBvd2VyLgoKQWxzbywgbm90 IHJlbGF0ZWQgdG8gbW9iaWxlLCB0aGUgcHJpbWFyeSAob25seT8pIGdvYWwgb2YgYSBiYXNlbGlu ZQpjb2RlYyBpcyB0byBwcm92aWRlIDEwMCUgY292ZXJhZ2UuICBUbyBnZXQgdG8gMTAwJSwgX3Nv bWVvbmVfIHdpbGwgaGF2ZQp0byB1c2UgYSBzb2Z0d2FyZSBjb2RlYy4gIFRoZXJlIGFyZSBubyBi YXJyaWVycyB0byBhbiBpbXBsZW1lbnRvciB1c2luZwpWUDggaW4gc29mdHdhcmU7IHRoYXQncyBz b3J0IG9mIHRoZSBlbnRpcmUgcG9pbnQgb2YgZnJlZSBjb2RlY3MuICBUaGVyZQphcmUgYnVzaW5l c3MgYmFycmllcnMgdGhhdCB3aWxsIG5ldmVyIGNoYW5nZSBmb3IgY29tcGFuaWVzIGxpa2UgUmVk IEhhdAp0byB1c2UgSC4yNjQgaW4gc29mdHdhcmUuICBUaHVzLCB5b3Ugd2lsbCBuZXZlciBnZXQg MTAwJSBjb3ZlcmFnZSBmcm9tCkguMjY0LiAgRXZlci4gIEFkZGluZyBWUDggaXMsIGFzIHlvdSBz YXksIGEgInZlcnkgdHJpdmlhbCBzb2Z0d2FyZQpidXJkZW4iLgoKRnJvbSBteSB2YW50YWdlIHBv aW50LCB5b3VyIHN1Z2dlc3Rpb24gb2YgSC4yNjQgYXMgYSBiYXNlbGluZSBjb2RlYwpjb21lcyBk b3duIHRvICJ3YW50IHRvIHNhdmUgYSBmZXcgcGVyY2VudCBvZiBwb3dlciB1c2FnZSBvbmx5IGZv ciB0aGUKY3VycmVudCBnZW5lcmF0aW9uICh3aGljaCB3aWxsIGJhcmVseSBzZWUgV2ViUlRDIGFu eXdheSksIHdpbGxpbmcgdG8Kc2FjcmlmaWNlIGFjdHVhbGx5IGF0dGFpbmluZyB0aGUgZ29hbCBv ZiBhIGJhc2VsaW5lIGNvZGVjIi4KCgoKRGF2aWQKCgoKT24gRnJpLCAyMDEyLTAzLTIzIGF0IDEy OjM0ICswMDAwLCBDYXZpZ2lvbGksIENocmlzIHdyb3RlOgo+IExldCdzIGJlIGNsZWFyIG9uIHBy b2ZpbGVzLiAgSWYgd2Ugc2VlayB3aWRlc3QgbW9iaWxlIGhhcmR3YXJlIGZvb3RwcmludDoKPiAt IElUVS1UIEguMjY0IENvbnN0cmFpbmVkIEJhc2VsaW5lIFByb2ZpbGUgaXMgcHJvYmFibHkgdGhl IG1vc3QgdWJpcXVpdG91cyBoYXJkd2FyZSB2aWRlbyBjb2RlYyB0b2RheSB3aXRoIHJlYXNvbmFi bGUgcG93ZXIvcGVyZm9ybWFuY2UgcmF0aW8KPiAtIElUVS1UIEcuNzExLCBib3RoIHVfbGF3IChO b3J0aCBBbWVyaWNhKSBhbmQgQV9sYXcgKEV1cm9wZSkgZm9ybWF0cywgY2FuIGJlIHN1cHBvcnRl ZCBieSBldmVyeW9uZSB3aXRoIHZlcnkgdHJpdmlhbCBzb2Z0d2FyZSBidXJkZW4KPiAtY2hyaXMK PiAKPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IHJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJr dXMuSXNvbWFraUBub2tpYS5jb20KPiBTZW50OiBGcmlkYXksIE1hcmNoIDIzLCAyMDEyIDU6MTUg QU0KPiBUbzogdHRlcnJpYmVycnlAbW96aWxsYS5jb207IHN0ZWZhbi5say5oYWthbnNzb25AZXJp Y3Nzb24uY29tCj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZwo+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBP biB2aWRlbyBjb2RlYyBmb3IgcnRjd2ViCj4gCj4gSGksCj4gCj4gVGltb3RoeSBCLiBUZXJyaWJl cnJ5IHdyb3RlOgo+ID4KPiA+VGhlIHByaW1hcnkgcmVhc29uaW5nIGJlaGluZCB0aGF0IGRlY2lz aW9uLCBpLmUuIHRoZSBvbmUKPiA+ZmFjdG9yIHRoYXQgd2FzIG5vdCBpbiBvdXIgcG93ZXIgdG8g Y2hhbmdlLCB3YXMgdGhlIGF2YWlsYWJpbGl0eSBvZiBjb250ZW50IG9uCj4gPndlYnNpdGVzLiBU aGlzIGlzIG5vdCBhIHByb2JsZW0gZm9yIFdlYlJUQywgYXMgYnJvd3NlcnMgY29udHJvbCBib3Ro IGVuZHMgb2YKPiA+dGhlIGNvbW11bmljYXRpb24uCj4gPgo+IAo+IEluIFdlYlJUQyBjb250ZXh0 IHdoYXQgaXMgc29tZXdoYXQgYW5hbG9nb3VzIGlzIHRoZSBpbnRlcmNvbm5lY3QgdG8gZXhpc3Rp bmcgbm9uLXdlYiB2aWRlbyBzeXN0ZW1zLiBXaGF0IGNvZGVjcyBhcmUgdXNlZCBpbiB0aGVtIGlz IG5vdCB1bmRlciBicm93c2VyIGNvbnRyb2wuIEkgYmVsaWV2ZSB0aG9zZSBtb3N0bHkgdXNlIEgu MjY0LiBJdCdzIHByb2JhYmx5IHBvc3NpYmxlIHRvIHVzZSB0cmFuc2NvZGVycyBidXQgc28gaXQg aXMgYmV0d2VlbiBicm93c2VycyB0b28uIEknZCBzYXkgdGhhdCBldmVuIGlmIGNvdWxkbid0IG1h bmRhdGUgYSBzaW5nbGUgdmlkZW8gY29kZWMgKGFzIGl0IGhhcyBzZWVtZWQgdG8gbWUgc2luY2Ug dGhlIGJlZ2lubmluZyksIGluIHByYWN0aWNlIEguMjY0IHN1cHBvcnQgd291bGQgYmUgaGlnaGx5 IFJFQ09NTUVOREVEIChhIFNIT1VMRCkuIFRoZXJlIG1pZ2h0IGJlIGdvb2QgcmVhc29ucyBub3Qg dG8gZm9sbG93IHRoYXQgU0hPVUxELCBhcyBpdCBzZWVtcyB0byBiZSB0aGUgY2FzZSBmb3IgTW96 aWxsYS4gIAo+IAo+IE1hcmt1cwo+IAo+IAo+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ ID5Gcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYKPiA+T2YgZXh0IFRpbW90aHkgQi4gVGVycmliZXJyeQo+ID5TZW50 OiAyMyBNYXJjaCwgMjAxMiAxMzo0MQo+ID5UbzogU3RlZmFuIEhha2Fuc3NvbiBMSwo+ID5DYzog cnRjd2ViQGlldGYub3JnCj4gPlN1YmplY3Q6IFJlOiBbcnRjd2ViXSBPbiB2aWRlbyBjb2RlYyBm b3IgcnRjd2ViCj4gPgo+ID5TdGVmYW4gSGFrYW5zc29uIExLIHdyb3RlOgo+ID4+IFNvLCBJIHBy b3Bvc2UgdGhhdCBoLjI2NCBzaG91bGQgYmUgbWFuZGF0b3J5IHRvIGltcGxlbWVudC4KPiA+Cj4g Pk1vemlsbGEgc3Ryb25nbHkgb3Bwb3NlcyBzdWNoIGEgcHJvcG9zYWwuIE1hbnkgd2lsbCBiZSBm YW1pbGlhciB3aXRoIG91cgo+ID5hbm5vdW5jZW1lbnRzIHJlZ2FyZGluZyBvdXIgdXNlIG9mIHBs YXRmb3JtIGNvZGVjcyBvbiBCMkcgYW5kIHBvc3NpYmx5Cj4gPkFuZHJvaWQgbGFzdCB3ZWVrLiBU aGUgcHJpbWFyeSByZWFzb25pbmcgYmVoaW5kIHRoYXQgZGVjaXNpb24sIGkuZS4gdGhlIG9uZQo+ ID5mYWN0b3IgdGhhdCB3YXMgbm90IGluIG91ciBwb3dlciB0byBjaGFuZ2UsIHdhcyB0aGUgYXZh aWxhYmlsaXR5IG9mIGNvbnRlbnQgb24KPiA+d2Vic2l0ZXMuIFRoaXMgaXMgbm90IGEgcHJvYmxl bSBmb3IgV2ViUlRDLCBhcyBicm93c2VycyBjb250cm9sIGJvdGggZW5kcyBvZgo+ID50aGUgY29t bXVuaWNhdGlvbi4KPiA+Cj4gPldoYXQgX2lzXyBhIHByb2JsZW0gaXMgbGljZW5zaW5nIGFuZCBk aXN0cmlidXRpbmcgZW5jb2RlcnMgaW4gYW4gb3Blbi1zb3VyY2UKPiA+cHJvamVjdC4gVGhpcyBp cyBxdWl0ZSBhIGJpdCBkaWZmZXJlbnQgdGhhbiB1c2luZyBzeXN0ZW0gZGVjb2RlcnMsIGFzIG91 dHNpZGUgb2YKPiA+bW9iaWxlLCBlbmNvZGVycyBhcmUgdXN1YWxseSBub3QgYXZhaWxhYmxlLCBh bmQgZXZlbiBpZiB0aGV5IHdlcmUsIHRoZXkgbWlnaHQKPiA+bm90IGhhdmUgcGFydGljdWxhcmx5 IGdvb2QgcXVhbGl0eSwgbm9yIHRoZSBmZWF0dXJlcyB0byBjb250cm9sIGxhdGVuY3ksIGxvc3MK PiA+cm9idXN0bmVzcywgYW5kIG90aGVyIGFzcGVjdHMgbmVjZXNzYXJ5IGZvciByZWFsLXRpbWUg Y29tbXVuaWNhdGlvbi4KPiA+Cj4gPklmIHlvdSB0aG91Z2h0IHRoYXQgYSBjb25jZXNzaW9uIGlu IG9uZSBwbGFjZSB3b3VsZCBtYWtlIE1vemlsbGEgbW9yZSBsaWtlbHkKPiA+dG8gY29tcHJvbWlz ZSBpbiBvdGhlcnMsIEkgYXNzdXJlIHlvdSB0aGUgb3Bwb3NpdGUgaXMgdHJ1ZS4KPiA+TWFpbnRh aW5pbmcgdGhlIHVzZSBvZiBSRiBjb2RlY3MgaW4gV2ViUlRDIGlzIG5vdyBldmVuIG1vcmUgaW1w b3J0YW50IHRoYW4KPiA+aXQgd2FzIGJlZm9yZS4gU2VlIHRoZSB3b3JkcyBkaXJlY3RseSBmcm9t IE1vemlsbGEncyBDVE86Cj4gPmh0dHA6Ly9ncm91cHMuZ29vZ2xlLmNvbS9ncm91cC9tb3ppbGxh LmRldi5wbGF0Zm9ybS9tc2cvNTM4OTJhZDNlYTllZWIKPiA+OTgKPiA+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+cnRjd2ViIG1haWxpbmcgbGlzdAo+ ID5ydGN3ZWJAaWV0Zi5vcmcKPiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWIKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QKPiBydGN3ZWJAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYgo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCj4gcnRjd2ViIG1haWxpbmcgbGlzdAo+IHJ0Y3dlYkBp ZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViCgoK Cg== From roman@telurix.com Fri Mar 23 16:22:22 2012 Return-Path: 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 13A7D21E8027 for ; Fri, 23 Mar 2012 16:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 VV6O2yyzEOzc for ; Fri, 23 Mar 2012 16:22:21 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08521E8011 for ; Fri, 23 Mar 2012 16:22:21 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so3153707pbb.31 for ; Fri, 23 Mar 2012 16:22:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=DyBS7z8OoK8SUjUSazGZtexcusMSNlvqtKz6wnn7OJg=; b=PUZPy2th1W0uu+m/VW6jNrB5SmVs0W5k+M1I8JFkjjR689kYNA7ErtjZ82UiCfuelt FAdLZ4R0G1CzSpbUpxyKJPk8nnqKHEdfLCutxMU8Nd/xjh08LYSgWczgfogJW1B/TTYQ DtAl7adun5vROgYgz3EN1hEwEbj46AZQ8jYaV3v4cgGe0rIjL8nof9R5YGaW8OsaKp+W crSN1ZlDhUVELlzOEmVo5rQkrZmg6R5yCzinehVwthIsB+5jtvxmi49U55SmReuTW0jd BBnwy3TG0mqgVIt9JVUYiSrUjx+5ZPfN20SGZvwM2DCrwerr1XEOu3kDfzSqa6JyPosD v+vw== Received: by 10.68.203.4 with SMTP id km4mr32832343pbc.53.1332544941204; Fri, 23 Mar 2012 16:22:21 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id u10sm6741717pbf.37.2012.03.23.16.22.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 16:22:20 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so3153690pbb.31 for ; Fri, 23 Mar 2012 16:22:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.221.10 with SMTP id qa10mr32009193pbc.139.1332544939128; Fri, 23 Mar 2012 16:22:19 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Fri, 23 Mar 2012 16:22:19 -0700 (PDT) In-Reply-To: <4F6CC86A.3090107@hidayahonline.org> References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <4F6C6DC1.7020606@mozilla.com> <4F6CC86A.3090107@hidayahonline.org> Date: Fri, 23 Mar 2012 19:22:19 -0400 Message-ID: From: Roman Shpount To: Basil Mohamed Gohar Content-Type: multipart/alternative; boundary=e89a8ff24801be75a604bbf14bfe X-Gm-Message-State: ALoCoQlGZFBzdPI6fOnMxTzIz6FrwzvOB3nu/FhEMj4HEYrwICzNos34tsCK/8koOHh5xNkDgCbC Cc: rtcweb@ietf.org Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 23:22:22 -0000 --e89a8ff24801be75a604bbf14bfe Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 23, 2012 at 3:00 PM, Basil Mohamed Gohar < abu_hurayrah@hidayahonline.org> wrote: > On 03/23/2012 12:48 PM, Roman Shpount wrote: > > On Fri, Mar 23, 2012 at 8:34 AM, Timothy B. Terriberry > > > wrote: > > > > With a direct browser-to-browser connection, there is nothing > > sitting between them to do the transcoding. In the DTLS-SRTP case > > with identity verification, which I think a number of people here > > view as highly important, you are in fact _guaranteeing_ that > > nothing but the browser can encode or decode the video. > > > > > > This is not technically correct. You can still build a system that > > implements a media proxy that does nothing but handling ICE, > > encryption, and identity verification without ever transcoding the > > content. The cost of re-encrypting the media is low (ie single E5 Xeon > > CPU can probably do about 10GB/s), but the cost of transcoding video, > > or even audio is huge in comparison. Because of this, supporting a > > comprehensive set of codecs is highly desirable. > While perhaps technically desirable for those already knee-deep in the > existing telecommunications, it will serve to lock-out any WebRTC > implementations that either choose to or cannot implement an encumbered > format, such as free/open source software developers and companies. As > of right now, there *are* no official complete WebRTC implementations to > inconvenience by choosing a mandatory-to-implement codec. It would be > only an inconvenience to existing infrastructure, but because of the > free and open nature of the proposed format, adding support for it in > software would be a minimal effort, especially as it would standardized. > > The reference implementation of VP8 (libvpx) is also licensed in such as > a way as to be equally available to all types of software. > > I am not arguing for making H.264 a base codec. I would actually prefer VP8. All I was saying that despite lack of interoperability on encryption, ICE, and identity, there are still significant benefits of supporting the same codecs when communicating with legacy equipment, since re-encryption and media proxy can be handled separately and using much less resources then transcoding. _____________ Roman Shpount --e89a8ff24801be75a604bbf14bfe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 23, 2012 at 3:00 P= M, Basil Mohamed Gohar <abu_hurayrah@hidayahonline.org> wrote:
On 03/23/2012 12:48 PM, Roman Shpount wrote:
> On Fri, Mar 23, 2012 at 8:34 AM, Timothy B. Terriberry
> <tterriberry@mozilla.com <mailto:tterriberry@mozilla.com>> wrote:
>
> =A0 =A0 With a direct browser-to-browser connection, there is nothing<= br> > =A0 =A0 sitting between them to do the transcoding. In the DTLS-SRTP c= ase
> =A0 =A0 with identity verification, which I think a number of people h= ere
> =A0 =A0 view as highly important, you are in fact _guaranteeing_ that<= br> > =A0 =A0 nothing but the browser can encode or decode the video.
>
>
> This is not technically correct. You can still build a system that
> implements a media proxy that does nothing but handling ICE,
> encryption, and identity verification without ever transcoding the
> content. The cost of re-encrypting the media is low (ie single E5 Xeon=
> CPU can probably do about 10GB/s), but the cost of transcoding video,<= br> > or even audio is huge in comparison. Because of this, supporting a
> comprehensive set of codecs is highly desirable.
While perhaps technically desirable for those already knee-deep= in the
existing telecommunications, it will serve to lock-out any WebRTC
implementations that either choose to or cannot implement an encumbered
format, such as free/open source software developers and companies. =A0As of right now, there *are* no official complete WebRTC implementations to inconvenience by choosing a mandatory-to-implement codec. =A0It would be only an inconvenience to existing infrastructure, but because of the
free and open nature of the proposed format, adding support for it in
software would be a minimal effort, especially as it would standardized.
The reference implementation of VP8 (libvpx) is also licensed in such as a way as to be equally available to all types of software.


I am not arguing for makin= g H.264 a base codec. I would actually prefer VP8. All I was saying that de= spite lack of interoperability on encryption, ICE, and identity, there are = still significant benefits of supporting the same codecs when communicating= with legacy equipment, since re-encryption and media proxy can be handled = separately and using much less resources then transcoding.
_____________
Roman Shpount


--e89a8ff24801be75a604bbf14bfe-- From gmaxwell@juniper.net Fri Mar 23 17:49:33 2012 Return-Path: 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 DA53321E8034 for ; Fri, 23 Mar 2012 17:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 lklWAvg6w+Wy for ; Fri, 23 Mar 2012 17:49:32 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDB621E800F for ; Fri, 23 Mar 2012 17:49:32 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT20aGdbyyV6JNtxbfyZA+NkViQF2tAd4@postini.com; Fri, 23 Mar 2012 17:49:32 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 23 Mar 2012 17:48:40 -0700 From: Gregory Maxwell To: Roman Shpount , Basil Mohamed Gohar Date: Fri, 23 Mar 2012 17:48:38 -0700 Thread-Topic: [rtcweb] On video codec for rtcweb Thread-Index: Ac0JS89Y14yGlRY2QXCagWy79vAi7AACdKwM Message-ID: References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <4F6C6DC1.7020606@mozilla.com> <4F6CC86A.3090107@hidayahonline.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 00:49:34 -0000 Roman Shpount wrote: > I am not arguing for making H.264 a base codec. I would actually prefer=20 > VP8. All I was saying that despite lack of interoperability on=20 > encryption, ICE, and identity, there are still significant benefits of=20 > supporting the same codecs when communicating with legacy equipment,=20 This is all true, but there won't always be a gateway or SBC in the media path and users may not want one even if all it did was transcode. The case with no media gateway can _only_ work reliably by virtue of compatibility being baked into the specification=97 in the other cases interoperability is 'simply' a matter of different tradeoffs. An interesting observation on the cost of transcoding: a number of mobile providers are now transparently transcoding their users' http video downloads on the fly, not for the purposes of changing the codec, but solely to make them smaller. This can do terrible things to the video quality (beyond just the reduction in bitrate: MP4 wasn't designed to stream from a live source). Perhaps this is an argument for more pervasive end-to-end encryption=97 but the point remains that CPU power, especially CPU power in high density data-centers, is still relatively cheap. From cb.list6@gmail.com Fri Mar 23 18:10:25 2012 Return-Path: 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 A852721E8011 for ; Fri, 23 Mar 2012 18:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 MakK8v+P8npp for ; Fri, 23 Mar 2012 18:10:24 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B379F21E800F for ; Fri, 23 Mar 2012 18:10:24 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so3233271pbb.31 for ; Fri, 23 Mar 2012 18:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nslgQF86YX2q4TALRtp9liBPhyY8u2f3PJwmh6myNeo=; b=sDhR9DByV/PNwqKxOMZufZvQnQi0dyLKm/lempdyLGvmQDR8SeoAFQKcTv3QPndYHe EVJwfZsUnDGhA8o3QCsHe9f3Bhr9acTQoWCXWoRo7yBsBsrqoIkH7rCoeJgpcKlN9y4l KvE05gu5xIMGBpmS3i8Ql5vWpFFYP/AgWhJFwtEYCpd/Fm8dJga3vSzbClfgEfPtrFhi xAkLebqxY2uPMpMkXRJb0asJgQCTAEmSelq5LK2EDTl6pvmyizohCHHV1yiI/KjQW+39 ZU3m+eavMruZh+NXfCdpzvYYZdp+yECJarqa1JK9zuvffqRatsjeR86qe/DYJa6sqcMB tnQQ== MIME-Version: 1.0 Received: by 10.68.219.131 with SMTP id po3mr33466827pbc.70.1332551424454; Fri, 23 Mar 2012 18:10:24 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Fri, 23 Mar 2012 18:10:24 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Fri, 23 Mar 2012 18:10:24 -0700 (PDT) In-Reply-To: References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <4F6C6DC1.7020606@mozilla.com> <4F6CC86A.3090107@hidayahonline.org> Date: Fri, 23 Mar 2012 18:10:24 -0700 Message-ID: From: Cameron Byrne To: Gregory Maxwell Content-Type: multipart/alternative; boundary=e89a8ff249794caf5c04bbf2ce74 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 01:10:25 -0000 --e89a8ff249794caf5c04bbf2ce74 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mar 23, 2012 5:49 PM, "Gregory Maxwell" wrote: > > Roman Shpount wrote: > > I am not arguing for making H.264 a base codec. I would actually prefer > > VP8. All I was saying that despite lack of interoperability on > > encryption, ICE, and identity, there are still significant benefits of > > supporting the same codecs when communicating with legacy equipment, > > This is all true, but there won't always be a gateway or SBC in the media > path and users may not want one even if all it did was transcode. The cas= e > with no media gateway can _only_ work reliably by virtue of compatibility > being baked into the specification=97 in the other cases interoperability > is 'simply' a matter of different tradeoffs. > > An interesting observation on the cost of transcoding: a number of > mobile providers are now transparently transcoding their users' http > video downloads on the fly, not for the purposes of changing the codec, > but solely to make them smaller. This can do terrible things to the video > quality (beyond just the reduction in bitrate: MP4 wasn't designed to > stream from a live source). Perhaps this is an argument for more pervasiv= e > end-to-end encryption=97 but the point remains that CPU power, especially Excellent points both about encryption and codec. This carrier transcoding mess is a real challenge and should be architecturally thwarted. Cb > CPU power in high density data-centers, is still relatively cheap. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --e89a8ff249794caf5c04bbf2ce74 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Mar 23, 2012 5:49 PM, "Gregory Maxwell" <gmaxwell@juniper.net> wrote:
>
> Roman Shpount wrote:
> > I am not arguing for making H.264 a base codec. I would actually = prefer
> > VP8. All I was saying that despite lack of interoperability on > > encryption, ICE, and identity, there are still significant benefi= ts of
> > supporting the same codecs when communicating with legacy equipme= nt,
>
> This is all true, but there won't always be a gateway or SBC in th= e media
> path and users may not want one even if all it did was transcode. The = case
> with no media gateway can _only_ work reliably by virtue of compatibil= ity
> being baked into the specification=97 in the other cases interoperabil= ity
> is 'simply' a matter of different tradeoffs.
>
> An interesting observation on the cost of transcoding: a number of
> mobile providers are now transparently transcoding their users' ht= tp
> video downloads on the fly, not for the purposes of changing the codec= ,
> but solely to make them smaller. This can do terrible things to the vi= deo
> quality (beyond just the reduction in bitrate: MP4 wasn't designed= to
> stream from a live source). Perhaps this is an argument for more perva= sive
> end-to-end encryption=97 but the point remains that CPU power, especia= lly

Excellent points both about encryption and codec. This carrier transcodi= ng mess is a real challenge and should be architecturally thwarted.

Cb

> CPU power in high density data-centers, is still relatively cheap.<= br> >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--e89a8ff249794caf5c04bbf2ce74-- From giles@thaumas.net Fri Mar 23 18:32:57 2012 Return-Path: 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 71EB821E8084 for ; Fri, 23 Mar 2012 18:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 ZEufAp5ckRzn for ; Fri, 23 Mar 2012 18:32:56 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB28021E8011 for ; Fri, 23 Mar 2012 18:32:53 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so3954569vcb.31 for ; Fri, 23 Mar 2012 18:32:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=8F5W0FzAIs/92czU1zOhSBppUu0oU/nFScMWBZ/uQR4=; b=TMqJzpESU36PbaR1hJGwFi5su2TkJZs93HKZCvsVIBgyEfL6EcIa1kJyZAPxO43CO5 2ezMdkw+9icczmNrEjP70NLSgEfTbFTFCPMcDHdp/lLiBCqoLkLX4Dcnth6h6OiFEcRp jyBHrO+p1oRkQs/xrCVXeqd0zM1MtKMFR5dCryhhBdpRKQHikomlQpY0YBmp0RteF6jA VtN/LSaFBR9z5KzAeXWqmz2pMlUxcSHMexRUqFzHkbiydFTnx3DggOa0CzN0L2AVLmR2 rdZ+DRXVDkic3c2zS73lXRZyJYbZu/w+WJojnIDWTq2kb4gDDiVyA45jlBRnDjZftwhq z0OA== MIME-Version: 1.0 Received: by 10.52.72.130 with SMTP id d2mr5330953vdv.80.1332552773325; Fri, 23 Mar 2012 18:32:53 -0700 (PDT) Received: by 10.220.151.130 with HTTP; Fri, 23 Mar 2012 18:32:53 -0700 (PDT) X-Originating-IP: [66.183.19.247] In-Reply-To: <4F6CC6B6.7060903@alcatel-lucent.com> References: <4F6B5FEE.9060706@alcatel-lucent.com> <4F6B6CD6.2070801@alcatel-lucent.com> <4F6C5D02.6010800@alvestrand.no> <4F6CC6B6.7060903@alcatel-lucent.com> Date: Fri, 23 Mar 2012 18:32:53 -0700 Message-ID: From: Ralph Giles To: igor.faynberg@alcatel-lucent.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkYcwuZJl6TMw6bJ7QONOIR/Cf1MROv3ciIU/pzqg6YZ9gVRQ1P637T3NObaTDlM1zoqckP Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] IdP in 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 01:32:57 -0000 On 23 March 2012 11:53, Igor Faynberg wr= ote: > Now I understand =C2=A0and agree that we cannot change their specificatio= n. > =C2=A0But... do we need to use it? We intend to use it in Firefox. -r From HKaplan@acmepacket.com Fri Mar 23 20:19:30 2012 Return-Path: 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 7A47121E8018 for ; Fri, 23 Mar 2012 20:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.094, 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 14E6RMSMI0XO for ; Fri, 23 Mar 2012 20:19:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8018621E800F for ; Fri, 23 Mar 2012 20:19:29 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 23 Mar 2012 23:19:24 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Fri, 23 Mar 2012 23:19:24 -0400 From: Hadriel Kaplan To: Roman Shpount Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris Thread-Index: AQHNCWzpAfjutPOyGkap6/qZ4J174g== Date: Sat, 24 Mar 2012 03:19:24 +0000 Message-ID: <86CD9009-0557-4F94-9E9F-89DAD2D80FF1@acmepacket.com> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: multipart/alternative; boundary="_000_86CD900905574F949E9F89DAD2D80FF1acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 03:19:30 -0000 --_000_86CD900905574F949E9F89DAD2D80FF1acmepacketcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 23, 2012, at 1:45 PM, Roman Shpount wrote: Personally, if I were running such an org, and I don't know if it's possibl= e, but I'd go get some form of rootkit/kernel-mod to intercept audio/video/= keystrokes well below the user layer, so that you wouldn't have to worry wh= at application was running - just intercept the audio/screen/keyboard somew= here near the drivers. Presumably some companies make such things, for jus= t such organizations? (sort of like the equivalent of CarrierIQ) That way = it doesn't matter whether it's WebRTC, Flash, or native apps. Unfortunately this does not always work. What you are looking for is a way = to enforceme that all the devices on the organizational network either conf= irms to organization communication policy or not allowed to communicate. Th= is also applies to other devices that are being brought to your organizatio= n (ie lawyer laptop in prison). Organization cannot force everybody to inst= all a key logger to their computers that they bring in, but they can force = all the communications coming from within the organization to go through so= me sort of proxy or not to be allowed to communicate. But that *is* their policy, and it *is* being followed: as you said, their = policy is "all the devices on the organizational network either confirms to= organization communication policy or not allowed to communicate". That is= being followed, because all web communications go through the Organization= 's proxy, and if a lawyer comes in his/her web traffic goes through the pro= xy=85 but the lawyer can't use it for WebRTC-created media - which is exac= tly matching the Organization's policy, because the lawyer's laptop must no= t and will not work for WebRTC communications. I'm not trying to be pedantic or difficult here, or trying to dismiss the u= se-case. I know there are many such "super-tight" networks, but I just don= 't see how we can reasonably accommodate their use-case in this WG. And I'= m pointing out that we really are following their policies, inasmuch as Web= RTC media will fail to escape their network - I would be far more worried i= f we somehow bypassed their policies instead. At least this way it's simil= ar behavior they get for unknown/unauthorized applications, which is arguab= ly what going to random websites and running downloaded javascript is equiv= alent to. -hadriel --_000_86CD900905574F949E9F89DAD2D80FF1acmepacketcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8E5F6E8A9450CF48B81B5D30EDB01813@acmepacket.com> Content-Transfer-Encoding: quoted-printable
On Mar 23, 2012, at 1:45 PM, Roman Shpount wrote:

Personally, if I were running such an org, and I don't know if it's possibl= e, but I'd go get some form of rootkit/kernel-mod to intercept audio/video/= keystrokes well below the user layer, so that you wouldn't have to worry wh= at application was running - just intercept the audio/screen/keyboard somewhere near the drivers.  Pres= umably some companies make such things, for just such organizations? (sort = of like the equivalent of CarrierIQ)  That way it doesn't matter wheth= er it's WebRTC, Flash, or native apps.

 
Unfortunately this does not always work. What you are looking for is a= way to enforceme that all the devices on the organizational network either= confirms to organization communication policy or not allowed to communicat= e. This also applies to other devices that are being brought to your organization (ie lawyer laptop in prison). = Organization cannot force everybody to install a key logger to their comput= ers that they bring in, but they can force all the communications coming fr= om within the organization to go through some sort of proxy or not to be allowed to communicate.

But that *is* their policy, and it *is* being followed: as you said, t= heir policy is "all the devices on the organizational network either c= onfirms to organization communication policy or not allowed to communicate&= quot;.  That is being followed, because all web communications go through the Organization's proxy, and if a lawyer co= mes in his/her web traffic goes through the proxy=85  but the lawyer can't use= it for WebRTC-created media - which is exactly matching the Organization's= policy, because the lawyer's laptop must not and will not work for WebRTC = communications.

I'm not trying to be pedantic or difficult here, or trying to dismiss = the use-case.  I know there are many such "super-tight" netw= orks, but I just don't see how we can reasonably accommodate their use-case= in this WG.  And I'm pointing out that we really are following their policies, inasmuch as WebRTC media will fail to escape= their network - I would be far more worried if we somehow bypassed their p= olicies instead.  At least this way it's similar behavior they get for= unknown/unauthorized applications, which is arguably what going to random websites and running downloaded javascrip= t is equivalent to.

-hadriel



--_000_86CD900905574F949E9F89DAD2D80FF1acmepacketcom_-- From tim@phonefromhere.com Sat Mar 24 02:15:11 2012 Return-Path: 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 D2A1021F86E3 for ; Sat, 24 Mar 2012 02:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 DbNy4h7HZcOu for ; Sat, 24 Mar 2012 02:15:11 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 62BA021F8552 for ; Sat, 24 Mar 2012 02:15:11 -0700 (PDT) Received: from [192.168.157.130] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 333FA37A904; Sat, 24 Mar 2012 09:27:48 +0000 (GMT) References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7D8EC27B-2446-4992-B5F5-5CC7A17D2BCE@phonefromhere.com> X-Mailer: iPhone Mail (9B176) From: Tim Panton Date: Sat, 24 Mar 2012 09:15:09 +0000 To: "Cavigioli, Chris" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 09:15:11 -0000 Sent from my iPhone On 23 Mar 2012, at 12:34, "Cavigioli, Chris" wro= te: > ITU-T G.711, both u_law (North America) and A_law (Europe) formats, can be= supported by everyone with very trivial software burden I hope that doesn't mean we forget the plan to support Opus.=20 We need an adaptive codec with fec in order to get decent audio out of real w= orld networks, like 3G, cafe wifi, vsat etc.=20 G711 is ok for perfect networks with legacy interop needs, but pretty much u= seless anywhere else.=20 Tim.= From fluffy@cisco.com Sat Mar 24 04:38:24 2012 Return-Path: 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 8063A21F86FD for ; Sat, 24 Mar 2012 04:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 3l4tXRP8PLH0 for ; Sat, 24 Mar 2012 04:38:23 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9B04A21F86C1 for ; Sat, 24 Mar 2012 04:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=473; q=dns/txt; s=iport; t=1332589103; x=1333798703; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=cEMmcBzLN9FfWtlcLpcXaxmMEud0p4tmrFsAZ1v7ePY=; b=R9j1/UpimMMNpOLw+O6/Zqve7SYay3VnWbKLfabDDPTjGFuUtGXkihrZ Ix5zmCg4BV/mjSCpiml/rHOMldjDEASiw1PmfoGGtOXB3gPsk49Y3Lnlb NqFFqQ4PIOuuePbNUx6xVSnzZLY8rn1ztjucIRLBqgEtgtUCxQ9eogyYb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFAKCwbU+Q/khN/2dsb2JhbAAiIbgpgQeCIgEnP4Fzh2ieXZZ9jgSCQWMElWCORYFogmg X-IronPort-AV: E=Sophos;i="4.73,641,1325462400"; d="scan'208";a="69243058" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 24 Mar 2012 11:38:22 +0000 Received: from dhcp-10-61-98-60.cisco.com (dhcp-10-61-98-60.cisco.com [10.61.98.60]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2OBcMPl019664; Sat, 24 Mar 2012 11:38:22 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 24 Mar 2012 12:38:22 +0100 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [rtcweb] RTCWeb DEMO's Thursday at Lunch X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 11:38:24 -0000 We will be doing RTCWeb related demos in room 242AB on Thursday = 1130-1300. Please let the chairs know if there is a demo you would like = to show.=20 There will be no food provided - I suspect what we will do is just run = demos from 11:30 to 12:00 and then give people time to go for lunch. The = chairs will see what people want to demo and then plan a schedule.=20 If you have some code that might run, lets us know and lets see it. =20 Thanks, Cullen From lists@infosecurity.ch Sat Mar 24 15:41:32 2012 Return-Path: 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 BC31E21F8489 for ; Sat, 24 Mar 2012 15:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 jxbbFYco2RWD for ; Sat, 24 Mar 2012 15:41:18 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 951F021F8478 for ; Sat, 24 Mar 2012 15:41:18 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so2561358wib.13 for ; Sat, 24 Mar 2012 15:41:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding :x-gm-message-state; bh=I1HjTYVyiaPpUBL/nYjhZpilXXA0PThke+sfdEUG/Xo=; b=aG6GTHFYQPqgTBmhNQK87OV71sMD+YcQ6WJaHGZZiypxjtZL5+LcW3ZS3zpqdK9BoO tqzE25HpLvY1GMOL1IESCv7etbG7wEYFNVr77FEgYL7b4tKadN3gOBK9K1VCEIoo1g8R sWZi95h72D9qWVXmm2k5RphPhg1bWejjzoRyhe1gZ1h6mBTTHbk0LYaK2psGtISRslom ULfdteBDoljhMLxuG0q6xuguTb69zX6XTlNiVGsI4qVRk24htsG8qb4uf4s/yDsSoSI8 LCg17GekhdE0elAvCqNjKSzW0K2MhkGjs2flkG4YthSIaJlFqD0dU5CEGr1VB4eRYpEi Wlkw== Received: by 10.180.89.9 with SMTP id bk9mr7342808wib.11.1332628877542; Sat, 24 Mar 2012 15:41:17 -0700 (PDT) Received: from sonyvaiop13.local (93-32-159-172.ip34.fastwebnet.it. [93.32.159.172]) by mx.google.com with ESMTPS id ff2sm43556484wib.9.2012.03.24.15.41.15 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Mar 2012 15:41:16 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F6E4D8A.60402@infosecurity.ch> Date: Sat, 24 Mar 2012 23:41:14 +0100 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlm5gXh6zto3pV+1A1l1mbMmBGawO/jQqmAkCMxrKIugUaMRjPlhomx+FoMHll1Wyef/Twb Subject: [rtcweb] Encryption consideration: SDES and TLS-SRP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 22:41:32 -0000 Hi all, i wanted to ask the WG opinion on the encryption framework for the RTCWEB. In particular as we know today there is a strong need to have an encryption-by-default on most new protocols. Today: - Email provider encryption by default traffic - Mobile operators encrypt by default traffic - Almost all web transaction use encryption So it's realistic and practical to think that VoIP future is encrypted-by-default to at least basically protect against the casual wiretapper. (Can we evaluate this assumption?) In that case we may have different threat scenario: - Eavesdropping by third party with access to user's communication line - Eavesdropping by who is providing the telephony service A simpler protection scenario would at least provide protection against third party with access to user's communication line. A stronger protection scenario would also provide protection against who is providing the service. Here we should consider the security of: - Signaling - Media Signaling has to be protected with TLS. Media has to be protected with SRTP that rely on DTLS or on the new proposal to use SDES [1] (idea that i like). So basically in both cases there is the need to rely on a TLS-secured channel and here we should evaluate the possible weak points. As you know the TLS based trust model based on "Browser/OS Pre-loaded Trusted CA" revealed serious risks posed to internet trust model [2] . So, because we are defining a stack that should look forward the future, we cannot not-consider seriously the serious issues related with TLS and way to manage it. An idea that came to my mind is that the specification, to face a future-proof approach to the internet trust issues, could mandate to support the implementation of TLS-SRP. TLS-SRP is a new standard that let the TLS key exchange be authenticated by a login/password with no need to trust a specific CA. Status of implementation of RFC5054 http://tools.ietf.org/html/rfc5054 is available on http://trustedhttp.org/wiki/Main_Page . If we embrace SDES key exchange and TLS-SRP authentication the overall protocol stack would be simpler than having to deal with DTLS and relying only on Trusted-CA architectures. [1] http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/slides/rtcweb-7.pdf [2] http://ritter.vg/p/2012-TLS-Survey.pdf p.s. I'm quite new to the list, so i may repeat some discussion elements. In that case i kindly ask to leave to archive pointer to already made discussion. From roman@telurix.com Sat Mar 24 16:56:44 2012 Return-Path: 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 2FEE921E8028 for ; Sat, 24 Mar 2012 16:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 SygM99-IA7J2 for ; Sat, 24 Mar 2012 16:56:43 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B02D821E8019 for ; Sat, 24 Mar 2012 16:56:43 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so4261445pbb.31 for ; Sat, 24 Mar 2012 16:56:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=jI/D5//k/NdujBJfYU2KCYRXWjD1aiFK/DTPYzDA3Ws=; b=IMltAX4NNb5jQ/R4ikgHDyoC8LLYBPMA/nQPc3WJGym29iK0IeSJ8H13ZzEeIH0WfQ JlUsBoALNLhjH6WAq5JnOIweQ4sVddSWhoGop8oNqSde/Cd5Ym2s5b0sYZSSb2osO9zI rad/4p6enIC4RLi9TO6HcY3Y6iTXOlqFKOht/lqjydS7Yfu/K4KWjkLj9DPG0SWI7hDm 1tcc5AkaY49Z6wDh9MqqUfCAJeXx4gFUV1yF6bWgE8Xj7nc6+bRPpmnrVuwo64akABL8 OEzVDAwXm5pVYhEmueZJ1XXbqZ2KVt38p/6zU0c5WZCzqUamWeMND62WhyAWRWhHNRyE wheg== Received: by 10.68.240.41 with SMTP id vx9mr33884944pbc.10.1332633403526; Sat, 24 Mar 2012 16:56:43 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id jm10sm8983247pbc.74.2012.03.24.16.56.40 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Mar 2012 16:56:41 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so4261400pbb.31 for ; Sat, 24 Mar 2012 16:56:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.201.98 with SMTP id jz2mr40749820pbc.97.1332633400382; Sat, 24 Mar 2012 16:56:40 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Sat, 24 Mar 2012 16:56:39 -0700 (PDT) In-Reply-To: <7D8EC27B-2446-4992-B5F5-5CC7A17D2BCE@phonefromhere.com> References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <7D8EC27B-2446-4992-B5F5-5CC7A17D2BCE@phonefromhere.com> Date: Sat, 24 Mar 2012 19:56:39 -0400 Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=047d7b15aee97214b504bc05e437 X-Gm-Message-State: ALoCoQn6aeh27YNVraH0aiiMdtFtW4mGRbhK9v1rQrayPhQkZnmZSuPnG3xckdJlQKKcYM4JvXcx Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 23:56:44 -0000 --047d7b15aee97214b504bc05e437 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 24, 2012 at 5:15 AM, Tim Panton wrote: > G711 is ok for perfect networks with legacy interop needs, but pretty much > useless anywhere else. > > Not that I have anything against OPUS (except that it is not a standard yet), but G711 works just fine for calls within local LAN or over a wireline network. If you have the bandwidth, you can run it with 16 or 32 KHz sampling rate and it will sound considerably better then any compressed codec. Since we are getting more and more bandwidth between end points, in the future we might not need to compress audio at all. It is not just for interop. _____________ Roman Shpount --047d7b15aee97214b504bc05e437 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Mar 24, 2012 at 5:15 A= M, Tim Panton <tim@phonefromhere.com> wrote:
G711 is ok for perfect networks with legacy interop needs, but pretty much = useless anywhere else.


Not that I have a= nything against OPUS (except that it is not a standard yet), but G711 works= just fine for calls within local LAN or over a wireline network. If you ha= ve the bandwidth, you can run it with 16 or 32 KHz sampling rate and it wil= l sound considerably better then any compressed codec. Since we are getting= more and more bandwidth between end points, in the future we might not nee= d to compress audio at all. It is not just for interop.
_____________
Roman Shpount


--047d7b15aee97214b504bc05e437-- From jmvalin@mozilla.com Sat Mar 24 17:34:37 2012 Return-Path: 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 7C2FD21F84EC for ; Sat, 24 Mar 2012 17:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6L-ee4wLD3zw for ; Sat, 24 Mar 2012 17:34:37 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 6824721F84EA for ; Sat, 24 Mar 2012 17:34:35 -0700 (PDT) Received: from [172.22.10.239] (unknown [207.164.135.98]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 9D9B34AED83; Sat, 24 Mar 2012 17:34:34 -0700 (PDT) Message-ID: <4F6E6818.1010206@mozilla.com> Date: Sat, 24 Mar 2012 20:34:32 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Roman Shpount References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <7D8EC27B-2446-4992-B5F5-5CC7A17D2BCE@phonefromhere.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On video codec for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 00:34:37 -0000 On 24/03/12 07:56 PM, Roman Shpount wrote: > Not that I have anything against OPUS (except that it is not a standard > yet), but G711 works just fine for calls within local LAN or over a > wireline network. If you have the bandwidth, you can run it with 16 or > 32 KHz sampling rate and it will sound considerably better then any > compressed codec. Have you ever listened to G.711 at 16 kHz? Certainly not "better then any compressed codec". In fact, the white quantization noise will usually be louder than the higher frequencies of the signal. And 32 kHz will just be even worse. Jean-Marc From harald@alvestrand.no Sun Mar 25 13:12:09 2012 Return-Path: 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 0D9E421E8015 for ; Sun, 25 Mar 2012 13:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 k4Cr3NxDfgl0 for ; Sun, 25 Mar 2012 13:12:08 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D8A1E21E800C for ; Sun, 25 Mar 2012 13:12:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 83AA739E180; Sun, 25 Mar 2012 22:12:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leXLfiBUmQ2o; Sun, 25 Mar 2012 22:11:45 +0200 (CEST) Received: from [10.216.6.96] (unknown [93.158.42.180]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2B77F39E04C; Sun, 25 Mar 2012 22:11:44 +0200 (CEST) Message-ID: <4F6F7C01.8050709@alvestrand.no> Date: Sun, 25 Mar 2012 22:11:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "Fabio Pietrosanti (naif)" References: <4F6E4D8A.60402@infosecurity.ch> In-Reply-To: <4F6E4D8A.60402@infosecurity.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [rtcweb] Encryption consideration: SDES and TLS-SRP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 20:12:09 -0000 Please read draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch. I'm sorry, but not even checking the names of drafts the working group is working on before asking questions is below the minimum bar we expect of participants posting long emails. Harald On 03/24/2012 11:41 PM, Fabio Pietrosanti (naif) wrote: > Hi all, > > i wanted to ask the WG opinion on the encryption framework for the RTCWEB. > > In particular as we know today there is a strong need to have an > encryption-by-default on most new protocols. > > Today: > - Email provider encryption by default traffic > - Mobile operators encrypt by default traffic > - Almost all web transaction use encryption > > So it's realistic and practical to think that VoIP future is > encrypted-by-default to at least basically protect against the casual > wiretapper. (Can we evaluate this assumption?) > > In that case we may have different threat scenario: > - Eavesdropping by third party with access to user's communication line > - Eavesdropping by who is providing the telephony service > > A simpler protection scenario would at least provide protection against > third party with access to user's communication line. > A stronger protection scenario would also provide protection against who > is providing the service. > > Here we should consider the security of: > - Signaling > - Media > > Signaling has to be protected with TLS. > Media has to be protected with SRTP that rely on DTLS or on the new > proposal to use SDES [1] (idea that i like). > > So basically in both cases there is the need to rely on a TLS-secured > channel and here we should evaluate the possible weak points. > > As you know the TLS based trust model based on "Browser/OS Pre-loaded > Trusted CA" revealed serious risks posed to internet trust model [2] . > > So, because we are defining a stack that should look forward the future, > we cannot not-consider seriously the serious issues related with TLS and > way to manage it. > > An idea that came to my mind is that the specification, to face a > future-proof approach to the internet trust issues, could mandate to > support the implementation of TLS-SRP. > > TLS-SRP is a new standard that let the TLS key exchange be authenticated > by a login/password with no need to trust a specific CA. > Status of implementation of RFC5054 http://tools.ietf.org/html/rfc5054 > is available on http://trustedhttp.org/wiki/Main_Page . > > If we embrace SDES key exchange and TLS-SRP authentication the overall > protocol stack would be simpler than having to deal with DTLS and > relying only on Trusted-CA architectures. > > [1] > http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/slides/rtcweb-7.pdf > [2] http://ritter.vg/p/2012-TLS-Survey.pdf > > p.s. I'm quite new to the list, so i may repeat some discussion > elements. In that case i kindly ask to leave to archive pointer to > already made discussion. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Mon Mar 26 02:12:17 2012 Return-Path: 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 1639B21F84E6 for ; Mon, 26 Mar 2012 02:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 X2WCXww9OlPM for ; Mon, 26 Mar 2012 02:12:16 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4F11B21F84D2 for ; Mon, 26 Mar 2012 02:12:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 564B639E0FA for ; Mon, 26 Mar 2012 11:12:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CitDVHQ9DAwZ for ; Mon, 26 Mar 2012 11:12:12 +0200 (CEST) Received: from [130.129.85.52] (dhcp-5534.meeting.ietf.org [130.129.85.52]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D017739E062 for ; Mon, 26 Mar 2012 11:12:12 +0200 (CEST) Message-ID: <4F7032EE.2010007@alvestrand.no> Date: Mon, 26 Mar 2012 11:12:14 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Dependency graphs for 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:12:17 -0000 Just FYI.... the automatically generated dependency graphs for RTCWEB are visible here: http://fenron.net/~fenner/ietf/deps/viz/rtcweb-norm.pdf (normative references only) http://fenron.net/~fenner/ietf/deps/viz/rtcweb.pdf (all references) Worthy of note. Harald From fluffy@cisco.com Mon Mar 26 05:17:20 2012 Return-Path: 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 7CCF521F866C for ; Mon, 26 Mar 2012 05:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 98HHLoNQP01E for ; Mon, 26 Mar 2012 05:17:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 606FD21F8646 for ; Mon, 26 Mar 2012 05:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1296; q=dns/txt; s=iport; t=1332764235; x=1333973835; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=IdKrM2XTfnTyHwUzSWEHySvJ+14qxT4O23fBN3Mlu+Q=; b=jDHKwyzlWS5wBzXc/iqzOPuKPaLaIv/ycBjlmWprVav4ZGBpQBka8lAv vZqnfj8EEkplSqQ26siHkfqb5yQttDdFj719+LRL4KzLtm8IK40wM8NBe rAnuX4Lh7fzC3MPFD0xIdFSZ3n9BkteTDMXzVnZNj2qygdVahqLttmmt5 o=; X-IronPort-AV: E=Sophos;i="4.73,650,1325462400"; d="scan'208";a="133353181" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 26 Mar 2012 12:17:14 +0000 Received: from dhcp-10-61-97-136.cisco.com (dhcp-10-61-97-136.cisco.com [10.61.97.136]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2QCHE4s001498; Mon, 26 Mar 2012 12:17:14 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 26 Mar 2012 14:17:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Cullen Jennings X-Mailer: Apple Mail (2.1257) Cc: rtcweb@ietf.org Subject: [rtcweb] Moving to WEDNESDAY Re: RTCWeb DEMO's Thursday at Lunch - X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 12:17:20 -0000 This meeting is going to move to Wednesday 1130-1300 in room 242AB.=20 This was moved to avoid the conflict with the lunch talk titled "Status = of Standards for Cloud Storage" being given by Scality as they are a = paying sponsor of this IETF. Instead we will move to conflict with the = Cisco lunch talk - I really doubt that Cisco will have a problem with = this. I'd got some side questions about what this was and wanted it to be = clear - this is to look at the running code of folks building the RTCWeb = specs and gets some feedback from implementors about the specs as well = as help folks understand how the implementations matched (or fail to = match) the specs.=20 Cullen On Mar 24, 2012, at 12:38 , Cullen Jennings wrote: >=20 > We will be doing RTCWeb related demos in room 242AB on Thursday = 1130-1300. Please let the chairs know if there is a demo you would like = to show.=20 >=20 > There will be no food provided - I suspect what we will do is just run = demos from 11:30 to 12:00 and then give people time to go for lunch. The = chairs will see what people want to demo and then plan a schedule.=20 >=20 > If you have some code that might run, lets us know and lets see it. =20= >=20 > Thanks, Cullen >=20 >=20 >=20 >=20 >=20 >=20 From ajrmeyn@gmail.com Tue Mar 27 00:52:04 2012 Return-Path: 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 51F5921F87CB for ; Tue, 27 Mar 2012 00:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] 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 jVesW7VdauIZ for ; Tue, 27 Mar 2012 00:52:03 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED48621F8766 for ; Tue, 27 Mar 2012 00:52:02 -0700 (PDT) Received: by lbol12 with SMTP id l12so5037949lbo.31 for ; Tue, 27 Mar 2012 00:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:mime-version:content-type :x-priority:x-msmail-priority:importance:x-mailer:x-mimeole; bh=75f0M+6cEcUNRR4Mk7xk9pDPM075+Fm90Ty9A5+r+p8=; b=gYID8x/el0469hGk6V3cOToe+FuThpyykjaOWBYUBakK63RMXA/HSKVjbTESimC/xr KVxgCRRgVMJUaxn7jXpuEIpbCVITDxXkwtfDk4digdjVqt9HSeVnfcdzPQNAhxSgi+o6 FBilWf3xnt2I39E5fiumA/Zwwi48w5jyQ1eKAMWRA35dFuWViRgPwFe+xyWSBa35TFfd 40cTXZCJC5rifAa9iJ+mdPWJw2+9mQ3pw86z9/u+VB8t0rwVrhVoLnHO4xUWTbEyfkU5 9k6385zBaf/+xKFY1uEh/s242RTJhBcKpOtJuY9hG2XePCUEhHk2isekD/zslEbiUUm/ hwLg== Received: by 10.112.105.101 with SMTP id gl5mr8575162lbb.71.1332834720629; Tue, 27 Mar 2012 00:52:00 -0700 (PDT) Received: from devbox ([2001:708:30:1090:b05a:6cc3:d370:3016]) by mx.google.com with ESMTPS id ox7sm25010712lbb.17.2012.03.27.00.51.59 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 00:51:59 -0700 (PDT) Message-ID: From: To: Date: Tue, 27 Mar 2012 10:51:58 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01CD0C07.A1E646E0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Subject: [rtcweb] Query regarding rtcweb use cases and requirements. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:52:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0045_01CD0C07.A1E646E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This is with regards to the following document:Web Real-Time = Communication Use-cases and Requirements draft-ietf-rtcweb-use-cases-and-requirements-06.txt http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requireme= nts/?include_text=3D1=20 I have noticed that the use cases with regards to Data API of web real = time communication, have not been addressed. For example: use cases that = are related to file sharing between browsers.=20 is there any particular reason for the same? Regards, Antony Meyn ------=_NextPart_000_0045_01CD0C07.A1E646E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Hi,
 
This is with regards to the =
following document:
Web Real-Time Communication Use-cases and Requirements
draft-ietf-rtcweb-use-cases-and-requirements-06.txt
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases= -and-requirements/?include_text=3D1
I have noticed that the use cases with regards = to Data=20 API of web real time communication, have not been addressed. For = example: use=20 cases that are related to file sharing between browsers.
 
is there any particular reason for the = same?
 
Regards,
Antony=20 Meyn
------=_NextPart_000_0045_01CD0C07.A1E646E0-- From harald@alvestrand.no Tue Mar 27 03:36:28 2012 Return-Path: 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 4F40021E8162 for ; Tue, 27 Mar 2012 03:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 6lI+42-6ZuOe for ; Tue, 27 Mar 2012 03:36:26 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 86C7121E8101 for ; Tue, 27 Mar 2012 03:36:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E3F139E098; Tue, 27 Mar 2012 12:36:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0oJT8Zfu8n9; Tue, 27 Mar 2012 12:36:24 +0200 (CEST) Received: from [130.129.67.10] (dhcp-430a.meeting.ietf.org [130.129.67.10]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 58B8039E03A; Tue, 27 Mar 2012 12:36:24 +0200 (CEST) Message-ID: <4F71982B.4010208@alvestrand.no> Date: Tue, 27 Mar 2012 12:36:27 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: ajrmeyn@gmail.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040102050509010701030701" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Query regarding rtcweb use cases and requirements. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:36:28 -0000 This is a multi-part message in MIME format. --------------040102050509010701030701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/27/2012 09:51 AM, ajrmeyn@gmail.com wrote: > Hi, > > This is with regards to the following document: > Web Real-Time Communication Use-cases and Requirements > draft-ietf-rtcweb-use-cases-and-requirements-06.txt > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/?include_text=1 > I have noticed that the use cases with regards to Data API of web real > time communication, have not been addressed. For example: use cases > that are related to file sharing between browsers. > is there any particular reason for the same? Requirement F23 is a data-passing requirement. For communications that did not need low latency, the WG felt that the RTCWEB requirements were not different from the requirements of any other application, so those could be fulfilled with other types of interfaces, including server-mediated file transfers. The WG is suggesting data API/protocol solutions that can be used for other things than fulfiling the most narrow interpretation of the requirement listed, but did not feel a need to add a requirement covering those. The purpose of the "use cases and requirements" is to find a minimum set of things that the protocol suite has to be able to do in order to be "good enough", not to delineate everything the protocol can be used for. My interpretation.... Harald > Regards, > Antony Meyn > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------040102050509010701030701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/27/2012 09:51 AM, ajrmeyn@gmail.com wrote: 
Hi,
 
This is with regards to the following document:
Web Real-Time Communication Use-cases and Requirements
draft-ietf-rtcweb-use-cases-and-requirements-06.txt
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/?include_text=1
I have noticed that the use cases with regards to Data API of web real time communication, have not been addressed. For example: use cases that are related to file sharing between browsers.
 
is there any particular reason for the same?
Requirement F23 is a data-passing requirement.

For communications that did not need low latency, the WG felt that the RTCWEB requirements were not different from the requirements of any other application, so those could be fulfilled with other types of interfaces, including server-mediated file transfers.

The WG is suggesting data API/protocol solutions that can be used for other things than fulfiling the most narrow interpretation of the requirement listed, but did not feel a need to add a requirement covering those.

The purpose of the "use cases and requirements" is to find a minimum set of things that the protocol suite has to be able to do in order to be "good enough", not to delineate everything the protocol can be used for.

My interpretation....

                      Harald




 
Regards,
Antony Meyn

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

--------------040102050509010701030701-- From ietf@meetecho.com Tue Mar 27 07:43:58 2012 Return-Path: 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 6235721E81D9 for ; Tue, 27 Mar 2012 07:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 UlAhfLrj6F4s for ; Tue, 27 Mar 2012 07:43:57 -0700 (PDT) Received: from smtplq03.aruba.it (smtplqs-out29.aruba.it [62.149.158.69]) by ietfa.amsl.com (Postfix) with SMTP id 5075C21E81AB for ; Tue, 27 Mar 2012 07:43:56 -0700 (PDT) Received: (qmail 22036 invoked by uid 89); 27 Mar 2012 14:43:53 -0000 Received: from unknown (HELO smtp5.aruba.it) (62.149.158.225) by smtplq03.aruba.it with SMTP; 27 Mar 2012 14:43:53 -0000 Received: (qmail 15231 invoked by uid 89); 27 Mar 2012 14:43:53 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp5.ad.aruba.it with SMTP; 27 Mar 2012 14:43:53 -0000 Message-ID: <4F71D227.60509@meetecho.com> Date: Tue, 27 Mar 2012 16:43:51 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [rtcweb] Meetecho support for RTCWEB WG meeting session X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:43:58 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Wednesday's RTCWEB WG meeting session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf83/rtcweb The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to, by either calling a landline phone number, or using our embedded VoIP applet (in this last case they are *strongly* advised to use a headset). A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf83/tutorials Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From martin.thomson@gmail.com Tue Mar 27 20:28:27 2012 Return-Path: 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 01DD321E8027 for ; Tue, 27 Mar 2012 20:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.688 X-Spam-Level: X-Spam-Status: No, score=-4.688 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 4JP2nx9N7mhV for ; Tue, 27 Mar 2012 20:28:26 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 11A4C21E801A for ; Tue, 27 Mar 2012 20:28:25 -0700 (PDT) Received: by bkuw5 with SMTP id w5so537556bku.31 for ; Tue, 27 Mar 2012 20:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=K6nLNwASvgQEgLACk9WiruXwxJMenK1bhwBAvHBsSJU=; b=fb/eFOnuejR/WVJezuC8GhTqRv9xvw1WE9KWNUGX87sa99a24Mmle3LWOH7DKJ1wsg Saus3KTzFI7Q1+uNPy0k27kBYGDs87ENHqEbz22kAYmIAd8sFSmh1tr/NESR4IP+bS0N SpVYGRzXVDZBGWFa229FW0Vf9Kl9pM7Ox4EgbilqrRzfyhnOhhwhulXyTvMHS0zsgQEb a0aRWnAFLUJWFzGLbdf1GyD2OkEIu73IUq5boSXc1yAuV6LpYJ05GpdoXvwAlY60wzQ7 ZKGzm4onzLpChuQUq/e6j4xzJN9JDLiH8B2I55/0pt5f7GMQmGfBJYmgfeCuY3zScAZo 8bLQ== MIME-Version: 1.0 Received: by 10.204.152.12 with SMTP id e12mr11179503bkw.29.1332905304968; Tue, 27 Mar 2012 20:28:24 -0700 (PDT) Received: by 10.205.38.73 with HTTP; Tue, 27 Mar 2012 20:28:24 -0700 (PDT) In-Reply-To: <20120328031913.20922.78617.idtracker@ietfa.amsl.com> References: <20120328031913.20922.78617.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 05:28:24 +0200 Message-ID: From: Martin Thomson To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] Fwd: New Version Notification for draft-thomson-rtcweb-ice-dtls-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 03:28:27 -0000 I finally got around to posting this. Since the version that I circulated, I've fleshed out the security considerations a little. I didn't remove the extra round trip, because I forgot. From: A new version of I-D, draft-thomson-rtcweb-ice-dtls-00.txt has been successfully submitted by Martin Thomson and posted to the IETF repository. From rbarnes@bbn.com Wed Mar 28 02:15:34 2012 Return-Path: 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 C423721E805A for ; Wed, 28 Mar 2012 02:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 VcbQB6Ay13PD for ; Wed, 28 Mar 2012 02:15:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id CC3B821E804A for ; Wed, 28 Mar 2012 02:15:33 -0700 (PDT) Received: from [128.89.254.245] (port=58318 helo=neutrino.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCoyN-000G4s-Gh for rtcweb@ietf.org; Wed, 28 Mar 2012 05:15:19 -0400 Message-ID: <4F72D6B3.40803@bbn.com> Date: Wed, 28 Mar 2012 11:15:31 +0200 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:15:34 -0000 I didn't make it to the mic at the meeting today, but I wanted to express one concern about the possibility of making RTCWEB SRTP-only. Hadriel mentioned the "marketing value" of having always-on encryption, this idea that only supporting SRTP will make RTCWEB look like something secure and trustworthy. I'm concerned that this might not be the case, and in fact that being SRTP-only might effectively be an over-promise, in light of the fact the absence of universal authentication. Hadriel noted that the competitors to this technology are Skype and Flash, and it's worth considering the security situation with these technologies, because they kind of bracket RTCWEB. With Skype (assuming they've designed it properly), there is actually a universal authentication, under a single authority. So you really do know that you're talking to whatever Skype ID you intend to, and nobody else. With Flash, well, does anyone expect it to be secure anyway? What I'm concerned about in the RTCWEB context is that without a universal authentication/identity infrastructure, we will end up *promising* a secure call, but not *delivering* it. I haven't done the analysis, but it does not seem implausible to me that FireSheep-like vulnerabilities are lurking here. So ISTM the "marketing" argument carries with it some serious risks as well as some small possible benefit. --Richard From harald@alvestrand.no Wed Mar 28 03:13:41 2012 Return-Path: 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 5C3F421F89AC for ; Wed, 28 Mar 2012 03:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 U4SK6eVRIFe0 for ; Wed, 28 Mar 2012 03:13:40 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 70D9921F89A8 for ; Wed, 28 Mar 2012 03:13:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 55C3339E178; Wed, 28 Mar 2012 12:13:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD4-KDKUdyuw; Wed, 28 Mar 2012 12:13:38 +0200 (CEST) Received: from [130.129.85.52] (dhcp-5534.meeting.ietf.org [130.129.85.52]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7DFC339E088; Wed, 28 Mar 2012 12:13:38 +0200 (CEST) Message-ID: <4F72E453.7070204@alvestrand.no> Date: Wed, 28 Mar 2012 12:13:39 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4F72D6B3.40803@bbn.com> In-Reply-To: <4F72D6B3.40803@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:13:41 -0000 On 03/28/2012 11:15 AM, Richard L. Barnes wrote: > I didn't make it to the mic at the meeting today, but I wanted to > express one concern about the possibility of making RTCWEB SRTP-only. > > Hadriel mentioned the "marketing value" of having always-on > encryption, this idea that only supporting SRTP will make RTCWEB look > like something secure and trustworthy. I'm concerned that this might > not be the case, and in fact that being SRTP-only might effectively be > an over-promise, in light of the fact the absence of universal > authentication. > > Hadriel noted that the competitors to this technology are Skype and > Flash, and it's worth considering the security situation with these > technologies, because they kind of bracket RTCWEB. With Skype > (assuming they've designed it properly), there is actually a universal > authentication, under a single authority. So you really do know that > you're talking to whatever Skype ID you intend to, and nobody else. > With Flash, well, does anyone expect it to be secure anyway? > > What I'm concerned about in the RTCWEB context is that without a > universal authentication/identity infrastructure, we will end up > *promising* a secure call, but not *delivering* it. I haven't done > the analysis, but it does not seem implausible to me that > FireSheep-like vulnerabilities are lurking here. If there are, we need to close them before we ship the specs. Given reasonable practices (such as using only HTTPS for loading the pages and JS libraries), if we can't deliver security (against known attacks), we shouldn't ship the spec. > > So ISTM the "marketing" argument carries with it some serious risks as > well as some small possible benefit. Only if we don't deliver. > > --Richard > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From rbarnes@bbn.com Wed Mar 28 03:43:36 2012 Return-Path: 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 6E03821F8A19 for ; Wed, 28 Mar 2012 03:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 iWrlYPjpDUu3 for ; Wed, 28 Mar 2012 03:43:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 684E621F8A14 for ; Wed, 28 Mar 2012 03:43:34 -0700 (PDT) Received: from [128.89.255.12] (port=58632 helo=neutrino.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCqLX-000Gh1-GT; Wed, 28 Mar 2012 06:43:19 -0400 Message-ID: <4F72EB53.5000409@bbn.com> Date: Wed, 28 Mar 2012 12:43:31 +0200 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Harald Alvestrand References: <4F72D6B3.40803@bbn.com> <4F72E453.7070204@alvestrand.no> In-Reply-To: <4F72E453.7070204@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:43:36 -0000 >> I didn't make it to the mic at the meeting today, but I wanted to >> express one concern about the possibility of making RTCWEB SRTP-only. >> >> Hadriel mentioned the "marketing value" of having always-on >> encryption, this idea that only supporting SRTP will make RTCWEB look >> like something secure and trustworthy. I'm concerned that this might >> not be the case, and in fact that being SRTP-only might effectively be >> an over-promise, in light of the fact the absence of universal >> authentication. >> >> Hadriel noted that the competitors to this technology are Skype and >> Flash, and it's worth considering the security situation with these >> technologies, because they kind of bracket RTCWEB. With Skype >> (assuming they've designed it properly), there is actually a universal >> authentication, under a single authority. So you really do know that >> you're talking to whatever Skype ID you intend to, and nobody else. >> With Flash, well, does anyone expect it to be secure anyway? >> >> What I'm concerned about in the RTCWEB context is that without a >> universal authentication/identity infrastructure, we will end up >> *promising* a secure call, but not *delivering* it. I haven't done the >> analysis, but it does not seem implausible to me that FireSheep-like >> vulnerabilities are lurking here. > If there are, we need to close them before we ship the specs. > Given reasonable practices (such as using only HTTPS for loading the > pages and JS libraries), if we can't deliver security (against known > attacks), we shouldn't ship the spec. I agree that we should lock things down to the extent we can, and I think we will be able to do pretty well, using things such as you note. But at base, without authentication, you cannot prevent MitM if someone is in the right place in the network. You can just constrain the set of places from which an MitM can be launched. >> So ISTM the "marketing" argument carries with it some serious risks as >> well as some small possible benefit. > Only if we don't deliver. Except that "deliver" in this case entails a global authentication/identity infrastructure. And it seems unlikely that we'll deliver that in the short run. --Richard From mmanig@gmail.com Wed Mar 28 03:55:18 2012 Return-Path: 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 9258721F89C7 for ; Wed, 28 Mar 2012 03:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 c7Wve5odTLpz for ; Wed, 28 Mar 2012 03:55:18 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C594321F896A for ; Wed, 28 Mar 2012 03:55:17 -0700 (PDT) Received: by yhkk25 with SMTP id k25so612131yhk.31 for ; Wed, 28 Mar 2012 03:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PXtSxDpsrCaC9s0TTTWaCoO9w49KDMXDK+bb6+P0mUw=; b=qIpJU0sIQTzkIvsg2wIYuPD0A/8Owdvy4pgjVb0uTsHy/NV/8ovouQTuEPa15WKAbU Q0HMuvTYrQO+vWOMXlqh2jHZ8hhSzQNXaUoQcWCZs6hJQQbXsk2WCcNEpZy0xf1hRBXE SiBWMRZsDTBqoyFWb/mmmWfw6tHVPLHS0DC96WIn4Uo9+0Kv8PQm5H+FjrxKYdCNdeEO NVUDJEngvkpC3ZVLh1w55V058Fls122nvJ1XUfZM5oBCUWDl3uwb0P8RtK+1GkoUpz4C OvMtkT7bmWvgIZoEazTjVZ+UZboogqS4RT/8JRVzwCu7uEfi33Lvu2Bvuq0GfVQItKpt xRwg== MIME-Version: 1.0 Received: by 10.60.0.195 with SMTP id 3mr36898255oeg.2.1332932116880; Wed, 28 Mar 2012 03:55:16 -0700 (PDT) Received: by 10.182.67.161 with HTTP; Wed, 28 Mar 2012 03:55:16 -0700 (PDT) In-Reply-To: <4F72D6B3.40803@bbn.com> References: <4F72D6B3.40803@bbn.com> Date: Wed, 28 Mar 2012 03:55:16 -0700 Message-ID: From: Mahalingam Mani To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=e89a8fb1ede0561c3004bc4b71f7 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:55:18 -0000 --e89a8fb1ede0561c3004bc4b71f7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 28, 2012 at 2:15 AM, Richard L. Barnes wrote: > [...] > What I'm concerned about in the RTCWEB context is that without a universal > authentication/identity infrastructure, we will end up *promising* a secure > call, but not *delivering* it. I haven't done the analysis, but it does > not seem implausible to me that FireSheep-like vulnerabilities are lurking > here. > > > The choices of framework proposed in today's meeting still carry an overall undercurrent of the same generic mechanism as a SAML-based authentication and authorization. Even if a universal authentication infrastructure should exist - it becomes a potential single point of failure (imagine that being the defunct diginotar) or non-success (MS Passport). Too many trust-anchors (IdPs) is a problem as well for the single end-user (non-enterprise). But in the end - would users prefer to go with the trust-anchors they have come to associate with and have gained a reputation for; or something completely new? Even with identity - the authoritative case proposes a : paradigm and in the 3rd party case too - assertions are based on association of a user to domain - by an outside idP. Thus, there's significant closeness in the identity form - regardless of whether it is the most common RFC822 (email address), SIP URI (with a slight exception of OpenID) or other URI forms. -mani > So ISTM the "marketing" argument carries with it some serious risks as > well as some small possible benefit. > > --Richard > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --e89a8fb1ede0561c3004bc4b71f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Mar 28, 2012 at 2:15 AM, Richard= L. Barnes <rbarnes= @bbn.com> wrote:

[...]
What I'm concerned about in the RTCWEB context is that without a univer= sal authentication/identity infrastructure, we will end up *promising* a se= cure call, but not *delivering* it. =A0I haven't done the analysis, but= it does not seem implausible to me that FireSheep-like vulnerabilities are= lurking here.

=A0

=A0
The choices of framework prop= osed in today's meeting still carry an overall undercurrent of the same= generic mechanism as a SAML-based authentication and authorization.
Even if a universal authentication infrastructure should exist - it be= comes a potential single point of failure (imagine that being the defunct d= iginotar) or non-success (MS Passport).
Too many trust-anchors (I= dPs) is a problem as well for the single end-user (non-enterprise). But in = the end - would users prefer to go with the trust-anchors they have come to= associate with and have gained a reputation for; or something completely n= ew?
=A0
Even with identity - the authoritative case proposes a &= lt;name>:<domain> paradigm and in the 3rd party case too - asserti= ons are based on association of a user to domain - by an outside idP. Thus,= there's significant closeness in the identity form - regardless of whe= ther it is the most common RFC822 (email address), SIP URI (with a slight e= xception of OpenID) or other URI forms.
=A0
-mani
So ISTM the "marketing" argument carries with it some serious ris= ks as well as some small possible benefit.

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

--e89a8fb1ede0561c3004bc4b71f7-- From harald@alvestrand.no Wed Mar 28 07:42:26 2012 Return-Path: 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 83C1721E813B for ; Wed, 28 Mar 2012 07:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 ALapgzmRXOpy for ; Wed, 28 Mar 2012 07:42:25 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB3221E812F for ; Wed, 28 Mar 2012 07:42:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7BA1C39E17A; Wed, 28 Mar 2012 16:42:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ET6duJa6uAw; Wed, 28 Mar 2012 16:42:23 +0200 (CEST) Received: from [130.129.85.52] (dhcp-5534.meeting.ietf.org [130.129.85.52]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0145039E088; Wed, 28 Mar 2012 16:42:22 +0200 (CEST) Message-ID: <4F732350.3090306@alvestrand.no> Date: Wed, 28 Mar 2012 16:42:24 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Mahalingam Mani References: <4F72D6B3.40803@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020302080109010309070300" Cc: rtcweb@ietf.org Subject: [rtcweb] Identity and authorities (Re: SRTP and "marketing") X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:42:26 -0000 This is a multi-part message in MIME format. --------------020302080109010309070300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Changing the subject line... On 03/28/2012 12:55 PM, Mahalingam Mani wrote: > > > On Wed, Mar 28, 2012 at 2:15 AM, Richard L. Barnes > wrote: > > [...] > What I'm concerned about in the RTCWEB context is that without a > universal authentication/identity infrastructure, we will end up > *promising* a secure call, but not *delivering* it. I haven't > done the analysis, but it does not seem implausible to me that > FireSheep-like vulnerabilities are lurking here. > > The choices of framework proposed in today's meeting still carry an > overall undercurrent of the same generic mechanism as a SAML-based > authentication and authorization. > Even if a universal authentication infrastructure should exist - it > becomes a potential single point of failure (imagine that being the > defunct diginotar) or non-success (MS Passport). > Too many trust-anchors (IdPs) is a problem as well for the single > end-user (non-enterprise). But in the end - would users prefer to go > with the trust-anchors they have come to associate with and have > gained a reputation for; or something completely new? > Even with identity - the authoritative case proposes a : > paradigm and in the 3rd party case too - assertions are based on > association of a user to domain - by an outside idP. Thus, there's > significant closeness in the identity form - regardless of whether it > is the most common RFC822 (email address), SIP URI (with a slight > exception of OpenID) or other URI forms. This actually shows that the IdP proposal brings a dependency with it on the domain hierarchy. This has real issues, the most important one perhaps being that domain identities can't be guaranteed over time; even when real-life organizational identities exist, it's not unusual to see the domain name change hands multiple times, either voluntarily (selling) or involuntarily (UDRP, court cases, forgetting to renew and being drop-kicked). Not sure where discussion of this problem belongs; it might not be a problem if one never has to verify a stored identity. I think the proposals bring significant value even in the absence of standardized identity verification - FireSheep is a good example, for instance; with HTTPS, FireSheep is powerless as long as it's not in cahoots with a corrupted CA - which defeats a huge subset of the set of potential attackers. --------------020302080109010309070300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Changing the subject line...

On 03/28/2012 12:55 PM, Mahalingam Mani wrote:


On Wed, Mar 28, 2012 at 2:15 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:

[...]
What I'm concerned about in the RTCWEB context is that without a universal authentication/identity infrastructure, we will end up *promising* a secure call, but not *delivering* it.  I haven't done the analysis, but it does not seem implausible to me that FireSheep-like vulnerabilities are lurking here.

 

 
The choices of framework proposed in today's meeting still carry an overall undercurrent of the same generic mechanism as a SAML-based authentication and authorization.
Even if a universal authentication infrastructure should exist - it becomes a potential single point of failure (imagine that being the defunct diginotar) or non-success (MS Passport).
Too many trust-anchors (IdPs) is a problem as well for the single end-user (non-enterprise). But in the end - would users prefer to go with the trust-anchors they have come to associate with and have gained a reputation for; or something completely new?
 
Even with identity - the authoritative case proposes a <name>:<domain> paradigm and in the 3rd party case too - assertions are based on association of a user to domain - by an outside idP. Thus, there's significant closeness in the identity form - regardless of whether it is the most common RFC822 (email address), SIP URI (with a slight exception of OpenID) or other URI forms.

This actually shows that the IdP proposal brings a dependency with it on the domain hierarchy.
This has real issues, the most important one perhaps being that domain identities can't be guaranteed over time; even when real-life organizational identities exist, it's not unusual to see the domain name change hands multiple times, either voluntarily (selling) or involuntarily (UDRP, court cases, forgetting to renew and being drop-kicked).

Not sure where discussion of this problem belongs; it might not be a problem if one never has to verify a stored identity.

I think the proposals bring significant value even in the absence of standardized identity verification - FireSheep is a good example, for instance; with HTTPS, FireSheep is powerless as long as it's not in cahoots with a corrupted CA - which defeats a huge subset of the set of potential attackers.



--------------020302080109010309070300-- From magnus.westerlund@ericsson.com Wed Mar 28 07:50:29 2012 Return-Path: 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 7107621E825D for ; Wed, 28 Mar 2012 07:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.394 X-Spam-Level: X-Spam-Status: No, score=-110.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 cvxwdfWps7G0 for ; Wed, 28 Mar 2012 07:50:29 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 90BDC21E8282 for ; Wed, 28 Mar 2012 07:50:28 -0700 (PDT) X-AuditID: c1b4fb3d-b7b5aae000002dcb-d8-4f7325330c8d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 41.F1.11723.335237F4; Wed, 28 Mar 2012 16:50:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Wed, 28 Mar 2012 16:50:27 +0200 Message-ID: <4F732531.2030208@ericsson.com> Date: Wed, 28 Mar 2012 16:50:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:50:29 -0000 WG, In todays RTCWEB WG meeting there was discussion around media security mechanism. In this meeting there was some clear consensus in the meeting which we would like to confirm on the list. The first was that there was overwhelming consensus that all RTP packets SHALL be protected by SRTP. Secondly that no one objected against making DTLS-SRTP a mandatory to implement and the default keying mechanism. Additional mechanisms are not precluded. WG participants may state their position regarding these consensus calls until 12th of April when the chairs will declare the final consensus. If you where present in the meeting room and comment on this, please indicate that. Best Regards Magnus Westerlund For the WG chairs From abu_hurayrah@hidayahonline.org Wed Mar 28 07:51:35 2012 Return-Path: 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 42CEF21E828B for ; Wed, 28 Mar 2012 07:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] 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 6afr0BXOB0Cl for ; Wed, 28 Mar 2012 07:51:34 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 76C2321E8287 for ; Wed, 28 Mar 2012 07:51:34 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 942086524A1 for ; Wed, 28 Mar 2012 10:51:33 -0400 (EDT) Message-ID: <4F732562.6010902@hidayahonline.org> Date: Wed, 28 Mar 2012 10:51:14 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F72D6B3.40803@bbn.com> In-Reply-To: <4F72D6B3.40803@bbn.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=5AF4B362 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:51:35 -0000 On 03/28/2012 05:15 AM, Richard L. Barnes wrote: > I didn't make it to the mic at the meeting today, but I wanted to > express one concern about the possibility of making RTCWEB SRTP-only. > > Hadriel mentioned the "marketing value" of having always-on > encryption, this idea that only supporting SRTP will make RTCWEB look > like something secure and trustworthy. I'm concerned that this might > not be the case, and in fact that being SRTP-only might effectively be > an over-promise, in light of the fact the absence of universal > authentication. > > Hadriel noted that the competitors to this technology are Skype and > Flash, and it's worth considering the security situation with these > technologies, because they kind of bracket RTCWEB. With Skype > (assuming they've designed it properly), there is actually a universal > authentication, under a single authority. So you really do know that > you're talking to whatever Skype ID you intend to, and nobody else. > With Flash, well, does anyone expect it to be secure anyway? > > What I'm concerned about in the RTCWEB context is that without a > universal authentication/identity infrastructure, we will end up > *promising* a secure call, but not *delivering* it. I haven't done > the analysis, but it does not seem implausible to me that > FireSheep-like vulnerabilities are lurking here. > > So ISTM the "marketing" argument carries with it some serious risks as > well as some small possible benefit. > > --Richard If I'm totally missing the point (not having attended the event mentioned), please disregard what I have to say. I think that there is a value to having an encrypted connection, even if it does not combine with it authentication from both ends, as this would, at the very least, prevent snooping of the communications between the two end points. This would be the equivalent of using a self-signed certificate for HTTPS, without the drama of the certificate warnings we get in browsers. What I mean is, we can make the higher degree of security be one that combines authentication with encryption, but always-on encryption can be the default, and this is what I meant by saying it still has value. At least a 3rd-party would not be able to spy on communications between two people and the connection has a minimum degree of privacy to it. Combined with a trusted method of establishing authentication, whether via a central authority (e.g., current CA's) or allowing users to exchanged keys via other channels (e.g., PGP chain of trust style), then a fully trustworthy and private method of communications can be established. I hope the two degrees I am pointing out are clear. From abu_hurayrah@hidayahonline.org Wed Mar 28 07:55:12 2012 Return-Path: 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 4400621F87D0 for ; Wed, 28 Mar 2012 07:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] 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 AutPWbKP3nwb for ; Wed, 28 Mar 2012 07:55:11 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id D8BB021F87B2 for ; Wed, 28 Mar 2012 07:55:08 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 651CF6524A1 for ; Wed, 28 Mar 2012 10:55:08 -0400 (EDT) Message-ID: <4F732649.5010705@hidayahonline.org> Date: Wed, 28 Mar 2012 10:55:05 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F732531.2030208@ericsson.com> In-Reply-To: <4F732531.2030208@ericsson.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=5AF4B362 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:55:12 -0000 On 03/28/2012 10:50 AM, Magnus Westerlund wrote: > WG, > > In todays RTCWEB WG meeting there was discussion around media security > mechanism. In this meeting there was some clear consensus in the > meeting which we would like to confirm on the list. > > The first was that there was overwhelming consensus that all RTP > packets SHALL be protected by SRTP. > > Secondly that no one objected against making DTLS-SRTP a mandatory to > implement and the default keying mechanism. Additional mechanisms are > not precluded. > > WG participants may state their position regarding these consensus calls > until 12th of April when the chairs will declare the final consensus. If > you where present in the meeting room and comment on this, please > indicate that. > > Best Regards > > Magnus Westerlund > For the WG chairs I already brought-up my concerns in the other thread, so I'll summarize the core point I was making here. Would using SRTP *require* a central authority for establishing authenticity, or can authenticity be established via a point-to-point means (e.g., how it's traditionally done via SSH [i.e., upon first connection or via previous key exchange])? This is about degrees of trust that the user is will to place upon various methods, of course. I am stating that the option should exist for authenticity of an end point to be established outside of a central authority (e.g., key exchange via other means). From ekr@rtfm.com Wed Mar 28 08:14:35 2012 Return-Path: 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 2DAA321E8228 for ; Wed, 28 Mar 2012 08:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 krERRP+3HxTv for ; Wed, 28 Mar 2012 08:14:34 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3495721E81AD for ; Wed, 28 Mar 2012 08:14:34 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so893663vbb.31 for ; Wed, 28 Mar 2012 08:14:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=76TRW5pIXoOglKfKLO567/BICkt6jwbXZJQuWphqNZg=; b=OCzFXPWK/7Da6yBlFxZB/O/fLHX9Cd0Yje1oqgt+FA7gPl8oeAVSCpzkO0osGKxHw0 FwRWMGurWSadkbpINadeg1VgY3zzR2uAn1SOJEmocnysE9JLoJshyRLYLx47Rl1B3XLy H57gCQ4Osl4LGRlqWkcWHWZ7I1OfdaeBSstGCYIm9r4oIuCzAtDEf3B6t87ukCEFGYKV MD2I6FE/U42f1SERbjmRd5g0of+lBOQzXfP4BnpD+c+7jxXN2DD3VJGkSpVotQaXBk7M ydwosaZuUHHatD0TMtoKf8YRt+3q5u4PB727gdyxGDjJTCavj82aaIr+oCsp5FrzT1BV b6aA== Received: by 10.52.69.100 with SMTP id d4mr12425841vdu.9.1332947673557; Wed, 28 Mar 2012 08:14:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Wed, 28 Mar 2012 08:13:53 -0700 (PDT) X-Originating-IP: [2001:df8:0:80:5a55:caff:fef1:5a11] In-Reply-To: <4F732649.5010705@hidayahonline.org> References: <4F732531.2030208@ericsson.com> <4F732649.5010705@hidayahonline.org> From: Eric Rescorla Date: Wed, 28 Mar 2012 17:13:53 +0200 Message-ID: To: Basil Mohamed Gohar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnYUsvKcp0Xrfk4YVjmN59ZIsTMRrAM8/f4KsxQBCKAUn7kHeYeSAeZZB3oxugc4SRLTBkb Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 15:14:35 -0000 On Wed, Mar 28, 2012 at 4:55 PM, Basil Mohamed Gohar wrote: > On 03/28/2012 10:50 AM, Magnus Westerlund wrote: >> WG, >> >> In todays RTCWEB WG meeting there was discussion around media security >> mechanism. In this meeting there was some clear consensus in the >> meeting which we would like to confirm on the list. >> >> The first was that there was overwhelming consensus that all RTP >> packets SHALL be protected by SRTP. >> >> Secondly that no one objected against making DTLS-SRTP a mandatory to >> implement and the default keying mechanism. Additional mechanisms are >> not precluded. >> >> WG participants may state their position regarding these consensus calls >> until 12th of April when the chairs will declare the final consensus. If >> you where present in the meeting room and comment on this, please >> indicate that. >> >> Best Regards >> >> Magnus Westerlund >> For the WG chairs > I already brought-up my concerns in the other thread, so I'll summarize > the core point I was making here. =A0Would using SRTP *require* a central > authority for establishing authenticity, or can authenticity be > established via a point-to-point means (e.g., how it's traditionally > done via SSH [i.e., upon first connection or via previous key exchange])? > > This is about degrees of trust that the user is will to place upon > various methods, of course. =A0I am stating that the option should exist > for authenticity of an end point to be established outside of a central > authority (e.g., key exchange via other means). This will still be possible. I agree that it's very important in some applications. -Ekr From roman@telurix.com Wed Mar 28 08:49:26 2012 Return-Path: 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 2ECAC21E80BD for ; Wed, 28 Mar 2012 08:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 WL5Njuc7wFvl for ; Wed, 28 Mar 2012 08:49:25 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6932821E80B8 for ; Wed, 28 Mar 2012 08:49:25 -0700 (PDT) Received: by yhkk25 with SMTP id k25so891384yhk.31 for ; Wed, 28 Mar 2012 08:49:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=IQFkHG9g9jVhUg6G4ZAOB2YothaTSpEsIdBBTOUkf2M=; b=Ada/DqczjwFwyVACXeKoJPmT1jzsFwMF8pf+MPsErqzxs+yXrA56SVFZnI3O4t33AF J6Xj7GGgRPCZalHAOw5oBTETjJ8GbxeQY8wBTh2OeY4dz0SZNG9wT1g+WJi3nP8R/Tfv 5J0KRlJeB9e+s+JA6O+RgUJmIx7FGLIr199Y4EtwjglEWQOz7gItfy1Qa5iVUu6bktKM PHc0X3oGLALncXdpVb64Rgnzquo0oes7Ja97+roUguIqPS0s1wlk6ZuwxKmXt29c6q0+ BnAp+985VYJPdusNV6bk6x7KLzpk7dP3P+4BboueZXDcg5J2VMANDWNrgZ5MQe4QSaQE y/0g== Received: by 10.236.165.34 with SMTP id d22mr30160608yhl.107.1332949764976; Wed, 28 Mar 2012 08:49:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id r9sm4346661anl.0.2012.03.28.08.49.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 08:49:24 -0700 (PDT) Received: by ggmi1 with SMTP id i1so909588ggm.31 for ; Wed, 28 Mar 2012 08:49:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.240.6 with SMTP id vw6mr15912361pbc.76.1332949762934; Wed, 28 Mar 2012 08:49:22 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Wed, 28 Mar 2012 08:49:22 -0700 (PDT) In-Reply-To: <4F732531.2030208@ericsson.com> References: <4F732531.2030208@ericsson.com> Date: Wed, 28 Mar 2012 11:49:22 -0400 Message-ID: From: Roman Shpount To: Magnus Westerlund Content-Type: multipart/alternative; boundary=047d7b3395a11f86ed04bc4f8d3c X-Gm-Message-State: ALoCoQmu9GfAud/PjdbipC7YGhT+/jMYps3hyPJgzl43L1zBPXnCKujNgDQwvF3B40L3EjAXYARR Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 15:49:26 -0000 --047d7b3395a11f86ed04bc4f8d3c Content-Type: text/plain; charset=ISO-8859-1 As I have mentioned before on this list I am strongly against making SRTP protection for RTP a requirement. I think this is an unnecessary requirement that serves little real purpose except feeding into some marketing message that most of the WebRTC users would not care about. Unless use of identity is also a requirement, requiring SRTP will provide security only in a very narrow sense of the word. At the same time I do believe that extra standard requirements will stifle innovation and will complicate new service or application creation. I have no objection to making DTLS-SRTP a required to implement protocol. _____________ Roman Shpount On Wed, Mar 28, 2012 at 10:50 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > WG, > > In todays RTCWEB WG meeting there was discussion around media security > mechanism. In this meeting there was some clear consensus in the > meeting which we would like to confirm on the list. > > The first was that there was overwhelming consensus that all RTP > packets SHALL be protected by SRTP. > > Secondly that no one objected against making DTLS-SRTP a mandatory to > implement and the default keying mechanism. Additional mechanisms are > not precluded. > > WG participants may state their position regarding these consensus calls > until 12th of April when the chairs will declare the final consensus. If > you where present in the meeting room and comment on this, please > indicate that. > > Best Regards > > Magnus Westerlund > For the WG chairs > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b3395a11f86ed04bc4f8d3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As I have mentioned before on this list I am strongly against making SRTP p= rotection for RTP a requirement. I think this is an unnecessary requirement= that serves little real purpose except feeding into some marketing message= that most of the WebRTC users would not care about. Unless use of identity= is also a requirement, requiring SRTP will provide security only in a very= narrow sense of the word. At the same time I do believe that extra standar= d requirements will stifle innovation and=A0 will complicate new service or= application creation.

I have no objection to making DTLS-SRTP a required to implement protoco= l.
_____________
Roman Shpount


On Wed, Mar 28, 2012 at 10:50 AM, Magnus= Westerlund <magnus.westerlund@ericsson.com> wrote:
WG,

In todays RTCWEB WG meeting there was discussion around media security
mechanism. In this meeting there was some clear consensus in the
meeting which we would like to confirm on the list.

The first was that there was overwhelming consensus that all RTP
packets SHALL be protected by SRTP.

Secondly that no one objected against making DTLS-SRTP a mandatory to
implement and the default keying mechanism. Additional mechanisms are
not precluded.

WG participants may state their position regarding these consensus calls until 12th of April when the chairs will declare the final consensus. If you where present in the meeting room and comment on this, please
indicate that.

Best Regards

Magnus Westerlund
For the WG chairs

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

--047d7b3395a11f86ed04bc4f8d3c-- From igor.faynberg@alcatel-lucent.com Wed Mar 28 08:56:05 2012 Return-Path: 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 9B6CE21E82CA for ; Wed, 28 Mar 2012 08:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.341 X-Spam-Level: X-Spam-Status: No, score=-9.341 tagged_above=-999 required=5 tests=[AWL=1.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 EiM2fsOa3j0s for ; Wed, 28 Mar 2012 08:56:04 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A3AD521E82C8 for ; Wed, 28 Mar 2012 08:56:04 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q2SFu3L1018422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 28 Mar 2012 10:56:04 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2SFu3lE026240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 28 Mar 2012 10:56:03 -0500 Received: from [135.244.27.182] (faynberg.lra.lucent.com [135.244.27.182]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2SFu2Jk001170; Wed, 28 Mar 2012 10:56:02 -0500 (CDT) Message-ID: <4F733492.9040601@alcatel-lucent.com> Date: Wed, 28 Mar 2012 11:56:02 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F732531.2030208@ericsson.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000406000806040000090208" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 15:56:05 -0000 This is a multi-part message in MIME format. --------------000406000806040000090208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Roman, I think there is a misunderstanding (I assume you did not attend the meeting today). It has been clarified that SRTP allows the NULL encryption algorithm, and that this option will be available. Igor On 3/28/2012 11:49 AM, Roman Shpount wrote: > As I have mentioned before on this list I am strongly against making > SRTP protection for RTP a requirement. I think this is an unnecessary > requirement that serves little real purpose except feeding into some > marketing message that most of the WebRTC users would not care about. > Unless use of identity is also a requirement, requiring SRTP will > provide security only in a very narrow sense of the word. At the same > time I do believe that extra standard requirements will stifle > innovation and will complicate new service or application creation. > > I have no objection to making DTLS-SRTP a required to implement protocol. > _____________ > Roman Shpount > > > On Wed, Mar 28, 2012 at 10:50 AM, Magnus Westerlund > > wrote: > > WG, > > In todays RTCWEB WG meeting there was discussion around media security > mechanism. In this meeting there was some clear consensus in the > meeting which we would like to confirm on the list. > > The first was that there was overwhelming consensus that all RTP > packets SHALL be protected by SRTP. > > Secondly that no one objected against making DTLS-SRTP a mandatory to > implement and the default keying mechanism. Additional mechanisms are > not precluded. > > WG participants may state their position regarding these consensus > calls > until 12th of April when the chairs will declare the final > consensus. If > you where present in the meeting room and comment on this, please > indicate that. > > Best Regards > > Magnus Westerlund > For the WG 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 --------------000406000806040000090208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Roman,

I think there is a misunderstanding (I assume you did not attend the meeting today).  It has been clarified that SRTP allows the NULL encryption algorithm, and that this option will be available.

Igor

On 3/28/2012 11:49 AM, Roman Shpount wrote:
As I have mentioned before on this list I am strongly against making SRTP protection for RTP a requirement. I think this is an unnecessary requirement that serves little real purpose except feeding into some marketing message that most of the WebRTC users would not care about. Unless use of identity is also a requirement, requiring SRTP will provide security only in a very narrow sense of the word. At the same time I do believe that extra standard requirements will stifle innovation and  will complicate new service or application creation.

I have no objection to making DTLS-SRTP a required to implement protocol.
_____________
Roman Shpount


On Wed, Mar 28, 2012 at 10:50 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
WG,

In todays RTCWEB WG meeting there was discussion around media security
mechanism. In this meeting there was some clear consensus in the
meeting which we would like to confirm on the list.

The first was that there was overwhelming consensus that all RTP
packets SHALL be protected by SRTP.

Secondly that no one objected against making DTLS-SRTP a mandatory to
implement and the default keying mechanism. Additional mechanisms are
not precluded.

WG participants may state their position regarding these consensus calls
until 12th of April when the chairs will declare the final consensus. If
you where present in the meeting room and comment on this, please
indicate that.

Best Regards

Magnus Westerlund
For the WG 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
--------------000406000806040000090208-- From HKaplan@acmepacket.com Wed Mar 28 09:06:47 2012 Return-Path: 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 AA59F21E827D for ; Wed, 28 Mar 2012 09:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.107, 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 t-hbH3eBuymv for ; Wed, 28 Mar 2012 09:06:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B68A221E826C for ; Wed, 28 Mar 2012 09:06:46 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 28 Mar 2012 12:06:45 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Wed, 28 Mar 2012 12:06:45 -0400 From: Hadriel Kaplan To: "" Thread-Topic: [rtcweb] Consensus call regarding media security Thread-Index: AQHNDPzFhnzzZTqOnkq4McxXkUzHHA== Date: Wed, 28 Mar 2012 16:06:44 +0000 Message-ID: <91F0E66E-A75E-4369-A010-9712FF90258D@acmepacket.com> References: <4F732531.2030208@ericsson.com> <4F733492.9040601@alcatel-lucent.com> In-Reply-To: <4F733492.9040601@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: multipart/alternative; boundary="_000_91F0E66EA75E4369A0109712FF90258Dacmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:06:47 -0000 --_000_91F0E66EA75E4369A0109712FF90258Dacmepacketcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Actually, I was confused about that - it seems to me it's still an open ite= m whether to allow null cipher or not. -hadriel On Mar 28, 2012, at 5:56 PM, Igor Faynberg wrote: Roman, I think there is a misunderstanding (I assume you did not attend the meetin= g today). It has been clarified that SRTP allows the NULL encryption algor= ithm, and that this option will be available. Igor On 3/28/2012 11:49 AM, Roman Shpount wrote: As I have mentioned before on this list I am strongly against making SRTP p= rotection for RTP a requirement. I think this is an unnecessary requirement= that serves little real purpose except feeding into some marketing message= that most of the WebRTC users would not care about. Unless use of identity= is also a requirement, requiring SRTP will provide security only in a very= narrow sense of the word. At the same time I do believe that extra standar= d requirements will stifle innovation and will complicate new service or a= pplication creation. I have no objection to making DTLS-SRTP a required to implement protocol. _____________ Roman Shpount On Wed, Mar 28, 2012 at 10:50 AM, Magnus Westerlund > wrote: WG, In todays RTCWEB WG meeting there was discussion around media security mechanism. In this meeting there was some clear consensus in the meeting which we would like to confirm on the list. The first was that there was overwhelming consensus that all RTP packets SHALL be protected by SRTP. Secondly that no one objected against making DTLS-SRTP a mandatory to implement and the default keying mechanism. Additional mechanisms are not precluded. WG participants may state their position regarding these consensus calls until 12th of April when the chairs will declare the final consensus. If you where present in the meeting room and comment on this, please indicate that. Best Regards Magnus Westerlund For the WG 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 --_000_91F0E66EA75E4369A0109712FF90258Dacmepacketcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Actually, I was confused about that - it seems to me it's still an ope= n item whether to allow null cipher or not.

-hadriel


On Mar 28, 2012, at 5:56 PM, Igor Faynberg wrote:

Roman,

I think there is a misunderstanding (I assume you did not attend the meetin= g today).  It has been clarified that SRTP allows the NULL encryption = algorithm, and that this option will be available.

Igor

On 3/28/2012 11:49 AM, Roman Shpount wrote:
As I have mentioned before on this list I am strongly against making SRTP p= rotection for RTP a requirement. I think this is an unnecessary requirement= that serves little real purpose except feeding into some marketing message= that most of the WebRTC users would not care about. Unless use of identity is also a requirement, requiring SR= TP will provide security only in a very narrow sense of the word. At the sa= me time I do believe that extra standard requirements will stifle innovatio= n and  will complicate new service or application creation.

I have no objection to making DTLS-SRTP a required to implement protocol. _____________
Roman Shpount


On Wed, Mar 28, 2012 at 10:50 AM, Magnus Westerl= und <magnus.westerlund@ericsson.com> wrote:
WG,

In todays RTCWEB WG meeting there was discussion around media security
mechanism. In this meeting there was some clear consensus in the
meeting which we would like to confirm on the list.

The first was that there was overwhelming consensus that all RTP
packets SHALL be protected by SRTP.

Secondly that no one objected against making DTLS-SRTP a mandatory to
implement and the default keying mechanism. Additional mechanisms are
not precluded.

WG participants may state their position regarding these consensus calls until 12th of April when the chairs will declare the final consensus. If you where present in the meeting room and comment on this, please
indicate that.

Best Regards

Magnus Westerlund
For the WG chairs

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


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

--_000_91F0E66EA75E4369A0109712FF90258Dacmepacketcom_-- From kpfleming@digium.com Wed Mar 28 09:10:40 2012 Return-Path: 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 B2ED621E82CA for ; Wed, 28 Mar 2012 09:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 DgYn+WKJUj0G for ; Wed, 28 Mar 2012 09:10:40 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id DE8F221E808F for ; Wed, 28 Mar 2012 09:10:39 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SCvSJ-0004Gm-En for rtcweb@ietf.org; Wed, 28 Mar 2012 11:10:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 6B70DD8017 for ; Wed, 28 Mar 2012 11:10:39 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnVy-soKo-Fr for ; Wed, 28 Mar 2012 11:10:38 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id E1990D8002 for ; Wed, 28 Mar 2012 11:10:38 -0500 (CDT) Message-ID: <4F7337FE.3030007@digium.com> Date: Wed, 28 Mar 2012 11:10:38 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F732531.2030208@ericsson.com> <4F733492.9040601@alcatel-lucent.com> In-Reply-To: <4F733492.9040601@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:10:40 -0000 On 03/28/2012 10:56 AM, Igor Faynberg wrote: > I think there is a misunderstanding (I assume you did not attend the > meeting today). It has been clarified that SRTP allows the NULL > encryption algorithm, and that this option will be available. The cipher algorithms are not the issue, and in many cases, neither is the CPU consumption required to do the encryption/decryption. I believe the larger concern that has been expressed is making WebRTC media dependent on DTLS-SRTP (the protocol) itself, since it is still relatively immature deployment-wise, and there are not many implementations available for developers to use to build products. As an example, if the WG had chosen SDES-SRTP instead (even though it has its own set of faults), this concern would not be present, because that is already widely deployed, well understood and there are proven implementations available to choose from. I'm not in any way lobbying against DTLS-SRTP being a MUST, though: I support that position. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From lists@infosecurity.ch Wed Mar 28 09:12:18 2012 Return-Path: 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 D689B21F898A for ; Wed, 28 Mar 2012 09:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] 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 nsh4LPfmCQO7 for ; Wed, 28 Mar 2012 09:12:17 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4AA21F85A7 for ; Wed, 28 Mar 2012 09:12:16 -0700 (PDT) Received: by eeke51 with SMTP id e51so406349eek.31 for ; Wed, 28 Mar 2012 09:12:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=jWxHbCDNqXLNptRPPUoiIMZ67h2+p/3YQum1F4i7Urk=; b=GrHZRnKGL8Jhxf4t8Nfm/2QAi7pDmgcn0NpfHlMjAaq1eL9TKkd+UPkxn7OLxO/olx ES1+tWi7wAOwz+kEQ0kS0zCDIv2xzT49FPUNliODuc/cHaSdqsnEKZLd+xpyFKPJKl9A GywpLHI6HnuUOKU3lPHSOGRgRpeaD+aEbpzPSeUfBtqWsB4aTH4/morV4CZTTQhP4RtR BSDpi3oaCbyl8gulHmwBRzEU8glbnb1qaVUOQB4mj99V2fIKrigR97URFhLGub9MOjQM oIRIWWHhWuojZqZWwEHSlyPo2jyMYysiasgckvyIVDJrYAAbfVWEgdTfwZbu46p4bJYy W6+A== Received: by 10.14.37.12 with SMTP id x12mr3997584eea.78.1332951135638; Wed, 28 Mar 2012 09:12:15 -0700 (PDT) Received: from sonyvaiop13.local (host30-198-static.115-2-b.business.telecomitalia.it. [2.115.198.30]) by mx.google.com with ESMTPS id e56sm11993840eea.11.2012.03.28.09.12.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 09:12:14 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F733853.7040900@infosecurity.ch> Date: Wed, 28 Mar 2012 18:12:03 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "" References: <4F732531.2030208@ericsson.com> <4F733492.9040601@alcatel-lucent.com> In-Reply-To: <4F733492.9040601@alcatel-lucent.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQncEQbdpnMIT/za2FbjdmCSihW4KqUL2nIxlhQ+96FuSjgNBTCdrzJjzrVzvX1ur37ZKOLZ Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:12:18 -0000 I agree with Igor and Magnus, it's better to have "Security by Default" in place, and then leave to the open options for: - Key Agreement - Encryption algorithms Interesting consideration on RTP encryption by default: Why RTP Does Not Mandate a Single Security Mechanism http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08 Also a must read, while designing IETF widely spread protocols: Strong Security Requirements for Internet Engineering Task Force Standard Protocols http://tools.ietf.org/html/rfc3365 It's up the Telecommunication Regulators, Telecommunication Providers, Telecommunication Equipment Manufacturer and Security Monitoring equipment to handle the rules for Lawful interception, where an agency have the rights to listen to a conversation. But this is "a particular case" for which, even when there is encryption-by-default, it's possible to listen/record the conversation. Please remind that today there are multiple asymmetric cyberwar in action and is an irresponsible action to even think not to include security-by-default in any new protocol. It's ok not to over-complicate the first version of the standard by introducing dozen of different key management systems (SDES/ZRTP/MIKEY), but imho it's not ok to leave in 2012 the standardizaton of a non-encrypted-by-default protocol. Again, imho it's an act of irresponsibility, what's defined in IETF environment, have chance to get adopted by *billions* of people. We must act responsibly. -- Fabio Pietrosanti Founder, CTO Tel: +39 02 911930893 + ext: 907 Mobile: +39 340 1801049 E-mail: fabio.pietrosanti@privatewave.com Skype: fpietrosanti Linkedin: http://linkedin.com/in/secret PrivateWave Italia S.p.A. Via Gaetano Giardino 1 - 20123 Milano - Italy www.privatewave.com On 3/28/12 5:56 PM, Igor Faynberg wrote: > Roman, > > I think there is a misunderstanding (I assume you did not attend the > meeting today). It has been clarified that SRTP allows the NULL > encryption algorithm, and that this option will be available. > > Igor From roman@telurix.com Wed Mar 28 09:15:17 2012 Return-Path: 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 45CD921E8260 for ; Wed, 28 Mar 2012 09:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.822 X-Spam-Level: X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 VtOsqreFxLxG for ; Wed, 28 Mar 2012 09:15:16 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 391E821E808F for ; Wed, 28 Mar 2012 09:15:16 -0700 (PDT) Received: by ggmi1 with SMTP id i1so938471ggm.31 for ; Wed, 28 Mar 2012 09:15:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=chqJF1Fcgygx0fFeJjeow14oO7XpZiP6uf0N1Q3jS5g=; b=L8f4HTxO4lRNoYaK/HVGTKhNzFLPg8+NRXMd9MEaJptmee1ke0U/eSl/ggJWTaQhFl jm1uZYkikESUAI+BbvN8KgJWrncC/JFFYKBnFh16JPT7VpKM6kWEwiHw2FNOaqNLXIj/ oDtZppJEHc6Nvkp1pUYBMnzpHPsjI3KHaEHtgendXxL7LjgwPkpwWzqFQoyEHExWuup3 m/fx3uk2jaU/v7aVq0THiEqJzKx1x50FwKme2rEZVuMJp9Oxjp9VfbzIDGnMOqpqBRnz ImdMhzewckqvULZwNr3HCmLUlb1SdLYr7ZgBr/ah62l0JkAA6WW6xPfqkrupK4rAjB/i O+Cg== Received: by 10.236.145.34 with SMTP id o22mr1743215yhj.7.1332951315828; Wed, 28 Mar 2012 09:15:15 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by mx.google.com with ESMTPS id t43sm9025479yht.11.2012.03.28.09.15.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 09:15:15 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so978081vcb.31 for ; Wed, 28 Mar 2012 09:15:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.58.197 with SMTP id i5mr7809964vch.38.1332951310413; Wed, 28 Mar 2012 09:15:10 -0700 (PDT) Received: by 10.220.192.195 with HTTP; Wed, 28 Mar 2012 09:15:10 -0700 (PDT) In-Reply-To: <4F733492.9040601@alcatel-lucent.com> References: <4F732531.2030208@ericsson.com> <4F733492.9040601@alcatel-lucent.com> Date: Wed, 28 Mar 2012 12:15:10 -0400 Message-ID: From: Roman Shpount To: igor.faynberg@alcatel-lucent.com Content-Type: multipart/alternative; boundary=0023544477cd5c31a904bc4fe9c0 X-Gm-Message-State: ALoCoQkHfJN8dTuQY6xShSO/BN3eBueb2uH32zJiLA5nOhWxxHnnopkIp76n7sWU/43lRs1ZaHIc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:15:17 -0000 --0023544477cd5c31a904bc4fe9c0 Content-Type: text/plain; charset=ISO-8859-1 Igor, I could not attend the meeting today, but I am responding to the call of consent on the list, that did not mention that or any other conditions on SRTP encryption support. Does it also mean that the call can be established using plain RTP, or is DTLS handshake, even in order to setup NULL encruption, is still a requirement? If DTLS handshake is a requirement, I still would object to it, since this will require an extra implementation and interop step in anything communicating with WebRTC. On the related note, where is SRTP profile with NULL encoding defined? I have seen quite a few SRTP implementations but not a single one of them supported NULL codec in any of its profiles. Also, we should be very careful not to support NULL encoding unless it is specifically enabled in API. Even though I do want to support unencrypted media, I do not want anything that allows to bid down from encrypted to unencrypted connection, for instance during DTLS negotiation, unless specifically enabled. _____________ Roman Shpount On Wed, Mar 28, 2012 at 11:56 AM, Igor Faynberg < igor.faynberg@alcatel-lucent.com> wrote: > ** > Roman, > > I think there is a misunderstanding (I assume you did not attend the > meeting today). It has been clarified that SRTP allows the NULL encryption > algorithm, and that this option will be available. > > Igor > > > On 3/28/2012 11:49 AM, Roman Shpount wrote: > > As I have mentioned before on this list I am strongly against making SRTP > protection for RTP a requirement. I think this is an unnecessary > requirement that serves little real purpose except feeding into some > marketing message that most of the WebRTC users would not care about. > Unless use of identity is also a requirement, requiring SRTP will provide > security only in a very narrow sense of the word. At the same time I do > believe that extra standard requirements will stifle innovation and will > complicate new service or application creation. > > I have no objection to making DTLS-SRTP a required to implement protocol. > _____________ > Roman Shpount > > > On Wed, Mar 28, 2012 at 10:50 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> WG, >> >> In todays RTCWEB WG meeting there was discussion around media security >> mechanism. In this meeting there was some clear consensus in the >> meeting which we would like to confirm on the list. >> >> The first was that there was overwhelming consensus that all RTP >> packets SHALL be protected by SRTP. >> >> Secondly that no one objected against making DTLS-SRTP a mandatory to >> implement and the default keying mechanism. Additional mechanisms are >> not precluded. >> >> WG participants may state their position regarding these consensus calls >> until 12th of April when the chairs will declare the final consensus. If >> you where present in the meeting room and comment on this, please >> indicate that. >> >> Best Regards >> >> Magnus Westerlund >> For the WG chairs >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --0023544477cd5c31a904bc4fe9c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Igor,

I could not attend the meeting today, but I am responding to t= he call of consent on the list, that did not mention that or any other cond= itions on SRTP encryption support. Does it also mean that the call can be e= stablished using plain RTP, or is DTLS handshake, even in order to setup NU= LL encruption, is still a requirement? If DTLS handshake is a requirement, = I still would object to it, since this will require an extra implementation= and interop step in anything communicating with WebRTC.

On the related note, where is SRTP profile with NULL encoding defined? = I have seen quite a few SRTP implementations but not a single one of them s= upported NULL codec in any of its profiles.=A0 Also, we should be very care= ful not to support NULL encoding unless it is specifically enabled in API. = Even though I do want to support unencrypted media, I do not want anything = that allows to bid down from encrypted to unencrypted connection, for insta= nce during DTLS negotiation, unless specifically enabled.
_____________
Roman Shpount


On Wed, Mar 28, 2012 at 11:56 AM, Igor F= aynberg <igor.faynberg@alcatel-lucent.com> wrote:
=20 =20 =20
Roman,

I think there is a misunderstanding (I assume you did not attend the meeting today).=A0 It has been clarified that SRTP allows the NULL encryption algorithm, and that this option will be available.

Igor


On 3/28/2012 11:49 AM, Roman Shpount wrote:
As I have mentioned before on this list I am = strongly against making SRTP protection for RTP a requirement. I think this is an unnecessary requirement that serves little real purpose except feeding into some marketing message that most of the WebRTC users would not care about. Unless use of identity is also a requirement, requiring SRTP will provide security only in a very narrow sense of the word. At the same time I do believe that extra standard requirements will stifle innovation and=A0 will complicate new service or application creation.

I have no objection to making DTLS-SRTP a required to implement protocol.
_____________
Roman Shpount


On Wed, Mar 28, 2012 at 10:50 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
WG,

In todays RTCWEB WG meeting there was discussion around media security
mechanism. In this meeting there was some clear consensus in the
meeting which we would like to confirm on the list.

The first was that there was overwhelming consensus that all RTP
packets SHALL be protected by SRTP.

Secondly that no one objected against making DTLS-SRTP a mandatory to
implement and the default keying mechanism. Additional mechanisms are
not precluded.

WG participants may state their position regarding these consensus calls
until 12th of April when the chairs will declare the final consensus. If
you where present in the meeting room and comment on this, please
indicate that.

Best Regards

Magnus Westerlund
For the WG 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


--0023544477cd5c31a904bc4fe9c0-- From lists@infosecurity.ch Wed Mar 28 09:17:44 2012 Return-Path: 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 AFAC021F8818 for ; Wed, 28 Mar 2012 09:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] 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 wiezuRNHnsWM for ; Wed, 28 Mar 2012 09:17:44 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id CCA0121F8677 for ; Wed, 28 Mar 2012 09:17:36 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so5384897wib.13 for ; Wed, 28 Mar 2012 09:17:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=ChLb5uvmeLBNnd2GtUvvoM1f1nsAXxQuhXbCop2eCrU=; b=pcLqLR22wkcI7ix/GOBiAaRpVRBgEQGTYx7NGLhumudxELjil7/so59w7HLrJBYxZz ZP7ApcRoNWXWGka6vnX38PTUmiJOh02fVN1WvDeMAmAQYibfh5SDqqmghSr3TI+aWOZd qEigCp83xwtBxi3IT/OKiQwME4ZPLfRWXahtXU5Yco8tzkpJOwiLnvFGIhmWQPSQoXJ4 heVpkPWERJZN9Yvqg+ANXhdbtgbTG/Gh8dL4Ah1m9Memf3Y2THk90LO7SsgXHjLSJP3R 1O0VA5v/vdTpuxI8NbJWxulsJN2+ySOsKVteYSx2vlhn5xo5byFYL3w7Uh+ynNrDDlef 6kvA== Received: by 10.180.104.230 with SMTP id gh6mr8338817wib.22.1332951456044; Wed, 28 Mar 2012 09:17:36 -0700 (PDT) Received: from sonyvaiop13.local (host30-198-static.115-2-b.business.telecomitalia.it. [2.115.198.30]) by mx.google.com with ESMTPS id k6sm59002762wie.9.2012.03.28.09.17.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 09:17:34 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F733999.10707@infosecurity.ch> Date: Wed, 28 Mar 2012 18:17:29 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "" References: <4F732531.2030208@ericsson.com> <4F733492.9040601@alcatel-lucent.com> <4F7337FE.3030007@digium.com> In-Reply-To: <4F7337FE.3030007@digium.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkE34aBX3js38MpXlWKpwqL53pl6z+b41hucKAriWziSVdK8J82+rS11fyhRVdBhZaPr7a2 Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:17:44 -0000 On 3/28/12 6:10 PM, Kevin P. Fleming wrote: > As an example, if the WG had chosen SDES-SRTP instead (even though it > has its own set of faults), this concern would not be present, because > that is already widely deployed, well understood and there are proven > implementations available to choose from. > > I'm not in any way lobbying against DTLS-SRTP being a MUST, though: I > support that position. That's true, if you consider that even the US National Security Agency approved for Classified/Top-Secret use the SDES-SRTP schema http://www.nsa.gov/ia/programs/mobility_program/index.shtml . The reason, underlined by NSA for adoption, is that is a mature, secure and widely diffused internet security protocol. -- Fabio Pietrosanti Founder, CTO Tel: +39 02 911930893 + ext: 907 Mobile: +39 340 1801049 E-mail: fabio.pietrosanti@privatewave.com Skype: fpietrosanti Linkedin: http://linkedin.com/in/secret PrivateWave Italia S.p.A. Via Gaetano Giardino 1 - 20123 Milano - Italy www.privatewave.com From HKaplan@acmepacket.com Wed Mar 28 09:36:00 2012 Return-Path: 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 B889721E81E7 for ; Wed, 28 Mar 2012 09:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] 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 I2UCvQ3A9Paw for ; Wed, 28 Mar 2012 09:36:00 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2879B21E8191 for ; Wed, 28 Mar 2012 09:36:00 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 28 Mar 2012 12:35:59 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Wed, 28 Mar 2012 12:35:59 -0400 From: Hadriel Kaplan To: Roman Shpount Thread-Topic: [rtcweb] Consensus call regarding media security Thread-Index: AQHNDQDaQ/5LBlCzwkGMs4wK+RhBMQ== Date: Wed, 28 Mar 2012 16:35:58 +0000 Message-ID: <7DDA6692-2CA2-414A-B592-ED73E440AB08@acmepacket.com> References: <4F732531.2030208@ericsson.com> <4F733492.9040601@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <435C0EEB3F1F164B95A7DFF7AFD3308A@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:36:00 -0000 On Mar 28, 2012, at 6:15 PM, Roman Shpount wrote: > On the related note, where is SRTP profile with NULL encoding defined? I = have seen quite a few SRTP implementations but not a single one of them sup= ported NULL codec in any of its profiles. =20 The RFC for SRTP itself included NULL cipher mode - see RFC 3711. Note that it is even mandatory to implement, but not mandatory to use - so = we can specify in RTCWeb it MUST NOT be used, I believe. -hadriel From roman@telurix.com Wed Mar 28 09:42:53 2012 Return-Path: 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 866EA21E80F3 for ; Wed, 28 Mar 2012 09:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.824 X-Spam-Level: X-Spam-Status: No, score=-2.824 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 hndOxBWfmO1N for ; Wed, 28 Mar 2012 09:42:53 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D008F21E80D5 for ; Wed, 28 Mar 2012 09:42:52 -0700 (PDT) Received: by ghbg16 with SMTP id g16so978756ghb.31 for ; Wed, 28 Mar 2012 09:42:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=QJTkmB7M6NSb88KJ+2CkkwCNLLb2YJNv0gj6tx54xyw=; b=XmFqkW3bRFNmu2TybEXOcROWeHpvLBj3pyJyOjr+xpTqkSof++WFcRohPiXY4+2FYC DCpu2u6kI/Hg4aQeVg7JUFN/6AciLWw9O14aaLJm4WIlXlJ8JtKMHqTFDJrVVqtkX5Nd NYQ7BScUOpF5pjUd6sNxNF9GMKwskqID0DqgdA4Te6PPvOjXDhYhyAoVu+gnCveT5jdf /ulurpl9kQdKOgYSNAQ/zf4g+8vhPWOgiJIYbJTzmJ8UFb80DcCATugu6+FATlhRvqyN Vl+tdjkxgtvusgqlQDo0wcod2yQ/Qiv8B7gvYbJAGBiGri8tUV2SDFxlEIxOqha3rYii +HTw== Received: by 10.236.73.195 with SMTP id v43mr4835975yhd.78.1332952972443; Wed, 28 Mar 2012 09:42:52 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by mx.google.com with ESMTPS id g49sm9150010yhk.20.2012.03.28.09.42.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 09:42:51 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so973444vbb.31 for ; Wed, 28 Mar 2012 09:42:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.90.178 with SMTP id bx18mr11824856vdb.123.1332952971261; Wed, 28 Mar 2012 09:42:51 -0700 (PDT) Received: by 10.220.192.195 with HTTP; Wed, 28 Mar 2012 09:42:51 -0700 (PDT) In-Reply-To: <7DDA6692-2CA2-414A-B592-ED73E440AB08@acmepacket.com> References: <4F732531.2030208@ericsson.com> <4F733492.9040601@alcatel-lucent.com> <7DDA6692-2CA2-414A-B592-ED73E440AB08@acmepacket.com> Date: Wed, 28 Mar 2012 12:42:51 -0400 Message-ID: From: Roman Shpount To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=20cf3071cffa5ab77104bc504c43 X-Gm-Message-State: ALoCoQk7R0GMIRVOYn/1Z1o1n8MewD23GDjR4pFqx5sRyAIU4rO9WWizzqVV6L3IypBVJHnwZtTi Cc: "" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:42:53 -0000 --20cf3071cffa5ab77104bc504c43 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 28, 2012 at 12:35 PM, Hadriel Kaplan wrote: > > On Mar 28, 2012, at 6:15 PM, Roman Shpount wrote: > > > On the related note, where is SRTP profile with NULL encoding defined? I > have seen quite a few SRTP implementations but not a single one of them > supported NULL codec in any of its profiles. > > The RFC for SRTP itself included NULL cipher mode - see RFC 3711. > Note that it is even mandatory to implement, but not mandatory to use - so > we can specify in RTCWeb it MUST NOT be used, I believe. > > What was always getting me confused is that RFC 4568 provided no way to specify that NULL cipher mode should be used. All crypto suites there are AES CM or F8 based. This might be irrelevant if we are going to use DTLS for cipher negotiation. _____________ Roman Shpount --20cf3071cffa5ab77104bc504c43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 28, 2012 at 12:35 = PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:

On Mar 28, 2012, at 6:15 PM, Roman Shpount wrote:

> On the related note, where is SRTP profile with NULL encoding defined?= I have seen quite a few SRTP implementations but not a single one of them = supported NULL codec in any of its profiles.

The RFC for SRTP itself included NULL cipher mode - see RFC 3711.
Note that it is even mandatory to implement, but not mandatory to use - so = we can specify in RTCWeb it MUST NOT be used, I believe.


What was always g= etting me confused is that RFC 4568 provided no way to specify that NULL ci= pher mode should be used. All crypto suites there are AES CM or F8 based. T= his might be irrelevant if we are going to use DTLS for cipher negotiation.=

_____________
Roman Shpount


--20cf3071cffa5ab77104bc504c43-- From magnus.westerlund@ericsson.com Wed Mar 28 09:47:09 2012 Return-Path: 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 9734B21F8850 for ; Wed, 28 Mar 2012 09:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.221 X-Spam-Level: X-Spam-Status: No, score=-108.221 tagged_above=-999 required=5 tests=[AWL=-1.972, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 XtUbzAX07ovj for ; Wed, 28 Mar 2012 09:47:09 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7AE21F843F for ; Wed, 28 Mar 2012 09:47:08 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-60-4f73408b56f1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E9.11.25560.B80437F4; Wed, 28 Mar 2012 18:47:07 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Wed, 28 Mar 2012 18:47:06 +0200 Message-ID: <4F734089.9040208@ericsson.com> Date: Wed, 28 Mar 2012 18:47:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Additional keying mechanisms for media security for discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:47:10 -0000 WG, In addition to the consensus in todays meeting (see other email) there was no consensus established about if there should be additional keying mechanisms. We did a consensus call if in addition to DTLS-SRTP: a) Security Description SHALL be mandatory to also implement b) Security Description SHALL NOT be mandatory to also implement This consensus call was clearly tied. We will continue to discuss this with the goal to make a decision at a later point. We chairs also deferred the question if EKT is a mechanism that shall or be recommended to be supported. So please discuss this also. Regards Magnus Westerlund WG chair From dwing@cisco.com Wed Mar 28 09:54:52 2012 Return-Path: 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 536E421E8270 for ; Wed, 28 Mar 2012 09:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.432 X-Spam-Level: X-Spam-Status: No, score=-109.432 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Cx2fRV-Ro3VS for ; Wed, 28 Mar 2012 09:54:51 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8B10821E8091 for ; Wed, 28 Mar 2012 09:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4644; q=dns/txt; s=iport; t=1332953691; x=1334163291; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=+rvEdGC1Hla1/Qsmu5N0HXl/MfQibA9BnyNl40+QZug=; b=RMf4ns0c8Lh7zDfhYQxo10ENNfJ52NvwhqsQ8KD00fzQ+G9JcKX4AecR qp34jIGvo66gA3kvmXUheIDJ/qhIvkV5WxjpD+UKI47BYJ/5GKu5UZ49P b1/T3PKsLVCaq9X8WBTvGp6ywP2SXb7q8Qe2hTDMAfqg1rHS1FFomouH1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAFJBc0+rRDoI/2dsb2JhbAA8CakKj2KBB4IJAQEBAwEBAQEFCgEXEDQBCgUHAQMCCQ8CBAEBAScHGQ4VCgkIAQEEARILF4djBAybdZ8jim+GIwSNa4kHjTSBaIJp X-IronPort-AV: E=Sophos;i="4.73,662,1325462400"; d="scan'208";a="37962171" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 28 Mar 2012 16:54:51 +0000 Received: from dwingWS (sjc-vpn2-273.cisco.com [10.21.113.17]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2SGsn0Z012785; Wed, 28 Mar 2012 16:54:50 GMT From: "Dan Wing" To: "'Roman Shpount'" , References: <4F732531.2030208@ericsson.com> <4F733492.9040601@alcatel-lucent.com> In-Reply-To: Date: Wed, 28 Mar 2012 18:54:49 +0200 Message-ID: <0bf201cd0d03$7dabb380$79031a80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0M/fnAmFS1m3uzQZyAZ+llZHxXPQABG/GA Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:54:52 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Roman Shpount > Sent: Wednesday, March 28, 2012 6:15 PM > To: igor.faynberg@alcatel-lucent.com > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Consensus call regarding media security > > Igor, > > I could not attend the meeting today, but I am responding to the call > of consent on the list, that did not mention that or any other > conditions on SRTP encryption support. Does it also mean that the call > can be established using plain RTP, or is DTLS handshake, even in order > to setup NULL encruption, is still a requirement? If DTLS handshake is > a requirement, I still would object to it, since this will require an > extra implementation and interop step in anything communicating with > WebRTC. The opposite it also true. Specifically, if Security Descriptions is required for RTCWEB endpoints, it requires extra implementation and interop for all RTCWEB endpoints. > On the related note, where is SRTP profile with NULL encoding defined? > I have seen quite a few SRTP implementations but not a single one of > them supported NULL codec in any of its profiles. Also, we should be > very careful not to support NULL encoding unless it is specifically > enabled in API. Even though I do want to support unencrypted media, I > do not want anything that allows to bid down from encrypted to > unencrypted connection, for instance during DTLS negotiation, unless > specifically enabled. During their (D)TLS handshake, the (D)TLS client and server exchange a list of cipher suites they support, and use the strongest supported by both the client and server. To negotiate Null, the ClientHello needs to include the Null cipher suite and the (D)TLS server needs to choose Null -- if its policy allows choosing Null. A (D)TLS server will usually not allow negotiating Null, and a (D)TLS client will usually not include Null in its list of cipher suites. -d > _____________ > Roman Shpount > > > > On Wed, Mar 28, 2012 at 11:56 AM, Igor Faynberg lucent.com> wrote: > > > > Roman, > > I think there is a misunderstanding (I assume you did not attend > the meeting today). It has been clarified that SRTP allows the NULL > encryption algorithm, and that this option will be available. > > Igor > > > On 3/28/2012 11:49 AM, Roman Shpount wrote: > > As I have mentioned before on this list I am strongly > against making SRTP protection for RTP a requirement. I think this is > an unnecessary requirement that serves little real purpose except > feeding into some marketing message that most of the WebRTC users would > not care about. Unless use of identity is also a requirement, requiring > SRTP will provide security only in a very narrow sense of the word. At > the same time I do believe that extra standard requirements will stifle > innovation and will complicate new service or application creation. > > I have no objection to making DTLS-SRTP a required to > implement protocol. > _____________ > Roman Shpount > > > > On Wed, Mar 28, 2012 at 10:50 AM, Magnus Westerlund > wrote: > > > WG, > > In todays RTCWEB WG meeting there was discussion > around media security > mechanism. In this meeting there was some clear > consensus in the > meeting which we would like to confirm on the list. > > The first was that there was overwhelming consensus > that all RTP > packets SHALL be protected by SRTP. > > Secondly that no one objected against making DTLS- > SRTP a mandatory to > implement and the default keying mechanism. > Additional mechanisms are > not precluded. > > WG participants may state their position regarding > these consensus calls > until 12th of April when the chairs will declare the > final consensus. If > you where present in the meeting room and comment on > this, please > indicate that. > > Best Regards > > Magnus Westerlund > For the WG 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 > > > From dwing@cisco.com Wed Mar 28 09:59:29 2012 Return-Path: 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 4C7D921E8258 for ; Wed, 28 Mar 2012 09:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.443 X-Spam-Level: X-Spam-Status: No, score=-109.443 tagged_above=-999 required=5 tests=[AWL=1.156, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 tEJWbFo1ZRQ7 for ; Wed, 28 Mar 2012 09:59:28 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 71CB721E8254 for ; Wed, 28 Mar 2012 09:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2978; q=dns/txt; s=iport; t=1332953968; x=1334163568; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Ow8EY9KMSSZZZpf2tSL7kYUSXXp4XFD8XqIpT1QTzuk=; b=IRlg9gva6AevgFaZcTzSB23r7YqLb6tFxVAJbuBk7oWB+ONjr5kkCbAO BUcy7ZgE/feLl0W4VAV+VNYMenIvdl6NWAB8Erc5JxtDMeP5emyd06cBg uilOSHGfiTSJ/zC42H2X/1+R3clyutZz+3k8FzqS1QK19kOt6AK5qODuM M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAH1Cc0+rRDoI/2dsb2JhbAA8CakKj2KBB4IJAQEBBAEBAQUKARcQLQcBCgwBAwIJDwIEAQEoBxkOFQoJCAEBBAESCxeHZwybep8fBIpvhiMEjWuWO4Fogmk X-IronPort-AV: E=Sophos;i="4.73,662,1325462400"; d="scan'208";a="37962956" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 28 Mar 2012 16:59:28 +0000 Received: from dwingWS (sjc-vpn2-273.cisco.com [10.21.113.17]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2SGxQlZ014793; Wed, 28 Mar 2012 16:59:27 GMT From: "Dan Wing" To: "'Richard L. Barnes'" , "'Harald Alvestrand'" References: <4F72D6B3.40803@bbn.com> <4F72E453.7070204@alvestrand.no> <4F72EB53.5000409@bbn.com> In-Reply-To: <4F72EB53.5000409@bbn.com> Date: Wed, 28 Mar 2012 18:59:26 +0200 Message-ID: <0bf301cd0d04$22d53200$687f9600$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0Mz6RtUjUda4oFQsOOmqoPd72ayQANE4PQ Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:59:29 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Richard L. Barnes > Sent: Wednesday, March 28, 2012 12:44 PM > To: Harald Alvestrand > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] SRTP and "marketing" > > >> I didn't make it to the mic at the meeting today, but I wanted to > >> express one concern about the possibility of making RTCWEB SRTP- > only. > >> > >> Hadriel mentioned the "marketing value" of having always-on > >> encryption, this idea that only supporting SRTP will make RTCWEB > look > >> like something secure and trustworthy. I'm concerned that this might > >> not be the case, and in fact that being SRTP-only might effectively > be > >> an over-promise, in light of the fact the absence of universal > >> authentication. > >> > >> Hadriel noted that the competitors to this technology are Skype and > >> Flash, and it's worth considering the security situation with these > >> technologies, because they kind of bracket RTCWEB. With Skype > >> (assuming they've designed it properly), there is actually a > universal > >> authentication, under a single authority. So you really do know that > >> you're talking to whatever Skype ID you intend to, and nobody else. > >> With Flash, well, does anyone expect it to be secure anyway? > >> > >> What I'm concerned about in the RTCWEB context is that without a > >> universal authentication/identity infrastructure, we will end up > >> *promising* a secure call, but not *delivering* it. I haven't done > the > >> analysis, but it does not seem implausible to me that FireSheep-like > >> vulnerabilities are lurking here. > > If there are, we need to close them before we ship the specs. > > Given reasonable practices (such as using only HTTPS for loading the > > pages and JS libraries), if we can't deliver security (against known > > attacks), we shouldn't ship the spec. > > I agree that we should lock things down to the extent we can, and I > think we will be able to do pretty well, using things such as you note. > > But at base, without authentication, you cannot prevent MitM if someone > is in the right place in the network. You can just constrain the set > of > places from which an MitM can be launched. > > > >> So ISTM the "marketing" argument carries with it some serious risks > as > >> well as some small possible benefit. > > Only if we don't deliver. > > Except that "deliver" in this case entails a global > authentication/identity infrastructure. And it seems unlikely that > we'll deliver that in the short run. We do need a foundation upon which an authentication/identity infrastructure can be built. We know we need one. That foundation is DTLS-SRTP, and not Security Descriptions. -d > > --Richard > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dwing@cisco.com Wed Mar 28 10:06:48 2012 Return-Path: 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 937DF21E82CF for ; Wed, 28 Mar 2012 10:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.455 X-Spam-Level: X-Spam-Status: No, score=-109.455 tagged_above=-999 required=5 tests=[AWL=1.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 VJOz3ebARUA2 for ; Wed, 28 Mar 2012 10:06:48 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFA421E82C6 for ; Wed, 28 Mar 2012 10:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2627; q=dns/txt; s=iport; t=1332954408; x=1334164008; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=ckOWpr/bxm0kvKagyXzLtKzwASkytqazrMcSxuZirX0=; b=mVemxOfHtdko9UjPSrqtaWjUjDC+r9HSE7fAvDpL4N69gb1HCmifxf1F PKmjCdrYe3f0A5cxj53TBSu01yL3CO6j0kk/rcLE99Z/Ll/dnN04WbxOL pyUc72InGnsiutnAOL/qYeAMR/LRWn0oKSSfrwq6e3kVakH1Q8mjS1PoT 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAOBEc0+rRDoI/2dsb2JhbAA8CakKj2KBB4IJAQEBAwEICgEXEEQHAQMCCQ8CBAEBAScHGSMKCQgBAQQBEgsXh2MEDJtznySKb4YjBI1riQeNNIFogmk X-IronPort-AV: E=Sophos;i="4.73,662,1325462400"; d="scan'208";a="37964150" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 28 Mar 2012 17:06:46 +0000 Received: from dwingWS (sjc-vpn2-273.cisco.com [10.21.113.17]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2SH6juO017867; Wed, 28 Mar 2012 17:06:46 GMT From: "Dan Wing" To: "'Basil Mohamed Gohar'" , References: <4F732531.2030208@ericsson.com> <4F732649.5010705@hidayahonline.org> In-Reply-To: <4F732649.5010705@hidayahonline.org> Date: Wed, 28 Mar 2012 19:06:45 +0200 Message-ID: <0bf401cd0d05$284c50a0$78e4f1e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0M8skmfauMp1u3SaeTuf3dsaXQJAAEYgdw Content-Language: en-us Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:06:48 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Basil Mohamed Gohar > Sent: Wednesday, March 28, 2012 4:55 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Consensus call regarding media security > > On 03/28/2012 10:50 AM, Magnus Westerlund wrote: > > WG, > > > > In todays RTCWEB WG meeting there was discussion around media > security > > mechanism. In this meeting there was some clear consensus in the > > meeting which we would like to confirm on the list. > > > > The first was that there was overwhelming consensus that all RTP > > packets SHALL be protected by SRTP. > > > > Secondly that no one objected against making DTLS-SRTP a mandatory to > > implement and the default keying mechanism. Additional mechanisms are > > not precluded. > > > > WG participants may state their position regarding these consensus > calls > > until 12th of April when the chairs will declare the final consensus. > If > > you where present in the meeting room and comment on this, please > > indicate that. > > > > Best Regards > > > > Magnus Westerlund > > For the WG chairs > I already brought-up my concerns in the other thread, so I'll summarize > the core point I was making here. Would using SRTP *require* a central > authority for establishing authenticity, or can authenticity be > established via a point-to-point means (e.g., how it's traditionally > done via SSH [i.e., upon first connection or via previous key > exchange])? A central authority is not required. DTLS-SRTP itself doesn't use the information in the DTLS certificates (the information that might be present is ignored). Of course, if you want identity, then an identity service needs to exist. But it is possible to operate DTLS-SRTP without identity, which still provides value beyond Security Descriptions. For example, because you mentioned ssh, an 'easy' way to do DTLS-SRTP is to place the remote peer's certificate fingerprint into your local address book. No central authority is needed, and you could get an alert if/when the remote peer's certificate changes. A similar technique for HTTP is described in draft-ietf-websec-key-pinning. A similar technique for ZRTP is http://tools.ietf.org/html/rfc6189#section-12. > This is about degrees of trust that the user is will to place upon > various methods, of course. I am stating that the option should exist > for authenticity of an end point to be established outside of a central > authority (e.g., key exchange via other means). I agree that is valuable. -d From rbarnes@bbn.com Wed Mar 28 10:21:00 2012 Return-Path: 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 357A021E82DD for ; Wed, 28 Mar 2012 10:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 Z2KUl2Q7mB72 for ; Wed, 28 Mar 2012 10:20:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 09BA321E82E3 for ; Wed, 28 Mar 2012 10:20:59 -0700 (PDT) Received: from [128.89.255.27] (port=62795 helo=neutrino.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCwY7-00018d-AM; Wed, 28 Mar 2012 13:20:43 -0400 Message-ID: <4F734878.2070901@bbn.com> Date: Wed, 28 Mar 2012 19:20:56 +0200 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Magnus Westerlund References: <4F734089.9040208@ericsson.com> In-Reply-To: <4F734089.9040208@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Additional keying mechanisms for media security for discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:21:00 -0000 (b) On 3/28/12 6:47 PM, Magnus Westerlund wrote: > WG, > > In addition to the consensus in todays meeting (see other email) there > was no consensus established about if there should be additional keying > mechanisms. > > We did a consensus call if in addition to DTLS-SRTP: > > a) Security Description SHALL be mandatory to also implement > > b) Security Description SHALL NOT be mandatory to also implement > > This consensus call was clearly tied. We will continue to discuss this > with the goal to make a decision at a later point. > > We chairs also deferred the question if EKT is a mechanism that shall or > be recommended to be supported. So please discuss this also. > > Regards > > Magnus Westerlund > WG chair > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Wed Mar 28 10:50:14 2012 Return-Path: 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 E65B921E804A for ; Wed, 28 Mar 2012 10:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 6CQeYoMjwO10 for ; Wed, 28 Mar 2012 10:50:13 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 164B421E8040 for ; Wed, 28 Mar 2012 10:50:13 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1057119vcb.31 for ; Wed, 28 Mar 2012 10:50:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=PondkANjsgj5YDk3TGM3T50OZmFBumWDlJ4buCstmIA=; b=jpzzxGkps3eWCJbj3Vm178m0jJdfAmvswgM/EapcyZquPuB5Q2+UIOKPxAK8S1Q/XO qmJgYMqjts591cmC+qPLstt4zVyeUoRRSDVwkuHuDk6XKMRSLOrY5RIKfnDx8X8Z+Ydg LL+fPy8Avmb0mWaxCM1W7eZeaQnNAGVBwPMcJLLs2aPQxxVcxrq0p0vLpnmx9IkiATY8 giy/FNIjUcVfLBAMqFfD6fmtnzPAtafilarNpJ7ig/PoWk5Smsp9YgRO+aV8bLwTyfX2 YEPT+pli9Or9kdT64g25fmwNEDxEaGxkTNrWH1lhnQDxinhb5CuLJNkJmKz5ivw4sNfG 5lNg== Received: by 10.52.15.233 with SMTP id a9mr1174049vdd.34.1332957012615; Wed, 28 Mar 2012 10:50:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 28 Mar 2012 10:43:10 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 28 Mar 2012 19:43:10 +0200 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkuYc5WfX8QbMKWxtaMBALnymnoAFNXfwOuRrNTNVGafHK0dEdKhnwv9Jwa/4Ah2SrO6SJL Subject: [rtcweb] About DTLS-SRTP-EKT and key changes X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:50:15 -0000 Hi all, this is probably a very easy question: In slide 34 in http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pd= f, there is a new EKT key from the WebRTC endpoint, and in slide 35 there is a re-INVITE from the SDES endpoints with (I assume) a new SDES key. When do such key change occur? I assume it could occur in case a SIP PBX performs a "hidden" transfer to other local phone by keeping untouched the SIP dialog in the other leg (in this case the new SIP destination would provide a different SDES key so it must be sent to the WebRTC endpoint in the form of a new EKT key, am I right?). But, does such a key change could occur in simpler cases as for example "putting on hold"? I hope the answer is NOT. Thanks a lot for any clarification. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Mar 28 10:56:47 2012 Return-Path: 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 2081C21E80A4 for ; Wed, 28 Mar 2012 10:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 bGHxeaMOMrgK for ; Wed, 28 Mar 2012 10:56:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 890DB21E809F for ; Wed, 28 Mar 2012 10:56:46 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1062585vcb.31 for ; Wed, 28 Mar 2012 10:56:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=r7sJpicDr0iqEwY8SD7j+XEQGCbKhfyaVeeCSc7TW+A=; b=lPVbO4nE5gtfdISbt+wLiPy+siNW7ggPQoCnyIl015LZJYwG8cgaA/NEy7UwsCIA0e 8J+PqKzoclELw056SVIrRDKAJifZUyTsSTEHuxjBvH2MkS7swL12GVpWduzpfvt0miAs zLzJI5b/rHh5lnav3YrcSmaAbKBsnmCEJJvwHd4pedchAD3t4IGv73Orm8GSEeur6/be dZthPzPmXGCjwuC3wS2gy4iInMu16lk74wLdCUibsSklCftF7pXGlRyTYja08mXQD4R2 CajfKBGu9C3ze1ZIL8Q88NfwAe09baAWOw49nNPLCyaBqyZuS9VBzE+yi2klrfYkrB0X IyGA== Received: by 10.52.15.233 with SMTP id a9mr1183079vdd.34.1332957406074; Wed, 28 Mar 2012 10:56:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 28 Mar 2012 10:56:23 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 28 Mar 2012 19:56:23 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlonGdXThyfwYP3YFwNVBa9LO2aAyqoL2F1VDaOO+drZVulETy4fUHp4rrVL6fwVNCn4AHv Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:56:47 -0000 2012/3/28 Roman Shpount : > As I have mentioned before on this list I am strongly against making SRTP > protection for RTP a requirement. I think this is an unnecessary requirem= ent > that serves little real purpose except feeding into some marketing messag= e > that most of the WebRTC users would not care about. Unless use of identit= y > is also a requirement, requiring SRTP will provide security only in a ver= y > narrow sense of the word. At the same time I do believe that extra standa= rd > requirements will stifle innovation and=C2=A0 will complicate new service= or > application creation. SRTP (with SDES so without identity authentication) is still much better than plain RTP, right? If I'm in an airport connected to an open WiFi network, but I use HTTPS/WSS for signaling from my WebRTC browser, then I can be sure that no one in the airport can intercept my media streams (using SRTP-SDES). Of course this does not solve the fact that there could be some MiM attacker somewhere in the signaling path, but NOT in the airport! What is sure is that if I was using plain RTP then everyone in the open WiFi network could intercept my media streams. IMHO it's really clear that SRTP (even with SDES) is MUCH better than plain RTP. And so far I have not heard any advantage fof allowing plain RTP other than "it allows interoperability with my 5 years ago SIP device". So +1 for the voted consensus. Regards. --=20 I=C3=B1aki Baz Castillo From abu_hurayrah@hidayahonline.org Wed Mar 28 11:01:19 2012 Return-Path: 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 5694B21F87A8 for ; Wed, 28 Mar 2012 11:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] 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 IWIJYHVxO1tE for ; Wed, 28 Mar 2012 11:01:18 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7AA21F879D for ; Wed, 28 Mar 2012 11:01:18 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 06294652509 for ; Wed, 28 Mar 2012 14:01:17 -0400 (EDT) Message-ID: <4F7351EB.8020504@hidayahonline.org> Date: Wed, 28 Mar 2012 14:01:15 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F732531.2030208@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=5AF4B362 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 18:01:19 -0000 On 03/28/2012 01:56 PM, Iñaki Baz Castillo wrote: > 2012/3/28 Roman Shpount : >> As I have mentioned before on this list I am strongly against making SRTP >> protection for RTP a requirement. I think this is an unnecessary requirement >> that serves little real purpose except feeding into some marketing message >> that most of the WebRTC users would not care about. Unless use of identity >> is also a requirement, requiring SRTP will provide security only in a very >> narrow sense of the word. At the same time I do believe that extra standard >> requirements will stifle innovation and will complicate new service or >> application creation. > SRTP (with SDES so without identity authentication) is still much > better than plain RTP, right? If I'm in an airport connected to an > open WiFi network, but I use HTTPS/WSS for signaling from my WebRTC > browser, then I can be sure that no one in the airport can intercept > my media streams (using SRTP-SDES). > > Of course this does not solve the fact that there could be some MiM > attacker somewhere in the signaling path, but NOT in the airport! What > is sure is that if I was using plain RTP then everyone in the open > WiFi network could intercept my media streams. > > IMHO it's really clear that SRTP (even with SDES) is MUCH better than > plain RTP. And so far I have not heard any advantage fof allowing > plain RTP other than "it allows interoperability with my 5 years ago > SIP device". > > So +1 for the voted consensus. > > Regards. This captures the sentiment of what I was trying to convey. So, +1 to this explanation. From ibc@aliax.net Wed Mar 28 11:02:14 2012 Return-Path: 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 3430221E8193 for ; Wed, 28 Mar 2012 11:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 BiGHC8Ea5H+V for ; Wed, 28 Mar 2012 11:02:13 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF8321F8692 for ; Wed, 28 Mar 2012 11:02:13 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1066759vcb.31 for ; Wed, 28 Mar 2012 11:02:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Q7ZmTj/xxBIXmfLZJNn4FlIMzZjCsZN6gDZVubzmaOw=; b=nOvLgdRx/Fl4OGHPc4WiC+t9q1aTZ7Dp6vfHlGZdHgxplU+cBPtEUCcuLaoJh9yHhk hbu4Fe3a7eIFi0VEu35tsEbUXkGmvDGGajiyS9wZYOf6Y0Q465igXdX4k+ZiXrYwGTgG MTr8MK7QwAP8sV1xqNs0pBk7ww5SdcfrRbV693SDntRPAHly9ixabXxMN8A/cTYuAJNj 7nftvNLfGZbyciszylkfiBO1qKD3grkUs5lc/9NnaXwb+JFFtwokv2XXXWGZ9qyyArUj 9cAz4ggfEBvJGXTCFMRtSBpj1Ua0V/mqsBBVYNQtNnRfPSKnN7N6hErcIe5KkIDTixYB iEUg== Received: by 10.52.15.233 with SMTP id a9mr1190639vdd.34.1332957732695; Wed, 28 Mar 2012 11:02:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 28 Mar 2012 11:01:50 -0700 (PDT) In-Reply-To: <4F734089.9040208@ericsson.com> References: <4F734089.9040208@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 28 Mar 2012 20:01:50 +0200 Message-ID: To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnmHUCxBTOqPD/WH++PIHTMVRxf5Hz3lmcFwHqSwxmPlM0owsq7HpAGaypIPZbXDHO86Zdx Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Additional keying mechanisms for media security for discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 18:02:14 -0000 2012/3/28 Magnus Westerlund : > We did a consensus call if in addition to DTLS-SRTP: > > a) Security Description SHALL be mandatory to also implement > > b) Security Description SHALL NOT be mandatory to also implement > > This consensus call was clearly tied. We will continue to discuss this > with the goal to make a decision at a later point. I vote for (a). Rationale: SRTP-SDES is proven to work and it's widely implemented. It is not the perfect solution but it's easy to implement and much better than plain RTP. NOTE: Of course I also vote for SRTP-DTLS to be mandatory (for which AFAIK there is already consensus: it MUST be implemented). > We chairs also deferred the question if EKT is a mechanism that shall or > be recommended to be supported. So please discuss this also. That's still less tested than DTLS-SRTP, so I vote for "SHALL NOT be mandatory to also implement" (at least for now). --=20 I=C3=B1aki Baz Castillo From tterriberry@mozilla.com Wed Mar 28 11:30:10 2012 Return-Path: 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 2039221E80F1 for ; Wed, 28 Mar 2012 11:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] 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 Zk050a8rZJm6 for ; Wed, 28 Mar 2012 11:30:09 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD5E21E8040 for ; Wed, 28 Mar 2012 11:30:09 -0700 (PDT) Received: from [130.129.69.85] (dhcp-4555.meeting.ietf.org [130.129.69.85]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 271B44AED56 for ; Wed, 28 Mar 2012 11:30:07 -0700 (PDT) Message-ID: <4F7358AE.4040006@mozilla.com> Date: Wed, 28 Mar 2012 11:30:06 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F732531.2030208@ericsson.com> <4F733492.9040601@alcatel-lucent.com> <91F0E66E-A75E-4369-A010-9712FF90258D@acmepacket.com> In-Reply-To: <91F0E66E-A75E-4369-A010-9712FF90258D@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 18:30:10 -0000 Hadriel Kaplan wrote: > > Actually, I was confused about that - it seems to me it's still an open > item whether to allow null cipher or not. As a browser vendor, I could see adding an about:config option to enable the null cipher for debugging purposes, but would expect that for the vast majority of users it will never be allowed. From ibc@aliax.net Wed Mar 28 11:40:08 2012 Return-Path: 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 1263B21E8109 for ; Wed, 28 Mar 2012 11:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 WPOMxjgB1KS8 for ; Wed, 28 Mar 2012 11:40:07 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 28C6721E80F1 for ; Wed, 28 Mar 2012 11:40:07 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1068092vbb.31 for ; Wed, 28 Mar 2012 11:40:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=DBEHyBCHZf8/nW3Q/lObuOwD50iiTaCPwC/WZNA42Y0=; b=GrIZpzNOx1CdecQDjiLbHl4UQtSN9ijy+RrXNh9LaarhYsKVI75I79ixweICacDycu zLAFFcWQXihzi75kBBoX5L3/ZytnO59mBRG4+QSGbPxOYwd80rVgxOsCsNG2ZTYGSRPA 2mzQkzQJW85gNcorlFWgCGxzM8te390EAIULH8cAbie8VwlxZn75t43L3Vq9pIiZxAwi FqsKRW0+cMCC2De5xW/PcRdP6LPL8aZHIoc6TKvwfmTiVZg8F0BJ7d37WwnnxngaqZAj rKwiYP7v1hMT+znH7RNTlYtgDr4HXuOPpHIi3U291+L2w1oyolBAytlaCYwDvHu4u/1y gDXA== Received: by 10.52.15.233 with SMTP id a9mr1244866vdd.34.1332960006610; Wed, 28 Mar 2012 11:40:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 28 Mar 2012 11:39:46 -0700 (PDT) In-Reply-To: <4F7358AE.4040006@mozilla.com> References: <4F732531.2030208@ericsson.com> <4F733492.9040601@alcatel-lucent.com> <91F0E66E-A75E-4369-A010-9712FF90258D@acmepacket.com> <4F7358AE.4040006@mozilla.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 28 Mar 2012 20:39:46 +0200 Message-ID: To: "Timothy B. Terriberry" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnj5LC2XIqcsSXgxwWNb4IAy+uVYipVszNGEXPUbVpQ69cvlNlt25/FtUw6iiLyUUxty3t0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 18:40:08 -0000 2012/3/28 Timothy B. Terriberry : >> Actually, I was confused about that - it seems to me it's still an open >> item whether to allow null cipher or not. > > > As a browser vendor, I could see adding an about:config option to enable = the > null cipher for debugging purposes, but would expect that for the vast > majority of users it will never be allowed. And if such an about:config option is automatically reverted upon browser restart, then much better. --=20 I=C3=B1aki Baz Castillo From lists@infosecurity.ch Wed Mar 28 12:41:54 2012 Return-Path: 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 CFC5021E8217 for ; Wed, 28 Mar 2012 12:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7wopgaxlDzPi for ; Wed, 28 Mar 2012 12:41:54 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B402021E80D0 for ; Wed, 28 Mar 2012 12:41:53 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so908589wgb.13 for ; Wed, 28 Mar 2012 12:41:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding :x-gm-message-state; bh=sV6DaWUBqxTdRAKp+da5zzdLtmcKi6MgyzKhrGbEK10=; b=oeV+Ho2YJ1y5rX41KsB1bgunQn9Lvg7m+HoYo1KZNVUuqB0i4LFJu27VbxV+5baU9Z 1JJizP244/X+zZ66zYqAuEG4kd0hGTR9FZK01XqJhaib9Hnr76DnusLHWAoLrxBvZVf7 SafuryYq/jFZSEcPq3yLcrqfe25+0Ue9bFO3UqRoLRUJyQD6+nvGuEYtD6UGr7GGHve5 FxdLoPUERQN7QV5PY/LbxFqEIgwZhFcTnSXZJc3A06vpQbjo9QMhDDO+XUCP+1iEkBbk xAGbkgtTwh/7VoYiIPpwERG7KIfG3Br03eEXvmL+p5MJS83cGz93wOqLZJW26ZSVV2qx 8RlQ== Received: by 10.180.104.65 with SMTP id gc1mr886348wib.13.1332963712350; Wed, 28 Mar 2012 12:41:52 -0700 (PDT) Received: from sonyvaiop13.local (93-32-156-99.ip34.fastwebnet.it. [93.32.156.99]) by mx.google.com with ESMTPS id o2sm17100239wiv.11.2012.03.28.12.41.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 12:41:51 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F73697D.5080006@infosecurity.ch> Date: Wed, 28 Mar 2012 21:41:49 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkdsi67xEstd3UJCj2HHpd3giyFOsYjaliIEtNH0x1PSHpiI/nMIz2UJGQITuKOB91bANxk Subject: [rtcweb] DTLS-SRTP implementation diffusion: Why not SDES-SRTP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 19:41:54 -0000 Hi all, i read that 80% of Sipit participant support SDES-SRTP but 0% support DTLS-SRTP https://www.sipit.net/SIPit29_summary . At SIPit there were 34 attendees from 17 companies visiting from 12 countries with 25 distinct VoIP implementations. For SDES-SRTP it's reported that: ** All implementations supported SDES for SRTP key exchange. Good interop with many different combinations of endpoints. ** I do not really see which is the rationale in making DTLS-SRTP mandatory while plain SRTP with SDES key exchange is already so well know and used. Anyone can provide some very strong and valuable point about using DTLS-SRTP (considering it's weak diffusion and incompatibility risks) rather than standardizing the transport/communication of SDES key exchange over a Web medium (HTTPS/HTTPS/Javascript)? -- Fabio Pietrosanti Founder, CTO Tel: +39 02 911930893 + ext: 907 Mobile: +39 340 1801049 E-mail: fabio.pietrosanti@privatewave.com Skype: fpietrosanti Linkedin: http://linkedin.com/in/secret PrivateWave Italia S.p.A. Via Gaetano Giardino 1 - 20123 Milano - Italy www.privatewave.com From ibc@aliax.net Wed Mar 28 12:53:38 2012 Return-Path: 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 7FEF921E80BE for ; Wed, 28 Mar 2012 12:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 xJhv2RzxmAza for ; Wed, 28 Mar 2012 12:53:36 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2814F21E80A5 for ; Wed, 28 Mar 2012 12:53:35 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1124176vbb.31 for ; Wed, 28 Mar 2012 12:53:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=FJr8uChk3uZAzU022XV3f+9FpqKQcmWJjzrZT4Jm8iU=; b=JiHPzdwYDxkT/PtT5G8Eo/6bWUgiIdwSID79LHtzQskZFwtnTItFbWfBjdffEaWB94 u+w2F/hpJ7YWksQ0t4zLl2omCSK63WwLU8Jn9fHM2+3wXGUcnoBGvFXildUqwdjTG1Yv LpWo/p+ER5Q080BFPO1akZvH71GARqrkpcanEmzNx4527ua5Q3RThVudBaP0kRPH0luY mQZcn06x+9N5MFnEb/nSbiILoqFi3rQxi1NBN6F6fvgihtlv2hy3JUROovLld8TREIaP XrFkZ0Ee3zf8beYcO0QgE/MpJKuWobuMj6fK1PVKQxhpPfK+UQX6whxa4ogBPkQtSuGI XgTw== Received: by 10.220.152.205 with SMTP id h13mr10480512vcw.12.1332964413933; Wed, 28 Mar 2012 12:53:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 28 Mar 2012 12:53:13 -0700 (PDT) In-Reply-To: <4F73697D.5080006@infosecurity.ch> References: <4F73697D.5080006@infosecurity.ch> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 28 Mar 2012 21:53:13 +0200 Message-ID: To: "Fabio Pietrosanti (naif)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnf4yXKr2syM3OSbwRh7g1JHvIafBBXNPZ2WI/Ep1vSnBcOwIJS9tjWYLaxAbMLkGzOI29i Cc: "" Subject: Re: [rtcweb] DTLS-SRTP implementation diffusion: Why not SDES-SRTP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 19:53:38 -0000 2012/3/28 Fabio Pietrosanti (naif) : > Hi all, > > i read that 80% of Sipit participant support SDES-SRTP but 0% support > DTLS-SRTP =C2=A0https://www.sipit.net/SIPit29_summary . > > At SIPit there were 34 attendees from 17 companies visiting from 12 > countries with 25 distinct VoIP implementations. Right, but this is rtcweb, not SIP. > I do not really see which is the rationale in making DTLS-SRTP mandatory > while plain SRTP with SDES key exchange is already so well know and used. That's a good reason to *also* allow (and mandate) SDES-SRTP support in WebRTC clients, much better than the interoperability with SIP (again: this is rtcweb, not SIP world). > Anyone can provide some very strong and valuable point about using > DTLS-SRTP (considering it's weak diffusion and incompatibility risks)? Lot of recent threads about this topic in this maillist. But also check a recent presentation (yesterday in IETF Pairs): http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf --=20 I=C3=B1aki Baz Castillo From juberti@google.com Wed Mar 28 13:21:59 2012 Return-Path: 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 19F7121E80A3 for ; Wed, 28 Mar 2012 13:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1, 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 810KX73H3c-P for ; Wed, 28 Mar 2012 13:21:58 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C20821E8089 for ; Wed, 28 Mar 2012 13:21:58 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1075110qcs.31 for ; Wed, 28 Mar 2012 13:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=lEXFhL0bxT9Qe4xIF07L5z8H2FDX56hKlJOle1o8bD8=; b=ej61QHYrU0iPhM8+3PQYti2xJd6UNfIwGzpEPseD/odFiOrLbFYkj79YGHso0NOusA YXSAbKMpd5vwyx6c+A/XtcJ1lvps2mfeG+AJMAobmurW+ALDudx2m77z+PyuJo7mg8L5 bSUCwf2z8Ne+IR+o16FoKJCFEL5kazJ9DT6MRZkVZvplz/agr5uCc9kTgPbdTjBYY03w 8LO1sR1uvZpkfnl5x86xRbiyp8w8jNad2dguxt0Z1I4sjkiCMzV8V7pMDW4ys6XPRNQH ODby6SL0B7/tpHR74XzwKN6wgc/r2P03Bz6jiVhRbJq8wMBNBYQQYaoqRE+N+kgqh/9u A0xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=lEXFhL0bxT9Qe4xIF07L5z8H2FDX56hKlJOle1o8bD8=; b=oby0eTErXwWTXH4CeKylYTUhQkN7cerLmuYGdDNdMdUgUQgjRti1srBJuejzqHIpfw wRqlnP7mQKmGsLz+Erco/lh4fIBQSLbkAWF3imBkiANegxVp3gByS/4MGUXzr7obVvT5 Z6CdkgcY6i3fhvxdE6O4vixMIZrZEsUlMJws5n94OcxfGSXgAmcRs15UVzzXEsYIjS81 2jhIf6CCBtlq+UBnrdUcEKr4smtO41o7Ixo0n4SLwKM0q91wcobKBeKGmvw0DV0cyScn 8jn/J4G7356q1Jg9dEgXhrBW/vGZiCCUWEuKksrzT+a4+d8L+HlDRylUcDTWDuMDxDmK 44Ug== Received: by 10.224.98.3 with SMTP id o3mr39646948qan.62.1332966117482; Wed, 28 Mar 2012 13:21:57 -0700 (PDT) Received: by 10.224.98.3 with SMTP id o3mr39646932qan.62.1332966117306; Wed, 28 Mar 2012 13:21:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.161.134 with HTTP; Wed, 28 Mar 2012 13:21:37 -0700 (PDT) In-Reply-To: <4F7358AE.4040006@mozilla.com> References: <4F732531.2030208@ericsson.com> <4F733492.9040601@alcatel-lucent.com> <91F0E66E-A75E-4369-A010-9712FF90258D@acmepacket.com> <4F7358AE.4040006@mozilla.com> From: Justin Uberti Date: Wed, 28 Mar 2012 16:21:37 -0400 Message-ID: To: "Timothy B. Terriberry" Content-Type: multipart/alternative; boundary=20cf3074d9e2eb734904bc535b03 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlOjs++YTH63R3IL6yU6fg7MH5hiO56/mHIFD5KGE3nr4v9muBKWtHQuCdGMjcvnBSCQucyKiBxG88h60QYwIn1CENvbjk6FqHXQdBwPhbLPhiuVyhz2+k80D3p4kowmdd4c2W8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:21:59 -0000 --20cf3074d9e2eb734904bc535b03 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 28, 2012 at 2:30 PM, Timothy B. Terriberry < tterriberry@mozilla.com> wrote: > Hadriel Kaplan wrote: > >> >> Actually, I was confused about that - it seems to me it's still an open >> item whether to allow null cipher or not. >> > > As a browser vendor, I could see adding an about:config option to enable > the null cipher for debugging purposes, but would expect that for the vast > majority of users it will never be allowed. As another browser vendor, this is also my expectation. --20cf3074d9e2eb734904bc535b03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Mar 28, 2012 at 2:30 PM, Timothy= B. Terriberry <tterriberry@mozilla.com> wrote:
Hadriel Kaplan wrote:

Actually, I was confused about that - it seems to me it's still an open=
item whether to allow null cipher or not.

As a browser vendor, I could see adding an about:config option to enable th= e null cipher for debugging purposes, but would expect that for the vast ma= jority of users it will never be allowed.

As another browser vendor, this is also my expectation.
--20cf3074d9e2eb734904bc535b03-- From roman@telurix.com Wed Mar 28 13:41:54 2012 Return-Path: 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 2A88F21F87D6 for ; Wed, 28 Mar 2012 13:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 TJOdANSy40ce for ; Wed, 28 Mar 2012 13:41:53 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3645121F877D for ; Wed, 28 Mar 2012 13:41:53 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1166177yhk.31 for ; Wed, 28 Mar 2012 13:41:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=4bOc22qQpYEQ+ChRdA3EmHDZYrwVzkSftzSA+vSgqzw=; b=C7FnEeOk6qhmTQW/h23/5fPqquIn0HDX6mr+1sC6rmZjEc0TrdJk009dbs5iLgwet5 DlrJs4hmjN82l9swCH9rlSX0xCxwOFx48bdEMK+CGRFa3s7IFaWqyeQTT0WD4SPxB3Pj XPrEnmUNjUoBQV7MyMtJyIUWvINqbLsY3TsnEyK+zEnY1/WCWN0FP+T1H+2S4b014eLa oEs0hAF9yXhy0cXD3kx7zx01anRRQNrz1WAvRV/996TtJOmuVUzDUAYPlQs0dTdcJixh WjjXAAk4H6NY/zCPhXRza8f6toYSt8qR8yooXbp6E+He+NCna5STfuUTEvdKrpCQUsj0 QOXw== Received: by 10.236.156.233 with SMTP id m69mr30962212yhk.128.1332967312480; Wed, 28 Mar 2012 13:41:52 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id d25sm10700611yhe.4.2012.03.28.13.41.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 13:41:50 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1188527ggm.31 for ; Wed, 28 Mar 2012 13:41:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.221.10 with SMTP id qa10mr73888004pbc.139.1332967309832; Wed, 28 Mar 2012 13:41:49 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Wed, 28 Mar 2012 13:41:49 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> Date: Wed, 28 Mar 2012 16:41:49 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8ff24801fff33404bc53a2db X-Gm-Message-State: ALoCoQktfn/ZRMsujLFVHnpS4HzfyyDlM6dZ7hpM6Iu8j/NNvSFSbFeLFyyKdfndzR5q0yvkotUu Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:41:54 -0000 --e89a8ff24801fff33404bc53a2db Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2012 at 1:56 PM, I=F1aki Baz Castillo wrote= : > 2012/3/28 Roman Shpount : > > As I have mentioned before on this list I am strongly against making SR= TP > > protection for RTP a requirement. I think this is an unnecessary > requirement > > that serves little real purpose except feeding into some marketing > message > > that most of the WebRTC users would not care about. Unless use of > identity > > is also a requirement, requiring SRTP will provide security only in a > very > > narrow sense of the word. At the same time I do believe that extra > standard > > requirements will stifle innovation and will complicate new service or > > application creation. > > SRTP (with SDES so without identity authentication) is still much > better than plain RTP, right? If I'm in an airport connected to an > open WiFi network, but I use HTTPS/WSS for signaling from my WebRTC > browser, then I can be sure that no one in the airport can intercept > my media streams (using SRTP-SDES). > > Of course this does not solve the fact that there could be some MiM > attacker somewhere in the signaling path, but NOT in the airport! What > is sure is that if I was using plain RTP then everyone in the open > WiFi network could intercept my media streams. > > IMHO it's really clear that SRTP (even with SDES) is MUCH better than > plain RTP. And so far I have not heard any advantage fof allowing > plain RTP other than "it allows interoperability with my 5 years ago > SIP device". > > My main objection is that if an application developer does not take care to develop a secure application, nothing you can do on the standard side will make it a secure application. If I am building a public voice blog that records a voice message that anybody can listen to on the web site security is not needed. My assumption is that a fair number of applications would be like this. So for such applications this is an unnecessary feature. WebRTC will not exist in vacuum. It will communicate with other systems. It is not limited to old SIP devices. It can be something new like server side speech recognition that is integrated with web application. For such application extra code and interop requirements to support security will represent a real and significant cost. Any requirement, unless absolutely necessary will create barriers to entry for new applications. I would like to avoid as many of those as possible. _____________ Roman Shpount --e89a8ff24801fff33404bc53a2db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 28, 2012 at 1:56 P= M, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2012/3/28 Roman Shpount <roman@telu= rix.com>:
> As I have mentioned before on this list I am strongl= y against making SRTP
> protection for RTP a requirement. I think this is an unnecessary requi= rement
> that serves little real purpose except feeding into some marketing mes= sage
> that most of the WebRTC users would not care about. Unless use of iden= tity
> is also a requirement, requiring SRTP will provide security only in a = very
> narrow sense of the word. At the same time I do believe that extra sta= ndard
> requirements will stifle innovation and=A0 will complicate new service= or
> application creation.

SRTP (with SDES so without identity authentication) is still much
better than plain RTP, right? If I'm in an airport connected to an
open WiFi network, but I use HTTPS/WSS for signaling from my WebRTC
browser, then I can be sure that no one in the airport can intercept
my media streams (using SRTP-SDES).

Of course this does not solve the fact that there could be some MiM
attacker somewhere in the signaling path, but NOT in the airport! What
is sure is that if I was using plain RTP then everyone in the open
WiFi network could intercept my media streams.

IMHO it's really clear that SRTP (even with SDES) is MUCH better than plain RTP. And so far I have not heard any advantage fof allowing
plain RTP other than "it allows interoperability with my 5 years ago SIP device".


My main objection is that if an application deve= loper does not take care to develop a secure application, nothing you can d= o on the standard side will make it a secure application. If I am building = a public voice blog that records a voice message that anybody can listen to= on the web site security is not needed. My assumption is that a fair numbe= r of applications would be like this. So for such applications this is an u= nnecessary feature.

WebRTC will not exist in vacuum. It will communicate with other systems= . It is not limited to old SIP devices. It can be something new like server= side speech recognition that is integrated with web application. For such = application extra code and interop requirements to support security will re= present a real and significant cost. Any requirement, unless absolutely nec= essary will create barriers to entry for new applications. I would like to = avoid as many of those as possible.=A0
_____________
Roman Shpount

--e89a8ff24801fff33404bc53a2db-- From abu_hurayrah@hidayahonline.org Wed Mar 28 14:08:13 2012 Return-Path: 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 9321E21E8040 for ; Wed, 28 Mar 2012 14:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] 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 qR+2QqgrFLvw for ; Wed, 28 Mar 2012 14:08:13 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id E513821E800E for ; Wed, 28 Mar 2012 14:08:12 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id D275865256F for ; Wed, 28 Mar 2012 17:08:08 -0400 (EDT) Message-ID: <4F737DB3.5020804@hidayahonline.org> Date: Wed, 28 Mar 2012 17:08:03 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F732531.2030208@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=5AF4B362 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 21:08:13 -0000 On 03/28/2012 04:41 PM, Roman Shpount wrote: > My main objection is that if an application developer does not take > care to develop a secure application, nothing you can do on the > standard side will make it a secure application. If I am building a > public voice blog that records a voice message that anybody can listen > to on the web site security is not needed. My assumption is that a > fair number of applications would be like this. So for such > applications this is an unnecessary feature. > > WebRTC will not exist in vacuum. It will communicate with other > systems. It is not limited to old SIP devices. It can be something new > like server side speech recognition that is integrated with web > application. For such application extra code and interop requirements > to support security will represent a real and significant cost. Any > requirement, unless absolutely necessary will create barriers to entry > for new applications. I would like to avoid as many of those as > possible. > _____________ > Roman Shpount Roman, You make a lot of good points. However, the inverse is true as well - namely, that is if encryption is not mandated, most implementations will likely leave it out, and adoption of secured communications would be stifled even longer. I cannot speak about the implementation difficulties, but I can speak from the user side that most people will remain ignorant of the underlying technology and not know enough to demand nor enable a feature if it is optional to implement and/or use. As WebRTC is a new standard, requiring encryption will ensure that, at least going forward, the important concept of encryption is widely adopted correctly from the beginning. Tacking it on later, no matter how much it is emphasized, will be difficult or impossible. The scope of WebRTC is broad enough to consider that we need to think about what's best going forward with regards to its implementation. Security by default is one of the best practices in general, the support from the browser community and others that are behind it will definitely ensure that adoption is widespread enough to make it easy enough to integrate into existing systems, as free software solutions will become available shortly after the standard emerges. From ibc@aliax.net Wed Mar 28 14:12:18 2012 Return-Path: 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 3F15021F84F2 for ; Wed, 28 Mar 2012 14:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 dJhEvKgarbXT for ; Wed, 28 Mar 2012 14:12:17 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26BED21F84EE for ; Wed, 28 Mar 2012 14:12:17 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1184110vbb.31 for ; Wed, 28 Mar 2012 14:12:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=2PhHRRZ7C1C5mJlDtlBAxNNBdYdQfo1nNj3SMqpqeys=; b=ACiP7TreeMI4W0qq5P7PHp2FPI15fm3Yy788Vf0W1KTbW/nGpQcHcQi42CaMt9ryLk gw9MfNHXyARQzoc9G5AyUxgKYszEQr8RW4NnGlcTkB8cxkoUyfUHMjzOuidl8jQdtJ+J 2RV/lYZmLEtIuPWdOnqrGoRSUKh3Y+tOX+Lm4+ccobr4A5a1NPkBv34fXWdKAuYt+N8q qT5qoJjwp7cSIQplQBsj3rZf54hdSEgMH4sKhckfUCozbOb1jinXBBo6PAanAu+Pkg/t pguMQhJWAOui+JFUIQRtcuN5rIno9YthvhZdl1vbf1KuzMQBBmPirQpioxztn1Znet0F jmag== Received: by 10.52.27.1 with SMTP id p1mr13964674vdg.17.1332969136611; Wed, 28 Mar 2012 14:12:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 28 Mar 2012 14:11:56 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 28 Mar 2012 23:11:56 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlR8VhowzUhnfd//3ybpGK/ed8GRslmEZdJegRFmlUJoSNjzgSlEe8lmuKUS6HW7UmilLpL Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 21:12:18 -0000 2012/3/28 Roman Shpount : > My main objection is that if an application developer does not take care = to > develop a secure application, nothing you can do on the standard side wil= l > make it a secure application. If I am building a public voice blog that > records a voice message that anybody can listen to on the web site securi= ty > is not needed. My assumption is that a fair number of applications would = be > like this. So for such applications this is an unnecessary feature. In all those scenarios you mention, using security (SRTP) is not *bad*, is = it? The fact that in certain scenarios it could be not needed, it does not mean that "no security" is better than "security". > WebRTC will not exist in vacuum. It will communicate with other systems. = It > is not limited to old SIP devices. It can be something new like server si= de > speech recognition that is integrated with web application. For such > application extra code and interop requirements to support security will > represent a real and significant cost. Any requirement, unless absolutely > necessary will create barriers to entry for new applications. I would lik= e > to avoid as many of those as possible. RFC 3711 was created in 2004, 8 years ago! Which "new" application you mean if it's not capable of implementing a simple specification from 2004? how "new" is it? is it really new? or is it a "SIP voicemail server" made in 2002? Sorry but I still see *no* argument at all in favour of allowing plain RTP in WebRTC. And AFAIK there is already consensus about it: plain RTP is not allowed. Regards. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Wed Mar 28 14:58:48 2012 Return-Path: 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 E35D821E80E9 for ; Wed, 28 Mar 2012 14:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] 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 BujmW+z4OZGD for ; Wed, 28 Mar 2012 14:58:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 80AE021E8097 for ; Wed, 28 Mar 2012 14:58:47 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 28 Mar 2012 17:58:43 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Wed, 28 Mar 2012 17:58:42 -0400 From: Hadriel Kaplan To: Dan Wing Thread-Topic: [rtcweb] SRTP and "marketing" Thread-Index: AQHNDS3wTtwICWEdGUmv8/XIx55mBA== Date: Wed, 28 Mar 2012 21:58:42 +0000 Message-ID: <00052A1F-CE65-4A53-9B7D-261E1CC75426@acmepacket.com> References: <4F72D6B3.40803@bbn.com> <4F72E453.7070204@alvestrand.no> <4F72EB53.5000409@bbn.com> <0bf301cd0d04$22d53200$687f9600$@com> In-Reply-To: <0bf301cd0d04$22d53200$687f9600$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <3F26AAEEA036844C8E51A1B2037F052C@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 21:58:49 -0000 On Mar 28, 2012, at 6:59 PM, Dan Wing wrote: > We do need a foundation upon which an authentication/identity=20 > infrastructure can be built. We know we need one. > That foundation is DTLS-SRTP, and not Security Descriptions. Now you're starting to sound like a marketing guy. ;) What's next: "we'll build more synergy and have a unified platform with DTL= S-SRTP"? But more seriously, I don't understand this "foundation" argument. We're g= oing to have DTLS-SRTP. No one's suggesting we don't have DTLS-SRTP. All = Browsers MUST implement DTLS-SRTP. We'll have it for Browser-to-Browser, a= nd for Browser-to-Gateway if the Gateway supports it. We'll have the found= ation. Requiring it for Gateways would make sense if it offered some real advantag= e, or didn't have any disadvantages. There don't appear to be real advanta= ges, while we know of disadvantages. And gateways have no real means of of= fering an end-to-end identity. Why would you want to build a foundation on= air? -hadriel From HKaplan@acmepacket.com Wed Mar 28 14:58:49 2012 Return-Path: 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 0671921E8097 for ; Wed, 28 Mar 2012 14:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] 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 VMakzcQxhc1s for ; Wed, 28 Mar 2012 14:58:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 30FAE21E80D2 for ; Wed, 28 Mar 2012 14:58:48 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 28 Mar 2012 17:58:43 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Wed, 28 Mar 2012 17:58:42 -0400 From: Hadriel Kaplan To: "Richard L. Barnes" Thread-Topic: [rtcweb] SRTP and "marketing" Thread-Index: AQHNDS3wTtwICWEdGUmv8/XIx55mBA== Date: Wed, 28 Mar 2012 21:58:42 +0000 Message-ID: <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> References: <4F72D6B3.40803@bbn.com> In-Reply-To: <4F72D6B3.40803@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <82B535C30625164BA5D0CB6958D0DC63@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 21:58:49 -0000 On Mar 28, 2012, at 11:15 AM, Richard L. Barnes wrote: > Hadriel noted that the competitors to this technology are Skype and Flash= , and it's worth considering the security situation with these technologies= , because they kind of bracket RTCWEB. With Skype (assuming they've design= ed it properly), there is actually a universal authentication, under a sing= le authority. So you really do know that you're talking to whatever Skype = ID you intend to, and nobody else. With Flash, well, does anyone expect it = to be secure anyway? As far as I know, you don't actually "know" that with Skype. You assume it= , because you trust Skype. They could forge whatever identity they wanted = to, and they can insert a recording middlebox if they wanted to, afaict. N= o one is concerned about that. They also have skype-in/skype-out to/from t= he PSTN, and clearly in those cases they can assert whatever identity they = want, and record it all. Again no one is concerned. Have you ever wondere= d why no one freaks out? > What I'm concerned about in the RTCWEB context is that without a universa= l authentication/identity infrastructure, we will end up *promising* a secu= re call, but not *delivering* it. I haven't done the analysis, but it does= not seem implausible to me that FireSheep-like vulnerabilities are lurking= here. > So ISTM the "marketing" argument carries with it some serious risks as we= ll as some small possible benefit. It was my understanding firesheep only works when the connection is HTTP, b= ecause it sniffs the packets. That's a real issue for RTP, not for SRTP (i= n either SDES or DTLS cases). Of course neither I nor anyone else can really foretell what the trade pres= s will say - but I remember what they said about SIP back when a couple ARP= -spoofing "attack" tools demonstrated how to intercept RTP and play it, sin= ce I was in marketing at the time. At the time, the articles were only adv= ocating people should use "SRTP" instead. They didn't care at all what the= key-exchange protocol was. -hadriel From Jim.Barnett@genesyslab.com Wed Mar 28 15:31:37 2012 Return-Path: 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 ACABE21E80B3 for ; Wed, 28 Mar 2012 15:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] 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 vpnIbc1PP85m for ; Wed, 28 Mar 2012 15:31:37 -0700 (PDT) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [198.49.180.223]) by ietfa.amsl.com (Postfix) with ESMTP id EFE6A21E8134 for ; Wed, 28 Mar 2012 15:31:36 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q2SMVUkS000404; Wed, 28 Mar 2012 15:31:30 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 15:31:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Mar 2012 15:31:10 -0700 Message-ID: In-Reply-To: <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SRTP and "marketing" Thread-Index: AQHNDS3wTtwICWEdGUmv8/XIx55mBJaASgFw References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> From: "Jim Barnett" To: "Hadriel Kaplan" , "Richard L. Barnes" X-OriginalArrivalTime: 28 Mar 2012 22:31:29.0728 (UTC) FILETIME=[852A4C00:01CD0D32] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 22:31:37 -0000 Another point is that username/password authentication schemes aren't really that secure - it's pretty easy to steal a username and password, after all. So there's not really a binary authenticated/unauthenticated switch. It's more a matter of degree. =20 - Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Wednesday, March 28, 2012 5:59 PM To: Richard L. Barnes Cc: Subject: Re: [rtcweb] SRTP and "marketing" On Mar 28, 2012, at 11:15 AM, Richard L. Barnes wrote: > Hadriel noted that the competitors to this technology are Skype and Flash, and it's worth considering the security situation with these technologies, because they kind of bracket RTCWEB. With Skype (assuming they've designed it properly), there is actually a universal authentication, under a single authority. So you really do know that you're talking to whatever Skype ID you intend to, and nobody else. With Flash, well, does anyone expect it to be secure anyway? As far as I know, you don't actually "know" that with Skype. You assume it, because you trust Skype. They could forge whatever identity they wanted to, and they can insert a recording middlebox if they wanted to, afaict. No one is concerned about that. They also have skype-in/skype-out to/from the PSTN, and clearly in those cases they can assert whatever identity they want, and record it all. Again no one is concerned. Have you ever wondered why no one freaks out? > What I'm concerned about in the RTCWEB context is that without a universal authentication/identity infrastructure, we will end up *promising* a secure call, but not *delivering* it. I haven't done the analysis, but it does not seem implausible to me that FireSheep-like vulnerabilities are lurking here. > So ISTM the "marketing" argument carries with it some serious risks as well as some small possible benefit. It was my understanding firesheep only works when the connection is HTTP, because it sniffs the packets. That's a real issue for RTP, not for SRTP (in either SDES or DTLS cases). Of course neither I nor anyone else can really foretell what the trade press will say - but I remember what they said about SIP back when a couple ARP-spoofing "attack" tools demonstrated how to intercept RTP and play it, since I was in marketing at the time. At the time, the articles were only advocating people should use "SRTP" instead. They didn't care at all what the key-exchange protocol was. -hadriel _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Wed Mar 28 17:57:24 2012 Return-Path: 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 310C021F857A for ; Wed, 28 Mar 2012 17:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599] 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 3B4YKe+5YllN for ; Wed, 28 Mar 2012 17:57:23 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB5D21F8552 for ; Wed, 28 Mar 2012 17:57:23 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SD3g2-0007pm-IM for rtcweb@ietf.org; Wed, 28 Mar 2012 19:57:22 -0500 Message-ID: <4F73B2B6.9080008@jesup.org> Date: Wed, 28 Mar 2012 20:54:14 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> In-Reply-To: <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 00:57:24 -0000 On 3/28/2012 5:58 PM, Hadriel Kaplan wrote: > On Mar 28, 2012, at 11:15 AM, Richard L. Barnes wrote: > >> Hadriel noted that the competitors to this technology are Skype and Flash, and it's worth considering the security situation with these technologies, because they kind of bracket RTCWEB. With Skype (assuming they've designed it properly), there is actually a universal authentication, under a single authority. So you really do know that you're talking to whatever Skype ID you intend to, and nobody else. With Flash, well, does anyone expect it to be secure anyway? > As far as I know, you don't actually "know" that with Skype. You assume it, because you trust Skype. They could forge whatever identity they wanted to, and they can insert a recording middlebox if they wanted to, afaict. And they do. Very, very quietly I assume. (I.e. they're certainly subject to CALEA in the US for on-net calls, and I assume have a deal with the FCC/etc to cover it.) There have been a few public hints about this and similar deals with other countries. > No one is concerned about that. Define "no one" :-) > They also have skype-in/skype-out to/from the PSTN, and clearly in those cases they can assert whatever identity they want, and record it all. Again no one is concerned. Have you ever wondered why no one freaks out? People don't freak out because a) few realize it, b) most who do realize it's government mandated on them, and fighting it would likely be a huge losing proposition for them ($$$$). If I were a democracy activist in Iran or China other similar countries I would not assume Skype was safe (though in many of those countries it probably is, but probably not China). Those are just my assumptions; small on-net companies and services can fly under the radar or avoid touching things that force them to comply (I did that at Worldgate; no PSTN access == no CALEA). That doesn't mean I don't want to implement a truly secure communications ability. Note that by "secure" here I mean "I can detect if the service MITMd me" -- without reading cert phrases and preferably without having to install client certs and somehow build a working PKI. One idea we've had is a non-centralized WebRTC service built on distributed hash tables and a partial-mesh set of connections used to pass signaling on WebRTC (or other) data channels to set up calls, with some type of Id system to validate who you get connected to (since you can't really trust any of the nodes fully). If an intermediary node can downgrade you to SDES and sniff the keys, there is no security. An alternative would be to allow a hybrid: SDES at the start of a call and rekey over to DTLS-SRTP after the call is connected. If something blocks the DTLS connection it would be treated as a gateway-to-legacy/PSTN call (i.e. show no security, though it's secure against non-in-path attackers); if the DTLS connection is allowed, we can use it to rekey to DTLS-SRTP and to verify identity. This minimizes the risk of bid-down - the primary additional risk is that without initial SDES, to tap the signal you'd need to use a WebRTC-enabled B2BUA to accept the DTLS-SRTP connection and siphon it off. Also, a "good" gateway in a pure DTLS-SRTP world might have a identity established ("gateway@L3.com"); with SDES it wouldn't by default (but it could if it wanted to by rekeying via DTLS also). You also have a start-of-call risk where someone could see & hear until rekeying, and perhaps for a short while by blocking actual rekeying by dropping/corrupting DTLS packets, until the client either gives up or warns of no security. I'm still strongly in favor of pure DTLS-SRTP - as Harald and others say, less moving parts and less things that need to be secured. But this might be a useful compromise if we *need* to support SDES in some cases. -- Randell Jesup randell-ietf@jesup.org From tterriberry@mozilla.com Wed Mar 28 19:30:04 2012 Return-Path: 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 A023821F862B for ; Wed, 28 Mar 2012 19:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LLzkDshRvDzI for ; Wed, 28 Mar 2012 19:30:03 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id D521E21F8624 for ; Wed, 28 Mar 2012 19:30:03 -0700 (PDT) Received: from [130.129.69.85] (dhcp-4555.meeting.ietf.org [130.129.69.85]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 110244AEDD1 for ; Wed, 28 Mar 2012 19:30:02 -0700 (PDT) Message-ID: <4F73C929.9010900@mozilla.com> Date: Wed, 28 Mar 2012 19:30:01 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> In-Reply-To: <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 02:30:04 -0000 Hadriel Kaplan wrote: > As far as I know, you don't actually "know" that with Skype. You assume it, > because you trust Skype. They could forge whatever identity they wanted to, > and they can insert a recording middlebox if they wanted to, afaict. > No one is concerned about that. They also have skype-in/skype-out to/from This is, of course, not true. See, for example, http://www.technologyreview.com/web/38379/ The relevant bit, for those who don't want to read the whole article: '"We met using Mumble [which is open-source, uses digital certificate authentication, and is regarded by Takriz as more secure than Skype].' (brackets in the original). Which is not to say that Tunisian rebels never used Skype (the article mentions several instances where they did), but it is clearly inaccurate to say no one was concerned about it. From ietf@meetecho.com Wed Mar 28 22:41:13 2012 Return-Path: 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 7078521E801B for ; Wed, 28 Mar 2012 22:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 0DIPAq1PQ2oz for ; Wed, 28 Mar 2012 22:41:12 -0700 (PDT) Received: from smtplq01.aruba.it (smtplqs-out27.aruba.it [62.149.158.67]) by ietfa.amsl.com (Postfix) with SMTP id D4CA221E8015 for ; Wed, 28 Mar 2012 22:41:11 -0700 (PDT) Received: (qmail 9194 invoked by uid 89); 29 Mar 2012 05:41:03 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq01.aruba.it with SMTP; 29 Mar 2012 05:41:03 -0000 Received: (qmail 8077 invoked by uid 89); 29 Mar 2012 05:41:03 -0000 Received: from unknown (HELO ?192.168.0.40?) (alex@meetecho.com@78.192.151.119) by smtp2.ad.aruba.it with ESMTPA; 29 Mar 2012 05:41:03 -0000 Message-ID: <4F73F5E8.2080702@meetecho.com> Date: Thu, 29 Mar 2012 07:40:56 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F71D227.60509@meetecho.com> In-Reply-To: <4F71D227.60509@meetecho.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: Re: [rtcweb] Meetecho support for RTCWEB WG meeting session X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 05:41:13 -0000 All, the information below are also valid for today's meeting. Cheers, the Meetecho team Il 27/03/2012 16:43, Meetecho IETF support ha scritto: > Hi all, > > a virtual room has been reserved on the Meetecho system for Wednesday's > RTCWEB WG meeting session. > > Access to the on-line session (including audio and video streams) will > be available at: > http://www.meetecho.com/ietf83/rtcweb > > The Meetecho session automatically logs you into the standard IETF > jabber room. So, from there, you can have an integrated experience > involving all media and allowing you to interact with the room. > Remote participants might also send their own voice to the room, if they > want to, by either calling a landline phone number, or using our > embedded VoIP applet (in this last case they are *strongly* advised to > use a headset). > > A tutorial of interactivity features of the tool can be found at: > http://www.meetecho.com/ietf83/tutorials > > Cheers, > the Meetecho team > From roman@telurix.com Wed Mar 28 22:43:00 2012 Return-Path: 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 04EB321E8037 for ; Wed, 28 Mar 2012 22:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 06WsZq4F+8sR for ; Wed, 28 Mar 2012 22:42:58 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C726321E8015 for ; Wed, 28 Mar 2012 22:42:58 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2945885pbb.31 for ; Wed, 28 Mar 2012 22:42:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=LPGllpoOw3hw3cjuNzrHWGxIxQScuDs/Zq6xK19Ev2U=; b=ZRXx8pc2P2jIC5gqPWw7Lu4FhTbcsJboukxPHGDvm2Z7nii2uU2oHCshRSwSpe06Do jI8zA20STv3q6BF8Flg1/fGgG3S7uSv9NlIC2cYtodE+cY/GEG9KeRLIjmHtAJYotRdF LZRNvhqsQhpomgSwni4moj0VxhiAcdD1gFw4UJIAZptnMsp4hadUW419vDR4Qxh+nR5g SNZwDf1h0DcrZzL1t/CGwRx6RlOJyDFPMvkgSjsnSaogg5hQui3tOAFpgFDYo7LhVVaB zxrsOTkq8yDD0uDRAH7eFh1epOCj6wEEUMe2sCtaudx+axSfMCiOK3Q9+4tW1A02xnEV z4eQ== Received: by 10.68.194.103 with SMTP id hv7mr2800170pbc.133.1332999778559; Wed, 28 Mar 2012 22:42:58 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id y2sm4234382pbe.67.2012.03.28.22.42.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 22:42:57 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2945853pbb.31 for ; Wed, 28 Mar 2012 22:42:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.230.99 with SMTP id sx3mr2779986pbc.55.1332999776978; Wed, 28 Mar 2012 22:42:56 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Wed, 28 Mar 2012 22:42:56 -0700 (PDT) In-Reply-To: <4F73C929.9010900@mozilla.com> References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> <4F73C929.9010900@mozilla.com> Date: Thu, 29 Mar 2012 01:42:56 -0400 Message-ID: From: Roman Shpount To: "Timothy B. Terriberry" Content-Type: multipart/alternative; boundary=047d7b2edf0331489504bc5b327c X-Gm-Message-State: ALoCoQkz2fCWgDLptSN6x4ZUaA2kArw1cnMv0vgF90ogukR3szVpaucafCajjNtaBVGh5z+1jTeT Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 05:43:00 -0000 --047d7b2edf0331489504bc5b327c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 28, 2012 at 10:30 PM, Timothy B. Terriberry < tterriberry@mozilla.com> wrote: > Hadriel Kaplan wrote: > >> As far as I know, you don't actually "know" that with Skype. You assume >> it, >> because you trust Skype. They could forge whatever identity they wanted >> to, >> and they can insert a recording middlebox if they wanted to, afaict. >> No one is concerned about that. They also have skype-in/skype-out to/from >> > > This is, of course, not true. See, for example, > http://www.technologyreview.**com/web/38379/ > > The relevant bit, for those who don't want to read the whole article: '"We > met using Mumble [which is open-source, uses digital certificate > authentication, and is regarded by Takriz as more secure than Skype].' > (brackets in the original). > > Which is not to say that Tunisian rebels never used Skype (the article > mentions several instances where they did), but it is clearly inaccurate to > say no one was concerned about it. > > And then there is an argument that Skype is a huge security risk exactly due to the fact that it is using encrypted communications. There were hints of using Skype communication protocol and Skype client to access files remotely on the user computer or ability to open ports into a local network using a Skype client running there (using Skype as a malicious VPN client). Entire protocol and client are proprietary and were never validated by an independent party as being secure in a sense of preventing unauthorized remote access. This is one of the reasons why Skype is not allowed in a lot of corporate or government networks. Even though this should not apply to WebRTC since it is going to be an open standard with an intensive peer review, it would still apply to the web browsers. If web browser software is compromised due to some sort of attack or malicious plugin (or one of the browser vendors snooping), and since browser applications will start establishing unsolicited encrypted connections, there is no easy way to determine that the browser is not doing something undesirable. I actually believe that if sufficient monitoring constraints are not build into a browser (not to record but at least to monitor who the browser is exchanging data with and using what protocols), WebRTC would be simply disabled in most enterprises as a security risk. _____________ Roman Shpount --047d7b2edf0331489504bc5b327c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 28, 2012 at 10:30 = PM, Timothy B. Terriberry <tterriberry@mozilla.com> wrote:
Hadriel Kaplan wrote:
As far as I know, you don't actually "know" that with Skype. = =A0You assume it,
because you trust Skype. =A0They could forge whatever identity they wanted = to,
and they can insert a recording middlebox if they wanted to, afaict.
No one is concerned about that. =A0They also have skype-in/skype-out to/fro= m

This is, of course, not true. See, for example, http://www.technologyreview.<= u>com/web/38379/

The relevant bit, for those who don't want to read the whole article: &= #39;"We met using Mumble [which is open-source, uses digital certifica= te authentication, and is regarded by Takriz as more secure than Skype].= 9; (brackets in the original).

Which is not to say that Tunisian rebels never used Skype (the article ment= ions several instances where they did), but it is clearly inaccurate to say= no one was concerned about it.


And then there is an argument that Skype is a h= uge security risk exactly due to the fact that it is using encrypted commun= ications. There were hints of using Skype communication protocol and Skype = client to access files remotely on the user computer or ability to open por= ts into a local network using a Skype client running there (using Skype as = a malicious VPN client). Entire protocol and client are proprietary and wer= e never validated by an independent party as being secure in a sense of pre= venting unauthorized remote access. This is one of the reasons why Skype is= not allowed in a lot of corporate or government networks. Even though this= should not apply to WebRTC since it is going to be an open standard with a= n intensive peer review, it would still apply to the web browsers. If web b= rowser software is compromised due to some sort of attack or malicious plug= in (or one of the browser vendors snooping), and since browser applications= will start establishing unsolicited encrypted connections, there is no eas= y way to determine that the browser is not doing something undesirable.=A0 = I actually believe that if sufficient monitoring constraints are not build = into a browser (not to record but at least to monitor who the browser is ex= changing data with and using what protocols), WebRTC would be simply disabl= ed in most enterprises as a security risk.
_____________
Roman Shpount

--047d7b2edf0331489504bc5b327c-- From roman@telurix.com Wed Mar 28 22:56:26 2012 Return-Path: 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 E247321E8051 for ; Wed, 28 Mar 2012 22:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.829 X-Spam-Level: X-Spam-Status: No, score=-2.829 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 SOKgRZq8gmPa for ; Wed, 28 Mar 2012 22:56:26 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C61921E8015 for ; Wed, 28 Mar 2012 22:56:26 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2961596pbb.31 for ; Wed, 28 Mar 2012 22:56:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=qYRTst560ZJjlODwcEs2/B+7ZUNBY5j7b6qFnp0EoOk=; b=Pr1yhBdt3rT+gv9fWerDZL7LZFE0lIRL2TSEvNZ1uCr4OGRtnwA5dj6GUQ4mB4PlpD hlZpKSewt2vNmPObehuX0i0q+g+vo7IPETpJ81NxIcxZorpYax+y2caBSobF17EodYBQ Rd+pxxKt+dpD/bY5QhXi0ckjeHNVICC2Z9LfSeYVXIU3rHSpR6uxiHdAmGQlv4OZdsCE fU3kB4nDmPimzYCTiBPjLKEmuAhPr/XvoL7knUhB7CZIHcP6JeQZxLg9DG9HkDuxlvug 0z/FWIXsAfVS+/nKy+zs19fBJwb12S3ZWzwjrZMUcK03/LBKgHzix4bdmSy0aEvMi+Zv ieEA== Received: by 10.68.135.74 with SMTP id pq10mr2911224pbb.24.1333000585819; Wed, 28 Mar 2012 22:56:25 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id z1sm4270382pbc.38.2012.03.28.22.56.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 22:56:24 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2961538pbb.31 for ; Wed, 28 Mar 2012 22:56:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.40 with SMTP id pp8mr2831960pbb.13.1333000583049; Wed, 28 Mar 2012 22:56:23 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Wed, 28 Mar 2012 22:56:22 -0700 (PDT) In-Reply-To: <4F737DB3.5020804@hidayahonline.org> References: <4F732531.2030208@ericsson.com> <4F737DB3.5020804@hidayahonline.org> Date: Thu, 29 Mar 2012 01:56:22 -0400 Message-ID: From: Roman Shpount To: Basil Mohamed Gohar Content-Type: multipart/alternative; boundary=047d7b10d17b3cf37504bc5b6222 X-Gm-Message-State: ALoCoQl28lqF1qMOFNijmq7ayVIECg4dv2au3zpTw2lMtMI1vqVsumer/7je/CiA0rGxrY0Ekr59 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 05:56:27 -0000 --047d7b10d17b3cf37504bc5b6222 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 28, 2012 at 5:08 PM, Basil Mohamed Gohar < abu_hurayrah@hidayahonline.org> wrote: > The scope of WebRTC is broad enough to consider that we need to think > about what's best going forward with regards to its implementation. > Security by default is one of the best practices in general, the support > from the browser community and others that are behind it will definitely > ensure that adoption is widespread enough to make it easy enough to > integrate into existing systems, as free software solutions will become > available shortly after the standard emerges. > > I would actually challenge the assumption that free software will emerge. SRTP with SDES was released 8 years ago. The only open source library that supported it until recently was libsrtp, which is a broken unusable peace of code spaghetti (GPF crashes, two different replay DBs which do the same thing, random number generator that stops working after generating few thousand keys) that supports 2/3 of the protocol (no F8 support). Majority of open source (and a large number of closed source) clients use this library, but do not see any of those issues since very few real SRTP calls are actually placed. DTLS-SRTP is two years old. Support for it was just added to GNU TLS (unusable by many due to GNU license) and to OpenSSL (using above mentioned libsrtp). There is little or no experience with DTLS-SRTP interop. All of these things are not trivial. My point is, if we require support for encryption implementation in the standard and if 4 or 5 browser vendors will cooperate, we will get vast majority of WebRTC clients security enabled. If everything surrounding WebRTC will not use encryption, it is not a big loss since, in most cases, it is not doing now anyway. _____________ Roman Shpount --047d7b10d17b3cf37504bc5b6222 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 28, 2012 at 5:08 P= M, Basil Mohamed Gohar <abu_hurayrah@hidayahonline.org> wrote:
The scope of WebRTC is broad enough to consider that we need to think
about what's best going forward with regards to its implementation.
Security by default is one of the best practices in general, the support from the browser community and others that are behind it will definitely ensure that adoption is widespread enough to make it easy enough to
integrate into existing systems, as free software solutions will become
available shortly after the standard emerges.


I would actually challenge= the assumption that free software will emerge. SRTP with SDES was released= 8 years ago. The only open source library that supported it until recently= was libsrtp, which is a broken unusable peace of code spaghetti (GPF crash= es, two different replay DBs which do the same thing, random number generat= or that stops working after generating few thousand keys) that supports 2/3= of the protocol (no F8 support). Majority of open source (and a large numb= er of closed source) clients use this library, but do not see any of those = issues since very few real SRTP calls are actually placed. DTLS-SRTP is two= years old. Support for it was just added to GNU TLS (unusable by many due = to GNU license) and to OpenSSL (using above mentioned libsrtp). There is li= ttle or no experience with DTLS-SRTP interop. All of these things are not t= rivial.

My point is, if we require support for encryption implementation in the= standard and if 4 or 5 browser vendors will cooperate, we will get vast ma= jority of WebRTC clients security enabled. If everything surrounding WebRTC= will not use encryption, it is not a big loss since, in most cases, it is = not doing now anyway.
_____________
Roman Shpount

--047d7b10d17b3cf37504bc5b6222-- From bernard_aboba@hotmail.com Wed Mar 28 23:02:08 2012 Return-Path: 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 EB9A521E8049 for ; Wed, 28 Mar 2012 23:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.948 X-Spam-Level: X-Spam-Status: No, score=-101.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 00Sa+IDvkIFL for ; Wed, 28 Mar 2012 23:02:07 -0700 (PDT) Received: from blu0-omc3-s8.blu0.hotmail.com (blu0-omc3-s8.blu0.hotmail.com [65.55.116.83]) by ietfa.amsl.com (Postfix) with ESMTP id C542521E8042 for ; Wed, 28 Mar 2012 23:02:06 -0700 (PDT) Received: from BLU169-W80 ([65.55.116.72]) by blu0-omc3-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 23:02:05 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d5ea533e-84d9-419e-a416-d2373d14ad5b_" X-Originating-IP: [130.129.23.181] From: Bernard Aboba To: Magnus Westerlund , Date: Wed, 28 Mar 2012 23:02:05 -0700 Importance: Normal In-Reply-To: <4F732531.2030208@ericsson.com> References: <4F732531.2030208@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 29 Mar 2012 06:02:05.0960 (UTC) FILETIME=[7803E880:01CD0D71] Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:02:08 -0000 --_d5ea533e-84d9-419e-a416-d2373d14ad5b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with proposition #1 (SRTP) unconditionally.=20 With respect to proposition #2 (DTLS-SRTP)=2C perhaps the words "with detai= ls to be worked out" should have been added. =20 I believe that the consensus achieved was only on a general direction=2C no= t an endorsement of particular proposals.=20 Personally=2C I would like to have more specifics about the required featur= es of DTLS-SRTP in the RTCWEB context. > Date: Wed=2C 28 Mar 2012 16:50:25 +0200 > From: magnus.westerlund@ericsson.com > To: rtcweb@ietf.org > Subject: [rtcweb] Consensus call regarding media security >=20 > WG=2C >=20 > In todays RTCWEB WG meeting there was discussion around media security > mechanism. In this meeting there was some clear consensus in the > meeting which we would like to confirm on the list. >=20 > The first was that there was overwhelming consensus that all RTP > packets SHALL be protected by SRTP. >=20 > Secondly that no one objected against making DTLS-SRTP a mandatory to > implement and the default keying mechanism. Additional mechanisms are > not precluded. >=20 > WG participants may state their position regarding these consensus calls > until 12th of April when the chairs will declare the final consensus. If > you where present in the meeting room and comment on this=2C please > indicate that. >=20 > Best Regards >=20 > Magnus Westerlund > For the WG chairs >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --_d5ea533e-84d9-419e-a416-d2373d14ad5b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree with proposition #1 (SRTP) unconditionally.

With respect to= proposition #2 (DTLS-SRTP)=2C perhaps the words "with details to be worked= out" should have been added. =3B

I believe that the consensus = achieved was only on a general direction=2C not an endorsement of particula= r proposals.

Personally=2C I would like to have more specifics abou= t the required features of DTLS-SRTP in the RTCWEB context.



=
>=3B Date: Wed=2C 28 Mar 2012 = 16:50:25 +0200
>=3B From: magnus.westerlund@ericsson.com
>=3B To:= rtcweb@ietf.org
>=3B Subject: [rtcweb] Consensus call regarding media= security
>=3B
>=3B WG=2C
>=3B
>=3B In todays RTCWEB = WG meeting there was discussion around media security
>=3B mechanism. = In this meeting there was some clear consensus in the
>=3B meeting whi= ch we would like to confirm on the list.
>=3B
>=3B The first was= that there was overwhelming consensus that all RTP
>=3B packets SHALL= be protected by SRTP.
>=3B
>=3B Secondly that no one objected a= gainst making DTLS-SRTP a mandatory to
>=3B implement and the default = keying mechanism. Additional mechanisms are
>=3B not precluded.
>= =3B
>=3B WG participants may state their position regarding these con= sensus calls
>=3B until 12th of April when the chairs will declare the= final consensus. If
>=3B you where present in the meeting room and co= mment on this=2C please
>=3B indicate that.
>=3B
>=3B Best = Regards
>=3B
>=3B Magnus Westerlund
>=3B For the WG chairs<= br>>=3B
>=3B _______________________________________________
>= =3B rtcweb mailing list
>=3B rtcweb@ietf.org
>=3B https://www.iet= f.org/mailman/listinfo/rtcweb
= --_d5ea533e-84d9-419e-a416-d2373d14ad5b_-- From roman@telurix.com Wed Mar 28 23:04:59 2012 Return-Path: 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 4C28221E8064 for ; Wed, 28 Mar 2012 23:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 k9-l+KOzy-py for ; Wed, 28 Mar 2012 23:04:58 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD1F21E8042 for ; Wed, 28 Mar 2012 23:04:57 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1367489ggm.31 for ; Wed, 28 Mar 2012 23:04:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=VCkPminWbw52ppjGvATGunMS0PEzRt+zK7uIfQQ+seI=; b=KKUqIRL62nrFA8U/6DcGKmssq1MnojgEwKvtDsPHQmP+mqxrPMbunmhiDiBzOFB4Dz NR24BG0GJS6CSKMuH7Ot91Vi3MKll9lOLSMxjRc4dtviaJst3c7YkhLUnttaaMs21L7P IFlxlr/VpMuOXkyJ4t7Gz87uSIdfiK1oISBYe8ff92OkMOrNXnSJi3bGwSgJG0QCRZoG PBqPygzEBScdXYIBa21P/72WfJYZCqD1rfQNeQKGqvnB7doBATryB0+ICKM3zF1PtRvJ 3apyDRN0l43aPX8XuigIkgsweOpAHumIg/1dkSncsBJPHSTVWwneoYM9pnuCqhgTtO4q s22A== Received: by 10.68.193.231 with SMTP id hr7mr2897737pbc.44.1333001096034; Wed, 28 Mar 2012 23:04:56 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id o2sm4280069pbb.45.2012.03.28.23.04.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 23:04:55 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2972234pbb.31 for ; Wed, 28 Mar 2012 23:04:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.221.10 with SMTP id qa10mr2898470pbc.139.1333001094439; Wed, 28 Mar 2012 23:04:54 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Wed, 28 Mar 2012 23:04:54 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> Date: Thu, 29 Mar 2012 02:04:54 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8ff24801b821cb04bc5b8056 X-Gm-Message-State: ALoCoQmN+E6P3d2S1/0TAB8zQ8qN13cqp0QUH8TZtIFQsHAq6SAD68MdiY2a0lVma9aO2LoK49D7 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:04:59 -0000 --e89a8ff24801b821cb04bc5b8056 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2012 at 5:11 PM, I=F1aki Baz Castillo wrote= : > In all those scenarios you mention, using security (SRTP) is not *bad*, i= s > it? > The fact that in certain scenarios it could be not needed, it does not > mean that "no security" is better than "security". > > I actually think that you are confusing encryption with security. No encryption often means better security. Bot nets use encryption to communicate, it does not mean they enable user security. In a lot of cases ability for the user to check what exactly they are communicating and to whom is security. As a security conscious person I do not want encrypted communication from my computer or my network unless I know exactly who it is going to. If I do not have to I would prefer my communications to be unencrypted. > RFC 3711 was created in 2004, 8 years ago! > > Which "new" application you mean if it's not capable of implementing a > simple specification from 2004? how "new" is it? is it really new? or > is it a "SIP voicemail server" made in 2002? > > Well let me list them: FreeSwitch, Asterisk, linphone, etc. All of those use libsrtp. For all of them SRTP is broken. Not a single one of them bothered to check or only recently detected problems ( https://issues.asterisk.org/jira/browse/ASTERISK-16665). > > Sorry but I still see *no* argument at all in favour of allowing plain > RTP in WebRTC. And AFAIK there is already consensus about it: plain > RTP is not allowed. > > I do not see an argument why RTP should not be allowed. I think you are arguing we should require a feature (SRTP) for the sake of requiring a feature. _____________ Roman Shpount --e89a8ff24801b821cb04bc5b8056 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 28, 2012 at 5:11 P= M, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
In all those scenarios you mention, using security (SRTP) is not *bad*, is = it?
The fact that in certain scenarios it could be not needed, it does not
mean that "no security" is better than "security".

I actually think that you are= confusing encryption with security. No encryption often means better secur= ity. Bot nets use encryption to communicate, it does not mean they enable u= ser security. In a lot of cases ability for the user to check what exactly = they are communicating and to whom is security. As a security conscious per= son I do not want encrypted communication from my computer or my network un= less I know exactly who it is going to. If I do not have to I would prefer = my communications to be unencrypted.
=A0
RFC 3711 was created in 2004, 8 years ago!

Which "new" application you mean if it's not capable of imple= menting a
simple specification from 2004? how "new" is it? is it really new= ? or
is it a "SIP voicemail server" made in 2002?

Well let me list them: FreeSwitch, Asterisk, linphone= , etc. All of those use libsrtp. For all of them SRTP is broken. Not a sing= le one of them bothered to check or only recently detected problems (https://issues= .asterisk.org/jira/browse/ASTERISK-16665).
=A0

Sorry but I still see *no* argument at all in favour of allowing plain
RTP in WebRTC. And AFAIK there is already consensus about it: plain
RTP is not allowed.

I do no= t see an argument why RTP should not be allowed. I think you are arguing we= should require a feature (SRTP) for the sake of requiring a feature.
_____________
Roman Shpount
--e89a8ff24801b821cb04bc5b8056-- From roman@telurix.com Wed Mar 28 23:06:36 2012 Return-Path: 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 9785A21E8092 for ; Wed, 28 Mar 2012 23:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 sLfxP+KlVvD5 for ; Wed, 28 Mar 2012 23:06:32 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA2F21E8042 for ; Wed, 28 Mar 2012 23:06:32 -0700 (PDT) Received: by yenm5 with SMTP id m5so1355789yen.31 for ; Wed, 28 Mar 2012 23:06:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=89twTRxI8nUiEFYdOwpbiXBwLb0/hIEUeWtvy/eCQ7M=; b=cUQylYHukWQ4GmZHxTBKiIwiTjHWw8W9p/JfKaP5qTxUJkSv+t4/sM3sDsFWUuhGag mD3HMeC8ObmWpt5jcn2QR6RyR2RIj+Gr8sHOcD/KGqO/BtwsJGXVbHC12pzkjFkYx2mf Bntu8oOOa00yIT4NJNaEoimyefxLt/jfbngsBNncknonf8jmfAcswk4vilVXmd7LZQyV anFt98I5Fv+Dxvd/jbzsag9XUA9WJqJ34SjMlEFLBJOc+xRbrnIwigly3CkOyVzVwWPS 46MnVN13zGRCVZPuT1zZmL8JMjKAwyDz+DLKwQQrL6yxKAdW8IeRFKw6Hm4HFVuxnhUX Ps6w== Received: by 10.68.216.234 with SMTP id ot10mr2923187pbc.107.1333001191436; Wed, 28 Mar 2012 23:06:31 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id d4sm4287342pbe.36.2012.03.28.23.06.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 23:06:30 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2974217pbb.31 for ; Wed, 28 Mar 2012 23:06:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.40 with SMTP id or8mr2812830pbb.34.1333001189997; Wed, 28 Mar 2012 23:06:29 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Wed, 28 Mar 2012 23:06:29 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> Date: Thu, 29 Mar 2012 02:06:29 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b10cde36a3dc104bc5b86e1 X-Gm-Message-State: ALoCoQmyTLUPXunnam1EaOoV8C9uogo69YBlus6PIG0dbHEooc2XgYCKCNS0oS0vfSXQV43sVJTk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:06:36 -0000 --047d7b10cde36a3dc104bc5b86e1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2012 at 5:11 PM, I=F1aki Baz Castillo wrote= : > And AFAIK there is already consensus about it: plain > RTP is not allowed. > > AFAIK there is a consensus call on this exact issue right now. Nothing was reached yet. _____________ Roman Shpount --047d7b10cde36a3dc104bc5b86e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 28, 2012 at 5:11 P= M, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
And AFAIK there is already consensus about it: plain
RTP is not allowed.


AFAIK there is a consensus = call on this exact issue right now. Nothing was reached yet.
_____________
Roman Shpount
--047d7b10cde36a3dc104bc5b86e1-- From roman@telurix.com Wed Mar 28 23:18:32 2012 Return-Path: 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 6408D21E8087 for ; Wed, 28 Mar 2012 23:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.831 X-Spam-Level: X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 I2pMYpX5Md1n for ; Wed, 28 Mar 2012 23:18:31 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44F0221E8053 for ; Wed, 28 Mar 2012 23:18:31 -0700 (PDT) Received: by iazz13 with SMTP id z13so2980167iaz.31 for ; Wed, 28 Mar 2012 23:18:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=cFer4RgQiTm4JUHFkKi+TR6DM+2u+phj9PTxedc8fbM=; b=oeA4nfMSnYhGeFLvCvfSBcXzoABs2z27vw1THjo1HSv2YD0gQ1LADsuUCuUfrXOMWb uroSDPYycuRQKJktaL5EVGQ42NR3FnnXmFYKVpmehMTltXlwt664lPtSkbVPqqNFKuyV tO5k0SOhtaqHqTGWxQiuaNEmTGBDCCWvrmZRXSSPwNdoSgIQKKqretoboHY5wmv0f2IX CN8kIuqXeCWTzxUDZWYyhh6iVBxTUm1MxSwrlqqYwK7cA56TaHtpdho+4PyKtwFY/XpP AXghfhLnpAD2IwPA92uqDc74wHUcMXm4H/S1dKRdou9BP4YPrkipV66kuJP6KdZxfGms JM/Q== Received: by 10.68.225.102 with SMTP id rj6mr29557256pbc.120.1333001910593; Wed, 28 Mar 2012 23:18:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id b10sm4304360pbr.46.2012.03.28.23.18.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 23:18:29 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2989302pbb.31 for ; Wed, 28 Mar 2012 23:18:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.240.6 with SMTP id vw6mr21322655pbc.76.1333001908263; Wed, 28 Mar 2012 23:18:28 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Wed, 28 Mar 2012 23:18:28 -0700 (PDT) In-Reply-To: <86CD9009-0557-4F94-9E9F-89DAD2D80FF1@acmepacket.com> References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <86CD9009-0557-4F94-9E9F-89DAD2D80FF1@acmepacket.com> Date: Thu, 29 Mar 2012 02:18:28 -0400 Message-ID: From: Roman Shpount To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=047d7b3395a13a19f304bc5bb163 X-Gm-Message-State: ALoCoQm2sAenWuHXZMQgIwiO67l25WkSaO+kTw2WGIgftjsHSfR29P0KZzmwX1XR4ldycbTWRC6y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:18:32 -0000 --047d7b3395a13a19f304bc5bb163 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 23, 2012 at 11:19 PM, Hadriel Kaplan wrote: > I'm not trying to be pedantic or difficult here, or trying to dismiss the > use-case. I know there are many such "super-tight" networks, but I just > don't see how we can reasonably accommodate their use-case in this WG. And > I'm pointing out that we really are following their policies, inasmuch as > WebRTC media will fail to escape their network - I would be far more > worried if we somehow bypassed their policies instead. At least this way > it's similar behavior they get for unknown/unauthorized applications, which > is arguably what going to random websites and running downloaded javascript > is equivalent to. > Sorry for the late response, but enterprise policy does not have to be WebRTC on or off. It can be video is not allowed from the enterprise network but audio is ok. It can be that enterprise would only allow to communicate with SDP signed by some predefined list of identity providers. It can be that only certain amount of bandwidth can be used for WebRTC traffic. WebRTC media communications can only be allowed with certain IP networks. All of those policies are common with SIP and enterprise session border controllers. Right now there is no granular control similar to the control that you would get by running SIP enabled firewall. I would consider this a serious regression comparing to current SIP based communications and would really like this addressed. _____________ Roman Shpount --047d7b3395a13a19f304bc5bb163 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 23, 2012 at 11:19 = PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:
I'm not trying to be pedantic or difficult here, or trying to dismiss t= he use-case. =A0I know there are many such "super-tight" networks= , but I just don't see how we can reasonably accommodate their use-case= in this WG. =A0And I'm pointing out that we really are following their policies, inasmuch as WebRTC media will fail to escape= their network - I would be far more worried if we somehow bypassed their p= olicies instead. =A0At least this way it's similar behavior they get fo= r unknown/unauthorized applications, which is arguably what going to random websites and running downloaded javascrip= t is equivalent to.

Sorry for the late response, but ent= erprise policy does not have to be WebRTC on or off. It can be video is not= allowed from the enterprise network but audio is ok. It can be that enterp= rise would only allow to communicate with SDP signed by some predefined lis= t of identity providers. It can be that only certain amount of bandwidth ca= n be used for WebRTC traffic. WebRTC media communications can only be allow= ed with certain IP networks. All of those policies are common with SIP and = enterprise session border controllers. Right now there is no granular contr= ol similar to the control that you would get by running=A0 SIP enabled fire= wall. I would consider this a serious regression comparing to current SIP b= ased communications and would really like this addressed.
_____________
Roman Shpount
--047d7b3395a13a19f304bc5bb163-- From roman@telurix.com Wed Mar 28 23:20:53 2012 Return-Path: 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 33D2221E809C for ; Wed, 28 Mar 2012 23:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.833 X-Spam-Level: X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Jax8amfoDoxa for ; Wed, 28 Mar 2012 23:20:52 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id EAAF321E8053 for ; Wed, 28 Mar 2012 23:20:51 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1348733yhk.31 for ; Wed, 28 Mar 2012 23:20:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=T5kawUju0Kn+Y93Ub2gFuIJBdK7wa0XdS44TYqXlD60=; b=WkdJ9OflSNZHNXu5+RUg8VsdMr6RVM/934Zh0/xdTvjdY3PMHc39GZQ8CHRCUSncpN kBf2zaNMIgVReSx2C2QZZCsTvOID32DOItTdrBy3r6k+Do0Ay8tT4cyaJ2pSltVd+PuG PJeCnh0EhRZkBEmEpXw0MTXL7OBAvtg6kbZWnYY30hHFesPQgP82rK8DHn0A1JRQZpDo FlrkJZhI6IOqkVTjefKBmvosGkXvFBMLxffO47eH1CzF/BSeWxkHa6phCCq4bREfyiHl 7602th4YADaiBLlraXxOWfovn9cgl/8LBYEBxOWlICPimYNqbQ9uvAl9aOa+X8xOuy7Q nOOw== Received: by 10.68.225.104 with SMTP id rj8mr3022761pbc.135.1333002051037; Wed, 28 Mar 2012 23:20:51 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id b1sm4298385pbm.68.2012.03.28.23.20.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 23:20:50 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2992189pbb.31 for ; Wed, 28 Mar 2012 23:20:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.201.98 with SMTP id jz2mr2864980pbc.97.1333002049700; Wed, 28 Mar 2012 23:20:49 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Wed, 28 Mar 2012 23:20:49 -0700 (PDT) In-Reply-To: <4F6CC346.9000703@alvestrand.no> References: <4F4759DC.7060303@ericsson.com> <4F68A4CC.9090306@alvestrand.no> <4F6AECC6.8020004@alvestrand.no> <13C620B3-1297-4212-B61C-5643E08E9748@acmepacket.com> <4F6CC346.9000703@alvestrand.no> Date: Thu, 29 Mar 2012 02:20:49 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7b15aee9a8430604bc5bb9db X-Gm-Message-State: ALoCoQloaiMOgACsjH2fFJJlwPk0yCujtpR+j421UOUAu9FplYaDFvfOLWQZB6d78aDjN53mpkne Cc: "" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:20:53 -0000 --047d7b15aee9a8430604bc5bb9db Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 23, 2012 at 2:39 PM, Harald Alvestrand wrote: > ** > It seems to me that you are arguing that the scenarios in section 4.1 of > the use cases document do not cover that specific case, and I think you are > right in that; the list is: > > The following considerations are applicable to all use cases: > o Clients can be on IPv4-only > o Clients can be on IPv6-only > o Clients can be on dual-stack > o Clients can be on wideband (10s of Mbits/sec) > o Clients can be on narrowband (10s to 100s of Kbits/sec) > o Clients can be on variable-media-quality networks (wireless) > o Clients can be on congested networks > o Clients can be on firewalled networks with no UDP allowed > o Clients can be on networks with cone NAT > o Clients can be on networks with symmetric NAT > > Now, there are two ways to interpret this omission: > > - The WG did not think of that use case when the list was created > - The WG does not want that use case on the list because it constrains the > solution space too much > > If (re)opening this issue, I think I'd find myself in the "do not want > that use case" camp. > > I do not recall this use case ever being discussed on the working group, so I would assume the current situation is due to WG not thinking about this case when the list was created. _____________ Roman Shpount --047d7b15aee9a8430604bc5bb9db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 23, 2012 at 2:39 P= M, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20 =20
It seems to me that you are arguing that the scenarios in section 4.1 of the use cases document do not cover that specific case, and I think you are right in that; the list is:

=A0=A0 The following considerations are applicable to all use cases: =A0=A0 o=A0 Clients can be on IPv4-only
=A0=A0 o=A0 Clients can be on IPv6-only
=A0=A0 o=A0 Clients can be on dual-stack
=A0=A0 o=A0 Clients can be on wideband (10s of Mbits/sec)
=A0=A0 o=A0 Clients can be on narrowband (10s to 100s of Kbits/sec)
=A0=A0 o=A0 Clients can be on variable-media-quality networks (wireless= )
=A0=A0 o=A0 Clients can be on congested networks
=A0=A0 o=A0 Clients can be on firewalled networks with no UDP allowed =A0=A0 o=A0 Clients can be on networks with cone NAT
=A0=A0 o=A0 Clients can be on networks with symmetric NAT

Now, there are two ways to interpret this omission:

- The WG did not think of that use case when the list was created
- The WG does not want that use case on the list because it constrains the solution space too much

If (re)opening this issue, I think I'd find myself in the "do = not want that use case" camp.


I do not recall this use case ev= er being discussed on the working group, so I would assume the current situ= ation is due to WG not thinking about this case when the list was created. =
_____________
Roman Shpount
--047d7b15aee9a8430604bc5bb9db-- From lists@infosecurity.ch Wed Mar 28 23:22:34 2012 Return-Path: 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 132E721E80A9 for ; Wed, 28 Mar 2012 23:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 fxmQcKO-hC9o for ; Wed, 28 Mar 2012 23:22:33 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B17BC21E80AE for ; Wed, 28 Mar 2012 23:22:32 -0700 (PDT) Received: by eaaq11 with SMTP id q11so750898eaa.31 for ; Wed, 28 Mar 2012 23:22:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=bGZzEMqle/Q/KgxrF5pEdPfn9fBAcboISg6W+tecAxM=; b=gk4tOknn9X14oEn+Kllxoa0tWsXlcEWBMQcOTSGb5DLx5aAelN8W7p9ZbfQYBiekwr n2zt//+45z7Zag5XEK5ig7uDegfKm0z+OkWQFvq30zoFu5dT6XINcPLOrf0TRHxrNZQp GVKHP8yy8dNy77HH3rNe2NMfpwIaqi98/LNhvlZ98hXVQms8EIZhKxblFh0KFeH0SyIW pF9foFjI89dq7zkjhWDNhCRFx35Q9RrHmvg9aUfDVpRQ+tPmD+7XDmx1tvYtZYcX47vQ j9pvZfb0kO4qfH3s6hZ1EZ0RKdopGWshGjhwymgldwmhUjKOevOzrOAPLJGPclDvHJ9e U1Jg== Received: by 10.213.28.198 with SMTP id n6mr2313130ebc.298.1333002151569; Wed, 28 Mar 2012 23:22:31 -0700 (PDT) Received: from sonyvaiop13.local (93-32-184-146.ip34.fastwebnet.it. [93.32.184.146]) by mx.google.com with ESMTPS id r44sm18267416eef.2.2012.03.28.23.22.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 23:22:30 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F73FFA6.2030402@infosecurity.ch> Date: Thu, 29 Mar 2012 08:22:30 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "" References: <4F72D6B3.40803@bbn.com> <4F72E453.7070204@alvestrand.no> <4F72EB53.5000409@bbn.com> <0bf301cd0d04$22d53200$687f9600$@com> <00052A1F-CE65-4A53-9B7D-261E1CC75426@acmepacket.com> In-Reply-To: <00052A1F-CE65-4A53-9B7D-261E1CC75426@acmepacket.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl4iT6GBLmAGKd7pjizGl1tznXEJYSb7JhhzaPbTK0USwN9DhMvz7yBWFw89Aw5MdSr0wsi Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:22:34 -0000 On 3/28/12 11:58 PM, Hadriel Kaplan wrote: > > On Mar 28, 2012, at 6:59 PM, Dan Wing wrote: > >> We do need a foundation upon which an authentication/identity >> infrastructure can be built. We know we need one. >> That foundation is DTLS-SRTP, and not Security Descriptions. > > Now you're starting to sound like a marketing guy. ;) > What's next: "we'll build more synergy and have a unified platform with DTLS-SRTP"? > > But more seriously, I don't understand this "foundation" argument. We're going to have DTLS-SRTP. No one's suggesting we don't have DTLS-SRTP. I'm no-one, but i would strongly argue to use SDES-SRTP considering that forcing the world to implement a non-used new standard (DTLS-SRTP) for a new not-yet-implemented new standard (WebRTC) it's a fault. > All Browsers MUST implement DTLS-SRTP. We'll have it for Browser-to-Browser, and for Browser-to-Gateway if the Gateway supports it. We'll have the foundation. > > Requiring it for Gateways would make sense if it offered some real advantage, or didn't have any disadvantages. There don't appear to be real advantages, while we know of disadvantages. And gateways have no real means of offering an end-to-end identity. Why would you want to build a foundation on air? We need to build a new protocol on the foundation of existing protocol. DTLS-SRTP doesn't exists because no-one use it, there are no diffused implementation and no interoperability testing done. DTLS-SRTP require a *huge effort* to set it up. SDES-SRTP does not require such *huge effort* and will unleash the advantage of an existing ecosystem of application and protocol stacks already there. While i understand Mr. Wing points related to Identity, i think that Identity will be guaranteed not at "media level" but from existing transport that is HTTP/HTTPS and all the W3C protocol that run on top of the Web (Federated Authority) to handle Authorization and Authentication. Reinventing something new it's imho just wrong. -- Fabio Pietrosanti Founder, CTO Tel: +39 02 911930893 + ext: 907 Mobile: +39 340 1801049 E-mail: fabio.pietrosanti@privatewave.com Skype: fpietrosanti Linkedin: http://linkedin.com/in/secret PrivateWave Italia S.p.A. Via Gaetano Giardino 1 - 20123 Milano - Italy www.privatewave.com From lists@infosecurity.ch Wed Mar 28 23:24:54 2012 Return-Path: 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 5302B21E80C1 for ; Wed, 28 Mar 2012 23:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Wk6iae4XnPR2 for ; Wed, 28 Mar 2012 23:24:53 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 037F621E8048 for ; Wed, 28 Mar 2012 23:24:52 -0700 (PDT) Received: by eeke51 with SMTP id e51so744971eek.31 for ; Wed, 28 Mar 2012 23:24:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=32ic35RxMSprZG4fLjRdqxkUasRSKrkl5LiUbZeh9yk=; b=Pn6e/2NnpE2FEyLFe35R6K9AIUubjcUts0OWfQmKbB+65aVsQZ09wPy+dayz0lRdFt KHqqnijCEuRrAPTzkl4bf1rKV5byzrl1emO9yJsi6V40TbQf/082IR5JMgCfrgfvC/9/ 4kQghjdJt9bbUzlF2IZzurPozjp0tmvgsE68SyDwUm1lpBZj08C61LQ0m6QyNf5HpqgK kSuwpMOyxA+GTmiuijQtdM2sXvR3YxrKbZ/1Kb49R0EbfbLFiq70y5OIhd8bs7f66HPw +zDL6+kTMb4P9vdBCKJIt8cNFafT0mzoD596Xl0+nwtEYxNizBcmxbrzJWjLrNB9UzCM 2XWQ== Received: by 10.213.105.132 with SMTP id t4mr2354214ebo.107.1333002292053; Wed, 28 Mar 2012 23:24:52 -0700 (PDT) Received: from sonyvaiop13.local (93-32-184-146.ip34.fastwebnet.it. [93.32.184.146]) by mx.google.com with ESMTPS id d54sm18227231eei.9.2012.03.28.23.24.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 23:24:51 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F740033.1090004@infosecurity.ch> Date: Thu, 29 Mar 2012 08:24:51 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "" References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk+jxnD3RKsOgv466wRMm5JFOe1uj+/tVA6TuCUoyXLKe6AC4x0Jtuzo61mieQEtZxsmIoN Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:24:54 -0000 On 3/29/12 12:31 AM, Jim Barnett wrote: > Another point is that username/password authentication schemes aren't > really that secure - it's pretty easy to steal a username and password, > after all. So there's not really a binary > authenticated/unauthenticated switch. It's more a matter of degree. Why we would like to solve this problem at WebRTC level, while there's a stockpile of standard, best-practice and future perspective to authenticate/authorize users over Web secured (TLS) transport? VoIP for Browser imply that we have a Browser and a Web application (server & client side javascript). Imho we should re-use what's already there trying to avoid adding more complexity. -- Fabio Pietrosanti Founder, CTO Tel: +39 02 911930893 + ext: 907 Mobile: +39 340 1801049 E-mail: fabio.pietrosanti@privatewave.com Skype: fpietrosanti Linkedin: http://linkedin.com/in/secret PrivateWave Italia S.p.A. Via Gaetano Giardino 1 - 20123 Milano - Italy www.privatewave.com From lists@infosecurity.ch Wed Mar 28 23:27:23 2012 Return-Path: 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 1375B21F84B4 for ; Wed, 28 Mar 2012 23:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 WNQkS0RjDzCZ for ; Wed, 28 Mar 2012 23:27:22 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E38F421F84B2 for ; Wed, 28 Mar 2012 23:27:21 -0700 (PDT) Received: by eeke51 with SMTP id e51so747729eek.31 for ; Wed, 28 Mar 2012 23:27:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=s5EIbdTukwAEQbWX16uxvbF8DCeNq78kAf54WeUjmAg=; b=fnDSONg97iXTMrnYyza2Bw6ahF0Ee6WAFhqoVJVvWOLh4JT+Lz2nTAQsdKX8Zniiq1 TVX424z7cUcQaUnEc3aSARFSzrNn0P5oyzlWUE9QHY7dJulfu+7+zVBJ9kCWuLwRWhqj U9o4gMhAKjbzz2f+AUeZK7qPXy+bSdrllhtXahHSGgqGfHAFL61T3Tz1DexIn8WC13A3 qsos9asrT/uKukVer9Su1HhF4jgbD+N2GCMZHUbqqWelS3l1wSnLiwl9Pd3XumlQHtLM ++wL20QPm2mA3UuscSBi1VQTqq25UVTMeIoSokdBSEGN6jEoLcJtgTKbSkAdx7Sit2bv JI3A== Received: by 10.213.36.8 with SMTP id r8mr2410279ebd.112.1333002440954; Wed, 28 Mar 2012 23:27:20 -0700 (PDT) Received: from sonyvaiop13.local (93-32-184-146.ip34.fastwebnet.it. [93.32.184.146]) by mx.google.com with ESMTPS id e56sm18242833eea.11.2012.03.28.23.27.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 23:27:20 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F7400C7.6070605@infosecurity.ch> Date: Thu, 29 Mar 2012 08:27:19 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "" References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> <4F73C929.9010900@mozilla.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkiwmw1jhYFLp54ZYHV0MeFyMVHD1YaRgxOHmoUd255vwntnY6FmQ2ug9M4t7sFdVDypfgP Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:27:23 -0000 On 3/29/12 7:42 AM, Roman Shpount wrote: > I actually believe that if sufficient > monitoring constraints are not build into a browser (not to record but > at least to monitor who the browser is exchanging data with and using > what protocols), WebRTC would be simply disabled in most enterprises as > a security risk. Your concern would be addressed by the use of SDES-SRTP rather than DTLS-SRTP. SDES-SRTP would provide, in the context of WebRTC, the transport of SDES key over HTTP(S) and so would let all existing methods for HTTP/HTTPS inspection to works fine. Technology for inspection of HTTP/HTTPS traffic already exists, are widely deployed and so if we transport keying material over HTTP (with SDES-SRTP), all Enterprises will already have their existing infrastructure in-place. -- Fabio Pietrosanti Founder, CTO Tel: +39 02 911930893 + ext: 907 Mobile: +39 340 1801049 E-mail: fabio.pietrosanti@privatewave.com Skype: fpietrosanti Linkedin: http://linkedin.com/in/secret PrivateWave Italia S.p.A. Via Gaetano Giardino 1 - 20123 Milano - Italy www.privatewave.com From lists@infosecurity.ch Wed Mar 28 23:44:20 2012 Return-Path: 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 054AF21E80DB for ; Wed, 28 Mar 2012 23:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] 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 3ubnyaNhAiXs for ; Wed, 28 Mar 2012 23:44:18 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 341B821E805D for ; Wed, 28 Mar 2012 23:44:17 -0700 (PDT) Received: by eaaq11 with SMTP id q11so774414eaa.31 for ; Wed, 28 Mar 2012 23:44:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=HYnpPBSz2biNqK3WByKGrQRnQlfxafyJM54wt8WaBfc=; b=A+buKtCE0gQPFPtqNeQTSfs6sCqq519MwhbAfai6W4Z3m1zpjnmoXORZdKI++XJIq8 jly4o9veRyyH8FaD4eX9VfYG0yEvHKLAMU5X5SaEGbqyQdmadj2T7nSZNsvx2l9oXv+4 qSZD5NRmqlZNsstNEc8kijBjnSMmgmqiXDFHOmIfaYQpRz0Rshdwplfl/GA0c9zvsr47 gdk8D15wf5SJW6uHJrXLlIlOGG6Wv/1UPvue+/4pGLfj8sNc0sCw0hOVlqQWC5U5PGlf vwflGLf9JUkuC+2IPx7ROCeyvCvzNCYe1lglk6zNoeaE/xUUwVBa+rHytastNkDFUkk7 Bs3w== Received: by 10.213.34.201 with SMTP id m9mr2186355ebd.216.1333003455268; Wed, 28 Mar 2012 23:44:15 -0700 (PDT) Received: from sonyvaiop13.local (93-32-184-146.ip34.fastwebnet.it. [93.32.184.146]) by mx.google.com with ESMTPS id n56sm18447609eeb.4.2012.03.28.23.44.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 23:44:14 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F7404BE.9070302@infosecurity.ch> Date: Thu, 29 Mar 2012 08:44:14 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "" References: <4F732531.2030208@ericsson.com> <4F7351EB.8020504@hidayahonline.org> In-Reply-To: <4F7351EB.8020504@hidayahonline.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlYJuPX9YLCODfGlMHYs2BFC+Om3Sq61yQMxBwbyTYSxt+bp7bP1UuXwOVU3ffIH+jffkR/ Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:44:20 -0000 On 3/28/12 8:01 PM, Basil Mohamed Gohar wrote: >> IMHO it's really clear that SRTP (even with SDES) is MUCH better than >> plain RTP. And so far I have not heard any advantage fof allowing >> plain RTP other than "it allows interoperability with my 5 years ago >> SIP device". >> >> So +1 for the voted consensus. >> >> Regards. > This captures the sentiment of what I was trying to convey. So, +1 to > this explanation. +1 I totally support this initiative. If we would allow plain RTP any people with just using free too such as Cain&Abel http://www.oxid.it/cain.html can do Mitm+RTP-recording+Playing with a couple of click. We do not really want to see such kind of reviews and widespread of dumb-proof hacking tools/video/howto to show "your grandma how easy is to intercept your neighborhood calls". That's just a bad reputation that will hit that newly born technology. -- Fabio Pietrosanti Founder, CTO Tel: +39 02 911930893 + ext: 907 Mobile: +39 340 1801049 E-mail: fabio.pietrosanti@privatewave.com Skype: fpietrosanti Linkedin: http://linkedin.com/in/secret PrivateWave Italia S.p.A. Via Gaetano Giardino 1 - 20123 Milano - Italy www.privatewave.com From roman@telurix.com Wed Mar 28 23:45:59 2012 Return-Path: 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 A64C021E80E2 for ; Wed, 28 Mar 2012 23:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.835 X-Spam-Level: X-Spam-Status: No, score=-2.835 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 KTEcfY5k4eX6 for ; Wed, 28 Mar 2012 23:45:58 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A79D21E80E6 for ; Wed, 28 Mar 2012 23:45:58 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so3024028pbb.31 for ; Wed, 28 Mar 2012 23:45:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=lrwrCxE7y9nvXTzh4+XQ1uos2n6FS09buQggkkPpbhk=; b=Ji+raQ1cWi/GUcp+NoCDkepyKvHrJ4NZSS9SVhdZCyHKlKT0pEwvvlbDsFEuc8AswL V27JML1VgtFZJXgKpA35UCOUIqvWGfxaGe92pdClfBbMnnvE6kG7KE6j71fkEeyLmf2M 2YqGkh/8j/tT5iBUnpP5NlK/ueQ72zQyxJ8xQFGhwRxffqxzxEOObTabb/kvWhqGB/7X GX1x2+VOs+i59NttKA+xsy6eY3SWhUyt1gHrC08XzqhoTcv24n23jC90nT1RZu0cFEV/ VYATj/RAL5HRwEnDTERn8dhPKRJBPqumDabelALdntHLK06i1zWxyoXCYddjGOjQ04vC Z+vQ== Received: by 10.68.224.99 with SMTP id rb3mr12271767pbc.79.1333003557562; Wed, 28 Mar 2012 23:45:57 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id p5sm4365044pbd.15.2012.03.28.23.45.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 23:45:56 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so3023985pbb.31 for ; Wed, 28 Mar 2012 23:45:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.99 with SMTP id ot3mr3176345pbb.160.1333003556016; Wed, 28 Mar 2012 23:45:56 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Wed, 28 Mar 2012 23:45:55 -0700 (PDT) In-Reply-To: <4F7400C7.6070605@infosecurity.ch> References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> <4F73C929.9010900@mozilla.com> <4F7400C7.6070605@infosecurity.ch> Date: Thu, 29 Mar 2012 02:45:55 -0400 Message-ID: From: Roman Shpount To: "Fabio Pietrosanti (naif)" Content-Type: multipart/alternative; boundary=047d7b15a68b70d2b504bc5c13fd X-Gm-Message-State: ALoCoQlyvlc3jJ2x67w+GQD1eEtoIKm+MFyQRI1A53dXZJP/aOPdTo5ilT/gYL93Qcx4PMd7jGU7 Cc: "" Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:45:59 -0000 --047d7b15a68b70d2b504bc5c13fd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 29, 2012 at 2:27 AM, Fabio Pietrosanti (naif) < lists@infosecurity.ch> wrote: > On 3/29/12 7:42 AM, Roman Shpount wrote: > > I actually believe that if sufficient > > monitoring constraints are not build into a browser (not to record but > > at least to monitor who the browser is exchanging data with and using > > what protocols), WebRTC would be simply disabled in most enterprises as > > a security risk. > > Your concern would be addressed by the use of SDES-SRTP rather than > DTLS-SRTP. > > SDES-SRTP would provide, in the context of WebRTC, the transport of SDES > key over HTTP(S) and so would let all existing methods for HTTP/HTTPS > inspection to works fine. > > Technology for inspection of HTTP/HTTPS traffic already exists, are > widely deployed and so if we transport keying material over HTTP (with > SDES-SRTP), all Enterprises will already have their existing > infrastructure in-place. > I am not sure I would agree with this. In order for what you propose to work there is a need for a reliable mechanism to extract SDP from HTTP/HTTPS traffic. This is not as simple as you would think, since JavaScript application can use any custom protocol to transmit the SDP data. It can, for instance, even implement encryption in JavaScript that will encode SDP using user supplied key, which would make SDP extraction impossible. In order to implement such inspection we need to have some sort of hook in the browser that allows an external entity to intercept and examine all the SDP being passed to and from WebRTC. Without such hook there is no benefit to SDES. With such hook there is no downside to DTLS. _____________ Roman Shpount --047d7b15a68b70d2b504bc5c13fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 29, 2012 at 2:27 A= M, Fabio Pietrosanti (naif) <lists@infosecurity.ch> wrote:
On 3/29/12 7:42 AM, Roman Shpount wrote:
> I actually believe that if sufficient
> monitoring constraints are not build into a browser (not to record but=
> at least to monitor who the browser is exchanging data with and using<= br> > what protocols), WebRTC would be simply disabled in most enterprises a= s
> a security risk.

Your concern would be addressed by the use of SDES-SRTP rather than DTLS-SRTP.

SDES-SRTP would provide, in the context of WebRTC, the transport of SDES key over HTTP(S) and so would let all existing methods for HTTP/HTTPS
inspection to works fine.

Technology for inspection of HTTP/HTTPS traffic already exists, are
widely deployed and so if we transport keying material over HTTP (with
SDES-SRTP), all Enterprises will already have their existing
infrastructure in-place.

I am not sure I would agr= ee with this. In order for what you propose to work there is a need for a r= eliable mechanism to extract SDP from HTTP/HTTPS traffic. This is not as si= mple as you would think, since JavaScript application can use any custom pr= otocol to transmit the SDP data. It can, for instance, even implement encry= ption in JavaScript that will encode SDP using user supplied key, which wou= ld make SDP extraction impossible. In order to implement such inspection we= need to have some sort of hook in the browser that allows an external enti= ty to intercept and examine all the SDP being passed to and from WebRTC. Wi= thout such hook there is no benefit to SDES. With such hook there is no dow= nside to DTLS.
_____________
Roman Shpount

--047d7b15a68b70d2b504bc5c13fd-- From lists@infosecurity.ch Thu Mar 29 00:05:47 2012 Return-Path: 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 D9EF721E80E8 for ; Thu, 29 Mar 2012 00:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 CFoUX2IiXtx8 for ; Thu, 29 Mar 2012 00:05:46 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0DF321E80DD for ; Thu, 29 Mar 2012 00:05:44 -0700 (PDT) Received: by eaaq11 with SMTP id q11so798950eaa.31 for ; Thu, 29 Mar 2012 00:05:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=PMwYd1CCf2P1OOnT39iEk46EKmVI2bZsbFilVWtygQ4=; b=ULklUJ/DxTHgtAOMmvQ6PVMFQ1A2GHkQ40BfQigakIxhY7P6m2huO0+z15W6aMXZ4x ntpsTbPruz21jJKYLk+x52h4uHdNlBuS81MZ6t9c5xbQWJOaQgJ+89nHvOrAIYjbKuT6 bLiuedhEze9+dvlmmnpg25/tdskWSoUnD9PJ61dV7c8gEONw6WsXPkT8plqfe2GOn1LP 56wkCpcwPzTK7/2tHvw7ElRY1tdpr67H9RtXgFom9GK/LfRP48CRD/qjNuqZYMTjY8Vy bKfMKqBAeT3D76dFaWxr+erU3cF9ZNwZ7kysnG9fZ0uuiKQpGvWDC2AJ6u1YFwqjv2jQ tV7A== Received: by 10.213.28.196 with SMTP id n4mr2353947ebc.0.1333004744133; Thu, 29 Mar 2012 00:05:44 -0700 (PDT) Received: from sonyvaiop13.local (93-32-184-146.ip34.fastwebnet.it. [93.32.184.146]) by mx.google.com with ESMTPS id p57sm18586035eei.8.2012.03.29.00.05.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 00:05:43 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F7409C4.407@infosecurity.ch> Date: Thu, 29 Mar 2012 09:05:40 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4F73697D.5080006@infosecurity.ch> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQlpX3W7Y49dwNOzCNJ5GWo4WrsjdJVBfh+9cRfrFlIGp5aSyR1sac4hDOLlkhrX0L+1Lhm5 Cc: "" Subject: Re: [rtcweb] DTLS-SRTP implementation diffusion: Why not SDES-SRTP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 07:05:48 -0000 On 3/28/12 9:53 PM, Iñaki Baz Castillo wrote: > 2012/3/28 Fabio Pietrosanti (naif) : >> Hi all, >> >> i read that 80% of Sipit participant support SDES-SRTP but 0% support >> DTLS-SRTP https://www.sipit.net/SIPit29_summary . >> >> At SIPit there were 34 attendees from 17 companies visiting from 12 >> countries with 25 distinct VoIP implementations. > > Right, but this is rtcweb, not SIP. > > > >> I do not really see which is the rationale in making DTLS-SRTP mandatory >> while plain SRTP with SDES key exchange is already so well know and used. > > That's a good reason to *also* allow (and mandate) SDES-SRTP support > in WebRTC clients, much better than the interoperability with SIP > (again: this is rtcweb, not SIP world). That's true, but it's also true that the "rtcweb world" will strictly inter-operate with the "sip world". It would be reasonable to expect that current existing PBX software would evolve also with support for Rtcweb, to provide Web phone systems. In particular all opensource software will setup the path for the adoption of the standard, as we know history will repeat. It appear me as natural behavior of diffusion of implementation, and for that reason i see the need to "easily" inter-operate with the SIP world is a key value point. Creating an incompatible "media format" would require a lot of more effort because the "amount of compatibility testing to be done with DTLS-SRTP will be significantly higher than SDES-SRTP" . So it would provide an advantage for the *few vendor* supporting it, practically introducing a *technological entrance barrier*. This is a bad practice already see in other standard bodies. > > >> Anyone can provide some very strong and valuable point about using >> DTLS-SRTP (considering it's weak diffusion and incompatibility risks)? > > Lot of recent threads about this topic in this maillist. But also > check a recent presentation (yesterday in IETF Pairs): > > http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf I would like to strongly argue against the SLIDE 3 statement that "DTLS-SRTP meets RTCWEB's technical requirements" . DTLS-SRTP doesn't meet the RTCWEB's technical requirements because: - It does NOT provide inter-operation with existing SIP endpoints This is confirmed by the October 2011 SIPit data, with 80% of participants supporting, with good interoperability, SDES but with 0% supporting DTLS-SRTP . In order to try to "try to improve it's non-interoperability issue" the DTLS-SRTP is re-proposing him-selves as DTLS-SRTP-EKT . To speaking about the fact that even EKT draft explain that: " Today, Security Descriptions [RFC4568] is used for distributing SRTP keys in several different IP PBX systems and is expected to be used by 3GPP's Long Term Evolution (LTE). " http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-01#section-6.1 So: - Internt is using SDES-SRTP - 3GPP LTE is using SDES-SRTP - WebRTC is going to use DTLS-SRTP I do not really see how we can rationally accept to follow this different direction. I mean, we are discussing about a "new standard" that's based on "new technologies" rather than using existing, widely implemented technology. Do we really understand how much effort we are going to cause on the overall technological and security ecosystem by selecting DTLS-SRTP rather than SDES-SRTP? All US Federal Government will not be able to use WebRTC because NSA standardized SDES-SRTP for use in Classified communication: http://www.nsa.gov/ia/programs/mobility_program/index.shtml The argument that DTLS is *more secure* must face the reality that no-one is using it and that SDES-SRTP is *widely diffused and interoperable*. All Internet operators will have to introduce Protocol Gateway. All mobile operators will have to introduce Protocol Gateway. All that subjects, if using just SDES-SRTP, would just need to "update the software they already use to run VoIP infrastructure" with no need to handle modification to the Media for Interworking. So definitely the choice to go for DTLS-SRTP is imho a wrong choice, against any rationale for the diffusion of WebRTC standard, introducing artificially complexity where it may be possible to keep it simple. -- Fabio Pietrosanti Founder, CTO Tel: +39 02 911930893 + ext: 907 Mobile: +39 340 1801049 E-mail: fabio.pietrosanti@privatewave.com Skype: fpietrosanti Linkedin: http://linkedin.com/in/secret PrivateWave Italia S.p.A. Via Gaetano Giardino 1 - 20123 Milano - Italy www.privatewave.com From magnus.westerlund@ericsson.com Thu Mar 29 00:09:49 2012 Return-Path: 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 C865321E8102 for ; Thu, 29 Mar 2012 00:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.197 X-Spam-Level: X-Spam-Status: No, score=-108.197 tagged_above=-999 required=5 tests=[AWL=-1.948, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 VyzNLHK9xTT4 for ; Thu, 29 Mar 2012 00:09:48 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB2021E8100 for ; Thu, 29 Mar 2012 00:09:48 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-3d-4f740abaffd1 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA) Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 67.C5.25560.ABA047F4; Thu, 29 Mar 2012 09:09:46 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Thu, 29 Mar 2012 09:09:45 +0200 Message-ID: <4F740AB6.1080609@ericsson.com> Date: Thu, 29 Mar 2012 09:09:42 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Poll for dates for Interim Meeting before IETF 84 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 07:09:49 -0000 WG, We have started a doodle poll for an Interim meeting before IETF 84 in Vancouver. Locations considered so far are Stockholm, Boston Area or Silicon Valley. The meeting is planned to be a 2 day meeting. Please indicate which of the suggest times that works for you. http://doodle.com/nm3pp69znr3286cy Cheers Magnus Westerlund WG chair From martin.thomson@gmail.com Thu Mar 29 00:39:01 2012 Return-Path: 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 E68D821F8664 for ; Thu, 29 Mar 2012 00:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.842 X-Spam-Level: X-Spam-Status: No, score=-4.842 tagged_above=-999 required=5 tests=[AWL=-1.243, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ghRDxjyP5KNm for ; Thu, 29 Mar 2012 00:39:00 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 643AA21F87F8 for ; Thu, 29 Mar 2012 00:38:58 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1833786bku.31 for ; Thu, 29 Mar 2012 00:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=NiE+kj8NpXllPA17v1caTBDGPRJub9Ws8FR68aKU3uA=; b=MUOq00rZ8NVF42RQ1iXyvzG39cQRkk4j96c1m+X7a2zhAMyHGzW0qz064nXLd3iMhd +V3cgB/iugGdN4J/uuoxosb6TMe5c1KuPnBIHE4DDHc26tPau0TfD0Wkv9r5tJlGh+6L 1lDMgMVEUZWGTjN/BWOCsTwQF6f3VhYhOTg2lRaiAi8x3V2JXphomIKeXr7Jwi1J/mG3 rIG1MfIsZMLSP5f/9vgA8iCFG5TW79pVbnFNT+Y7RXXhYD3it50TKM7QEwvkkVVNI+s2 KAzS3DMxoNdtkQQTCu/Cwnvx2BOxoVw8aov63LxzuxS9k1HPtqsMRlYjbKGAKmix73QZ vKLg== MIME-Version: 1.0 Received: by 10.204.156.2 with SMTP id u2mr13379721bkw.101.1333006737465; Thu, 29 Mar 2012 00:38:57 -0700 (PDT) Received: by 10.205.38.73 with HTTP; Thu, 29 Mar 2012 00:38:57 -0700 (PDT) Date: Thu, 29 Mar 2012 09:38:57 +0200 Message-ID: From: Martin Thomson To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] (pr)answer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 07:39:01 -0000 ...is a matter for API, not a subject for the IETF. Release of "resources" is the only feature that PRANSWER provides. This is the business of the contract between application and application host (browser). --Martin From magnus.westerlund@ericsson.com Thu Mar 29 00:57:15 2012 Return-Path: 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 DA7F321F8587 for ; Thu, 29 Mar 2012 00:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.174 X-Spam-Level: X-Spam-Status: No, score=-108.174 tagged_above=-999 required=5 tests=[AWL=-1.925, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 5oHh9CyWSPWD for ; Thu, 29 Mar 2012 00:57:14 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BCE8521F8550 for ; Thu, 29 Mar 2012 00:57:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-bd-4f7415d62fb9 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EB.21.25560.6D5147F4; Thu, 29 Mar 2012 09:57:10 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Thu, 29 Mar 2012 09:57:10 +0200 Message-ID: <4F7415D5.80604@ericsson.com> Date: Thu, 29 Mar 2012 09:57:09 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Regarding cloning of PeerConnections when multiple answers are received X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 07:57:15 -0000 WG, as individual As just discussed in the meeting Justin and Hadriel didn't think that you could clone PeerConnections properly. I do believe it is possible. If the API provides a method where you can clone a current peerConnection you can actually share the transport layer information at one end-point for multiple peer connections assuming that the other end-points transport addresses are different between the different peerConnections being cloned. This works as the complete ICE username is the concatenation of both sides, as long as an secondary answer contains a different username and has candidates with different transport addresses (address+port). Then end-point A receiving the second answer can have the ICE stack accept both usernames and if connectivity checks works then you create different 5-tuple filter to divide any media streams to the right peer connections media handler. When you clone a PC then must allocate the media decoding resources for each cloning. And that is something the cloning function may block on. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ashwin.shirvanthe@gmail.com Thu Mar 29 01:36:11 2012 Return-Path: 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 0DCEF21F89C5 for ; Thu, 29 Mar 2012 01:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 MMQqPH5v5iC8 for ; Thu, 29 Mar 2012 01:36:10 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2BA21F89BF for ; Thu, 29 Mar 2012 01:36:10 -0700 (PDT) Received: by obbta17 with SMTP id ta17so266869obb.31 for ; Thu, 29 Mar 2012 01:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=RSXuXNJs12xTyCS+BPBvtim5CXyM/gkkBGEhtNFbVy0=; b=dABn/whWoqS1oKT816eM6BZQAW9CSz7xG9fvZIu/3X2rJm0yFDyzyTFAUL4reSzW8H rdguukwnZCMFcwTUSgZcmvbdGZWJUAymEneB7ZiOkyUQZFsKu6GmQqN3Bjt8W8yvBXC4 ZbHGki7Yo+S65G2dqMw+1CyaDQuAt1tPE25tP/DJCAQBUG/2lPK/MNaDLaM+lhfvnvp9 9ASOKemHCDn2GSDicVp0NQWZfhQ7MljV1tbYeNJIcTp0wXpsQrTlq6xZcBNeWfL0BlN2 z+sh9LxwYAgibOVT68oLmkJa/56I4h6ZV8PecvVwXIegNgDbF9iZUKooVfw8jR3Mu20R mN1g== MIME-Version: 1.0 Received: by 10.182.164.7 with SMTP id ym7mr42405804obb.68.1333010169906; Thu, 29 Mar 2012 01:36:09 -0700 (PDT) Received: by 10.60.40.39 with HTTP; Thu, 29 Mar 2012 01:36:09 -0700 (PDT) Date: Thu, 29 Mar 2012 10:36:09 +0200 Message-ID: From: Ashwin Rao To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: Randell Jesup , Patrick McManus Subject: [rtcweb] Discussion on Congestion Control X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:36:11 -0000 Hi, At the iccrg presentations at IETF there were a good number of people who were interested in working on congestion control in RTCWeb. I am interested in working in this area and I have expressed my interest to a few people working on RTCWeb at Mozilla. I would like to know if people are interested in discussing the problems in this area. I am assuming that the people interested in this area would attend the conex wg meeting today. The conex presentation ends at 19:40 in room 253. We could meet in this room after the conex presentation and if required move to another room. Topics that I would like to discuss include 1. Is RTCWeb [ http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-01 ] being too conservative with respect to increasing the rate of sending packets. 2. How to address issues related to other delay based congestion control algorithms like Vegas. 3. Lessons learned from LEDBAT. Please feel free to add other topics. Regards, Ashwin From ietf@meetecho.com Thu Mar 29 01:36:27 2012 Return-Path: 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 ACD3C21F89CE for ; Thu, 29 Mar 2012 01:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.937 X-Spam-Level: X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 oQ4TKXG0vTx9 for ; Thu, 29 Mar 2012 01:36:27 -0700 (PDT) Received: from smtplq04.aruba.it (smtplqs-out26.aruba.it [62.149.158.66]) by ietfa.amsl.com (Postfix) with SMTP id EEA5621F8936 for ; Thu, 29 Mar 2012 01:36:24 -0700 (PDT) Received: (qmail 13319 invoked by uid 89); 29 Mar 2012 08:36:22 -0000 Received: from unknown (HELO smtp3.aruba.it) (62.149.158.223) by smtplq04.aruba.it with SMTP; 29 Mar 2012 08:36:22 -0000 Received: (qmail 27170 invoked by uid 89); 29 Mar 2012 08:36:22 -0000 Received: from unknown (HELO ?130.129.21.177?) (alex@meetecho.com@130.129.21.177) by smtp3.ad.aruba.it with ESMTPA; 29 Mar 2012 08:36:22 -0000 Message-ID: <4F741EFF.50906@meetecho.com> Date: Thu, 29 Mar 2012 10:36:15 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [rtcweb] Meetecho session recording available X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:36:27 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of RTCWEB session at IETF-83 (Wednesday) is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/83/remote-participation.html#Meetecho), or by directly accessing the following URL: http://ietf83.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB_IETF83 For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From magnus.westerlund@ericsson.com Thu Mar 29 01:44:22 2012 Return-Path: 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 F088121F8916 for ; Thu, 29 Mar 2012 01:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.326 X-Spam-Level: X-Spam-Status: No, score=-110.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 PAt6EzaHG4WQ for ; Thu, 29 Mar 2012 01:44:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id F3D0D21F8757 for ; Thu, 29 Mar 2012 01:44:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7b5aae000002dcb-1c-4f7420c6b795 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 19.0C.11723.6C0247F4; Thu, 29 Mar 2012 10:43:51 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Thu, 29 Mar 2012 10:43:48 +0200 Message-ID: <4F7420C3.8020302@ericsson.com> Date: Thu, 29 Mar 2012 10:43:47 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F740AB6.1080609@ericsson.com> In-Reply-To: <4F740AB6.1080609@ericsson.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Poll for dates for Interim Meeting before IETF 84 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:44:22 -0000 WG, Please respond to this poll no later than Friday the 13th of April. Cheers Magnus On 2012-03-29 09:09, Magnus Westerlund wrote: > WG, > > We have started a doodle poll for an Interim meeting before IETF 84 in > Vancouver. Locations considered so far are Stockholm, Boston Area or > Silicon Valley. The meeting is planned to be a 2 day meeting. Please > indicate which of the suggest times that works for you. > > > http://doodle.com/nm3pp69znr3286cy > > > Cheers > > Magnus Westerlund > WG chair > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From lists@infosecurity.ch Thu Mar 29 01:54:37 2012 Return-Path: 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 CFE8221F89F2 for ; Thu, 29 Mar 2012 01:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 emuJn23XcqBM for ; Thu, 29 Mar 2012 01:54:35 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1288721F89F8 for ; Thu, 29 Mar 2012 01:54:34 -0700 (PDT) Received: by eeke51 with SMTP id e51so920627eek.31 for ; Thu, 29 Mar 2012 01:54:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding :x-gm-message-state; bh=iC0oCw8K+hqMnny0iPUGc7LfpqfEa26Tilsf0tq51Mc=; b=hA5u508n/8+m94PS/CdTOwUagPM3fa4AybSn0uhmAxezqF3gdd9IGCTaSzWNBvLDi1 Jy0GlK1nlhJig/bP46laJCWD/9ESjaF9jh6Y3Tmx+vZgJeu3V0H/YQqzFQ1sT3GsZIEH uSuRqsQHqVbXVXMsUxXgordvDkEw00vs24X599iE+fYf2o7vr/Fy3d8eR4+dAphjPYgJ zYt2Kv9VhSFUNLR+6XdtJzQGCI/jnRKf+Jz5rvJ55stlwiXAGmLrW6U9d2Hjvcq6w3yT 8cgKqnEPRg5gzjJ3P27NjyrOzgRkjHuGUMwmn1crmn9D7EWar8B3ZPE4y87dSjsoY+5H vprA== Received: by 10.213.11.15 with SMTP id r15mr2375640ebr.181.1333011271051; Thu, 29 Mar 2012 01:54:31 -0700 (PDT) Received: from sonyvaiop13.local (93-57-41-37.ip162.fastwebnet.it. [93.57.41.37]) by mx.google.com with ESMTPS id n56sm19318832eeb.4.2012.03.29.01.54.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 01:54:30 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F742344.802@infosecurity.ch> Date: Thu, 29 Mar 2012 10:54:28 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlid0wD98JzLmOYX9lWfu5i42gqQiG6zl+FtAriM3lOlnbw20uR2IyK669xLYSh9vdvU9bT Subject: [rtcweb] Support of SDES in WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:54:37 -0000 On the topic of SDES vs DTLS-SRTP a very nice analysis has been done on: http://www.potaroo.net/ietf/idref/draft-ohlsson-rtcweb-sdes-support/ Considering how vague are the security implementation consideration of DTLS-SRTP and how widely diffused in SDES-SRTP, i'm wondering whenever we should not mandate the use of SDES-SRTP. That way we would be able to see: - All implementation will start with SDES (simpler and quicker) - For who want enhanced security, greater implementation and interoperability complexity, implement also DTLS-SRTP But for the industry a full cycle of: - Implementation - Stabilization - Interoperability for DTLS-SRTP (that nobody use) may require from 2 up to 4-5 years of time. If we goes for SDES-SRTP by default, as early choice, probably within 1-2 years at maximum we can expect the overall technological ecosystem to be stable and interoperable. Because it will be built on top of existing stable framework. We may save dozens millions of USD of investments costs for the industry and gain some hundreds millions of users year in advance, just because we would save several years of time. I think that those consideration are valuable enough to strongly consider arguments in making SDES-SRTP a preferred, mandatory implementation for WebRTC. -- Fabio Pietrosanti Founder, CTO Tel: +39 02 85961748 (direct) Mobile: +39 340 1801049 E-mail: fabio.pietrosanti@privatewave.com Skype: fpietrosanti Linkedin: http://linkedin.com/in/secret PrivateWave Italia S.p.A. Via Gaetano Giardino 1 - 20123 Milano - Italy www.privatewave.com From vsingh.ietf@gmail.com Thu Mar 29 02:00:52 2012 Return-Path: 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 81E1521F88B1 for ; Thu, 29 Mar 2012 02:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Z+HdvCR3rIAg for ; Thu, 29 Mar 2012 02:00:51 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B63421F88D2 for ; Thu, 29 Mar 2012 02:00:51 -0700 (PDT) Received: by eaaq11 with SMTP id q11so941689eaa.31 for ; Thu, 29 Mar 2012 02:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=K9rT6W/eTGLSpTDKobAUFXzMTeSYGFrB2Z9VYXsl3U4=; b=AKD5jpoDEhrR7asgXlQ3XFgu1vn3G5PNu6WFNhKWnrU7zI/NMnhdndlXynGgjLa7cW IMJRinGesDh+wxWF8ApuMln9GU9y9UTy8rVaOpaZNkHNUSfCviTUzLiT89z9lL/TSkXt zEffqRbB+HNQQTFU7XRy6cUD9hr/k3s/L88ZaQXs+O1BkYqrkaz6s//Pkw8r+WlYvLzX Tis1FpHQp7tG0TriL7Re4PztbqHUR1k7fQtIb5NGBI5ZLSGa8zC5+Z4e6iiIzljAE2oj tyxLeu1bT+vQMhDxPaD8jrCtq8oA6Yh1Fd7eOHrmZgK5WrAsiBjgGAGQLkvg50xrWrJR EpoA== Received: by 10.180.96.228 with SMTP id dv4mr3576212wib.14.1333011650302; Thu, 29 Mar 2012 02:00:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.134 with HTTP; Thu, 29 Mar 2012 02:00:30 -0700 (PDT) In-Reply-To: References: From: Varun Singh Date: Thu, 29 Mar 2012 11:00:30 +0200 Message-ID: To: Ashwin Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , "rtcweb@ietf.org" , Patrick McManus Subject: Re: [rtcweb] Discussion on Congestion Control X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:00:52 -0000 Hi Ashwin, Most of the discussion related to congestion control for RTCWEB takes place at rtp-congestion@alvestrand.no. Will be happy to join this meeting. Cheers, Varun On Thu, Mar 29, 2012 at 10:36, Ashwin Rao wro= te: > Hi, > > At the iccrg presentations at IETF there were a good number of people > who were interested in working on congestion control in RTCWeb. I am > interested in working in this area and I have expressed my interest to > a few people working on RTCWeb at Mozilla. I would like to know if > people are interested in discussing the problems in this area. I am > assuming that the people interested in this area would attend the > conex wg meeting today. The conex presentation ends at 19:40 in room > 253. We could meet in this room after the conex presentation and if > required move to another room. > > Topics that I would like to discuss include > 1. Is RTCWeb [ http://tools.ietf.org/html/draft-alvestrand-rtcweb-congest= ion-01 > ] =A0being too conservative with respect to increasing the rate of > sending packets. > 2. How to address issues related to other delay based congestion > control algorithms like Vegas. > 3. Lessons learned from LEDBAT. > > Please feel free to add other topics. > > Regards, > Ashwin > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 http://www.netlab.tkk.fi/~varun/ From otto.wittner@uninett.no Thu Mar 29 02:57:20 2012 Return-Path: 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 9210121F8663 for ; Thu, 29 Mar 2012 02:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, NO_RELAYS=-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 ix01T-EGD00Z for ; Thu, 29 Mar 2012 02:57:18 -0700 (PDT) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:0:526:158:38:180:100]) by ietfa.amsl.com (Postfix) with ESMTP id A39E621F865D for ; Thu, 29 Mar 2012 02:57:16 -0700 (PDT) Received: from khuzdul.uninett.no (khuzdul.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:f70]) by epost.uninett.no (Postfix) with ESMTPSA id 689403363DF for ; Thu, 29 Mar 2012 11:57:14 +0200 (CEST) Message-ID: <4F7431FA.5050202@uninett.no> Date: Thu, 29 Mar 2012 11:57:14 +0200 From: Otto J Wittner Organization: UNINETT AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [rtcweb] Mandatory codec on condition? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:57:20 -0000 This might be a totally ridiculous suggestion, but I give it a shot anyway. Is there any way that two codecs could be specified as mandatory: - one unconditionally mandatory because it is guaranteed royalty free (e.g. h261) - one conditionally mandatory, that is mandatory as long as it stays royalty free (e.g. VP8). I'm unsure if "conditionally manadatory" really makes sense, I admit. -- Otto J Wittner Tel 73557945 UNINETT AS Mob 99550566 From HKaplan@acmepacket.com Thu Mar 29 03:26:14 2012 Return-Path: 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 5CF7121F89CE for ; Thu, 29 Mar 2012 03:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] 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 3j-PjlMEu1J7 for ; Thu, 29 Mar 2012 03:26:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 25E1421F89BD for ; Thu, 29 Mar 2012 03:26:13 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Mar 2012 06:26:08 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Thu, 29 Mar 2012 02:08:30 -0400 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] SRTP and "marketing" Thread-Index: AQHNDXJcDpOwIC7VUECfiGAXLr857A== Date: Thu, 29 Mar 2012 06:08:29 +0000 Message-ID: <6493BD08-5A9B-48AB-8D5C-8778384948A3@acmepacket.com> References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> <4F73B2B6.9080008@jesup.org> In-Reply-To: <4F73B2B6.9080008@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 10:26:14 -0000 On Mar 29, 2012, at 2:54 AM, Randell Jesup wrote: >> No one is concerned about that. >=20 > Define "no one" :-) There are Billions of people on the planet. Obviously I don't mean the num= ber who don't care is 0. :) > That doesn't mean I don't want to implement a truly secure communications= ability. Note that by "secure" here I mean "I can detect if the service M= ITMd me" -- without reading cert phrases and preferably without having to i= nstall client certs and somehow build a working PKI. > One idea we've had is a non-centralized WebRTC service built on distribut= ed hash tables and a partial-mesh set of connections used to pass signaling= on WebRTC (or other) data channels to set up calls, with some type of Id s= ystem to validate who you get connected to (since you can't really trust an= y of the nodes fully). If an intermediary node can downgrade you to SDES a= nd sniff the keys, there is no security. If you use SDES, no one should be claiming you *have* end-to-end security. = You have security from the browser to the HTTPS server, but nothing more. = The browser shouldn't be showing a lock icon, for example (and it shouldn'= t for DTLS-SRTP either). Since the media potentially goes into the PSTN, i= t can be no more secure than that. No matter how much stronger we make the= Browser-to-Gateway link, the end-to-end can't exceed the PSTN's level of s= ecurity. It's reasonably sufficient security for everyday use, but it won'= t let you bypass the government. And using DTLS-SRTP to a gateway won't ei= ther. And arguably even using IdP won't if the government can force the Id= P to lie. > An alternative would be to allow a hybrid: SDES at the start of a call an= d rekey over to DTLS-SRTP after the call is connected. If something blocks= the DTLS connection it would be treated as a gateway-to-legacy/PSTN call (= i.e. show no security, though it's secure against non-in-path attackers); i= f the DTLS connection is allowed, we can use it to rekey to DTLS-SRTP and t= o verify identity. Why bother? I assume the concern is a bid-down. Let's imagine we were dea= ling with a malicious website, and the website javascript removed DTLS-SRTP= from SDP but put in SDES, so that browser believes it's talking to a gatew= ay and uses SDES. The malicious website now has your SRTP key and can decr= ypt your media, assuming it has some access to your media. So you build a = better browser and try an active check for DTLS-SRTP in the media plane reg= ardless of SDP. If your browser is popular, why wouldn't the malicious web= site just insert a DTLS-SRTP b2bua gateway, and still be able to listen in?= =20 As far as I can see, there is no bid-down issue created by adding SDES - it= was already there. It was already possible to insert a DTLS-SRTP B2BUA an= d be malicious. Yes, we may have made it slightly cheaper to be malicious,= but it was already possible. The only thing that prevents a malicious web= site's DTLS-SRTP B2BUA from working is if then humans verify the fingerprin= ts or having an IdP you can trust. Even if you *do* verify the fingerprint= s and find they do NOT match, all you know is it went through one or more g= ateways in the middle - you don't know it's malicious - it could just be go= ing through the PSTN legitimately. With SDES the browser can indicate right-off-the-bat that the call is not e= nd-to-end secure, without having to show the fingerprint and having the use= r read it out. > This minimizes the risk of bid-down - the primary additional risk is that= without initial SDES, to tap the signal you'd need to use a WebRTC-enabled= B2BUA to accept the DTLS-SRTP connection and siphon it off. Also, a "good= " gateway in a pure DTLS-SRTP world might have a identity established ("gat= eway@L3.com"); with SDES it wouldn't by default (but it could if it wanted = to by rekeying via DTLS also). =20 Yeah I've been trying to figure out if there's some advantage to having a g= ateway be able to indicate "gateway@telco.com", once there is an IdP model.= I would think it's a major pita to deploy such a thing on gateways, unles= s there's a very popular IdP they could know everyone would trust. It woul= d actually be easier to just give the gateway a real TLS cert for DTLS to u= se, from a major CA, since gateways are the types of systems real certs wou= ld be reasonably possible to install on. > I'm still strongly in favor of pure DTLS-SRTP - as Harald and others say,= less moving parts and less things that need to be secured. But this might= be a useful compromise if we *need* to support SDES in some cases. I'm trying to be convinced that DTLS-SRTP is worth the complexity, cost and= downsides on the gateways, but I haven't found it yet. I think people are= willing to be convinced, myself included, but I have yet to hear a real ad= vantage for DTLS-SRTP in the gateway scenario. Everything put forward toda= y for DTLS-SRTP applied to the browser-to-browser scenarios, but not gatewa= ys. =20 -hadriel From Ranjit.Avasarala@Polycom.com Thu Mar 29 04:08:39 2012 Return-Path: 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 6E4A521F8868 for ; Thu, 29 Mar 2012 04:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.309 X-Spam-Level: X-Spam-Status: No, score=-5.309 tagged_above=-999 required=5 tests=[AWL=1.290, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 qt4sWwJgdi2b for ; Thu, 29 Mar 2012 04:08:38 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1A56421F850D for ; Thu, 29 Mar 2012 04:08:37 -0700 (PDT) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Thu, 29 Mar 2012 19:08:32 +0800 From: "Avasarala, Ranjit" To: Otto J Wittner , "rtcweb@ietf.org" Date: Thu, 29 Mar 2012 19:08:29 +0800 Thread-Topic: [rtcweb] Mandatory codec on condition? Thread-Index: Ac0NkzKzKJAXj0Y6TeKf3qJP8DV1+AACPq2Q Message-ID: <1F2A2C70609D9E41844A2126145FC09804BC6EEA6E@HKGMBOXPRD22.polycom.com> References: <4F7431FA.5050202@uninett.no> In-Reply-To: <4F7431FA.5050202@uninett.no> 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] Mandatory codec on condition? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:08:39 -0000 By two codecs you mean 1 audio codec and 1 video codec or 2 audio and 2 vid= eo codecs? Regards Ranjit -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Otto J Wittner Sent: Thursday, March 29, 2012 3:27 PM To: rtcweb@ietf.org Subject: [rtcweb] Mandatory codec on condition? This might be a totally ridiculous suggestion, but I give it a shot anyway. Is there any way that two codecs could be specified as mandatory: - one unconditionally mandatory because it is guaranteed royalty free (e.g= . h261) - one conditionally mandatory, that is mandatory as long as it stays royal= ty free (e.g. VP8). I'm unsure if "conditionally manadatory" really makes sense, I admit. --=20 Otto J Wittner Tel 73557945 UNINETT AS Mob 99550566 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Thu Mar 29 04:26:00 2012 Return-Path: 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 E752F21F8976 for ; Thu, 29 Mar 2012 04:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.813 X-Spam-Level: X-Spam-Status: No, score=-4.813 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ijXSEtpTkXo3 for ; Thu, 29 Mar 2012 04:26:00 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3492321F8974 for ; Thu, 29 Mar 2012 04:26:00 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2032855bku.31 for ; Thu, 29 Mar 2012 04:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eW40zb0AD7QTwGPNq4B2rbLxL9C8BtT4nzktptj5gcE=; b=kJZ63mBAEvjjwH8fNDavmSc6zV0u25MkxtBv80DWb7ytRDj1SNZMSPZvHdhnJXNJma zkCGzODUnoGkRZoFaIbQ3B/+uofyzl8ESsozEOPmPN4e9C+vW91Bkn5+JU81coSa05MN l7YonRS8OnVRxAcNKDg/AIggCHc12dwc37fLXQew/QyjlaYErOX5YnZeNbCZMTlLGx4P KQ1SFJGd3LfqyRAAdYmopWQLJagY5FwRcTBYW7lY0fNBV6FB8Hx90rzc9xEe68RxA0ql RAn21aC9abkqfA7sE3L+6x9UZcl3Q7rGJhqVhy32DvX3qM/Noz2xFIM1XnTs91T+qTXz JiXg== MIME-Version: 1.0 Received: by 10.204.152.12 with SMTP id e12mr13768252bkw.29.1333020359297; Thu, 29 Mar 2012 04:25:59 -0700 (PDT) Received: by 10.205.38.73 with HTTP; Thu, 29 Mar 2012 04:25:59 -0700 (PDT) Date: Thu, 29 Mar 2012 13:25:59 +0200 Message-ID: From: Martin Thomson To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , "" Subject: [rtcweb] IdP and universal trust X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:26:01 -0000 On 29 March 2012 08:08, Hadriel Kaplan wrote: > Yeah I've been trying to figure out if there's some advantage to having a= gateway be able to indicate "gateway@telco.com", once there is an IdP mode= l. =C2=A0I would think it's a major pita to deploy such a thing on gateways= , unless there's a very popular IdP they could know everyone would trust. = =C2=A0It would actually be easier to just give the gateway a real TLS cert = for DTLS to use, from a major CA, since gateways are the types of systems r= eal certs would be reasonably possible to install on. This is an important point, and I think that perhaps you missed the distinction. Iff third party assertions are permitted, then the problem that you refer to - namely, finding someone that others trust - is somewhat difficult. On the other hand, it is also true that you can gain multiple assertions and increase the chances of finding an acceptable IdP. What seems more likely is that IdPs are only going to be authoritative for their own domain. The overall story is a lot easier to tell. This has the nice quality that you don't have to trust the IdP, you only have to trust their CA. --Martin From otto.wittner@uninett.no Thu Mar 29 04:33:30 2012 Return-Path: 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 9E49521F898F for ; Thu, 29 Mar 2012 04:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, NO_RELAYS=-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 bTxwmMynMqhd for ; Thu, 29 Mar 2012 04:33:30 -0700 (PDT) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:0:526:158:38:180:100]) by ietfa.amsl.com (Postfix) with ESMTP id 0634221F898B for ; Thu, 29 Mar 2012 04:33:29 -0700 (PDT) Received: from khuzdul.uninett.no (khuzdul.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:f70]) by epost.uninett.no (Postfix) with ESMTPSA id E91773364B7 for ; Thu, 29 Mar 2012 13:33:24 +0200 (CEST) Message-ID: <4F744884.8070406@uninett.no> Date: Thu, 29 Mar 2012 13:33:24 +0200 From: Otto J Wittner Organization: UNINETT AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <4F7431FA.5050202@uninett.no> <1F2A2C70609D9E41844A2126145FC09804BC6EEA6E@HKGMBOXPRD22.polycom.com> In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804BC6EEA6E@HKGMBOXPRD22.polycom.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Mandatory codec on condition? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:33:30 -0000 Two of each if necessary. O2 On 03/29/2012 01:08 PM, Avasarala, Ranjit wrote: > By two codecs you mean 1 audio codec and 1 video codec or 2 audio and 2 video codecs? > > Regards > Ranjit > > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Otto J Wittner > Sent: Thursday, March 29, 2012 3:27 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Mandatory codec on condition? > > This might be a totally ridiculous suggestion, but I give it a shot anyway. > > Is there any way that two codecs could be specified as mandatory: > - one unconditionally mandatory because it is guaranteed royalty free (e.g. h261) > - one conditionally mandatory, that is mandatory as long as it stays royalty free (e.g. VP8). > > I'm unsure if "conditionally manadatory" really makes sense, I admit. > -- Otto J Wittner Tel 73557945 UNINETT AS Mob 99550566 From ietf@meetecho.com Thu Mar 29 04:43:09 2012 Return-Path: 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 168A721F8921 for ; Thu, 29 Mar 2012 04:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 eZ-aHu4vZFMk for ; Thu, 29 Mar 2012 04:43:08 -0700 (PDT) Received: from smtplq03.aruba.it (smtplqs-out29.aruba.it [62.149.158.69]) by ietfa.amsl.com (Postfix) with SMTP id 8D8D821F88E8 for ; Thu, 29 Mar 2012 04:43:07 -0700 (PDT) Received: (qmail 4925 invoked by uid 89); 29 Mar 2012 11:43:01 -0000 Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq03.aruba.it with SMTP; 29 Mar 2012 11:43:01 -0000 Received: (qmail 14939 invoked by uid 89); 29 Mar 2012 11:43:01 -0000 Received: from unknown (HELO ?130.129.21.177?) (alex@meetecho.com@130.129.21.177) by smtp8.ad.aruba.it with ESMTPA; 29 Mar 2012 11:43:01 -0000 Message-ID: <4F744ABD.3000208@meetecho.com> Date: Thu, 29 Mar 2012 13:42:53 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F741EFF.50906@meetecho.com> In-Reply-To: <4F741EFF.50906@meetecho.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: Re: [rtcweb] Meetecho session recording available X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:43:09 -0000 Hi again, the recording of Thursday's session is available as well: http://ietf83.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB_II_IETF83 Cheers, the Meetecho team Il 29/03/2012 10:36, Meetecho IETF support ha scritto: > Dear all, > > the full recording (synchronized video, audio, slides and jabber room) > of RTCWEB session at IETF-83 (Wednesday) is available. > > You can watch it by either clicking the proper link on the remote > participation page > (http://www.ietf.org/meeting/83/remote-participation.html#Meetecho), or > by directly accessing the following URL: > http://ietf83.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB_IETF83 > > For the chair(s): please feel free to put the link to the recording in > the minutes, if you think this might be useful. > > In case of problems with the playout, just drop an e-mail to > team@meetecho.com. > > Cheers, > the Meetecho team > From ibc@aliax.net Thu Mar 29 04:58:40 2012 Return-Path: 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 AC82821F89DD for ; Thu, 29 Mar 2012 04:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 4rk97-m1YF7c for ; Thu, 29 Mar 2012 04:58:39 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 955CC21F84EE for ; Thu, 29 Mar 2012 04:58:39 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1620052vbb.31 for ; Thu, 29 Mar 2012 04:58:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=NRIb9kRUh8qF9oU/SrEihKhvXhhzDaorSIYrjEVyt6c=; b=Rqc1qAlFVXboi9OpME3Zqcwuz9oEryQm7Yof5zw9muAWZ4xvOF+iNM1Z9kFMFtZ990 YWVXqnJSqCDVKUorVd1Dv+ssgzltW526qYiQn3/OX9RmeNbKw2XtzQ+X4rQxcGnRoIzO oyzzBsn9nhA2TW08XpiWz9PlK/g1+L9TJ2v5LLp+rZYZfYvtFnKUV1W88oJG2XJEbfQF ZlPkXwskxqHqI6Vy8+mz637eHu+182Q4VKT0yn+MH1m2se7pK+RuKujiWIG8RuYo7Lhh ukGXOPWYt3a8PvtE6ciaLMnEL2mmSHxR6DPCGUABk0W9AAldhUI/uV3nR7conzGf9601 pEWA== Received: by 10.220.152.205 with SMTP id h13mr11857619vcw.12.1333022313876; Thu, 29 Mar 2012 04:58:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 29 Mar 2012 04:58:06 -0700 (PDT) In-Reply-To: <4F7409C4.407@infosecurity.ch> References: <4F73697D.5080006@infosecurity.ch> <4F7409C4.407@infosecurity.ch> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 29 Mar 2012 13:58:06 +0200 Message-ID: To: "Fabio Pietrosanti (naif)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmy6l/XaRhCzuITSDbw3u+r6SGQ/pJbWmFT9fvSBDyw4dA2ULXkP+sl/h/VEXDURmH+/SoS Cc: "" Subject: Re: [rtcweb] DTLS-SRTP implementation diffusion: Why not SDES-SRTP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:58:40 -0000 2012/3/29 Fabio Pietrosanti (naif) : > That's true, but it's also true that the "rtcweb world" will strictly > inter-operate with the "sip world". > > It would be reasonable to expect that current existing PBX software > would evolve also with support for Rtcweb, to provide Web phone systems. Right, but it also reasonable to expect that those SIP PBX do implement some security, at least SDES-SRTP. NOTE: I do know you are not talking about allowing plain RTP in WebRTC ;) > In particular all opensource software will setup the path for the > adoption of the standard, as we know history will repeat. > > It appear me as natural behavior of diffusion of implementation, and for > that reason i see the need to "easily" inter-operate with the SIP world > is a key value point. > > Creating an incompatible "media format" would require a lot of more > effort because the "amount of compatibility testing to be done with > DTLS-SRTP will be significantly higher than SDES-SRTP" . I agree. >> http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf > > I would like to strongly argue against the SLIDE 3 statement that > "DTLS-SRTP meets RTCWEB's technical requirements" . > > DTLS-SRTP doesn't meet the RTCWEB's technical requirements because: > > - It does NOT provide inter-operation with existing SIP endpoints > > This is confirmed by the October 2011 SIPit data, with 80% of > participants supporting, with good interoperability, SDES but with 0% > supporting DTLS-SRTP . > > In order to try to "try to improve it's non-interoperability issue" the > DTLS-SRTP is re-proposing him-selves as DTLS-SRTP-EKT . > > To speaking about the fact that even EKT draft explain that: > " Today, Security Descriptions [RFC4568] is used for distributing SRTP > =C2=A0 keys in several different IP PBX systems and is expected to be use= d > =C2=A0 by 3GPP's Long Term Evolution (LTE). " > > http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-01#section-6.1 > > So: > - Internt is using SDES-SRTP > - 3GPP LTE is using SDES-SRTP > - WebRTC is going to use DTLS-SRTP > > I do not really see how we can rationally accept to follow this > different direction. Well, AFAIK the decision for WebRTC is one of the following options (assuming that plain RTP is not allowed, for which there was consensus yesterday in Paris): 1) Mandate DTLS-SRTP(-EKT?) implementation and dissalow SDES-SRTP. 2) Mandate DTLS-SRTP(-EKT?) implementation and allow SDES-SRTP (optional). 3) Mandate DTLS-SRTP(-EKT?) implementation and also SDES-SRTP. I vote for option (3) so WebRTC can *already* interop with well tested SDES-SRTP environments. Is option (3) good for you? > The argument that DTLS is *more secure* must face the reality that > no-one is using it and that SDES-SRTP is *widely diffused and > interoperable*. > > All Internet operators will have to introduce Protocol Gateway. > All mobile operators will have to introduce Protocol Gateway. It's worse than that. If you read slides 34 and 35 in http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf, the "Media Gateway" MUST be also a *signaling* B2BUA (cannot be a proxy) since it needs to generate re-INVITE in one leg (for crypto key updates) !! I hope I will not need that annoying stuff in order to make WebRTC to interoperate with SIP networks (assuming SDES-SRTP in those SIP networks, of course). > So definitely the choice to go for DTLS-SRTP is imho a wrong choice, > against any rationale for the diffusion of WebRTC standard, introducing > artificially complexity where it may be possible to keep it simple. Worse, it's not just choosing a non tested standard, but creating a new specification. The slide 39 says: ------------------------ Do part of DTLS handshake in ICE connectivity checks =E2=80=93 draft-thomson-rtcweb-ice-dtls ----------------------- So if that *new* spec is mandatory for WebRTC, then forget interoperability with any other network. Regards. --=20 I=C3=B1aki Baz Castillo From rbarnes@bbn.com Thu Mar 29 05:00:42 2012 Return-Path: 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 8FAF121F8A0C for ; Thu, 29 Mar 2012 05:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 b1rabmT58cXX for ; Thu, 29 Mar 2012 05:00:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8F81121F89F0 for ; Thu, 29 Mar 2012 05:00:41 -0700 (PDT) Received: from [128.89.254.227] (port=54677 helo=neutrino.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SDE1i-000G7P-Di; Thu, 29 Mar 2012 08:00:26 -0400 Message-ID: <4F744EE7.1080309@bbn.com> Date: Thu, 29 Mar 2012 14:00:39 +0200 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Roman Shpount References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <86CD9009-0557-4F94-9E9F-89DAD2D80FF1@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:00:42 -0000 On 3/29/12 8:18 AM, Roman Shpount wrote: > > On Fri, Mar 23, 2012 at 11:19 PM, Hadriel Kaplan > wrote: > > I'm not trying to be pedantic or difficult here, or trying to > dismiss the use-case. I know there are many such "super-tight" > networks, but I just don't see how we can reasonably accommodate > their use-case in this WG. And I'm pointing out that we really are > following their policies, inasmuch as WebRTC media will fail to > escape their network - I would be far more worried if we somehow > bypassed their policies instead. At least this way it's similar > behavior they get for unknown/unauthorized applications, which is > arguably what going to random websites and running downloaded > javascript is equivalent to. > > > Sorry for the late response, but enterprise policy does not have to be > WebRTC on or off. It can be video is not allowed from the enterprise > network but audio is ok. It can be that enterprise would only allow to > communicate with SDP signed by some predefined list of identity > providers. It can be that only certain amount of bandwidth can be used > for WebRTC traffic. WebRTC media communications can only be allowed with > certain IP networks. All of those policies are common with SIP and > enterprise session border controllers. Right now there is no granular > control similar to the control that you would get by running SIP > enabled firewall. I would consider this a serious regression comparing > to current SIP based communications and would really like this addressed. This sounds like an excellent use case for host-based controls, and an excellent example of the limitations of network-based controls. --Richard From ajrmeyn@gmail.com Thu Mar 29 05:05:40 2012 Return-Path: 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 5BFC521F8A2C for ; Thu, 29 Mar 2012 05:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 kDgAuxzHgyGp for ; Thu, 29 Mar 2012 05:05:39 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0A30721F8A2B for ; Thu, 29 Mar 2012 05:05:38 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so43505wgb.1 for ; Thu, 29 Mar 2012 05:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AC4hbu6nK2j9Y+kIbBTRKDLumXej2sl5XZuSIE1YksY=; b=m3pKyNC/NsxgddxPXPCtgAcW5FBeFcz9JfqrSaV16IrEYxrMh+4kniBkh6t7wKahiv LCI0I4qlcd0hAyPDUtQkYOljqrXUA4FvbA9MyxgSA0cB3ASmNW5Y0m6xLZBHFXLJj5YI UcmS4L/HLyHkWnEa4LYhi071xYwZp25FykaiZTzLaJg46LG8ad1lo1ZZ5qsYFp4Lrpxu BQsXPVZ241YHHCdQrRLEiKVMQQOecEBzIdKQiB1NP0mLL7DtesRal7XkF1pPda/hKlMG OOOaZsDFTt6R04HouqAo+d8ZSjD4OYf5hSaaeD1M5LkJEiZhpy3B6YfFn3AZnIv+wDEm KxMw== MIME-Version: 1.0 Received: by 10.180.85.69 with SMTP id f5mr4969694wiz.18.1333022738128; Thu, 29 Mar 2012 05:05:38 -0700 (PDT) Received: by 10.223.159.71 with HTTP; Thu, 29 Mar 2012 05:05:37 -0700 (PDT) In-Reply-To: <4F71982B.4010208@alvestrand.no> References: <4F71982B.4010208@alvestrand.no> Date: Thu, 29 Mar 2012 15:05:37 +0300 Message-ID: From: Antony Meyn To: Harald Alvestrand Content-Type: multipart/alternative; boundary=f46d043bde66c8a18e04bc608a47 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Query regarding rtcweb use cases and requirements. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:05:40 -0000 --f46d043bde66c8a18e04bc608a47 Content-Type: text/plain; charset=ISO-8859-1 @Herald: thanks. >>For communications that did not need low latency, the WG felt that the RTCWEB requirements were not different from the requirements of any other application, so those could be fulfilled with other types of interfaces, including server-mediated file transfers. What about use cases of static(non-live) video streaming from browser to browser, this would require low latency and servers-mediated file transfers would only add up to the latency, right?. A user would like to share his video without actually having to upload the content to a server. >> The purpose of the "use cases and requirements" is to find a minimum set of things that the protocol suite has to be able to do in order to be "good enough", not to delineate everything the protocol can be used for. Agree, but the use cases for the data API, does look promising, and it didn't seem to have much attention in comparison to live video streaming use cases. --f46d043bde66c8a18e04bc608a47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
@Herald: thanks.

>>For communications t= hat did not need low latency, the WG felt that the RTCWEB requirements were= not different from the requirements of any other application, so those cou= ld be fulfilled with other types of interfaces, including server-mediated f= ile transfers.

What about use cases of static(non-live) video streami= ng from browser to browser, this would require low latency and servers-medi= ated file transfers would only add up to the latency, right?. A user would = like to share his video without actually having to upload the content to a = server.

>> The purpose of the "use cases and requirements" is to find a mini= mum set of things that the protocol suite has to be able to do in order to = be "good enough", not to delineate everything the protocol can be= used for.=A0

Agree, but the use cases for the data API, does look pr= omising, and it didn't seem to have much attention in=A0comparison=A0to= live video streaming use cases.







--f46d043bde66c8a18e04bc608a47-- From igor.faynberg@alcatel-lucent.com Thu Mar 29 05:06:01 2012 Return-Path: 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 3F29421F8A2B for ; Thu, 29 Mar 2012 05:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 rLRPGdwvlA2o for ; Thu, 29 Mar 2012 05:06:00 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1935821F88C8 for ; Thu, 29 Mar 2012 05:06:00 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q2TC5wot017584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 29 Mar 2012 07:05:58 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2TC5vpZ004688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 29 Mar 2012 07:05:57 -0500 Received: from [135.244.32.64] (faynberg.lra.lucent.com [135.244.32.64]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2TC5uen005674; Thu, 29 Mar 2012 07:05:57 -0500 (CDT) Message-ID: <4F745024.2010203@alcatel-lucent.com> Date: Thu, 29 Mar 2012 08:05:56 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F73697D.5080006@infosecurity.ch> <4F7409C4.407@infosecurity.ch> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] DTLS-SRTP implementation diffusion: Why not SDES-SRTP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:06:01 -0000 +1 Igor On 3/29/2012 7:58 AM, Iñaki Baz Castillo wrote: > 2012/3/29 Fabio Pietrosanti (naif): > >> That's true, but it's also true that the "rtcweb world" will strictly >> inter-operate with the "sip world". >> >> It would be reasonable to expect that current existing PBX software >> would evolve also with support for Rtcweb, to provide Web phone systems. > Right, but it also reasonable to expect that those SIP PBX do > implement some security, at least SDES-SRTP. > > NOTE: I do know you are not talking about allowing plain RTP in WebRTC ;) > > > >> In particular all opensource software will setup the path for the >> adoption of the standard, as we know history will repeat. >> >> It appear me as natural behavior of diffusion of implementation, and for >> that reason i see the need to "easily" inter-operate with the SIP world >> is a key value point. >> >> Creating an incompatible "media format" would require a lot of more >> effort because the "amount of compatibility testing to be done with >> DTLS-SRTP will be significantly higher than SDES-SRTP" . > I agree. > > > >>> http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf >> I would like to strongly argue against the SLIDE 3 statement that >> "DTLS-SRTP meets RTCWEB's technical requirements" . >> >> DTLS-SRTP doesn't meet the RTCWEB's technical requirements because: >> >> - It does NOT provide inter-operation with existing SIP endpoints >> >> This is confirmed by the October 2011 SIPit data, with 80% of >> participants supporting, with good interoperability, SDES but with 0% >> supporting DTLS-SRTP . >> >> In order to try to "try to improve it's non-interoperability issue" the >> DTLS-SRTP is re-proposing him-selves as DTLS-SRTP-EKT . >> >> To speaking about the fact that even EKT draft explain that: >> " Today, Security Descriptions [RFC4568] is used for distributing SRTP >> keys in several different IP PBX systems and is expected to be used >> by 3GPP's Long Term Evolution (LTE). " >> >> http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-01#section-6.1 >> >> So: >> - Internt is using SDES-SRTP >> - 3GPP LTE is using SDES-SRTP >> - WebRTC is going to use DTLS-SRTP >> >> I do not really see how we can rationally accept to follow this >> different direction. > Well, AFAIK the decision for WebRTC is one of the following options > (assuming that plain RTP is not allowed, for which there was consensus > yesterday in Paris): > > 1) Mandate DTLS-SRTP(-EKT?) implementation and dissalow SDES-SRTP. > > 2) Mandate DTLS-SRTP(-EKT?) implementation and allow SDES-SRTP (optional). > > 3) Mandate DTLS-SRTP(-EKT?) implementation and also SDES-SRTP. > > > I vote for option (3) so WebRTC can *already* interop with well tested > SDES-SRTP environments. Is option (3) good for you? > > > > >> The argument that DTLS is *more secure* must face the reality that >> no-one is using it and that SDES-SRTP is *widely diffused and >> interoperable*. >> >> All Internet operators will have to introduce Protocol Gateway. >> All mobile operators will have to introduce Protocol Gateway. > It's worse than that. If you read slides 34 and 35 in > http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf, the > "Media Gateway" MUST be also a *signaling* B2BUA (cannot be a proxy) > since it needs to generate re-INVITE in one leg (for crypto key > updates) !! > > I hope I will not need that annoying stuff in order to make WebRTC to > interoperate with SIP networks (assuming SDES-SRTP in those SIP > networks, of course). > > > > >> So definitely the choice to go for DTLS-SRTP is imho a wrong choice, >> against any rationale for the diffusion of WebRTC standard, introducing >> artificially complexity where it may be possible to keep it simple. > Worse, it's not just choosing a non tested standard, but creating a > new specification. The slide 39 says: > > ------------------------ > Do part of DTLS handshake in ICE connectivity checks > – draft-thomson-rtcweb-ice-dtls > ----------------------- > > So if that *new* spec is mandatory for WebRTC, then forget > interoperability with any other network. > > > Regards. > From ibc@aliax.net Thu Mar 29 05:15:06 2012 Return-Path: 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 90D2C21F8A60 for ; Thu, 29 Mar 2012 05:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 OYO2CO1-LkXl for ; Thu, 29 Mar 2012 05:15:05 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE08521F89E9 for ; Thu, 29 Mar 2012 05:15:04 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1632113vbb.31 for ; Thu, 29 Mar 2012 05:15:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=oMSQF278c6i0kovpGSuU+ltcxdw/TrNy0I8IciEjHJw=; b=Bhfa9vwzqLWocZvpol8HqY/KlA920BbCUV/yYv0/RSlwvQDIpFbzL2R8hZrIRxPLBw f0VaEWrVLrQXTMiGw1VjxoNbzBttoC6esTocSewYeiYywfwoQ1nOU47kG8uVOVoPkkez B/fzcYU/lpp7xjcuAMJNXgdoa1ausPxfpDMgKDXtuZ2S2KRvz0IErR//IZ1VlMb+GSj0 WIDVEv+9P9uDmfjmuQ0xl2Tre/LIWevl0AtQwEgjQxHpoW21gul3QjzkFdrkshSLka8w l/JdVl/3OFksss3Y2Wq0DRbpUnIrg4ZmHsNlIQxPkQdRdTtsToQFsZfv7fwM6a5cCuLM Bw7g== Received: by 10.220.152.205 with SMTP id h13mr11886528vcw.12.1333023304449; Thu, 29 Mar 2012 05:15:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 29 Mar 2012 05:14:44 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 29 Mar 2012 14:14:44 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmFmGDftsvRYR6E1ubFYN3sH/Pu9Zdm776xkvVdgxy7fMKN8Wddj9C4dvCpJvKE3yXFSvdn Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:15:06 -0000 2012/3/29 Roman Shpount : > > On Wed, Mar 28, 2012 at 5:11 PM, I=C3=B1aki Baz Castillo = wrote: >> >> In all those scenarios you mention, using security (SRTP) is not *bad*, = is >> it? >> The fact that in certain scenarios it could be not needed, it does not >> mean that "no security" is better than "security". >> > I actually think that you are confusing encryption with security. Roman, you still don't want to see my simple example. Could you please reply to the following two questions rather than avoiding them?: 1) Why is better to use plain RTP in an open WiFi network (airport) rather than using SDES-SRTP? 2) Why is plain RTP better than SDES-SRTP in any other case? > No encryption often means better security. Sorry, I don't agree. Encryption is not enough, of course, but it's better than nothing (and again: the open WiFi network in the airport). > Bot nets use encryption to > communicate, it does not mean they enable user security. 1) User identity authentication/validation and confidentiality (encryption)= . 2) Just confidentiality (encryption). 3) Nothing. 1 is better than 2 and 2 is better than 3. > In a lot of cases > ability for the user to check what exactly they are communicating and to > whom is security. As a security conscious person I do not want encrypted > communication from my computer or my network unless I know exactly who it= is > going to. If I do not have to I would prefer my communications to be > unencrypted. Sure, but you are advanced user and I hope you are not talking in behalf of the 500 millions of Facebook users in the world. So you will be able to enter into your browser about://config and set a null crypto key for SRTP (so you get plain RTP and can debug it or whatever). This is confirmed to be the expectation of two browser vendors. >> RFC 3711 was created in 2004, 8 years ago! >> >> Which "new" application you mean if it's not capable of implementing a >> simple specification from 2004? how "new" is it? is it really new? or >> is it a "SIP voicemail server" made in 2002? >> > Well let me list them: FreeSwitch, Asterisk, linphone, etc. All of those = use > libsrtp. For all of them SRTP is broken. Not a single one of them bothere= d > to check or only recently detected problems > (https://issues.asterisk.org/jira/browse/ASTERISK-16665). I expect that, once SRTP becomes widely extended (thanks to WebRTC), developers will really want to fix their SRTP support, including libsrtp. But we cannot make a *new spec less secure than it can be just due a to a bug in a opensource library. >> Sorry but I still see *no* argument at all in favour of allowing plain >> RTP in WebRTC. And AFAIK there is already consensus about it: plain >> RTP is not allowed. >> > I do not see an argument why RTP should not be allowed. I think you are > arguing we should require a feature (SRTP) for the sake of requiring a > feature. I still don't understand why everyone in an airport should be able to intercept my audio/video communication with a simple RTP sniffer. Regards. --=20 I=C3=B1aki Baz Castillo From dean.willis@softarmor.com Thu Mar 29 05:15:37 2012 Return-Path: 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 573D721F8A78 for ; Thu, 29 Mar 2012 05:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.759 X-Spam-Level: X-Spam-Status: No, score=-102.759 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 qpIjb885UAKi for ; Thu, 29 Mar 2012 05:15:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6AD321F8A7B for ; Thu, 29 Mar 2012 05:15:35 -0700 (PDT) Received: by yenm5 with SMTP id m5so1504512yen.31 for ; Thu, 29 Mar 2012 05:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=psi8K62P2SLuYX0X5P+w2hRMHvS+VLMVlZkAVxvfAhw=; b=FyDJvXcvd2gVGfp3WOmkNOKawi2wEM81NeUSbFt/lL6am1A21bpw8KmR0pCDL356FW xBFxOEvOelydmyh2aHnTpOcoXg+fUtMMomPHUYX66yEOPjRWN6Dqv0SaClBUA4HeZaMe VyMDQ3nNByIVLDgpWKIFp/9vJXADDLXPILG/0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=psi8K62P2SLuYX0X5P+w2hRMHvS+VLMVlZkAVxvfAhw=; b=Y50A8hwXpUdAfB/3O3cXp8jUlXPqXiJwEEEiu6aouswYhnHNvni9ePzKX9y7upEYjt PIfNPnuRzpZUHYLm+F0Ibs9G7EPcfigs6pV9eFonFOGKG8AuHUdE3swywDT9Wa2POmHB fNI+scEjottqrvOiiTuU52vUFbX4ypK3o9YwICWIEgBcpoaNbz6drmdVoXmdTI7FHfS1 0rJWqR978n0gRcpSyJ/lpwOADaASwHeX/m3gXzLVAqCqk21nNLLRow6/FaZJVeNlUnvB nSKCqjEA4e9lcDfgE/MBtUarOnY/0/LY8RYd585s3/PUAh8dOb7A2qZLVZiSXA0tVuSK UeAw== MIME-Version: 1.0 Received: by 10.68.190.42 with SMTP id gn10mr5548105pbc.94.1333023335149; Thu, 29 Mar 2012 05:15:35 -0700 (PDT) Received: by 10.68.189.197 with HTTP; Thu, 29 Mar 2012 05:15:35 -0700 (PDT) Date: Thu, 29 Mar 2012 14:15:35 +0200 Message-ID: From: Dean Willis To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff1cb265e71b504bc60ae18 X-Gm-Message-State: ALoCoQk4ieZJnpnLnrnIwuR2YzYxaby1zX4+xHYjQOY+Sww+gTceVX6eO2KndnQTancet/xMUx0Y Subject: [rtcweb] Proposal for H.263 baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:15:37 -0000 --e89a8ff1cb265e71b504bc60ae18 Content-Type: text/plain; charset=ISO-8859-1 In today's meeting I made a plea for a mandatory baseline codec that is approachable to the small developer without the cost and IPR risks of either H.264 or VP8. I believe that some sort of baseline codec is required to jump start the protocol. It's OK if this isn't the best possible codec. Market forces will assure that commercial implementations converge on a higher quality when the market requires it. While I proposed today that H.261 could serve as a baseline, we know this would be "extremely basic". In other words, it might not pass the "good enough to use" test required for a successful launch. Stephane and several others suggested H.263 as an alternative during the after-meeting chat. While it is not as IPR-safe a choice as H.261, it is relatively mature and the known challenges have generally failed. Implementations are reasonably available and should make it possible for smaller implementers, students, and hobbyists to play ball. It's not all that network efficient and is outright piggy at higher resolutions, but it probably works "well enough to use." So I propose we set H.263 as the baseline ( I expect a bit of profiling may be necessary to further qualify the baseline) and run with that for now. If the situation changes, we can always replace it before final publication. -- Dean --e89a8ff1cb265e71b504bc60ae18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In today's meeting I made a plea for a mandatory baseline codec that is= approachable to the small developer without the cost and IPR risks of eith= er H.264 or VP8.

I believe that some sort of baseline co= dec is required to jump start the protocol. It's OK if this isn't t= he best possible codec. Market forces will assure that commercial implement= ations converge on a higher quality when the market requires it.

While I proposed today that H.261 could serve as a base= line, we know this would be "extremely basic". In other words, it= might not pass the "good enough to use" test required for a succ= essful launch.

Stephane and several others suggested H.263 as an alter= native during the after-meeting chat. While it is not as IPR-safe a choice = as H.261, it is relatively mature and the known challenges have generally f= ailed. Implementations are reasonably available and should make it possible= for smaller implementers, students, and hobbyists to play ball. It's n= ot all that network efficient and is outright piggy at higher resolutions, = but it probably works "well enough to use."

So I propose we set H.263 as the baseline ( I expect a = bit of profiling may be necessary to further qualify the baseline) and run = with that for now. If the situation changes, we can always replace it befor= e final publication.
--
Dean
--e89a8ff1cb265e71b504bc60ae18-- From lorenzo@meetecho.com Thu Mar 29 05:29:37 2012 Return-Path: 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 EE07821F8A62 for ; Thu, 29 Mar 2012 05:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 weN29LeRh2ok for ; Thu, 29 Mar 2012 05:29:36 -0700 (PDT) Received: from smtplq04.aruba.it (smtplqs-out26.aruba.it [62.149.158.66]) by ietfa.amsl.com (Postfix) with SMTP id B5FAF21F89F4 for ; Thu, 29 Mar 2012 05:29:35 -0700 (PDT) Received: (qmail 31025 invoked by uid 89); 29 Mar 2012 12:29:32 -0000 Received: from unknown (HELO smtp4.aruba.it) (62.149.158.224) by smtplq04.aruba.it with SMTP; 29 Mar 2012 12:29:32 -0000 Received: (qmail 32265 invoked by uid 89); 29 Mar 2012 12:29:32 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@130.129.23.208) by smtp4.ad.aruba.it with SMTP; 29 Mar 2012 12:29:32 -0000 Date: Thu, 29 Mar 2012 14:29:28 +0200 From: Lorenzo Miniero To: Dean Willis Message-ID: <20120329142928.4c21fee2@lminiero-acer> In-Reply-To: References: Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp4.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for H.263 baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:29:37 -0000 +1 Lorenzo Il giorno Thu, 29 Mar 2012 14:15:35 +0200 Dean Willis ha scritto: > In today's meeting I made a plea for a mandatory baseline codec that > is approachable to the small developer without the cost and IPR risks > of either H.264 or VP8. > > I believe that some sort of baseline codec is required to jump start > the protocol. It's OK if this isn't the best possible codec. Market > forces will assure that commercial implementations converge on a > higher quality when the market requires it. > > While I proposed today that H.261 could serve as a baseline, we know > this would be "extremely basic". In other words, it might not pass > the "good enough to use" test required for a successful launch. > > Stephane and several others suggested H.263 as an alternative during > the after-meeting chat. While it is not as IPR-safe a choice as > H.261, it is relatively mature and the known challenges have > generally failed. Implementations are reasonably available and should > make it possible for smaller implementers, students, and hobbyists to > play ball. It's not all that network efficient and is outright piggy > at higher resolutions, but it probably works "well enough to use." > > So I propose we set H.263 as the baseline ( I expect a bit of > profiling may be necessary to further qualify the baseline) and run > with that for now. If the situation changes, we can always replace it > before final publication. -- > Dean -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From Markus.Isomaki@nokia.com Thu Mar 29 05:31:02 2012 Return-Path: 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 417EA21F8ABD for ; Thu, 29 Mar 2012 05:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 3KQ+xeZUlkOo for ; Thu, 29 Mar 2012 05:31:00 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E3E8B21F8ABA for ; Thu, 29 Mar 2012 05:30:59 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2TCUWR2026470; Thu, 29 Mar 2012 15:30:54 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 15:30:51 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.245]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Thu, 29 Mar 2012 14:30:51 +0200 From: To: , Thread-Topic: [rtcweb] Proposal for H.263 baseline codec Thread-Index: AQHNDaWpd/o/91jlJkKpwWEOtM2OV5aBMYzQ Date: Thu, 29 Mar 2012 12:30:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [93.158.44.126] Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7621AFB9A008AM1MPN1042mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 29 Mar 2012 12:30:51.0743 (UTC) FILETIME=[C743EEF0:01CD0DA7] X-Nokia-AV: Clean Subject: Re: [rtcweb] Proposal for H.263 baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:31:02 -0000 --_000_E44893DD4E290745BB608EB23FDDB7621AFB9A008AM1MPN1042mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I support Dean's proposal to make H.263 as the mandatory-to-implement codec= . I'm not expert on profiles, but someone mentioned H.263 profile 0 as some= thing suitable for our needs (smallest IPR risk). I also believe that even making H.261 as the mandatory-to-implement would b= e better than going for the forced pseudo-random selection between H.264 or= VP8. Markus From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= ext Dean Willis Sent: 29 March, 2012 15:16 To: rtcweb@ietf.org Subject: [rtcweb] Proposal for H.263 baseline codec In today's meeting I made a plea for a mandatory baseline codec that is app= roachable to the small developer without the cost and IPR risks of either H= .264 or VP8. I believe that some sort of baseline codec is required to jump start the pr= otocol. It's OK if this isn't the best possible codec. Market forces will a= ssure that commercial implementations converge on a higher quality when the= market requires it. While I proposed today that H.261 could serve as a baseline, we know this w= ould be "extremely basic". In other words, it might not pass the "good enou= gh to use" test required for a successful launch. Stephane and several others suggested H.263 as an alternative during the af= ter-meeting chat. While it is not as IPR-safe a choice as H.261, it is rela= tively mature and the known challenges have generally failed. Implementatio= ns are reasonably available and should make it possible for smaller impleme= nters, students, and hobbyists to play ball. It's not all that network effi= cient and is outright piggy at higher resolutions, but it probably works "w= ell enough to use." So I propose we set H.263 as the baseline ( I expect a bit of profiling may= be necessary to further qualify the baseline) and run with that for now. I= f the situation changes, we can always replace it before final publication. -- Dean --_000_E44893DD4E290745BB608EB23FDDB7621AFB9A008AM1MPN1042mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I support Dean’s pr= oposal to make H.263 as the mandatory-to-implement codec. I’m not exp= ert on profiles, but someone mentioned H.263 profile 0 as something suitable for our needs (smallest IPR risk).

 <= /p>

I also believe that even = making H.261 as the mandatory-to-implement would be better than going for t= he forced pseudo-random selection between H.264 or VP8.

 <= /p>

Markus

 <= /p>

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Dean Willis
Sent: 29 March, 2012 15:16
To: rtcweb@ietf.org
Subject: [rtcweb] Proposal for H.263 baseline codec

 

In today's meeting I made a plea for a mandatory bas= eline codec that is approachable to the small developer without the cost an= d IPR risks of either H.264 or VP8.

 

I believe that some sort of baseline codec is requir= ed to jump start the protocol. It's OK if this isn't the best possible code= c. Market forces will assure that commercial implementations converge on a = higher quality when the market requires it.

 

While I proposed today that H.261 could serve as a b= aseline, we know this would be "extremely basic". In other words,= it might not pass the "good enough to use" test required for a s= uccessful launch.

 

Stephane and several others suggested H.263 as an al= ternative during the after-meeting chat. While it is not as IPR-safe a choi= ce as H.261, it is relatively mature and the known challenges have generall= y failed. Implementations are reasonably available and should make it possible for smaller implementers, students, = and hobbyists to play ball. It's not all that network efficient and is outr= ight piggy at higher resolutions, but it probably works "well enough t= o use."

 

So I propose we set H.263 as the baseline ( I expect= a bit of profiling may be necessary to further qualify the baseline) and r= un with that for now. If the situation changes, we can always replace it be= fore final publication.

--

Dean

--_000_E44893DD4E290745BB608EB23FDDB7621AFB9A008AM1MPN1042mgdn_-- From magnus.westerlund@ericsson.com Thu Mar 29 05:35:41 2012 Return-Path: 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 BDC9921F8AD2 for ; Thu, 29 Mar 2012 05:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.114 X-Spam-Level: X-Spam-Status: No, score=-108.114 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 NfGNOR5VTmys for ; Thu, 29 Mar 2012 05:35:41 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EDFAD21F8AD1 for ; Thu, 29 Mar 2012 05:35:40 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-c6-4f74571bd0e0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 43.11.25560.B17547F4; Thu, 29 Mar 2012 14:35:39 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Thu, 29 Mar 2012 14:35:39 +0200 Message-ID: <4F745719.5090709@ericsson.com> Date: Thu, 29 Mar 2012 14:35:37 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Bernard Aboba References: <4F732531.2030208@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:35:41 -0000 On 2012-03-29 08:02, Bernard Aboba wrote: > I agree with proposition #1 (SRTP) unconditionally. > > With respect to proposition #2 (DTLS-SRTP), perhaps the words "with > details to be worked out" should have been added. > > I believe that the consensus achieved was only on a general direction, > not an endorsement of particular proposals. > > Personally, I would like to have more specifics about the required > features of DTLS-SRTP in the RTCWEB context. I hope someone that knows the details can elaborate on this. I thought DTLS-SRTP has a core that you will need to implement. Then there is clearly a question of crypto algorithms to be supported. But that also applies to SRTP where we also need to select which crypto suites that are to be implemented if any in addtion to the MITM. The WG will need to select these details as part of the next steps. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bernard_aboba@hotmail.com Thu Mar 29 05:45:51 2012 Return-Path: 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 E166921F8B14 for ; Thu, 29 Mar 2012 05:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.38 X-Spam-Level: X-Spam-Status: No, score=-101.38 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 cYgCJY+Y4x48 for ; Thu, 29 Mar 2012 05:45:51 -0700 (PDT) Received: from blu0-omc4-s5.blu0.hotmail.com (blu0-omc4-s5.blu0.hotmail.com [65.55.111.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE1121F8AC1 for ; Thu, 29 Mar 2012 05:45:50 -0700 (PDT) Received: from BLU0-P2-EAS10 ([65.55.111.135]) by blu0-omc4-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 05:45:49 -0700 X-Originating-IP: [130.129.20.41] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: Date: Thu, 29 Mar 2012 14:46:22 +0200 To: Martin Thomson MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 29 Mar 2012 12:45:49.0592 (UTC) FILETIME=[DE6CD180:01CD0DA9] Cc: Randell Jesup , "" Subject: Re: [rtcweb] IdP and universal trust X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:45:52 -0000 There is a more basic problem here, which is that "legacy" scenarios are typ= ically about reaching an E.164 number. Given that IdP (or PKI for that mat= ter) cannot be used to prove ownership of an E.164 number, such as +14255551= 212@example.com, it is difficult to see how identity can be provided by any m= echanism for the legacy cases, and MITM attacks seem intrinsic to the scenar= io. For example, +14255551212@example.com is equivalent to +14255551212@evi= ltwin.example.net so that first-party IdPs are not authoritative for E.164 n= umbers, and MITM attacks have long been acknowledged as possible within the S= IP DTLS/SRTP framework (e.g. eviltwin.example.net can change the E.164 URI a= nd resign the message via RFC 4474 without being detected). On Mar 29, 2012, at 13:26, "Martin Thomson" wrote= : > On 29 March 2012 08:08, Hadriel Kaplan wrote: >> Yeah I've been trying to figure out if there's some advantage to having a= gateway be able to indicate "gateway@telco.com", once there is an IdP model= . I would think it's a major pita to deploy such a thing on gateways, unles= s there's a very popular IdP they could know everyone would trust. It would= actually be easier to just give the gateway a real TLS cert for DTLS to use= , from a major CA, since gateways are the types of systems real certs would b= e reasonably possible to install on. >=20 > This is an important point, and I think that perhaps you missed the > distinction. Iff third party assertions are permitted, then the > problem that you refer to - namely, finding someone that others trust > - is somewhat difficult. On the other hand, it is also true that you > can gain multiple assertions and increase the chances of finding an > acceptable IdP. >=20 > What seems more likely is that IdPs are only going to be authoritative > for their own domain. The overall story is a lot easier to tell. > This has the nice quality that you don't have to trust the IdP, you > only have to trust their CA. >=20 > --Martin > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Thu Mar 29 05:47:29 2012 Return-Path: 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 46D0621F8798 for ; Thu, 29 Mar 2012 05:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.049 X-Spam-Level: X-Spam-Status: No, score=-102.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, 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 PoZWHAfMWR3w for ; Thu, 29 Mar 2012 05:47:28 -0700 (PDT) Received: from snt0-omc2-s6.snt0.hotmail.com (snt0-omc2-s6.snt0.hotmail.com [65.55.90.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5E221F8797 for ; Thu, 29 Mar 2012 05:47:28 -0700 (PDT) Received: from SNT0-EAS258 ([65.55.90.72]) by snt0-omc2-s6.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 05:47:27 -0700 X-Originating-IP: [130.129.20.41] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <20120329142928.4c21fee2@lminiero-acer> Content-Transfer-Encoding: 7bit From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: <20120329142928.4c21fee2@lminiero-acer> Date: Thu, 29 Mar 2012 14:47:59 +0200 To: Lorenzo Miniero MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 29 Mar 2012 12:47:27.0500 (UTC) FILETIME=[18C864C0:01CD0DAA] Cc: "rtcweb@ietf.org" , Dean Willis Subject: Re: [rtcweb] Proposal for H.263 baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:47:29 -0000 +1 On Mar 29, 2012, at 14:29, "Lorenzo Miniero" wrote: > +1 > > Lorenzo > > > Il giorno Thu, 29 Mar 2012 14:15:35 +0200 > Dean Willis ha scritto: > >> In today's meeting I made a plea for a mandatory baseline codec that >> is approachable to the small developer without the cost and IPR risks >> of either H.264 or VP8. >> >> I believe that some sort of baseline codec is required to jump start >> the protocol. It's OK if this isn't the best possible codec. Market >> forces will assure that commercial implementations converge on a >> higher quality when the market requires it. >> >> While I proposed today that H.261 could serve as a baseline, we know >> this would be "extremely basic". In other words, it might not pass >> the "good enough to use" test required for a successful launch. >> >> Stephane and several others suggested H.263 as an alternative during >> the after-meeting chat. While it is not as IPR-safe a choice as >> H.261, it is relatively mature and the known challenges have >> generally failed. Implementations are reasonably available and should >> make it possible for smaller implementers, students, and hobbyists to >> play ball. It's not all that network efficient and is outright piggy >> at higher resolutions, but it probably works "well enough to use." >> >> So I propose we set H.263 as the baseline ( I expect a bit of >> profiling may be necessary to further qualify the baseline) and run >> with that for now. If the situation changes, we can always replace it >> before final publication. -- >> Dean > > > > -- > Lorenzo Miniero, COB > > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From p.ohanlon@gmail.com Thu Mar 29 05:48:42 2012 Return-Path: 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 39F4721F88DB for ; Thu, 29 Mar 2012 05:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 zPTnEJV194zL for ; Thu, 29 Mar 2012 05:48:40 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF88621F88D8 for ; Thu, 29 Mar 2012 05:48:39 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so19973wib.13 for ; Thu, 29 Mar 2012 05:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=hSCMY6gX4FEUZ5g9P9rmJXeI92p0Oiflb8TUndFiaMo=; b=T5SoA8yDYUGLKDJJBSIuJvE8n5W+PBmMqQAsEctKFtd9gE3Wbcpx94vk4QZM35SZx2 +0nnVhsVx5HO9JWDtXmN6SG9VsEFuwNHgNkBbVaSq8Sh2MYGM5joKpaawZ5kG3xEek/Z HRkrLmzaf9tV32EXFE7o8sk7L218DDLX3NTMoG96TZVDOKU5c7KsNj/7sn31cPGBhyGV aoXt3eguYZJJNZTKyc8WeiaFJZG8rE17YIp2U4kqbUJdiIHOuOnrhlaqJASUzxjvIXvF zvenZN6JFOlNYt9sg28DKUd+WtyGKORAxUn5XMtsnNquyfCe1mMaoBwmTy0LZ72WN1Bs /ugA== Received: by 10.180.85.69 with SMTP id f5mr5315169wiz.18.1333025318890; Thu, 29 Mar 2012 05:48:38 -0700 (PDT) Received: from dhcp-551d.meeting.ietf.org (dhcp-551d.meeting.ietf.org. [130.129.85.29]) by mx.google.com with ESMTPS id l5sm66880519wia.11.2012.03.29.05.48.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 05:48:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_F39DB3A0-7A23-485A-B507-7B3AD5C465CE" From: Piers O'Hanlon In-Reply-To: Date: Thu, 29 Mar 2012 14:48:35 +0200 Message-Id: <876B5C94-D6EC-463D-A3DB-1033DF794B76@gmail.com> References: To: X-Mailer: Apple Mail (2.1257) Cc: rtcweb@ietf.org, dean.willis@softarmor.com Subject: Re: [rtcweb] Proposal for H.263 baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:48:42 -0000 --Apple-Mail=_F39DB3A0-7A23-485A-B507-7B3AD5C465CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 29 Mar 2012, at 14:30, wrote: > Hi, > =20 > I support Dean=92s proposal to make H.263 as the = mandatory-to-implement codec. I=92m not expert on profiles, but someone = mentioned H.263 profile 0 as something suitable for our needs (smallest = IPR risk). > =20 > I also believe that even making H.261 as the mandatory-to-implement = would be better than going for the forced pseudo-random selection = between H.264 or VP8. > =20 One of the key limitations with H.261 is it's small range of available = supported resolutions (QCIF, Max:CIF(352x288)) - so if there is a low = IPR risk for an H.263(+?) configuration then it would be preferable.=20 The whole issue of which Profile and levels one might support for these = codecs is another issue as I think they lead to differing IPR = dependencies. Piers. > Markus > =20 > =20 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of ext Dean Willis > Sent: 29 March, 2012 15:16 > To: rtcweb@ietf.org > Subject: [rtcweb] Proposal for H.263 baseline codec > =20 > In today's meeting I made a plea for a mandatory baseline codec that = is approachable to the small developer without the cost and IPR risks of = either H.264 or VP8. > =20 > I believe that some sort of baseline codec is required to jump start = the protocol. It's OK if this isn't the best possible codec. Market = forces will assure that commercial implementations converge on a higher = quality when the market requires it. > =20 > While I proposed today that H.261 could serve as a baseline, we know = this would be "extremely basic". In other words, it might not pass the = "good enough to use" test required for a successful launch. > =20 > Stephane and several others suggested H.263 as an alternative during = the after-meeting chat. While it is not as IPR-safe a choice as H.261, = it is relatively mature and the known challenges have generally failed. = Implementations are reasonably available and should make it possible for = smaller implementers, students, and hobbyists to play ball. It's not all = that network efficient and is outright piggy at higher resolutions, but = it probably works "well enough to use." > =20 > So I propose we set H.263 as the baseline ( I expect a bit of = profiling may be necessary to further qualify the baseline) and run with = that for now. If the situation changes, we can always replace it before = final publication. > -- > Dean > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_F39DB3A0-7A23-485A-B507-7B3AD5C465CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Markus.Isomaki@nokia.com> = wrote:

I = support Dean=92s proposal to make H.263 as the mandatory-to-implement = codec. I=92m not expert on profiles, but someone mentioned H.263 profile = 0 as something suitable for our needs (smallest IPR = risk).
I = also believe that even making H.261 as the mandatory-to-implement would = be better than going for the forced pseudo-random selection between = H.264 or VP8.
 rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Dean = Willis
Sent: 29 March, 2012 = 15:16
To: rtcweb@ietf.org
Subject: [rtcweb] Proposal for = H.263 baseline codec
 
In today's meeting I made = a plea for a mandatory baseline codec that is approachable to the small = developer without the cost and IPR risks of either H.264 or = VP8.
I believe that some sort = of baseline codec is required to jump start the protocol. It's OK if = this isn't the best possible codec. Market forces will assure that = commercial implementations converge on a higher quality when the market = requires it.
While I proposed today = that H.261 could serve as a baseline, we know this would be "extremely = basic". In other words, it might not pass the "good enough to use" test = required for a successful launch.
 
Stephane and several others suggested H.263 as an = alternative during the after-meeting chat. While it is not as IPR-safe a = choice as H.261, it is relatively mature and the known challenges have = generally failed. Implementations are reasonably available and should = make it possible for smaller implementers, students, and hobbyists to = play ball. It's not all that network efficient and is outright piggy at = higher resolutions, but it probably works "well enough to = use."
So I propose we set H.263 = as the baseline ( I expect a bit of profiling may be necessary to = further qualify the baseline) and run with that for now. If the = situation changes, we can always replace it before final = publication.
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb

= --Apple-Mail=_F39DB3A0-7A23-485A-B507-7B3AD5C465CE-- From fluffy@iii.ca Thu Mar 29 05:54:03 2012 Return-Path: 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 349C821F8A2D for ; Thu, 29 Mar 2012 05:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 e8-Hi4MOuvVR for ; Thu, 29 Mar 2012 05:54:02 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id A91EB21F8A7B for ; Thu, 29 Mar 2012 05:53:59 -0700 (PDT) Received: from dhcp-10-61-96-243.cisco.com (unknown [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EBC7E50A5D; Thu, 29 Mar 2012 08:53:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F740AB6.1080609@ericsson.com> Date: Thu, 29 Mar 2012 14:53:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59C1272C-DA1D-4589-8702-AA26F7D5F676@iii.ca> References: <4F740AB6.1080609@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1257) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Poll for dates for Interim Meeting before IETF 84 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:54:03 -0000 Could we have the poll choices to indicate the location of the meeting? The problem is, and I suspect that this is a problem for most people, = depending on the location, my travel time dramatically changes the = number of days I need to have clear on my calendar.=20 On Mar 29, 2012, at 9:09 , Magnus Westerlund wrote: > WG, >=20 > We have started a doodle poll for an Interim meeting before IETF 84 in > Vancouver. Locations considered so far are Stockholm, Boston Area or > Silicon Valley. The meeting is planned to be a 2 day meeting. Please > indicate which of the suggest times that works for you. >=20 >=20 > http://doodle.com/nm3pp69znr3286cy >=20 >=20 > Cheers >=20 > Magnus Westerlund > WG chair >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Thu Mar 29 05:54:12 2012 Return-Path: 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 429C321F8AC9 for ; Thu, 29 Mar 2012 05:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.127 X-Spam-Level: X-Spam-Status: No, score=-102.127 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, 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 uIl3ypT+2WTd for ; Thu, 29 Mar 2012 05:54:11 -0700 (PDT) Received: from snt0-omc3-s1.snt0.hotmail.com (snt0-omc3-s1.snt0.hotmail.com [65.55.90.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9591521F8A7B for ; Thu, 29 Mar 2012 05:54:11 -0700 (PDT) Received: from SNT0-P5-EAS23 ([65.55.90.135]) by snt0-omc3-s1.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 05:54:10 -0700 X-Originating-IP: [130.129.20.41] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <4F732531.2030208@ericsson.com> <4F745719.5090709@ericsson.com> Content-Transfer-Encoding: base64 From: Bernard Aboba Content-Type: text/plain; charset="utf-8" In-Reply-To: <4F745719.5090709@ericsson.com> Date: Thu, 29 Mar 2012 14:54:42 +0200 To: Magnus Westerlund MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 29 Mar 2012 12:54:10.0035 (UTC) FILETIME=[08B65C30:01CD0DAB] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:54:12 -0000 VGhlcmUgYXJlIGEgbnVtYmVyIG9mIHBvdGVudGlhbCB2YXJpYW50czoNCg0KYS4gRFRMUy1TUlRQ IHdpdGggSWRQIChFcmljJ3MgcHJvcG9zYWwpDQpiLiBEVExTLVNSVFAgYXMgdXNlZCB3aXRoIFNJ UCAoZS5nLiB3L1JGQyA0NDc0KQ0KYy4gRFRMUy1TUlRQLUVLVA0KZC4gRFRMUy1TUlRQIHdpdGgg UEtJIChjb3VsZCBiZSB1c2VkIGluIGdvdmVybm1lbnQgb3IgaGlnaCBzZWN1cml0eSBzZXR0aW5n cykNCg0KVGhlc2UgdmFyaWFudHMgZGlmZmVyIGluIHRoZWlyIHBvdGVudGlhbCB1c2UgY2FzZXMs IHNlY3VyaXR5IHByb3BlcnRpZXMgYW5kIGludGVyb3BlcmFiaWxpdHkgd2l0aCBleGlzdGluZyBp bXBsZW1lbnRhdGlvbnMuIA0KDQpPbiBNYXIgMjksIDIwMTIsIGF0IDE0OjM1LCAiTWFnbnVzIFdl c3Rlcmx1bmQiIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiBJIGhv cGUgc29tZW9uZSB0aGF0IGtub3dzIHRoZSBkZXRhaWxzIGNhbiBlbGFib3JhdGUgb24gdGhpcy4g SSB0aG91Z2h0DQo+IERUTFMtU1JUUCBoYXMgYSBjb3JlIHRoYXQgeW91IHdpbGwgbmVlZCB0byBp bXBsZW1lbnQuIFRoZW4gdGhlcmUgaXMNCj4gY2xlYXJseSBhIHF1ZXN0aW9uIG9mIGNyeXB0byBh bGdvcml0aG1zIHRvIGJlIHN1cHBvcnRlZC4gQnV0IHRoYXQgYWxzbw0KPiBhcHBsaWVzIHRvIFNS VFAgd2hlcmUgd2UgYWxzbyBuZWVkIHRvIHNlbGVjdCB3aGljaCBjcnlwdG8gc3VpdGVzIHRoYXQN Cj4gYXJlIHRvIGJlIGltcGxlbWVudGVkIGlmIGFueSBpbiBhZGR0aW9uIHRvIHRoZSBNSVRNLiBU aGUgV0cgd2lsbCBuZWVkIHRvDQo+IHNlbGVjdCB0aGVzZSBkZXRhaWxzIGFzIHBhcnQgb2YgdGhl IG5leHQgc3RlcHMuDQo+IA0KPiBDaGVlcnMNCj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IE11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNl YXJjaCBFQUIvVFZNDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAg ICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCj4gRsOkcsO2Z2F0YW4gNiAgICAgICAgICAgICAg ICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58 IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gDQo= From oscar.ohlsson@ericsson.com Thu Mar 29 06:19:16 2012 Return-Path: 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 113D621F8B5E for ; Thu, 29 Mar 2012 06:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.781 X-Spam-Level: X-Spam-Status: No, score=-9.781 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] 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 5U3vdtVVRbzk for ; Thu, 29 Mar 2012 06:19:14 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A593221F8B58 for ; Thu, 29 Mar 2012 06:19:13 -0700 (PDT) X-AuditID: c1b4fb3d-b7b5aae000002dcb-df-4f7461501307 Authentication-Results: mailgw10.se.ericsson.net x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA) Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 25.C9.11723.051647F4; Thu, 29 Mar 2012 15:19:12 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.51]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 29 Mar 2012 15:19:11 +0200 From: Oscar Ohlsson To: "Fabio Pietrosanti (naif)" , "" Date: Thu, 29 Mar 2012 15:19:11 +0200 Thread-Topic: [rtcweb] Support of SDES in WebRTC Thread-Index: Ac0NiZWYdHL9SBPWQgOmTuIcbk0A4wAIZ5Aw Message-ID: References: <4F742344.802@infosecurity.ch> In-Reply-To: <4F742344.802@infosecurity.ch> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Support of SDES in WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:19:16 -0000 Hi Fabio, My assumption has always been the following: - DTLS-SRTP is the default - DTLS-SRTP + identity can be turned on via the JavaScript API if the webap= p wishes to do so - SDES can be turned on by a manipulated SDP offer/answer provided the enti= re webapp was retrieved over HTTPS BTW I'm also in favor of _only_ allowing the SRTP NULL encryption algorithm= in browser debug/developer mode. Regards, Oscar Ohlsson > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Fabio Pietrosanti (naif) > Sent: Thursday, March 29, 2012 10:54 AM > To: > Subject: [rtcweb] Support of SDES in WebRTC >=20 > On the topic of SDES vs DTLS-SRTP a very nice analysis has=20 > been done on: > http://www.potaroo.net/ietf/idref/draft-ohlsson-rtcweb-sdes-support/ >=20 > Considering how vague are the security implementation=20 > consideration of DTLS-SRTP and how widely diffused in=20 > SDES-SRTP, i'm wondering whenever we should not mandate the=20 > use of SDES-SRTP. >=20 > That way we would be able to see: >=20 > - All implementation will start with SDES (simpler and quicker) > - For who want enhanced security, greater implementation and=20 > interoperability complexity, implement also DTLS-SRTP >=20 > But for the industry a full cycle of: > - Implementation > - Stabilization > - Interoperability >=20 > for DTLS-SRTP (that nobody use) may require from 2 up to 4-5=20 > years of time. >=20 > If we goes for SDES-SRTP by default, as early choice, probably within > 1-2 years at maximum we can expect the overall technological=20 > ecosystem to be stable and interoperable. >=20 > Because it will be built on top of existing stable framework. >=20 > We may save dozens millions of USD of investments costs for=20 > the industry and gain some hundreds millions of users year in=20 > advance, just because we would save several years of time. >=20 > I think that those consideration are valuable enough to=20 > strongly consider arguments in making SDES-SRTP a preferred,=20 > mandatory implementation for WebRTC. >=20 > -- > Fabio Pietrosanti > Founder, CTO >=20 > Tel: +39 02 85961748 (direct) > Mobile: +39 340 1801049 > E-mail: fabio.pietrosanti@privatewave.com > Skype: fpietrosanti > Linkedin: http://linkedin.com/in/secret >=20 > PrivateWave Italia S.p.A. > Via Gaetano Giardino 1 - 20123 Milano - Italy=20 > www.privatewave.com _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From abu_hurayrah@hidayahonline.org Thu Mar 29 06:19:41 2012 Return-Path: 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 4ABAA21F8B5A for ; Thu, 29 Mar 2012 06:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] 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 ZMLzIbPhBhTL for ; Thu, 29 Mar 2012 06:19:40 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 574BE21F8B59 for ; Thu, 29 Mar 2012 06:19:40 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 1E07865265C for ; Thu, 29 Mar 2012 09:19:39 -0400 (EDT) Message-ID: <4F746163.5090506@hidayahonline.org> Date: Thu, 29 Mar 2012 09:19:31 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=5AF4B362 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposal for H.263 baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:19:41 -0000 On 03/29/2012 08:15 AM, Dean Willis wrote: > In today's meeting I made a plea for a mandatory baseline codec that > is approachable to the small developer without the cost and IPR risks > of either H.264 or VP8. > > I believe that some sort of baseline codec is required to jump start > the protocol. It's OK if this isn't the best possible codec. Market > forces will assure that commercial implementations converge on a > higher quality when the market requires it. > > While I proposed today that H.261 could serve as a baseline, we know > this would be "extremely basic". In other words, it might not pass the > "good enough to use" test required for a successful launch. > > Stephane and several others suggested H.263 as an alternative during > the after-meeting chat. While it is not as IPR-safe a choice as H.261, > it is relatively mature and the known challenges have generally > failed. Implementations are reasonably available and should make it > possible for smaller implementers, students, and hobbyists to play > ball. It's not all that network efficient and is outright piggy at > higher resolutions, but it probably works "well enough to use." > > So I propose we set H.263 as the baseline ( I expect a bit of > profiling may be necessary to further qualify the baseline) and run > with that for now. If the situation changes, we can always replace it > before final publication. > -- > Dean Claiming that VP8 is riskier than a known IPR-enforced format is a specious claim considering its already widely implemented usage across the web on numerous sites and in hardware. Additionally, a patent pool was called for over a year ago, and nothing has been made public about this. No technology can be completely free from the specter of patent trolls and spurious software patents, so these arguments that VP8 is not suitable based on this could be applied to anyone. The fact of the matter is that the only known patents on VP8 are owned now by Google and they have been licensed in a way compatible with all appropriate uses of the technology, including WebRTC. While I appreciate the sentiment of this suggestion, I am of the opinion that choosing a known-restricted format over VP8 will be counter-productive to the adoption of the WebRTC standard and will, in fact, restrict possible implementations. From martin.thomson@gmail.com Thu Mar 29 06:30:08 2012 Return-Path: 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 5C1A921F8B3C for ; Thu, 29 Mar 2012 06:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 j0GBMeBrEDY1 for ; Thu, 29 Mar 2012 06:30:07 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B41121F8B35 for ; Thu, 29 Mar 2012 06:30:06 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2172082bku.31 for ; Thu, 29 Mar 2012 06:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=06vVLhmtWjLvD9Q+mMV5JCPITydSj+Ff8qocLnNpzT4=; b=jjd8NHGqVgmwdP1BTFNDVc8h7KNdNtdd4yf3hzCYM5fiUrrf13CkhY750lH9qP28f0 svxl5EKYhJaJeS/SGDwIS4zbdK7+xswRU7HXKLcPXL08SVIu0MQipnqDPLVX8IwEEsMl /K8sID+JiaJT0HzpPh64UF7g+0I7c/ifIRMBERwlBoABNpTTqY6uKCL+d5+7za38Y6ct ApZNtUt2s21sU5KfS6KB2JsHoEz1WMueFbCo5tLRHQHrc3i/KopEF1BEu0J0aawb7pjl mCdN5iQD/p0hradUtN6KTDbEzRbfhDMrY4v5THv+wKK00UDN+93hKwaC0t5LvY+xcdgV kmZw== MIME-Version: 1.0 Received: by 10.204.152.156 with SMTP id g28mr14178670bkw.83.1333027806099; Thu, 29 Mar 2012 06:30:06 -0700 (PDT) Received: by 10.205.38.73 with HTTP; Thu, 29 Mar 2012 06:30:06 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Mar 2012 15:30:06 +0200 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , "" Subject: Re: [rtcweb] IdP and universal trust X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:30:08 -0000 On 29 March 2012 14:46, Bernard Aboba wrote: >=C2=A0For example, +14255551212@example.com is equivalent to +14255551212@= eviltwin.example.net Actually, if third party assertions were prohibited, these would be considered different, though I suspect that a user would have some difficulty making the distinction. But I take your point. From stewe@stewe.org Thu Mar 29 06:48:03 2012 Return-Path: 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 AE84D21F8AD0 for ; Thu, 29 Mar 2012 06:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.829 X-Spam-Level: X-Spam-Status: No, score=-3.829 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 SJb+p+20gt+9 for ; Thu, 29 Mar 2012 06:48:02 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE5521F8A8D for ; Thu, 29 Mar 2012 06:48:00 -0700 (PDT) Received: from mail97-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 13:48:00 +0000 Received: from mail97-db3 (localhost [127.0.0.1]) by mail97-db3-R.bigfish.com (Postfix) with ESMTP id E6AF74A0759; Thu, 29 Mar 2012 13:47:59 +0000 (UTC) X-SpamScore: -18 X-BigFish: PS-18(z11d7lz1803Mc85eh98dKzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839hbe3k) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT005.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail97-db3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT005.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail97-db3 (localhost.localdomain [127.0.0.1]) by mail97-db3 (MessageSwitch) id 1333028877762143_28911; Thu, 29 Mar 2012 13:47:57 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.226]) by mail97-db3.bigfish.com (Postfix) with ESMTP id A99C21E007A; Thu, 29 Mar 2012 13:47:57 +0000 (UTC) Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 13:47:56 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.179]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0135.002; Thu, 29 Mar 2012 13:47:55 +0000 From: Stephan Wenger To: Piers O'Hanlon , "Markus.Isomaki@nokia.com" Thread-Topic: [rtcweb] Proposal for H.263 baseline codec Thread-Index: AQHNDaWq9kefa/omnUePrLHPwXaly5aBNEEAgAAE9YCAADIYAA== Date: Thu, 29 Mar 2012 13:47:54 +0000 Message-ID: In-Reply-To: <876B5C94-D6EC-463D-A3DB-1033DF794B76@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: multipart/alternative; boundary="_000_CB9A2910852BCstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" , "dean.willis@softarmor.com" Subject: Re: [rtcweb] Proposal for H.263 baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:48:03 -0000 --_000_CB9A2910852BCstewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, A few random data points about H.263. I write this as someone who sat through the meetings which defined H.263+ a= nd H.263++ and with a vague recollection who proposed what. I'm leaning my= self fairly far out of the window here, so let me emphasize that this is no= t a formal risk analysis, no legal advice, and that it is instead today's s= napshot of what I would think is a sensible position for a risk-averse impl= ementer, which may be very different tomorrow. As usual, you and your lega= l folks will have to perform your own risk analysis. For those unfamiliar = with the ITU tool set, the ITU patent database can be found here http://www= .itu.int/ipr/IPRSearch.aspx?iprtype=3DPS and can be searched for Recommenda= tion H.263. The content of this database probably needs to be interpreted = in the context of the then valid policies, disclosure and declaration requi= rements, and practices in the ITU, which were IMO and at the time, consider= ably less strict than the disclosure requirements observed in the IETF toda= y. H.263 is not "profiled" in the sense the MPEG video codecs are. There is a= n Annex X defining profiles and levels, but this Annex was added several ye= ars after the first revision of H.263, almost as an afterthought. The prof= iles defined therein are not necessarily the mode combinations that are (or= have been) in practical use. Compared to modern video codecs, H.263 is trivial to implement. I would su= ggest that the availability or non-availability of certain modes and option= s in today's software base (be it open source or proprietary) should not th= e key driver in profiling H.263. Compared to the implementation effort of = the rest of the rtcweb stack, an H.263 implementation is cheap to have. The reference implementation for H.263+ was maintained by the University of= British Columbia and later by UB Video, and access to it for the public wa= s removed around 1999. UB Video also sold a close-to-real-time (on the mac= hines of the time) H.263+ encoder and decoder library. On today's machines= , I would expect this software, after some optimization reflecting "modern"= instructions sets, to handle 720p encoding and decoding on most machines. = UB Video was acquired by Scientific Atlanta, which in turn was acquired by= Cisco. AFAIK, today, Cisco owns the rights to all this software. I could= likely establish contacts to those people inside Cisco who may still have = a copy of the software, if I were approached by Cisco folks not so fortunat= e. Personally, I would not expect an IPR risk to go up significantly (compared= to H.263 baseline 1996) when using the PLUSPTYPE header, which would (amon= g other things) allow for flexible picture sizes. The same is IMHO true fo= r some of the optional modes of H.263+ that are "bug fixes" to the 1996 ver= sion of the spec, for example Annexes I (advanced intra), J (deblocking fil= ter), K (slices), and S (VLC bug fix) , as well as 1996 Annex D (unrestrict= ed motion). Annex I helps for Intra pictures, J is good for subjective qua= lity and not such a computational complexity bear as Annex F (overlapped bl= ock motion compensation), you want slices for MTU size matching if your pic= ture size goes beyond CIF, and S is a bug fix. The majority of the above coding tools do not require tricky encoder mode d= ecision steps; the are simply alternate or additional syntax for baseline t= ools and functionalities. Regards, Stephan From: Piers O'Hanlon > Date: Thu, 29 Mar 2012 14:48:35 +0200 To: > Cc: >, > Subject: Re: [rtcweb] Proposal for H.263 baseline codec On 29 Mar 2012, at 14:30, > wrote: Hi, I support Dean=92s proposal to make H.263 as the mandatory-to-implement cod= ec. I=92m not expert on profiles, but someone mentioned H.263 profile 0 as = something suitable for our needs (smallest IPR risk). I also believe that even making H.261 as the mandatory-to-implement would b= e better than going for the forced pseudo-random selection between H.264 or= VP8. One of the key limitations with H.261 is it's small range of available supp= orted resolutions (QCIF, Max:CIF(352x288)) - so if there is a low IPR risk = for an H.263(+?) configuration then it would be preferable. The whole issue of which Profile and levels one might support for these cod= ecs is another issue as I think they lead to differing IPR dependencies. Piers. Markus From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of ext Dean Willis Sent: 29 March, 2012 15:16 To: rtcweb@ietf.org Subject: [rtcweb] Proposal for H.263 baseline codec In today's meeting I made a plea for a mandatory baseline codec that is app= roachable to the small developer without the cost and IPR risks of either H= .264 or VP8. I believe that some sort of baseline codec is required to jump start the pr= otocol. It's OK if this isn't the best possible codec. Market forces will a= ssure that commercial implementations converge on a higher quality when the= market requires it. While I proposed today that H.261 could serve as a baseline, we know this w= ould be "extremely basic". In other words, it might not pass the "good enou= gh to use" test required for a successful launch. Stephane and several others suggested H.263 as an alternative during the af= ter-meeting chat. While it is not as IPR-safe a choice as H.261, it is rela= tively mature and the known challenges have generally failed. Implementatio= ns are reasonably available and should make it possible for smaller impleme= nters, students, and hobbyists to play ball. It's not all that network effi= cient and is outright piggy at higher resolutions, but it probably works "w= ell enough to use." So I propose we set H.263 as the baseline ( I expect a bit of profiling may= be necessary to further qualify the baseline) and run with that for now. I= f the situation changes, we can always replace it before final publication. -- Dean _______________________________________________ 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/rtcw= eb --_000_CB9A2910852BCstewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0387F14B395B9048AB7A009703C4C467@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,

A few random data points about H.263.

I write this as someone who sat through the meetings which defined H.2= 63+ and H.263++ and with a vague recollection who proposed what= .  I'm leaning myself fairly far out of the window here, so let me emp= hasize that this is not a formal risk analysis, no legal advice, and that it is instead today's snapshot of what I would thin= k is a sensible position for a risk-averse implementer, which may be very d= ifferent tomorrow.  As usual, you and your legal folks will have to pe= rform your own risk analysis.  For those unfamiliar with the ITU tool set, the ITU patent database can be found her= e http:= //www.itu.int/ipr/IPRSearch.aspx?iprtype=3DPS and can be searched = for Recommendation H.263.  The content of this database probably needs to be interpreted in the context of the then valid policies= , disclosure and declaration requirements, and practices in the ITU, which = were IMO and at the time, considerably less strict than the disclosure requ= irements observed in the IETF today.

H.263 is not "profiled" in the sense the MPEG video codecs a= re.  There is an Annex X defining profiles and levels, but this Annex = was added several years after the first revision of H.263, almost as an aft= erthought.  The profiles defined therein are not necessarily the mode combinations that are (or have been) in practical use= .

Compared to modern video codecs, H.263 is trivial to implement.  = I would suggest that the availability or non-availability of certain modes = and options in today's software base (be it open source or proprietary) sho= uld not the key driver in profiling H.263.  Compared to the implementation effort of the rest of the rtcweb stac= k, an H.263 implementation is cheap to have.  

The reference implementation for H.263+ was maintained by the Univ= ersity of British Columbia and later by UB Video, and access to it for the = public was removed around 1999.  UB Video also sold a close-to-real-ti= me (on the machines of the time) H.263+ encoder and decoder library.  On today's machines, I would expect this softwa= re, after some optimization reflecting "modern" instructions sets= , to handle 720p encoding and decoding on most machines.  UB Video was= acquired by Scientific Atlanta, which in turn was acquired by Cisco.  AFAIK, today, Cisco owns the rights to all this software. =  I could likely establish contacts to those people inside Cisco who ma= y still have a copy of the software, if I were approached by Cisco folks no= t so fortunate.

Personally, I would not expect an IPR risk to go up significantly (com= pared to H.263 baseline 1996) when using the PLUSPTYPE header, which would = (among other things) allow for flexible picture sizes.  The same is IM= HO true for some of the optional modes of H.263+ that are "bug fixes" to the 1996 version of the sp= ec, for example Annexes I (advanced intra), J (deblocking filter), K (slice= s), and S (VLC bug fix) , as well as 1996 Annex D (unrestricted motion). &n= bsp;Annex I helps for Intra pictures, J is good for subjective quality and not such a computational complexity bear as Annex F= (overlapped block motion compensation), you want slices for MTU size match= ing if your picture size goes beyond CIF, and S is a bug fix.  

The majority of the above coding tools do not require tricky encoder m= ode decision steps; the are simply alternate or additional syntax for basel= ine tools and functionalities.

Regards,
Stephan



From: Piers O'Hanlon <p.ohanlon@gmail.com>
Date: Thu, 29 Mar 2012 14:48:35 = 3;0200
To: <Markus.Isomaki@nokia.com>
Cc: <rtcweb@ietf.org>, <dean.willis@softarmor.com>
Subject: Re: [rtcweb] Proposal for = H.263 baseline codec


On 29 Mar 2012, at 14:30, <Markus.Isomaki@nokia.com> wrote:

Hi,
 
I support Dean=92s proposal to make H.263 as the mandator= y-to-implement codec. I=92m not expert on profiles, but someone mentioned H= .263 profile 0 as something suitable for our needs (smallest IPR risk).
 
I also believe that even making H.261 as the mandatory-to= -implement would be better than going for the forced pseudo-random selectio= n between H.264 or VP8.
 
One of the key limitations with H.261 is it's small range of available supp= orted resolutions (QCIF, Max:CIF(352x288)) - so if there is a low IPR = risk for an H.263(+?) configuration then it would be preferable. <= /div>

The whole issue of which Profile and levels one might support for thes= e codecs is another issue as I think they lead to differing IPR dependencie= s.

Piers.

Markus
 
 
From:=  rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org= ] On Behalf Of ext Dean Willis
Sent: 29 March, 20= 12 15:16
To: rtcweb@ietf.org
Subject: [rtcweb] = Proposal for H.263 baseline codec
 
In today's meeting I made a plea for a mandatory baseline codec that is app= roachable to the small developer without the cost and IPR risks of either H= .264 or VP8.
 
I believe that some sort of baseline codec is required to jump start the pr= otocol. It's OK if this isn't the best possible codec. Market forces will a= ssure that commercial implementations converge on a higher quality when the= market requires it.
 
While I proposed today that H.261 could serve as a baseline, we know this w= ould be "extremely basic". In other words, it might not pass the = "good enough to use" test required for a successful launch.<= /o:p>
 
Stephane and several others suggested H.263 as an alternative during the af= ter-meeting chat. While it is not as IPR-safe a choice as H.261, it is rela= tively mature and the known challenges have generally failed. Implementatio= ns are reasonably available and should make it possible for smaller implementers, students, and hobbyists = to play ball. It's not all that network efficient and is outright piggy at = higher resolutions, but it probably works "well enough to use."
 
So I propose we set H.263 as the baseline ( I expect a bit of profiling may= be necessary to further qualify the baseline) and run with that for now. I= f the situation changes, we can always replace it before final publication.=
--
Dean
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CB9A2910852BCstewesteweorg_-- From bernard_aboba@hotmail.com Thu Mar 29 06:54:05 2012 Return-Path: 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 9080A21F8B7D for ; Thu, 29 Mar 2012 06:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.488 X-Spam-Level: X-Spam-Status: No, score=-101.488 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 M-2owdS-zdS8 for ; Thu, 29 Mar 2012 06:54:04 -0700 (PDT) Received: from blu0-omc4-s5.blu0.hotmail.com (blu0-omc4-s5.blu0.hotmail.com [65.55.111.144]) by ietfa.amsl.com (Postfix) with ESMTP id 24B0F21F8B38 for ; Thu, 29 Mar 2012 06:54:02 -0700 (PDT) Received: from BLU0-P1-EAS74 ([65.55.111.137]) by blu0-omc4-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 06:54:02 -0700 X-Originating-IP: [130.129.20.41] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <4F742344.802@infosecurity.ch> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: Date: Thu, 29 Mar 2012 15:54:35 +0200 To: Oscar Ohlsson MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 29 Mar 2012 13:54:02.0478 (UTC) FILETIME=[65F9A8E0:01CD0DB3] Cc: "" Subject: Re: [rtcweb] Support of SDES in WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:54:05 -0000 Oscar said: > - SDES can be turned on by a manipulated SDP offer/answer provided the ent= ire webapp was retrieved over HTTPS [BA[ Unless SDES is indicated as supported in the SDP blob provided by creat= eAnswer(), "manipulating" the SDP offer to add it probably isn't a good idea= .=20 That's one reason why we need understand the precise semantics of createAnsw= er(). To (mis)quote Christer: does createAnswer() indicate a (subset) of w= hat the browser can do, what it would prefer to do, or all that it is capabl= e of doing?=20= From dwing@cisco.com Thu Mar 29 06:56:01 2012 Return-Path: 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 7339F21F8BA8 for ; Thu, 29 Mar 2012 06:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.474 X-Spam-Level: X-Spam-Status: No, score=-109.474 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 L5HRGKJVaENq for ; Thu, 29 Mar 2012 06:56:00 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFBC21F8B99 for ; Thu, 29 Mar 2012 06:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1526; q=dns/txt; s=iport; t=1333029360; x=1334238960; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=FEY69NKuk12V3JAplS4Ugrz2FON8US/VB0bemk6o2ao=; b=CBQm7PoFg61e9M56Nc18kRMPDx/GlGtF1c8Ww1y3W8/ERGRR7/JJTG1o gTRiJZQX4AtV9y9BWpd1jaqVZdfnhmbwTptfuAuhS8iq3xUUxaeLvF+/N 8K3FXpZRBUgQGzsv3wahZs4677wadNj2tcKcs7xgHMp6gSbU4d3Idpm8c o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJtodE+rRDoJ/2dsb2JhbAA6Cak+j1uBB4IJAQEBBAgKARcQNQoMAQMCCQ4BAgQBAQEnBxkjCgkIAgQTCxeHZ59SlzqKdIYrBI1rljyBaIJp X-IronPort-AV: E=Sophos;i="4.73,668,1325462400"; d="scan'208";a="35628246" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 29 Mar 2012 13:56:00 +0000 Received: from dwingWS (sjc-vpn4-676.cisco.com [10.21.82.164]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2TDtuoN020897; Thu, 29 Mar 2012 13:55:57 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" References: <4F72D6B3.40803@bbn.com> <4F72E453.7070204@alvestrand.no> <4F72EB53.5000409@bbn.com> <0bf301cd0d04$22d53200$687f9600$@com> <00052A1F-CE65-4A53-9B7D-261E1CC75426@acmepacket.com> In-Reply-To: <00052A1F-CE65-4A53-9B7D-261E1CC75426@acmepacket.com> Date: Thu, 29 Mar 2012 15:55:55 +0200 Message-ID: <032f01cd0db3$abeaeee0$03c0cca0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNDS3wTtwICWEdGUmv8/XIx55mBJaBSx7w Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:56:01 -0000 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Wednesday, March 28, 2012 11:59 PM > To: Dan Wing > Cc: Richard L. Barnes; Harald Alvestrand; > Subject: Re: [rtcweb] SRTP and "marketing" > > > On Mar 28, 2012, at 6:59 PM, Dan Wing wrote: > > > We do need a foundation upon which an authentication/identity > > infrastructure can be built. We know we need one. > > That foundation is DTLS-SRTP, and not Security Descriptions. > > Now you're starting to sound like a marketing guy. ;) > What's next: "we'll build more synergy and have a unified platform with > DTLS-SRTP"? > > But more seriously, I don't understand this "foundation" argument. > We're going to have DTLS-SRTP. No one's suggesting we don't have DTLS- > SRTP. All Browsers MUST implement DTLS-SRTP. We'll have it for > Browser-to-Browser, and for Browser-to-Gateway if the Gateway supports > it. We'll have the foundation. > > Requiring it for Gateways would make sense if it offered some real > advantage, or didn't have any disadvantages. There don't appear to be > real advantages, while we know of disadvantages. And gateways have no > real means of offering an end-to-end identity. Why would you want to > build a foundation on air? Even without any sort of identity at all, DTLS-SRTP provides superior media security compared with Security Descriptions -- even if one (or both) endpoints are gateways to RTP or are gateways to SDESC-SRTP. -d From juberti@google.com Thu Mar 29 07:00:34 2012 Return-Path: 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 3398921E801B for ; Thu, 29 Mar 2012 07:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.786 X-Spam-Level: X-Spam-Status: No, score=-102.786 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 mcRJezw2qrzz for ; Thu, 29 Mar 2012 07:00:33 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E02AF21E801A for ; Thu, 29 Mar 2012 07:00:32 -0700 (PDT) Received: by qaea16 with SMTP id a16so96808qae.10 for ; Thu, 29 Mar 2012 07:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=135gqUMnI5lIkow1z7WQDsRpAjQ5f59ZBzoxtkORFS4=; b=kHPCO0y/aFjGM+iWHtVvYSwuA3mf4K3Bc9uZz2N8FJF9F7J0AdXzbRDfdmjPzwSMCL TSsqBCxfZQSrJXQ2ImuDseH228VHLhkaLRcZNT2ANgATe7VRmFyM/yP343YaO2+3val3 UJRY7Zu36acLGPHKNuiGeKfw6Brwg0bhYqu8ky380GXzUF2l88/wXQXVM+KWIb0OBeEP oo6lhoAo5ahWjVlgn2kZJGjl2GyKgNJqYRkoFLFlTZVrUyS/4m6YWcYLmnZHh+SxQjHw NoX2gxHSSAbwC/ToF8flu/zp7oiz9CGG8UVPHhPoUzurlXz+z5WLH+gCQx5OkVQ14iiE zYeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:x-gm-message-state:content-type; bh=135gqUMnI5lIkow1z7WQDsRpAjQ5f59ZBzoxtkORFS4=; b=MK5YMupw2oYwwnhyHObOuv9+wa3UiKpFqNtJ3P7gL/xxHDD0UL3GQpWggexSoBk56R y8sV+GT2xJu3uVSIcpgAGY3s9YIQOn3Id7g7rMgMZE2RypDB0VScU1Ppxwjm8GEH6JBL hnWl2tlGE5DfufIEWcBfVCbKl5Z1DUH/LkOTi4znEqKXf13g5g7Y58BbIRUVKa1lYy+7 IhUMbzoeYB0AZXziRoRIEpZRlM7TjObB6Q9/0m9+E7wZ69saBmJrl/ue8JHxn8XPZkEl EvXfB8DSeNzhUJrzGTr8NjHuL7AF0hG1msUHs04n9ZCK/5K8xVSvSuTIHShrLnvmPbpT whjg== Received: by 10.224.193.69 with SMTP id dt5mr150162qab.75.1333029629636; Thu, 29 Mar 2012 07:00:29 -0700 (PDT) Received: by 10.224.193.69 with SMTP id dt5mr149944qab.75.1333029627498; Thu, 29 Mar 2012 07:00:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.161.134 with HTTP; Thu, 29 Mar 2012 07:00:07 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> <4F737DB3.5020804@hidayahonline.org> From: Justin Uberti Date: Thu, 29 Mar 2012 10:00:07 -0400 Message-ID: To: Roman Shpount X-System-Of-Record: true X-Gm-Message-State: ALoCoQlF7FPBi4pI25QQEFAaZwNLVUelfGyCqRRft01cg6bIa4SZ9u6DMROgqqqRgCRWPUev1OQcnmD0SF3lRa/tIXNQ/phvwrOPogIHYD3urf2BaUKlWer72PfdMZFZmaw0XaoZIRLC Content-Type: multipart/alternative; boundary=20cf300515066c0fdd04bc6225b8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:00:34 -0000 --20cf300515066c0fdd04bc6225b8 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 29, 2012 at 1:56 AM, Roman Shpount wrote: > > On Wed, Mar 28, 2012 at 5:08 PM, Basil Mohamed Gohar < > abu_hurayrah@hidayahonline.org> wrote: > >> The scope of WebRTC is broad enough to consider that we need to think >> about what's best going forward with regards to its implementation. >> Security by default is one of the best practices in general, the support >> from the browser community and others that are behind it will definitely >> ensure that adoption is widespread enough to make it easy enough to >> integrate into existing systems, as free software solutions will become >> available shortly after the standard emerges. >> >> > I would actually challenge the assumption that free software will emerge. > SRTP with SDES was released 8 years ago. The only open source library that > supported it until recently was libsrtp, which is a broken unusable peace > of code spaghetti (GPF crashes, two different replay DBs which do the same > thing, random number generator that stops working after generating few > thousand keys) that supports 2/3 of the protocol (no F8 support). Majority > of open source (and a large number of closed source) clients use this > library, but do not see any of those issues since very few real SRTP calls > are actually placed. DTLS-SRTP is two years old. Support for it was just > added to GNU TLS (unusable by many due to GNU license) and to OpenSSL > (using above mentioned libsrtp). There is little or no experience with > DTLS-SRTP interop. All of these things are not trivial. > > This is FUD. Google+ Hangouts uses libsrtp for all of its calls, and over the billions of minutes of call time to date, we haven't seen any crash bugs that could be blamed on libsrtp. And we track this stuff pretty closely. > My point is, if we require support for encryption implementation in the > standard and if 4 or 5 browser vendors will cooperate, we will get vast > majority of WebRTC clients security enabled. If everything surrounding > WebRTC will not use encryption, it is not a big loss since, in most cases, > it is not doing now anyway. > --20cf300515066c0fdd04bc6225b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 29, 2012 at 1:56 AM, Roman S= hpount <roman@tel= urix.com> wrote:

On Wed, Mar = 28, 2012 at 5:08 PM, Basil Mohamed Gohar <abu_hurayrah@hidaya= honline.org> wrote:
The scope of WebRTC is broad enough to consider that we need to think
about what's best going forward with regards to its implementation.
Security by default is one of the best practices in general, the support from the browser community and others that are behind it will definitely ensure that adoption is widespread enough to make it easy enough to
integrate into existing systems, as free software solutions will become
available shortly after the standard emerges.


I would actually cha= llenge the assumption that free software will emerge. SRTP with SDES was re= leased 8 years ago. The only open source library that supported it until re= cently was libsrtp, which is a broken unusable peace of code spaghetti (GPF= crashes, two different replay DBs which do the same thing, random number g= enerator that stops working after generating few thousand keys) that suppor= ts 2/3 of the protocol (no F8 support). Majority of open source (and a larg= e number of closed source) clients use this library, but do not see any of = those issues since very few real SRTP calls are actually placed. DTLS-SRTP = is two years old. Support for it was just added to GNU TLS (unusable by man= y due to GNU license) and to OpenSSL (using above mentioned libsrtp). There= is little or no experience with DTLS-SRTP interop. All of these things are= not trivial.


This is FUD. Google+ Hangouts uses lib= srtp for all of its calls, and over the billions of minutes of call time to= date, we haven't seen any crash bugs that could be blamed on libsrtp. = And we track this stuff pretty closely.

=C2=A0
My point is,= if we require support for encryption implementation in the standard and if= 4 or 5 browser vendors will cooperate, we will get vast majority of WebRTC= clients security enabled. If everything surrounding WebRTC will not use en= cryption, it is not a big loss since, in most cases, it is not doing now an= yway.
--20cf300515066c0fdd04bc6225b8-- From bernard_aboba@hotmail.com Thu Mar 29 07:02:51 2012 Return-Path: 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 08D0921F8B0D for ; Thu, 29 Mar 2012 07:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.457 X-Spam-Level: X-Spam-Status: No, score=-101.457 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 x8MT91Bkgi7I for ; Thu, 29 Mar 2012 07:02:48 -0700 (PDT) Received: from snt0-omc4-s3.snt0.hotmail.com (snt0-omc4-s3.snt0.hotmail.com [65.55.90.206]) by ietfa.amsl.com (Postfix) with ESMTP id 9738021F8AE2 for ; Thu, 29 Mar 2012 07:02:48 -0700 (PDT) Received: from SNT0-P7-EAS105 ([65.55.90.200]) by snt0-omc4-s3.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 07:02:48 -0700 X-Originating-IP: [130.129.20.41] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: Date: Thu, 29 Mar 2012 16:03:20 +0200 To: Martin Thomson MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 29 Mar 2012 14:02:48.0220 (UTC) FILETIME=[9F5785C0:01CD0DB4] Cc: Randell Jesup , "" Subject: Re: [rtcweb] IdP and universal trust X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:02:51 -0000 While they would be perceived as different with first party IdP, a signed as= sertion is still meaningless without some proof that the E.164 number is act= ually owned by the domain making the assertion.=20 On Mar 29, 2012, at 15:30, "Martin Thomson" wrote= : > On 29 March 2012 14:46, Bernard Aboba wrote: >> For example, +14255551212@example.com is equivalent to +14255551212@evil= twin.example.net >=20 > Actually, if third party assertions were prohibited, these would be > considered different, though I suspect that a user would have some > difficulty making the distinction. >=20 > But I take your point. From xiphmont@gmail.com Thu Mar 29 07:09:34 2012 Return-Path: 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 A5A5021E80A2 for ; Thu, 29 Mar 2012 07:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] 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 XztIDQXyzCpw for ; Thu, 29 Mar 2012 07:09:30 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6544D21E8092 for ; Thu, 29 Mar 2012 07:09:29 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1233821eaa.31 for ; Thu, 29 Mar 2012 07:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DpnRdbGawhzKz1Djx0ULrS85P+8/BtZCg9vHPRztjIc=; b=FmIeMsLCXLQKELf2yMzYx2m0pb84/6Qg66nlVcrkyq9a9ZQ0nHdHcwVz4ujjJiYZab NdNmem6h/cBvv3+OpnHUkph5RwblnPhRUHUScG9LdlDOMfv6k5+/PdYcTY3YKTMdMs1E 38ks51QxQFxEG9pk4m5RV90xZ1UjIGRyTqYrv3BhhK6E1hf0jP/WDETfICTAtym7jHnV WAFenejUyWEIZLzIP8OIFy18+GwyI78vkD7EJ34FIvb6TcYeK30Km8LXLHPGTHrA7Tev xtMjpmtjjdnGo8U+ug1IgJEKU0mnW81RpU/C3FvrO0MW/pr+bRUhg6JvbMHDCU9m1GD7 BVYw== MIME-Version: 1.0 Received: by 10.152.112.68 with SMTP id io4mr27273852lab.40.1333030168469; Thu, 29 Mar 2012 07:09:28 -0700 (PDT) Received: by 10.112.47.38 with HTTP; Thu, 29 Mar 2012 07:09:28 -0700 (PDT) Date: Thu, 29 Mar 2012 10:09:28 -0400 Message-ID: From: Monty Montgomery To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Proposal for Theora baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:09:34 -0000 If we're suggesting ten+ year-old codecs with low patent risk, let's choose an obviously higher performance example. Dare I say it... Theora? I think we've gotten off track. Twelve years ago, oblique threats were made against the nascent Vorbis by Thomson and the whole world decided it was a patent risk. It never was. Fool me once, shame on you. In the mid 2000s, people started picking on Theora the same way, and a few years ago Steve Jobs [and Larry Horn, et al] informed the world he was coming after us. Nothing came of it. Fool me twice, shame on me. Now we have the same substance-less muttering about VP8, suggesting that it's better to use leftover crumbs from 20 years ago. Fool me three times, I should begin to wonder if I have the requisite capacity to be engaging in technical endeavors. Monty Xiph.Org From andrew.hutton@siemens-enterprise.com Thu Mar 29 07:10:29 2012 Return-Path: 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 AE07D21E8092 for ; Thu, 29 Mar 2012 07:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] 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 SsHDIuvJw+ic for ; Thu, 29 Mar 2012 07:10:28 -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 8D99A21E80DF for ; Thu, 29 Mar 2012 07:10:28 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id A27E21EB84FD; Thu, 29 Mar 2012 16:10:26 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 29 Mar 2012 16:10:26 +0200 From: "Hutton, Andrew" To: Cullen Jennings , Magnus Westerlund Date: Thu, 29 Mar 2012 16:10:25 +0200 Thread-Topic: [rtcweb] Poll for dates for Interim Meeting before IETF 84 Thread-Index: Ac0Nqzyic8yF69y1S6OkmHjjKuLwDgACYaXA Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296C4CBB8@MCHP058A.global-ad.net> References: <4F740AB6.1080609@ericsson.com> <59C1272C-DA1D-4589-8702-AA26F7D5F676@iii.ca> In-Reply-To: <59C1272C-DA1D-4589-8702-AA26F7D5F676@iii.ca> 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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Poll for dates for Interim Meeting before IETF 84 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:10:29 -0000 +1=20 The location has a big relationship to the date and even day of the week I = would choose. Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: 29 March 2012 14:54 > To: Magnus Westerlund > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Poll for dates for Interim Meeting before IETF 84 >=20 >=20 > Could we have the poll choices to indicate the location of the meeting? >=20 > The problem is, and I suspect that this is a problem for most people, > depending on the location, my travel time dramatically changes the > number of days I need to have clear on my calendar. >=20 >=20 >=20 > On Mar 29, 2012, at 9:09 , Magnus Westerlund wrote: >=20 > > WG, > > > > We have started a doodle poll for an Interim meeting before IETF 84 > in > > Vancouver. Locations considered so far are Stockholm, Boston Area or > > Silicon Valley. The meeting is planned to be a 2 day meeting. Please > > indicate which of the suggest times that works for you. > > > > > > http://doodle.com/nm3pp69znr3286cy > > > > > > Cheers > > > > Magnus Westerlund > > WG chair > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stewe@stewe.org Thu Mar 29 07:20:18 2012 Return-Path: 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 5332521E8168 for ; Thu, 29 Mar 2012 07:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Emx5PK0SOWXz for ; Thu, 29 Mar 2012 07:20:16 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 612E321E8167 for ; Thu, 29 Mar 2012 07:20:16 -0700 (PDT) Received: from mail24-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 14:20:15 +0000 Received: from mail24-ch1 (localhost [127.0.0.1]) by mail24-ch1-R.bigfish.com (Postfix) with ESMTP id 95C722406C3; Thu, 29 Mar 2012 14:20:15 +0000 (UTC) X-SpamScore: -24 X-BigFish: PS-24(z11d7lzbb2dI9371I1432N98dKzz1202h1082kzz1033IL8275dhz2fh2a8h668h839h946h) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT005.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail24-ch1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT005.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail24-ch1 (localhost.localdomain [127.0.0.1]) by mail24-ch1 (MessageSwitch) id 1333030813425384_20914; Thu, 29 Mar 2012 14:20:13 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail24-ch1.bigfish.com (Postfix) with ESMTP id 60E483A0045; Thu, 29 Mar 2012 14:20:13 +0000 (UTC) Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 14:20:11 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.179]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0135.002; Thu, 29 Mar 2012 14:20:11 +0000 From: Stephan Wenger To: Basil Mohamed Gohar , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Proposal for H.263 baseline codec Thread-Index: AQHNDaWq9kefa/omnUePrLHPwXaly5aBQduAgAAyeIA= Date: Thu, 29 Mar 2012 14:20:10 +0000 Message-ID: In-Reply-To: <4F746163.5090506@hidayahonline.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3989F0D9AFD63944A2894DB7A8657E17@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [rtcweb] Proposal for H.263 baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:20:18 -0000 Please see inline. Stephan On 3.29.2012 15:19 , "Basil Mohamed Gohar" wrote: >On 03/29/2012 08:15 AM, Dean Willis wrote: >>[=8A] >> >> So I propose we set H.263 as the baseline ( I expect a bit of >> profiling may be necessary to further qualify the baseline) and run >> with that for now. If the situation changes, we can always replace it >> before final publication. >> -- >> Dean >Claiming that VP8 is riskier than a known IPR-enforced format is a >specious claim considering its already widely implemented usage across >the web on numerous sites and in hardware. Additionally, a patent pool >was called for over a year ago, and nothing has been made public about >this. These things take time. The formation of the MPEG-2 patent pool took 4+ years, the formation of the H.264 pool almost as long. VP8 may be a particularly hard-to-deal-with technology, because it is not a formal standard, which may provide rightholders options to enforce their patents in ways not available if they would have been involved in a standards setting process (see below), which can make the negotiation of the pool more complex (can't re-use previous pool agreements as templates, may have to check for antitrust compliance, and so on). The most commonly cited timeline for a widely in use technology to be "save" from a patent viewpoint, based on equitable defenses such as laches (in the US) is six years. In some countries of significant size, this time is longer, and in others, equitable defenses do not exist. (Very briefly, and perhaps incorrectly put, those equitable defenses allow a defendant to argue successfully that a patent cannot be enforced as the right holder knew that the patent claim was likely being infringed, and did not enforce the patent.). >No technology can be completely free from the specter of patent trolls >and spurious software patents, so these arguments that VP8 is not >suitable based on this could be applied to anyone. The fact of the >matter is that the only known patents on VP8 are owned now by Google and >they have been licensed in a way compatible with all appropriate uses of >the technology, including WebRTC. The second part of your sentence may or may not be true, depending on your relationship with google, your willingness to use the webm implementation in unchanged form, and other factors. Please see the webm license conditions, which AFAIK can be found here: http://www.webmproject.org/license/additional/ In addition, as I pointed out in the meeting, the use of a video codec created by a body such as MPEG or ITU-T SG16 has the advantage of that the patents of all participating players are available at least under Reasonable and Non Discriminatory (RAND) terms. This may sound like a Bad Thing if you operate under a business model that prevents you to pay anything for patent licenses, but it is surely a Good Thing if you are willing to dish out a moderate amount of money for a license. RAND recently has gotten teeth, not so much in terms of the monetary compensation aspect, but in terms of difficulty (if not unavailability) to obtain injunctive relive, among others. H.26x and the MPEG standards benefit from RAND commitments, VP8, AFAIK, does not. Stephan > >While I appreciate the sentiment of this suggestion, I am of the opinion >that choosing a known-restricted format over VP8 will be >counter-productive to the adoption of the WebRTC standard and will, in >fact, restrict possible implementations. >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From basilgohar@librevideo.org Thu Mar 29 07:17:48 2012 Return-Path: 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 CFC1121E818B for ; Thu, 29 Mar 2012 07:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 RJPobLIFJIur for ; Thu, 29 Mar 2012 07:17:44 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB6C21E816C for ; Thu, 29 Mar 2012 07:17:44 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id DC291652317 for ; Thu, 29 Mar 2012 10:17:43 -0400 (EDT) Message-ID: <4F746F04.7030800@librevideo.org> Date: Thu, 29 Mar 2012 10:17:40 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposal for Theora baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:20:21 -0000 On 03/29/2012 10:09 AM, Monty Montgomery wrote: > If we're suggesting ten+ year-old codecs with low patent risk, let's > choose an obviously higher performance example. Dare I say it... > Theora? > > I think we've gotten off track. > > Twelve years ago, oblique threats were made against the nascent Vorbis > by Thomson and the whole world decided it was a patent risk. It never > was. Fool me once, shame on you. > > In the mid 2000s, people started picking on Theora the same way, and a > few years ago Steve Jobs [and Larry Horn, et al] informed the world he > was coming after us. Nothing came of it. Fool me twice, shame on me. > > Now we have the same substance-less muttering about VP8, suggesting > that it's better to use leftover crumbs from 20 years ago. > > Fool me three times, I should begin to wonder if I have the requisite > capacity to be engaging in technical endeavors. > > Monty > Xiph.Org +1 VP8 is the only option that makes any sense for WebRTC going forward. It is high performant, it has optimizations for realtime usage (in the reference implementation), it is already implemented in a wide variety of software (Skype, browsers [Mozilla Firefox, Google Chrome, Opera]), and it is also implemented in hardware (as well as supported by the Android OS). No one can say something will never be the target of a lawsuit. But there *are* legal protections against organizations that assert patents against a standard after its adoption when they had the ability to make the standards body aware of it ahead of time (estoppel). From roman@telurix.com Thu Mar 29 07:20:49 2012 Return-Path: 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 AEFF521E8194 for ; Thu, 29 Mar 2012 07:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 5qqa-X4D+H90 for ; Thu, 29 Mar 2012 07:20:47 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A68DF21E8187 for ; Thu, 29 Mar 2012 07:20:47 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1622163yhk.31 for ; Thu, 29 Mar 2012 07:20:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=virvy2+AAi3j0jlyIi7xK4A813IT46aqdVPx+qsu/Vo=; b=lJbP94KYL+MxiTiDFMHmrjszGcq0oqPFZ7I4OdTnIZrlsts2i/okryWSFHkX+VqGTH TIIcDZgopR2sADX2XTljU8zzRpPF6G6PjSPB2i9MAH666IMpr3vU3bqGTSM5g4PhDxly yMwXTiOoFSJsr9iMmuXcSwNYv/dTbQ7wtuePX98FFmqkL9VpTT6lRe6tGBu4AqLYqxZv UZCc9GmJDAyS4TYtsMgZN7IRxSMrLxat8W9AjE6EGYYjttdu94EI/8H8cwZ5T/sMbaCG +QLyLl5HJ4AG7q8kOc+3kko6crCSVYLsT4ZUnCtES/Z027N9Q43TiJCjJjMLPgPXqv/x Bo4w== Received: by 10.236.200.197 with SMTP id z45mr34152762yhn.99.1333030830707; Thu, 29 Mar 2012 07:20:30 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id 2sm8077854ane.12.2012.03.29.07.20.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 07:20:30 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1622143yhk.31 for ; Thu, 29 Mar 2012 07:20:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.230.99 with SMTP id sx3mr388371pbc.55.1333030829042; Thu, 29 Mar 2012 07:20:29 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 29 Mar 2012 07:20:28 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> Date: Thu, 29 Mar 2012 10:20:28 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b2edf030a2c5704bc626dec X-Gm-Message-State: ALoCoQmEYyzhSuinN8wUVLucXttv5KZRY5U0mH8dKf1s55iHtCc8rV7uDtbhu5qYHAZ4XOLbe9zD Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:20:49 -0000 --047d7b2edf030a2c5704bc626dec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2012 at 8:14 AM, I=F1aki Baz Castillo wrote= : > Roman, you still don't want to see my simple example. Could you please > reply to the following two questions rather than avoiding them?: > > 1) Why is better to use plain RTP in an open WiFi network (airport) > rather than using SDES-SRTP? > I did not say that use of plain RTP is better in an open WiFi. what am saying that if I am communicating with a large number of applications it is no worse. For me, anything that can cause protocol not to work or to be used for some sort of an attack goes under MUST. Anything that is nice to have should be under SHOULD. From my point of view security is a SHOULD. > 2) Why is plain RTP better than SDES-SRTP in any other case? > In case of an enterprise network, their security concerns are not about user privacy (it is not end user equipment in a first place) but adherence to corporate standards or ability to monitor. In such cases SRTP is a liability, not an asset. In Flash, in HTTP, in email, encryption is optional. If you have anything where encryption is mandatory while communicating with an external party, it is not acceptable in a lot of enterprise or government environments. My goal is to have WebRTC functionality available in as many places as possible, even if it means giving up encryption in some cases. Developing new applications is harder. If you are building a speech recognition engine, you often need to add media support. Adding encrypted media support is much harder. I want people to build new things with the minimal effort, even just to educate themselves or to try new things. This is what makes progress possible. The more things we pile up in front of this, the harder it would be for people to do new things. > > No encryption often means better security. > > Sorry, I don't agree. Encryption is not enough, of course, but it's > better than nothing (and again: the open WiFi network in the airport). > > > Bot nets use encryption to > > communicate, it does not mean they enable user security. > > 1) User identity authentication/validation and confidentiality > (encryption). > > 2) Just confidentiality (encryption). > > 3) Nothing. > > > 1 is better than 2 and 2 is better than 3. > > > > > In a lot of cases > > ability for the user to check what exactly they are communicating and t= o > > whom is security. As a security conscious person I do not want encrypte= d > > communication from my computer or my network unless I know exactly who > it is > > going to. If I do not have to I would prefer my communications to be > > unencrypted. > > Sure, but you are advanced user and I hope you are not talking in > behalf of the 500 millions of Facebook users in the world. > So you will be able to enter into your browser about://config and set > a null crypto key for SRTP (so you get plain RTP and can debug it or > whatever). This is confirmed to be the expectation of two browser > vendors. > > And you are missing a point completely. If I am operating a corporate network with 50,000 computers, do I need to go into about://config for all of them? If I am put into this situation, I would just disable WebRTC completely and call it security. This is exactly what I am trying to avoid. > > >> RFC 3711 was created in 2004, 8 years ago! > >> > >> Which "new" application you mean if it's not capable of implementing a > >> simple specification from 2004? how "new" is it? is it really new? or > >> is it a "SIP voicemail server" made in 2002? > >> > > Well let me list them: FreeSwitch, Asterisk, linphone, etc. All of thos= e > use > > libsrtp. For all of them SRTP is broken. Not a single one of them > bothered > > to check or only recently detected problems > > (https://issues.asterisk.org/jira/browse/ASTERISK-16665). > > I expect that, once SRTP becomes widely extended (thanks to WebRTC), > developers will really want to fix their SRTP support, including > libsrtp. But we cannot make a *new spec less secure than it can be > just due a to a bug in a opensource library. > The issue is most of the developers would just look at this as a hurdle to interop with WebRTC, instead of the enabling the security. If security implementation is not taken seriously, you often end up with something that can communicate but not really secure. For instance you can use a bad algorithm to generate encryption keys and end up with keys that are easily predictable. Result -- encrypted but unsecured traffic. Encryption should be something that application developers can turn on or off, but unless they want it, forcing support for it is a fulls quest. > > >> Sorry but I still see *no* argument at all in favour of allowing plain > >> RTP in WebRTC. And AFAIK there is already consensus about it: plain > >> RTP is not allowed. > >> > > I do not see an argument why RTP should not be allowed. I think you are > > arguing we should require a feature (SRTP) for the sake of requiring a > > feature. > > I still don't understand why everyone in an airport should be able to > intercept my audio/video communication with a simple RTP sniffer. > There are enough cases where I or other users do not care if this happens, so I think that encryption should be a SHOULD. _____________ Roman Shpount --047d7b2edf030a2c5704bc626dec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2012 at 8:14 AM, I=F1aki Baz Castillo <= ;ibc@aliax.net> wrote:
Roman, you still don't want to see my simple example. Could you please<= br> reply to the following two questions rather than avoiding them?:

1) Why is better to use plain RTP in an open WiFi network (airport)
rather than using SDES-SRTP?

I did not say that us= e of plain RTP is better in an open WiFi. what=A0 am saying that if I am co= mmunicating with a large number of applications it is no worse. For me, any= thing that can cause protocol not to work or to be used for some sort of an= attack goes under MUST. Anything that is nice to have should be under SHOU= LD. From my point of view security is a SHOULD.
=A0
2) Why is plain RTP better than SDES-SRTP in any other case?

In case of an enterprise network, their security concerns are no= t about user privacy (it is not end user equipment in a first place) but ad= herence to corporate standards or ability to monitor. In such cases SRTP is= a liability, not an asset. In Flash, in HTTP, in email, encryption is opti= onal. If you have anything where encryption is mandatory while communicatin= g with an external party, it is not acceptable in a lot of enterprise or go= vernment environments. My goal is to have WebRTC functionality available in= as many places as possible, even if it means giving up encryption in some = cases.

Developing new applications is harder. If you are building a speech rec= ognition engine, you often need to add media support. Adding encrypted medi= a support is much harder. I want people to build new things with the minima= l effort, even just to educate themselves or to try new things. This is wha= t makes progress possible. The more things we pile up in front of this, the= harder it would be for people to do new things.


> No encryption often means better security.

Sorry, I don't agree. Encryption is not enough, of course, but it= 's
better than nothing (and again: the open WiFi network in the airport).

> Bot nets use encryption to
> communicate, it does not mean they enable user security.

1) User identity authentication/validation and confidentiality (encry= ption).

2) Just confidentiality (encryption).

3) Nothing.


1 is better than 2 and 2 is better than 3.



> In a lot of cases
> ability for the user to check what exactly they are communicating and = to
> whom is security. As a security conscious person I do not want encrypt= ed
> communication from my computer or my network unless I know exactly who= it is
> going to. If I do not have to I would prefer my communications to be > unencrypted.

Sure, but you are advanced user and I hope you are not talking in
behalf of the 500 millions of Facebook users in the world.
So you will be able to enter into your browser about://config and set
a null crypto key for SRTP (so you get plain RTP and can debug it or
whatever). This is confirmed to be the expectation of two browser
vendors.

And you are missing a point c= ompletely. If I am operating a corporate network with 50,000 computers, do = I need to go into about://config for all of them? If I am put into this sit= uation, I would just disable WebRTC completely and call it security. This i= s exactly what I am trying to avoid.
=A0

>> RFC 3711 was created in 2004, 8 years ago!
>>
>> Which "new" application you mean if it's not capable= of implementing a
>> simple specification from 2004? how "new" is it? is it r= eally new? or
>> is it a "SIP voicemail server" made in 2002?
>>
> Well let me list them: FreeSwitch, Asterisk, linphone, etc. All of tho= se use
> libsrtp. For all of them SRTP is broken. Not a single one of them both= ered
> to check or only recently detected problems
> (https://issues.asterisk.org/jira/browse/ASTERISK-16665)= .

I expect that, once SRTP becomes widely extended (thanks to WebRTC),<= br> developers will really want to fix their SRTP support, including
libsrtp. But we cannot make a *new spec less secure than it can be
just due a to a bug in a opensource library.

The i= ssue is most of the developers would just look at this as a hurdle to inter= op with WebRTC, instead of the enabling the security. If security implement= ation is not taken seriously, you often end up with something that can comm= unicate but not really secure. For instance you can use a bad algorithm to = generate encryption keys and end up with keys that are easily predictable. = Result -- encrypted but unsecured traffic. Encryption should be something t= hat application developers can turn on or off, but unless they want it, for= cing support for it is a fulls quest.
=A0

>> Sorry but I still see *no* argument at all in favour of allowing p= lain
>> RTP in WebRTC. And AFAIK there is already consensus about it: plai= n
>> RTP is not allowed.
>>
> I do not see an argument why RTP should not be allowed. I think you ar= e
> arguing we should require a feature (SRTP) for the sake of requiring a=
> feature.

I still don't understand why everyone in an airport should be abl= e to
intercept my audio/video communication with a simple RTP sniffer.

There are enough cases where I or other users do not care if thi= s happens, so I think that encryption should be a SHOULD.
_____________<= br>
Roman Shpount


--047d7b2edf030a2c5704bc626dec-- From basilgohar@librevideo.org Thu Mar 29 07:25:01 2012 Return-Path: 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 0AE1B21E81A2 for ; Thu, 29 Mar 2012 07:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] 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 IhqQAcNvVtjZ for ; Thu, 29 Mar 2012 07:25:00 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2BE21E819F for ; Thu, 29 Mar 2012 07:25:00 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 38928652662 for ; Thu, 29 Mar 2012 10:24:59 -0400 (EDT) Message-ID: <4F7470B7.9090202@librevideo.org> Date: Thu, 29 Mar 2012 10:24:55 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposal for H.263 baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:25:01 -0000 On 03/29/2012 10:20 AM, Stephan Wenger wrote: > The second part of your sentence may or may not be true, depending on your > relationship with google, your willingness to use the webm implementation > in unchanged form, and other factors. Please see the webm license > conditions, which AFAIK can be found here: > http://www.webmproject.org/license/additional/ Correct. I think you are referring to this part, explicitly: > If you or your agent or exclusive licensee institute or order or agree > to the institution of patent litigation against any entity (including > a cross-claim or counterclaim in a lawsuit) alleging that this > implementation of VP8 or any code incorporated within this > implementation of VP8 constitutes direct or contributory patent > infringement, or inducement of patent infringement, then any patent > rights granted to you under this License for this implementation of > VP8 shall terminate as of the date such litigation is filed. Perhaps I assumed that that is a very reasonable part of the license. That is, if you are suing someone alleging a patent infringement within VP8, you are no longer granted the license to use VP8's patented technologies that Google owns. From roman@telurix.com Thu Mar 29 07:31:17 2012 Return-Path: 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 DD83721E81B9 for ; Thu, 29 Mar 2012 07:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 b-zug42Gb5yR for ; Thu, 29 Mar 2012 07:31:16 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B34421F869D for ; Thu, 29 Mar 2012 07:31:16 -0700 (PDT) Received: by yenm5 with SMTP id m5so1646655yen.31 for ; Thu, 29 Mar 2012 07:31:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=dnQFRPqM4R1DhrpXC5RdqPiEj2GEKcW6DW3Vkco/m4Y=; b=bOo9HxvGxteEUWy2bOZafjbWxv6V8XwgPRvSEs2wDMlg3iGwHV+c6093G3ryQTAQiv paLtQ6a1qmJj1vyiG6k1bM9RohERy7TdUrEh6h96x/MaVDD7QABfGSGrOULC+8GrlNw3 tE9sNialTVuS6Mwzb6cV46TMJenSc6K+JynHt9nFDj95E3jYX6QPHDZdLb5obhIdr3Vq plA/7V7DJBUjXcTGZifbEgdQEMSXSrMNOL4PYYW9exC6vyiGHwqeKha7l9wTJV2lsJa+ S+OpliEq2RGXGtXlNuXuLPgB/wGg2Sjw5aQ9qyIu3erXC0amhMci8rpXOmeKVGBUmPq2 lC4Q== Received: by 10.236.161.72 with SMTP id v48mr26374676yhk.112.1333031475991; Thu, 29 Mar 2012 07:31:15 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id f40sm8101883ani.16.2012.03.29.07.31.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 07:31:14 -0700 (PDT) Received: by yenm5 with SMTP id m5so1646607yen.31 for ; Thu, 29 Mar 2012 07:31:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.240.6 with SMTP id vw6mr570240pbc.76.1333031473312; Thu, 29 Mar 2012 07:31:13 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 29 Mar 2012 07:31:13 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> <4F737DB3.5020804@hidayahonline.org> Date: Thu, 29 Mar 2012 10:31:13 -0400 Message-ID: From: Roman Shpount To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b3395a170f41304bc6293b0 X-Gm-Message-State: ALoCoQnO2l025ptds4dXRrmLQ/3xeItqGUQcH4HbMZRkCdGJF9rgOQeKi2UIVJXGxnAsmWT3nokc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:31:18 -0000 --047d7b3395a170f41304bc6293b0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 29, 2012 at 10:00 AM, Justin Uberti wrote: > This is FUD. Google+ Hangouts uses libsrtp for all of its calls, and over > the billions of minutes of call time to date, we haven't seen any crash > bugs that could be blamed on libsrtp. And we track this stuff pretty > closely. > > > This is not a FUD. Even with 100s of millions of secured minutes we are pushing we see new libsrtp related problems on a weekly basis. I gave you a reference to the Asterisk bug. This bug is addressed in sourceforge, but present in the download library (1.4.4) that is included in a lot of the products. This bug guarantees a crash in case RTCP and even small packet loss are present. You can try to run crypto_get_random in a loop until it generates an error. Simple and easy to reproduce bug. There is probably more, but it is outside of the scope of this list. If you want to do your users a favor -- swap this lib out from your code. You probably have a much better crypto utilities (random, AES) in other code you use, such as OpenSSL. The rest is trivial to re-implement and it will make the result product faster and more secure. _____________ Roman Shpount --047d7b3395a170f41304bc6293b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 29, 2012 at 10:00 = AM, Justin Uberti <juberti@google.com> wrote:
This is FUD. Google+ Hangouts uses libsrtp for all of its calls, and over t= he billions of minutes of call time to date, we haven't seen any crash = bugs that could be blamed on libsrtp. And we track this stuff pretty closel= y.


This is not a FUD. Even wi= th 100s of millions of secured minutes we are pushing we see new libsrtp re= lated problems on a weekly basis. I gave you a reference to the Asterisk bu= g. This bug is addressed in sourceforge, but present in the download librar= y (1.4.4) that is included in a lot of the products. This bug guarantees a = crash in case RTCP and even small packet loss are present.=A0 You can try t= o run crypto_get_random in a loop until it generates an error. Simple and e= asy to reproduce bug. There is probably more, but it is outside of the scop= e of this list. If you want to do your users a favor -- swap this lib out f= rom your code. You probably have a much better crypto utilities (random, AE= S) in other code you use, such as OpenSSL. The rest is trivial to re-implem= ent and it will make the result product faster and more secure.
_____________
Roman Shpount

--047d7b3395a170f41304bc6293b0-- From stewe@stewe.org Thu Mar 29 07:33:52 2012 Return-Path: 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 A434821E8084 for ; Thu, 29 Mar 2012 07:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 a9RHVbC555Me for ; Thu, 29 Mar 2012 07:33:48 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 640C821E803C for ; Thu, 29 Mar 2012 07:33:48 -0700 (PDT) Received: from mail37-db3-R.bigfish.com (10.3.81.240) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 14:33:47 +0000 Received: from mail37-db3 (localhost [127.0.0.1]) by mail37-db3-R.bigfish.com (Postfix) with ESMTP id 9426C180983; Thu, 29 Mar 2012 14:33:47 +0000 (UTC) X-SpamScore: -22 X-BigFish: PS-22(z11d7lz1432N98dKzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT003.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail37-db3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT003.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail37-db3 (localhost.localdomain [127.0.0.1]) by mail37-db3 (MessageSwitch) id 1333031625459619_14087; Thu, 29 Mar 2012 14:33:45 +0000 (UTC) Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.250]) by mail37-db3.bigfish.com (Postfix) with ESMTP id 6D9FB4A008F; Thu, 29 Mar 2012 14:33:45 +0000 (UTC) Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 14:33:42 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.179]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0135.002; Thu, 29 Mar 2012 14:33:31 +0000 From: Stephan Wenger To: Monty Montgomery , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Proposal for Theora baseline codec Thread-Index: AQHNDbWVvqwweyAi5ECaKn6ZQvaLwpaBd+qA Date: Thu, 29 Mar 2012 14:33:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <70AE0547BB7E1448A6073D70E448C95D@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [rtcweb] Proposal for Theora baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:33:52 -0000 Hi Monty, Couldn't it be that no one went after Vorbis and Theora because the rightholders had no real incentive to do so? For example, because the products implementing Vorbis, in their vast majority, also included MP3 and/or AAC, and the rightholders would have to deal with patent exhaustion arguments and whatnot after having gotten their money; and because theora deployment never reached a critical mass because it was a) not good enough technically, and b) felt to be too risky? I would turn your argument around: the (comparatively speaking) lack of commercial success of vorbis and theora, and the success of royalty bearing standard codecs, suggest to me only that no one was fooled, except perhaps the enthusiastic followers of those folks who keep pushing out one "free" codec after another... Stephan =20 On 3.29.2012 16:09 , "Monty Montgomery" wrote: >If we're suggesting ten+ year-old codecs with low patent risk, let's >choose an obviously higher performance example. Dare I say it... >Theora? > >I think we've gotten off track. > >Twelve years ago, oblique threats were made against the nascent Vorbis >by Thomson and the whole world decided it was a patent risk. It never >was. Fool me once, shame on you. > >In the mid 2000s, people started picking on Theora the same way, and a >few years ago Steve Jobs [and Larry Horn, et al] informed the world he >was coming after us. Nothing came of it. Fool me twice, shame on me. > >Now we have the same substance-less muttering about VP8, suggesting >that it's better to use leftover crumbs from 20 years ago. > >Fool me three times, I should begin to wonder if I have the requisite >capacity to be engaging in technical endeavors. > >Monty >Xiph.Org >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From keith.drage@alcatel-lucent.com Thu Mar 29 07:35:00 2012 Return-Path: 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 CF2BA21E8162 for ; Thu, 29 Mar 2012 07:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.675 X-Spam-Level: X-Spam-Status: No, score=-109.675 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 IwyUVx6bNCDX for ; Thu, 29 Mar 2012 07:34:57 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id B4C8E21E817F for ; Thu, 29 Mar 2012 07:34:56 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2TEYqMe023071 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Mar 2012 16:34:53 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 29 Mar 2012 16:34:52 +0200 From: "DRAGE, Keith (Keith)" To: Basil Mohamed Gohar , "rtcweb@ietf.org" Date: Thu, 29 Mar 2012 16:34:49 +0200 Thread-Topic: [rtcweb] Proposal for Theora baseline codec Thread-Index: Ac0NtyZR7Ghz5l/BQUGUPxMelIXHXQAAUrmg Message-ID: References: <4F746F04.7030800@librevideo.org> In-Reply-To: <4F746F04.7030800@librevideo.org> 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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [rtcweb] Proposal for Theora baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:35:00 -0000 > VP8 is the only option that makes any sense for WebRTC going forward. > It is high performant, it has optimizations for realtime usage (in the > reference implementation), it is already implemented in a wide variety > of software (Skype, browsers [Mozilla Firefox, Google Chrome, Opera]), > and it is also implemented in hardware (as well as supported by the > Android OS). > So are you saying that Adam's presentation today was incorrect? Quoting: "H.264: More deployed hardware acceleration Well known, clearly identified patent pool; royalties due for some uses Quality, compression ratio, and complexity approximately equal to VP8 VP8: Can be hardware accelerated, but current deployment is very low No specific patents asserted1, no one collecting royalties Quality, compression ratio, and complexity approximately equal to H.264" If so I think you need to be a little more technically specific as to why y= ou see one better than the other. Regards Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Basil Mohamed Gohar > Sent: 29 March 2012 15:18 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Proposal for Theora baseline codec >=20 > On 03/29/2012 10:09 AM, Monty Montgomery wrote: > > If we're suggesting ten+ year-old codecs with low patent risk, let's > > choose an obviously higher performance example. Dare I say it... > > Theora? > > > > I think we've gotten off track. > > > > Twelve years ago, oblique threats were made against the nascent Vorbis > > by Thomson and the whole world decided it was a patent risk. It never > > was. Fool me once, shame on you. > > > > In the mid 2000s, people started picking on Theora the same way, and a > > few years ago Steve Jobs [and Larry Horn, et al] informed the world he > > was coming after us. Nothing came of it. Fool me twice, shame on me. > > > > Now we have the same substance-less muttering about VP8, suggesting > > that it's better to use leftover crumbs from 20 years ago. > > > > Fool me three times, I should begin to wonder if I have the requisite > > capacity to be engaging in technical endeavors. > > > > Monty > > Xiph.Org > +1 >=20 > VP8 is the only option that makes any sense for WebRTC going forward. > It is high performant, it has optimizations for realtime usage (in the > reference implementation), it is already implemented in a wide variety > of software (Skype, browsers [Mozilla Firefox, Google Chrome, Opera]), > and it is also implemented in hardware (as well as supported by the > Android OS). >=20 > No one can say something will never be the target of a lawsuit. But > there *are* legal protections against organizations that assert patents > against a standard after its adoption when they had the ability to make > the standards body aware of it ahead of time (estoppel). > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From basilgohar@librevideo.org Thu Mar 29 07:39:16 2012 Return-Path: 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 E271321F88BD for ; Thu, 29 Mar 2012 07:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] 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 J-GRGru6HzVl for ; Thu, 29 Mar 2012 07:39:16 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5F021F8858 for ; Thu, 29 Mar 2012 07:39:15 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 7AE37652669 for ; Thu, 29 Mar 2012 10:39:12 -0400 (EDT) Message-ID: <4F74740E.6050004@librevideo.org> Date: Thu, 29 Mar 2012 10:39:10 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <4F746F04.7030800@librevideo.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposal for Theora baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:39:17 -0000 On 03/29/2012 10:34 AM, DRAGE, Keith (Keith) wrote: >> VP8 is the only option that makes any sense for WebRTC going forward. >> It is high performant, it has optimizations for realtime usage (in the >> reference implementation), it is already implemented in a wide variety >> of software (Skype, browsers [Mozilla Firefox, Google Chrome, Opera]), >> and it is also implemented in hardware (as well as supported by the >> Android OS). >> > So are you saying that Adam's presentation today was incorrect? > > Quoting: > > "H.264: > > More deployed hardware acceleration > Well known, clearly identified patent pool; royalties due for some uses > Quality, compression ratio, and complexity approximately equal to VP8 > > VP8: > > Can be hardware accelerated, but current deployment is very low > No specific patents asserted1, no one collecting royalties > Quality, compression ratio, and complexity approximately equal to > H.264" > > If so I think you need to be a little more technically specific as to why you see one better than the other. > > Regards > > Keith I'm not saying that. What I am saying, and what I left out of that short list above, is that VP8's royalty-free basis and patent grant from the only known owners of patents on the technology, *in addition* to its technical suitability, make it the only choice that makes any sense. -- Libre Video http://librevideo.org From xiphmont@gmail.com Thu Mar 29 07:44:00 2012 Return-Path: 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 87C7B21F8946 for ; Thu, 29 Mar 2012 07:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hLV95qdTRzcA for ; Thu, 29 Mar 2012 07:43:56 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E294021F8944 for ; Thu, 29 Mar 2012 07:43:55 -0700 (PDT) Received: by lagj5 with SMTP id j5so3050932lag.31 for ; Thu, 29 Mar 2012 07:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Oc1FGZrFAxbDFyAaLy8DLCdxSymIBT6EhpeoRlgcunI=; b=tzIHJHVuYnuVM1sM9FcpflggYMX4y1wxXkT1rEMTj38jasEQr2c0jca7ISR1lCIsHL 6BU9ed4Iceqv2Oora4hWJ00O0OwO2B9rIAOwVK4zWkkFqj9nxaWBddRjSYKhUYNC7HiV WSB6q2M9BmdoCpXe52/w6MAM6y0eZIUOPENQWVXFLtUFkaGaDASmbLBb6Spr8ahYqfjp VBuuh4btX5VNB5yheuM25cgchY8uweGCzXTIyq464DWMaX3vDGJO7ucmhxvQierEKPo3 148WZech5Zvq6O7lgGHHWOg1K7LFaZm77ecoZDi5Bo9Bgu/ENsOJPTkmwOjfdN8RqLg7 An8w== MIME-Version: 1.0 Received: by 10.152.133.68 with SMTP id pa4mr27593585lab.12.1333032234240; Thu, 29 Mar 2012 07:43:54 -0700 (PDT) Received: by 10.112.47.38 with HTTP; Thu, 29 Mar 2012 07:43:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Mar 2012 10:43:54 -0400 Message-ID: From: Monty Montgomery To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for Theora baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:44:00 -0000 > Hi Monty, > Couldn't it be that no one went after Vorbis and Theora because the > rightholders had no real incentive to do so? =A0For example, because the [...] The opposing argument neatly boils down to 'no one ever got fired for buying from IBM'. That specific sentiment seems quaint now, but the point is still relevant. Monty Xiph.Org From basilgohar@librevideo.org Thu Mar 29 07:47:26 2012 Return-Path: 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 A34F321F8433 for ; Thu, 29 Mar 2012 07:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] 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 0s3nXJiyjSdZ for ; Thu, 29 Mar 2012 07:47:25 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id A902121F842E for ; Thu, 29 Mar 2012 07:47:08 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 3267765266F for ; Thu, 29 Mar 2012 10:47:08 -0400 (EDT) Message-ID: <4F7475E9.104@librevideo.org> Date: Thu, 29 Mar 2012 10:47:05 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposal for Theora baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:47:26 -0000 On 03/29/2012 10:33 AM, Stephan Wenger wrote: > Hi Monty, > Couldn't it be that no one went after Vorbis and Theora because the > rightholders had no real incentive to do so? For example, because the > products implementing Vorbis, in their vast majority, also included MP3 > and/or AAC, and the rightholders would have to deal with patent exhaustion > arguments and whatnot after having gotten their money; and because theora > deployment never reached a critical mass because it was a) not good enough > technically, and b) felt to be too risky? > I would turn your argument around: the (comparatively speaking) lack of > commercial success of vorbis and theora, and the success of royalty > bearing standard codecs, suggest to me only that no one was fooled, except > perhaps the enthusiastic followers of those folks who keep pushing out one > "free" codec after another... > Stephan > Stephan, Monty already pointed out that sabre-rattling already happened. Had there been any meat to the threats, then it would have been ridiculous not to have pursued them. Mozilla implements both Theora and Vorbis in browser, and do not implement MPEG-related codecs, and they're a lucrative target (they're getting around $1 billion from Google in the coming few years). They *do* have a commercial entity that could be the target, as well. The real threat was that these formats posed a risk to the other formats monopolistic adoption, and the FUD that was spread every time these formats were presented in a standard or appeared poised to be adopted more widely, the sabre-rattling began again, and no real threats materialized. It's arguing by saying, "You never can be sure...". -- Libre Video http://librevideo.org From stewe@stewe.org Thu Mar 29 07:53:18 2012 Return-Path: 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 5B06221E80AC for ; Thu, 29 Mar 2012 07:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 pbWfD7bZd+Oy for ; Thu, 29 Mar 2012 07:53:17 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCDC21E80C5 for ; Thu, 29 Mar 2012 07:53:10 -0700 (PDT) Received: from mail59-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 14:53:09 +0000 Received: from mail59-am1 (localhost [127.0.0.1]) by mail59-am1-R.bigfish.com (Postfix) with ESMTP id 5C683240521; Thu, 29 Mar 2012 14:53:09 +0000 (UTC) X-SpamScore: -24 X-BigFish: PS-24(z11d7lzbb2dI9371I41c5N98dKzz1202h1082kzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT003.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail59-am1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT003.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail59-am1 (localhost.localdomain [127.0.0.1]) by mail59-am1 (MessageSwitch) id 1333032786996525_15970; Thu, 29 Mar 2012 14:53:06 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.235]) by mail59-am1.bigfish.com (Postfix) with ESMTP id E5BE6A0059; Thu, 29 Mar 2012 14:53:06 +0000 (UTC) Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 14:53:05 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.179]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0135.002; Thu, 29 Mar 2012 14:53:04 +0000 From: Stephan Wenger To: Basil Mohamed Gohar , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Proposal for H.263 baseline codec Thread-Index: AQHNDaWq9kefa/omnUePrLHPwXaly5aBQduAgAAyeID//9/OgIAAKWCA Date: Thu, 29 Mar 2012 14:53:03 +0000 Message-ID: In-Reply-To: <4F7470B7.9090202@librevideo.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <60F2425599A08547A7B5CA88AFA89420@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [rtcweb] Proposal for H.263 baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:53:18 -0000 On 3.29.2012 16:24 , "Basil Mohamed Gohar" wrote: >On 03/29/2012 10:20 AM, Stephan Wenger wrote: >> The second part of your sentence may or may not be true, depending on >>your >> relationship with google, your willingness to use the webm >>implementation >> in unchanged form, and other factors. Please see the webm license >> conditions, which AFAIK can be found here: >> http://www.webmproject.org/license/additional/ >Correct. I think you are referring to this part, explicitly: >> If you or your agent or exclusive licensee institute or order or agree >> to the institution of patent litigation against any entity (including >> a cross-claim or counterclaim in a lawsuit) alleging that this >> implementation of VP8 or any code incorporated within this >> implementation of VP8 constitutes direct or contributory patent >> infringement, or inducement of patent infringement, then any patent >> rights granted to you under this License for this implementation of >> VP8 shall terminate as of the date such litigation is filed. >Perhaps I assumed that that is a very reasonable part of the license. >That is, if you are suing someone alleging a patent infringement within >VP8, you are no longer granted the license to use VP8's patented >technologies that Google owns. Yes, that's one issue. Call it personal preference for different type of reciprocity conditions :-) (I could rant about it for hours, but let's continue to pretend that this is mostly a technical mailing list) The other issue, though (the fact that the license grant extends only to the VP8 implementation as provided by google, and does not extent to derivative works such as hardware implementations) should be moderately alarming even for an open source person. With respect to this clause, I will note that I criticized the licensing conditions in private and in public (IETF mike) several times, months ago, and nothing happened. Suggests to me one of three things: (1) google is a large company and decisions take time, or (2) google's legal is currently occupied with other stuff, or (3) that the choice of language is intentional, and intended to prevent forks. Take your pick. Stephan =20 >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From basilgohar@librevideo.org Thu Mar 29 07:57:24 2012 Return-Path: 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 C748921E81B3 for ; Thu, 29 Mar 2012 07:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] 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 uRrbzUcNGFRa for ; Thu, 29 Mar 2012 07:57:24 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 05B4C21E809C for ; Thu, 29 Mar 2012 07:57:24 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 62EDB6525CD; Thu, 29 Mar 2012 10:57:23 -0400 (EDT) Message-ID: <4F747851.7020906@librevideo.org> Date: Thu, 29 Mar 2012 10:57:21 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for H.263 baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:57:24 -0000 On 03/29/2012 10:53 AM, Stephan Wenger wrote: > > On 3.29.2012 16:24 , "Basil Mohamed Gohar" > wrote: > >> On 03/29/2012 10:20 AM, Stephan Wenger wrote: >>> The second part of your sentence may or may not be true, depending on >>> your >>> relationship with google, your willingness to use the webm >>> implementation >>> in unchanged form, and other factors. Please see the webm license >>> conditions, which AFAIK can be found here: >>> http://www.webmproject.org/license/additional/ >> Correct. I think you are referring to this part, explicitly: >>> If you or your agent or exclusive licensee institute or order or agree >>> to the institution of patent litigation against any entity (including >>> a cross-claim or counterclaim in a lawsuit) alleging that this >>> implementation of VP8 or any code incorporated within this >>> implementation of VP8 constitutes direct or contributory patent >>> infringement, or inducement of patent infringement, then any patent >>> rights granted to you under this License for this implementation of >>> VP8 shall terminate as of the date such litigation is filed. >> Perhaps I assumed that that is a very reasonable part of the license. >> That is, if you are suing someone alleging a patent infringement within >> VP8, you are no longer granted the license to use VP8's patented >> technologies that Google owns. > Yes, that's one issue. Call it personal preference for different type of > reciprocity conditions :-) (I could rant about it for hours, but let's > continue to pretend that this is mostly a technical mailing list) > > The other issue, though (the fact that the license grant extends only to > the VP8 implementation as provided by google, and does not extent to > derivative works such as hardware implementations) should be moderately > alarming even for an open source person. With respect to this clause, I > will note that I criticized the licensing conditions in private and in > public (IETF mike) several times, months ago, and nothing happened. > Suggests to me one of three things: (1) google is a large company and > decisions take time, or (2) google's legal is currently occupied with > other stuff, or (3) that the choice of language is intentional, and > intended to prevent forks. Take your pick. > Stephan Stephan, If the license wording is meant to limit the patent grant only to software implementations, then I will raise this issue myself, because that's a glaring hole and huge setback to the adoption of the format. If I find anything out about this, I'll report back here. The fact that there are already hardware implementations, though, seems to imply that in reality, this is not the case. Google has been open to changing the licensing situation of VP8 in the past when issues like this were brought up. I do not, however, want this to be a point of FUD. I would welcome anyone from Google on this list authorized to speak about this to clarify this ASAP. A public statement like that should allow us to discount this worry. -- Libre Video http://librevideo.org From stewe@stewe.org Thu Mar 29 08:04:10 2012 Return-Path: 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 176AB21E8137 for ; Thu, 29 Mar 2012 08:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.775 X-Spam-Level: X-Spam-Status: No, score=-3.775 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 sEQombq8mO9Q for ; Thu, 29 Mar 2012 08:04:09 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5C97021E8133 for ; Thu, 29 Mar 2012 08:03:50 -0700 (PDT) Received: from mail164-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 15:03:50 +0000 Received: from mail164-ch1 (localhost [127.0.0.1]) by mail164-ch1-R.bigfish.com (Postfix) with ESMTP id 130E4300214; Thu, 29 Mar 2012 15:03:50 +0000 (UTC) X-SpamScore: -29 X-BigFish: PS-29(z11d7lzbb2dI9371I1432N98dK1419Mzz1202h1082kzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT003.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail164-ch1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT003.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail164-ch1 (localhost.localdomain [127.0.0.1]) by mail164-ch1 (MessageSwitch) id 1333033428269404_25554; Thu, 29 Mar 2012 15:03:48 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239]) by mail164-ch1.bigfish.com (Postfix) with ESMTP id 33F9D2C0210; Thu, 29 Mar 2012 15:03:48 +0000 (UTC) Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 15:03:47 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.179]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0135.002; Thu, 29 Mar 2012 15:03:40 +0000 From: Stephan Wenger To: Basil Mohamed Gohar , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Proposal for Theora baseline codec Thread-Index: AQHNDbWVvqwweyAi5ECaKn6ZQvaLwpaBd+qA///iSICAACYlAA== Date: Thu, 29 Mar 2012 15:03:39 +0000 Message-ID: In-Reply-To: <4F7475E9.104@librevideo.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [rtcweb] Proposal for Theora baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:04:10 -0000 HI Basil, Really interesting discussion. Top-posting this time, as I have to run. Yes, saber-rattling was present. Is present. It worked in the past, plus/minus Mozilla, didn't it? That's the whole idea behind sabre-rattling. It's better than sabre-swinging. More diligently put, warning of potential infringement is better than to punish an infringer. Cheaper, and serves the purpose. And thinking of a Mozilla as a juicy target (based on the numbers you cited) seems to me a bit of a far fetch, considering a) the percentage of multimedia codecs on a web browser's value proposition even today (let alone 5-10 years ago), and b) the monetary damages asked in high-profile patent lawsuits today. Stephan On 3.29.2012 16:47 , "Basil Mohamed Gohar" wrote: >On 03/29/2012 10:33 AM, Stephan Wenger wrote: >> Hi Monty, >> Couldn't it be that no one went after Vorbis and Theora because the >> rightholders had no real incentive to do so? For example, because the >> products implementing Vorbis, in their vast majority, also included MP3 >> and/or AAC, and the rightholders would have to deal with patent >>exhaustion >> arguments and whatnot after having gotten their money; and because >>theora >> deployment never reached a critical mass because it was a) not good >>enough >> technically, and b) felt to be too risky? >> I would turn your argument around: the (comparatively speaking) lack of >> commercial success of vorbis and theora, and the success of royalty >> bearing standard codecs, suggest to me only that no one was fooled, >>except >> perhaps the enthusiastic followers of those folks who keep pushing out >>one >> "free" codec after another... >> Stephan >> >Stephan, > >Monty already pointed out that sabre-rattling already happened. Had >there been any meat to the threats, then it would have been ridiculous >not to have pursued them. Mozilla implements both Theora and Vorbis in >browser, and do not implement MPEG-related codecs, and they're a >lucrative target (they're getting around $1 billion from Google in the >coming few years). They *do* have a commercial entity that could be the >target, as well. > >The real threat was that these formats posed a risk to the other formats >monopolistic adoption, and the FUD that was spread every time these >formats were presented in a standard or appeared poised to be adopted >more widely, the sabre-rattling began again, and no real threats >materialized. > >It's arguing by saying, "You never can be sure...". > >--=20 >Libre Video >http://librevideo.org > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From basilgohar@librevideo.org Thu Mar 29 08:08:18 2012 Return-Path: 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 DBF8421E81A7 for ; Thu, 29 Mar 2012 08:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] 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 0MctEAEYgStp for ; Thu, 29 Mar 2012 08:08:18 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 05BE521E81A0 for ; Thu, 29 Mar 2012 08:08:18 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 5DCBA642FAF; Thu, 29 Mar 2012 11:08:17 -0400 (EDT) Message-ID: <4F747ADE.20205@librevideo.org> Date: Thu, 29 Mar 2012 11:08:14 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for Theora baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:08:19 -0000 On 03/29/2012 11:03 AM, Stephan Wenger wrote: > HI Basil, > Really interesting discussion. Top-posting this time, as I have to run. > Yes, saber-rattling was present. Is present. It worked in the past, > plus/minus Mozilla, didn't it? That's the whole idea behind > sabre-rattling. It's better than sabre-swinging. More diligently put, > warning of potential infringement is better than to punish an infringer. > Cheaper, and serves the purpose. > And thinking of a Mozilla as a juicy target (based on the numbers you > cited) seems to me a bit of a far fetch, considering a) the percentage of > multimedia codecs on a web browser's value proposition even today (let > alone 5-10 years ago), and b) the monetary damages asked in high-profile > patent lawsuits today. > Stephan I disagree. If there was a real, defensible infringement, then engaging in a license agreement would be the far wiser approach than to warn of infringement. This would be the tactic when a technology one has patents on can be displaced by another which may-or-may-not infringe. Being replaced by another technology is a real threat to revenue. Being replaced by a technology that one can also extract licenses from, is not a threat. Therefore, sabre-rattling only makes sense when there's the real threat to ones existing revenue stream, and one doubts litigation will be in their favor. > On 3.29.2012 16:47 , "Basil Mohamed Gohar" > wrote: > >> On 03/29/2012 10:33 AM, Stephan Wenger wrote: >>> Hi Monty, >>> Couldn't it be that no one went after Vorbis and Theora because the >>> rightholders had no real incentive to do so? For example, because the >>> products implementing Vorbis, in their vast majority, also included MP3 >>> and/or AAC, and the rightholders would have to deal with patent >>> exhaustion >>> arguments and whatnot after having gotten their money; and because >>> theora >>> deployment never reached a critical mass because it was a) not good >>> enough >>> technically, and b) felt to be too risky? >>> I would turn your argument around: the (comparatively speaking) lack of >>> commercial success of vorbis and theora, and the success of royalty >>> bearing standard codecs, suggest to me only that no one was fooled, >>> except >>> perhaps the enthusiastic followers of those folks who keep pushing out >>> one >>> "free" codec after another... >>> Stephan >>> >> Stephan, >> >> Monty already pointed out that sabre-rattling already happened. Had >> there been any meat to the threats, then it would have been ridiculous >> not to have pursued them. Mozilla implements both Theora and Vorbis in >> browser, and do not implement MPEG-related codecs, and they're a >> lucrative target (they're getting around $1 billion from Google in the >> coming few years). They *do* have a commercial entity that could be the >> target, as well. >> >> The real threat was that these formats posed a risk to the other formats >> monopolistic adoption, and the FUD that was spread every time these >> formats were presented in a standard or appeared poised to be adopted >> more widely, the sabre-rattling began again, and no real threats >> materialized. >> >> It's arguing by saying, "You never can be sure...". >> >> -- >> Libre Video >> http://librevideo.org >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > -- Libre Video http://librevideo.org From basilgohar@librevideo.org Thu Mar 29 08:15:09 2012 Return-Path: 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 3DC6F21E81A0 for ; Thu, 29 Mar 2012 08:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] 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 nNE576Vjvpiz for ; Thu, 29 Mar 2012 08:15:07 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9977E21E80AC for ; Thu, 29 Mar 2012 08:15:07 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id CF7306525CD for ; Thu, 29 Mar 2012 11:15:06 -0400 (EDT) Message-ID: <4F747C77.5030500@librevideo.org> Date: Thu, 29 Mar 2012 11:15:03 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F747851.7020906@librevideo.org> In-Reply-To: <4F747851.7020906@librevideo.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposal for H.263 baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:15:09 -0000 On 03/29/2012 10:57 AM, Basil Mohamed Gohar wrote: > On 03/29/2012 10:53 AM, Stephan Wenger wrote: >> On 3.29.2012 16:24 , "Basil Mohamed Gohar" >> wrote: >> >>> On 03/29/2012 10:20 AM, Stephan Wenger wrote: >>>> The second part of your sentence may or may not be true, depending on >>>> your >>>> relationship with google, your willingness to use the webm >>>> implementation >>>> in unchanged form, and other factors. Please see the webm license >>>> conditions, which AFAIK can be found here: >>>> http://www.webmproject.org/license/additional/ >>> Correct. I think you are referring to this part, explicitly: >>>> If you or your agent or exclusive licensee institute or order or agree >>>> to the institution of patent litigation against any entity (including >>>> a cross-claim or counterclaim in a lawsuit) alleging that this >>>> implementation of VP8 or any code incorporated within this >>>> implementation of VP8 constitutes direct or contributory patent >>>> infringement, or inducement of patent infringement, then any patent >>>> rights granted to you under this License for this implementation of >>>> VP8 shall terminate as of the date such litigation is filed. >>> Perhaps I assumed that that is a very reasonable part of the license. >>> That is, if you are suing someone alleging a patent infringement within >>> VP8, you are no longer granted the license to use VP8's patented >>> technologies that Google owns. >> Yes, that's one issue. Call it personal preference for different type of >> reciprocity conditions :-) (I could rant about it for hours, but let's >> continue to pretend that this is mostly a technical mailing list) >> >> The other issue, though (the fact that the license grant extends only to >> the VP8 implementation as provided by google, and does not extent to >> derivative works such as hardware implementations) should be moderately >> alarming even for an open source person. With respect to this clause, I >> will note that I criticized the licensing conditions in private and in >> public (IETF mike) several times, months ago, and nothing happened. >> Suggests to me one of three things: (1) google is a large company and >> decisions take time, or (2) google's legal is currently occupied with >> other stuff, or (3) that the choice of language is intentional, and >> intended to prevent forks. Take your pick. >> Stephan > Stephan, > > If the license wording is meant to limit the patent grant only to > software implementations, then I will raise this issue myself, because > that's a glaring hole and huge setback to the adoption of the format. > If I find anything out about this, I'll report back here. The fact that > there are already hardware implementations, though, seems to imply that > in reality, this is not the case. Google has been open to changing the > licensing situation of VP8 in the past when issues like this were > brought up. > > I do not, however, want this to be a point of FUD. I would welcome > anyone from Google on this list authorized to speak about this to > clarify this ASAP. A public statement like that should allow us to > discount this worry. > A quicker follow-up than a requested, and by someone from outside of Google. The first license you linked to appears to cover the libvpx implementation itself. It's solely a software implementation, obviously. The VP8 bitstream is licensed separately, here: http://www.webmproject.org/license/bitstream/ And that appears to make no distinction between software or hardware. It relates to the VP8 format (a.k.a., the bitstream) itself. If I'm wrong, hopefully someone can correct me. -- Libre Video http://librevideo.org From roman@telurix.com Thu Mar 29 08:15:24 2012 Return-Path: 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 061CA21E81ED for ; Thu, 29 Mar 2012 08:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 epnJzQExRdwO for ; Thu, 29 Mar 2012 08:15:23 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 465CC21E81E5 for ; Thu, 29 Mar 2012 08:15:23 -0700 (PDT) Received: by qaea16 with SMTP id a16so154947qae.10 for ; Thu, 29 Mar 2012 08:15:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :x-gm-message-state:content-type; bh=sBznaPT0Jz3fjab7QV11EJgfgYqU5SVc78mRSDDpcOU=; b=bohRg879JB1AHB8rfWY+NjNU/55hfmM0TytdUC6r2kwj/Dkk9TSnN5jfvVcXr9N0C9 j0ytcmCDzM3OoO3/imu3XB2STCcRj+zbGxH/rFMvMQ0c1OlaxDWLVXeyZipS5bheAQHt M687zSXMHocJ6l7qyXbSnKfQsfJ19Zn9ZJgFGgh9QADPJZnpyY6ZwCORE9y5IPGGkWfP 8Zaxh3Iv/yjyiGQ0h8vTaZVQa+F/WtW2LhdkFmqEBIqXqmIqJCsyUSP0MYfWU/7IIwkW BtYT0ELaHJICB7vynK7C8/YxGrn8mn+yi5pOBntI4cakco365Img7tbtHyxCJCiRxJB8 adZw== Received: by 10.224.174.72 with SMTP id s8mr580271qaz.67.1333034122790; Thu, 29 Mar 2012 08:15:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id dm8sm12851220qab.18.2012.03.29.08.15.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 08:15:22 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1722537ghb.31 for ; Thu, 29 Mar 2012 08:15:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.230.99 with SMTP id sx3mr704450pbc.55.1333034121152; Thu, 29 Mar 2012 08:15:21 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 29 Mar 2012 08:15:21 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> Date: Thu, 29 Mar 2012 11:15:21 -0400 Message-ID: From: Roman Shpount To: "rtcweb@ietf.org" X-Gm-Message-State: ALoCoQkK3J8tI8Iw0JivRtMi2F3SMdx2L461OwYVm7XZkqdi22cdUaWbGPSnUXQaXIQeckpQW6ye Content-Type: multipart/alternative; boundary=047d7b2edf0343c72004bc633144 Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:15:24 -0000 --047d7b2edf0343c72004bc633144 Content-Type: text/plain; charset=ISO-8859-1 I wanted to clarify what i actually want to see as security/encryption policy for WebRTC. 1. SRTP-DTLS is required to be supported and is offered by default with no option to bid down to anything else. 2. From HTTPS session SDES SRTP can be enabled via an API method 3. From HTTP session RTP can be enabled via an API method I only want to allow RTP from HTTP initiated session, since I see no benefit of supporting SDES SRTP there. I only want to allow SDES SRTP from HTTPS initiated sessions, since SDES SRTP provides no security benefits when session description is transmitted over clear channel. With my proposal, if an application provider does not care about security, they will use HTTP/RTP. If they care about security, they will use HTTPS/DTLS-SRTP or SDES-SRTP, if interop or weather forces them to do so. Also, this way we do not provide false sense of security if someone decides to start SDES-SRTP session from HTTP. Is someone can explain to me how this is less secure, even in the airport wifi comparing to SDES-RTP from HTTP session, please do so. P.S. I do know why this is less secure then DTLS-SRTP only option. _____________ Roman Shpount --047d7b2edf0343c72004bc633144 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I wanted to clarify what i actually want to see as security/encryption poli= cy for WebRTC.

1. SRTP-DTLS is required to be supported and is offer= ed by default with no option to bid down to anything else.
2. From HTTPS= session SDES SRTP can be enabled via an API method
3. From HTTP session RTP can be enabled via an API method

I only wan= t to allow RTP from HTTP initiated session, since I see no benefit of suppo= rting SDES SRTP there. I only want to allow SDES SRTP from HTTPS initiated = sessions, since SDES SRTP provides no security benefits when session descri= ption is transmitted over clear channel.

With my proposal, if an application provider does not care about securi= ty, they will use HTTP/RTP. If they care about security, they will use HTTP= S/DTLS-SRTP or SDES-SRTP, if interop or weather forces them to do so. Also,= this way we do not provide false sense of security if someone decides to s= tart SDES-SRTP session from HTTP.

Is someone can explain to me how this is less secure, even in the airpo= rt wifi comparing to SDES-RTP from HTTP session, please do so.

P.S. = I do know why this is less secure then DTLS-SRTP only option.
_____________
Roman Shpount


--047d7b2edf0343c72004bc633144-- From jmvalin@mozilla.com Thu Mar 29 08:16:35 2012 Return-Path: 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 B3B0A21E81ED for ; Thu, 29 Mar 2012 08:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 V9kB1QZWjMS6 for ; Thu, 29 Mar 2012 08:16:31 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id D9A2E21E81A0 for ; Thu, 29 Mar 2012 08:16:31 -0700 (PDT) Received: from [130.129.71.20] (dhcp-4714.meeting.ietf.org [130.129.71.20]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id D9D6C4AEDCC; Thu, 29 Mar 2012 08:16:30 -0700 (PDT) Message-ID: <4F747CCD.5060906@mozilla.com> Date: Thu, 29 Mar 2012 11:16:29 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for Theora baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:16:35 -0000 On 29/03/12 10:33 AM, Stephan Wenger wrote: > Couldn't it be that no one went after Vorbis and Theora because the > rightholders had no real incentive to do so? For example, because the > products implementing Vorbis, in their vast majority, also included MP3 > and/or AAC, and the rightholders would have to deal with patent exhaustion > arguments and whatnot after having gotten their money; and because theora > deployment never reached a critical mass because it was a) not good enough > technically, and b) felt to be too risky? Whatever the reason might have applied to Vorbis, it seems like would also apply to VP8. I've also heard similar arguments about "nobody going after Speex mainly because nobody with deep pockets is using it". That's despite the fact that Speex is being shipped by companies like Microsoft, Google, Apple and CISCO. You would have thought someone would have sued if they had something. Similarly, Vorbis is also shipped by (at least) Microsoft and Google and we haven't heard of anything. In fact, the only codec related patent lawsuits/threats I'm aware of all involve ITU/MPEG codecs with established patent pools around them. So if anything, I'd say VP8 might be safer from unexpected risks than H.264 Jean-Marc > On 3.29.2012 16:09 , "Monty Montgomery" wrote: > >> If we're suggesting ten+ year-old codecs with low patent risk, let's >> choose an obviously higher performance example. Dare I say it... >> Theora? >> >> I think we've gotten off track. >> >> Twelve years ago, oblique threats were made against the nascent Vorbis >> by Thomson and the whole world decided it was a patent risk. It never >> was. Fool me once, shame on you. >> >> In the mid 2000s, people started picking on Theora the same way, and a >> few years ago Steve Jobs [and Larry Horn, et al] informed the world he >> was coming after us. Nothing came of it. Fool me twice, shame on me. >> >> Now we have the same substance-less muttering about VP8, suggesting >> that it's better to use leftover crumbs from 20 years ago. >> >> Fool me three times, I should begin to wonder if I have the requisite >> capacity to be engaging in technical endeavors. >> >> Monty >> Xiph.Org >> _______________________________________________ >> 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 From martin.thomson@gmail.com Thu Mar 29 08:17:31 2012 Return-Path: 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 5F3C021F8549 for ; Thu, 29 Mar 2012 08:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[AWL=-1.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 A1qp9XZEA1IA for ; Thu, 29 Mar 2012 08:17:30 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id F2E7521F86DC for ; Thu, 29 Mar 2012 08:17:18 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2298495bku.31 for ; Thu, 29 Mar 2012 08:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=agV5dKZdymG0YtHIpBQKXG33LLNp2bvsB36GyzXfJ0Y=; b=pr8xoLoFSplWEgWheJbk6emzKIcEEaPTdca3EqHpsTXS5Zfr+VUh/mY0oIjYm0TmsT eMUwf7sPEfASrK9tj44cDzqU3c8SUwQBfc8R/Zjl8FtABvB0DTQqk872bmwwG8LjLXjs KmKAhNyQRgVdMiu9Vf/eoasES01spsRJhMgE+ClDrCrKbIpMz93PSMLwsIr6y5knMHgY 6hKjrhgR3OzOEPOPuS3uSABeNJOkR74W5XVFQ4Tpf/Rmx+PMxdovad1ezZy3Ye5uThLb E19K9jfA/oM03CWeGzc8G2gLZLj0oEcLZ2U2FyTdul+2X4FzMNpY7d/sIAZO6MQy6a6U bU+Q== MIME-Version: 1.0 Received: by 10.204.153.215 with SMTP id l23mr14066836bkw.11.1333034238084; Thu, 29 Mar 2012 08:17:18 -0700 (PDT) Received: by 10.205.38.73 with HTTP; Thu, 29 Mar 2012 08:17:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Mar 2012 17:17:18 +0200 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Cc: Randell Jesup , "" Subject: Re: [rtcweb] IdP and universal trust X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:17:31 -0000 On 29 March 2012 16:03, Bernard Aboba wrote: > While they would be perceived as different with first party IdP, a signed assertion is still meaningless without some proof that the E.164 number is actually owned by the domain making the assertion. Yes, if you infer that it is an E.164. I wouldn't have inferred that it was an E.164 number because I know that you can't make those sorts of assertions - it's just a string @ a domain. From andrew.hutton@siemens-enterprise.com Thu Mar 29 08:19:37 2012 Return-Path: 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 DC2B821F883F for ; Thu, 29 Mar 2012 08:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] 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 vAzyG765nIEd for ; Thu, 29 Mar 2012 08:19:37 -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 1F51D21F8841 for ; Thu, 29 Mar 2012 08:19:37 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 50C6C1EB84B1; Thu, 29 Mar 2012 17:19:36 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 29 Mar 2012 17:19:36 +0200 From: "Hutton, Andrew" To: Magnus Westerlund , "rtcweb@ietf.org" Date: Thu, 29 Mar 2012 17:19:34 +0200 Thread-Topic: [rtcweb] Consensus call regarding media security Thread-Index: Ac0M8kOUeqEsZNWCSMKEFgS7iyjaIgAy90KQ Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296C4CC7B@MCHP058A.global-ad.net> References: <4F732531.2030208@ericsson.com> In-Reply-To: <4F732531.2030208@ericsson.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] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:19:38 -0000 I agree that there was clear consensus on mandating the use of SRTP but it = was not clear to me what the consensus is regarding the use of SRTP with a = null cipher. Does the statement "there was overwhelming consensus that all = RTP packets SHALL be protected by SRTP" mean that the null cipher will not = be allowed? Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: 28 March 2012 16:50 > To: rtcweb@ietf.org > Subject: [rtcweb] Consensus call regarding media security >=20 > WG, >=20 > In todays RTCWEB WG meeting there was discussion around media security > mechanism. In this meeting there was some clear consensus in the > meeting which we would like to confirm on the list. >=20 > The first was that there was overwhelming consensus that all RTP > packets SHALL be protected by SRTP. >=20 > Secondly that no one objected against making DTLS-SRTP a mandatory to > implement and the default keying mechanism. Additional mechanisms are > not precluded. >=20 > WG participants may state their position regarding these consensus > calls > until 12th of April when the chairs will declare the final consensus. > If > you where present in the meeting room and comment on this, please > indicate that. >=20 > Best Regards >=20 > Magnus Westerlund > For the WG chairs >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Thu Mar 29 08:21:25 2012 Return-Path: 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 BC30921E8204 for ; Thu, 29 Mar 2012 08:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 dB2PSjwH31Ln for ; Thu, 29 Mar 2012 08:21:25 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD80C21E8202 for ; Thu, 29 Mar 2012 08:21:24 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1796171vbb.31 for ; Thu, 29 Mar 2012 08:21:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=zHalwkO9kXfw4XG85Zw/BtreUgvhhKF+bFkaegIJ5FI=; b=hqMIeV4/iHIzqbMJ/dyMlcOMpfjSYERetawsdOq6RQbEUQgM4iErBUpak1AIb3ujeF yflVEpwq0g6R1t4795Uqq3qNCs4lciIobLE3eYBuvBoLNsN9x+xywty8SBkEhMa+SVv0 uLrM/1e7HGIlzdY/q/RIMepooM37NMY4CssuM2dXu2wGlzwSWe3CltciMPA70RxmjEfV PWyc7cufWEhwyNrAZcIQij5WNRVA60h10Rjxu7eFJikzdOmRasGUsjG3WwjR4SvqfHsi PJ2/L2c/73ryU4JJaKBrPuwUnhuDQcwusyoRN+Mqgrh8wwMlQEWAZ8C5G5DMxEjMzk4J GELg== Received: by 10.52.15.233 with SMTP id a9mr2817157vdd.34.1333034484415; Thu, 29 Mar 2012 08:21:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 29 Mar 2012 08:21:04 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 29 Mar 2012 17:21:04 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlNv7JO0z4CnYouxMg4uNETIvDuMvMRmFHEyHqqudB//hp2DccanNyI/jgC6ZLRKo3FUCyn Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:21:25 -0000 2012/3/29 Roman Shpount : > 1. SRTP-DTLS is required to be supported and is offered by default with n= o > option to bid down to anything else. > 2. From HTTPS session SDES SRTP can be enabled via an API method > 3. From HTTP session RTP can be enabled via an API method > > I only want to allow RTP from HTTP initiated session, since I see no bene= fit > of supporting SDES SRTP there. I only want to allow SDES SRTP from HTTPS > initiated sessions, since SDES SRTP provides no security benefits when > session description is transmitted over clear channel. > > With my proposal, if an application provider does not care about security= , > they will use HTTP/RTP. If they care about security, they will use > HTTPS/DTLS-SRTP or SDES-SRTP, if interop or weather forces them to do so. > Also, this way we do not provide false sense of security if someone decid= es > to start SDES-SRTP session from HTTP. > > Is someone can explain to me how this is less secure, even in the airport > wifi comparing to SDES-RTP from HTTP session, please do so. You miss something: 1) I access some web using HTTPS with a valid certificate and so. 2) Some HTML and JavaScript is got. 3) The JS code opens a *non* secure WebSocket connection to some other server (same domain or not, it does not matter here). 4) WebRTC signaling goes through the WebSocket connection (so forget the initial HTTPS hyper-secure-and-verified connection). 5) SDES-SRTP is negotiated and accepted by both peers. 6) So signaling can be intercepted (unsecure WebSocket connection), and therefore also the SDES keys. Interception possible regardless the initial communication was HTTPS. 7) FAIL. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Mar 29 08:23:43 2012 Return-Path: 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 022B121E8209 for ; Thu, 29 Mar 2012 08:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 vgiOzCqPE-A4 for ; Thu, 29 Mar 2012 08:23:38 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0687521E819F for ; Thu, 29 Mar 2012 08:23:35 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1798139vbb.31 for ; Thu, 29 Mar 2012 08:23:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=4KeGk3yle5sqRWLktg11hhKFIgHTHa9s9m6iBWw5E2o=; b=HkGVWTHPK6aiwoMoatoyTwBMYyHyQeg4h/CT/7en6Yq8QBHVqNv5ZMZbkl7t0cO0Oe RwvAVXzwxbe9WqZDUsipT5VQ+3Z5TtZz3+Wizq+oWdVaQrqJ4iGxEOTR2lP/Z9JUeWPb tN0Q0ABlyerXxM3Dl8GN+wQ1fJ8uVF0kBaZf5mwl6kGqBoCO+P8okF5joenRqGaDcWi2 srU1X1ABtjQSOpPTk2AqjcFyI5bp2nPC6DXiKvm83MJACs2SwE2WKVHMg8oHCcn9wpPW 6kMBIYKuhFTMzEs+d5zGn7lqA5ksDc8b6sYPbzX2lqbzvDcdFJxeN7xZk/0QzTTEV2O8 J+Qw== Received: by 10.220.152.205 with SMTP id h13mr274482vcw.12.1333034614214; Thu, 29 Mar 2012 08:23:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 29 Mar 2012 08:23:13 -0700 (PDT) In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31296C4CC7B@MCHP058A.global-ad.net> References: <4F732531.2030208@ericsson.com> <101C6067BEC68246B0C3F6843BCCC1E31296C4CC7B@MCHP058A.global-ad.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 29 Mar 2012 17:23:13 +0200 Message-ID: To: "Hutton, Andrew" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlfd1Obpf1552KRGljNZz1KwFhmpmG3YrLUa2sVMVLZvUU49WN0oP6U8KN/Pi5qmZDOD3fl Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:23:44 -0000 2012/3/29 Hutton, Andrew : > I agree that there was clear consensus on mandating the use of SRTP but i= t was not clear to me what the consensus is regarding the use of SRTP with = a null cipher. Does the statement "there was overwhelming consensus that al= l RTP packets SHALL be protected by SRTP" mean that the null cipher will no= t be allowed? IMHO it's very easy: - The JavaScript WebRTC API MUST NOT be able to set a null cipher (never). - The browser MAY include an option in about://config ("SRTP: user null cipher for debugging purposes"). - Such an option is reverted (so dissabled) upon browser restart. --=20 I=C3=B1aki Baz Castillo From basilgohar@librevideo.org Thu Mar 29 08:30:21 2012 Return-Path: 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 A158821E820E for ; Thu, 29 Mar 2012 08:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] 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 EuC88dTCzU96 for ; Thu, 29 Mar 2012 08:30:20 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id C612B21E813B for ; Thu, 29 Mar 2012 08:30:20 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 183CF652674 for ; Thu, 29 Mar 2012 11:30:20 -0400 (EDT) Message-ID: <4F748009.1000300@librevideo.org> Date: Thu, 29 Mar 2012 11:30:17 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F732531.2030208@ericsson.com> <101C6067BEC68246B0C3F6843BCCC1E31296C4CC7B@MCHP058A.global-ad.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:30:21 -0000 On 03/29/2012 11:23 AM, Iñaki Baz Castillo wrote: > 2012/3/29 Hutton, Andrew : >> I agree that there was clear consensus on mandating the use of SRTP but it was not clear to me what the consensus is regarding the use of SRTP with a null cipher. Does the statement "there was overwhelming consensus that all RTP packets SHALL be protected by SRTP" mean that the null cipher will not be allowed? > IMHO it's very easy: > > - The JavaScript WebRTC API MUST NOT be able to set a null cipher (never). > > - The browser MAY include an option in about://config ("SRTP: user > null cipher for debugging purposes"). > > - Such an option is reverted (so dissabled) upon browser restart. > I think the standard need not specify that NULL cipher is allowed to enable the debugging feature for browsers or other implementations. It's reasonable to assume that, when testing and debugging, one may break the spec in the process. Leaving it out of the standard is the safest way to prevent it from being used in a production environment. -- Libre Video http://librevideo.org From andrew.hutton@siemens-enterprise.com Thu Mar 29 08:31:38 2012 Return-Path: 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 16A2121E820F for ; Thu, 29 Mar 2012 08:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 WEB9ogJyjdZI for ; Thu, 29 Mar 2012 08:31:37 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2BF21E813B for ; Thu, 29 Mar 2012 08:31:37 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 4D27123F0430; Thu, 29 Mar 2012 17:31:36 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 29 Mar 2012 17:31:36 +0200 From: "Hutton, Andrew" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Thu, 29 Mar 2012 17:31:34 +0200 Thread-Topic: [rtcweb] Consensus call regarding media security Thread-Index: Ac0Nv+lVl70zE7EhSV2W7S2ypjY57wAAQ3lg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296C4CC98@MCHP058A.global-ad.net> References: <4F732531.2030208@ericsson.com> <101C6067BEC68246B0C3F6843BCCC1E31296C4CC7B@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:31:38 -0000 SSB3b3VsZCBiZSBoYXBweSB3aXRoIHRoYXQuDQoNCkFuZHkNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4 Lm5ldF0NCj4gU2VudDogMjkgTWFyY2ggMjAxMiAxNzoyMw0KPiBUbzogSHV0dG9uLCBBbmRyZXcN Cj4gQ2M6IE1hZ251cyBXZXN0ZXJsdW5kOyBydGN3ZWJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFtydGN3ZWJdIENvbnNlbnN1cyBjYWxsIHJlZ2FyZGluZyBtZWRpYSBzZWN1cml0eQ0KPiANCj4g MjAxMi8zLzI5IEh1dHRvbiwgQW5kcmV3IDxhbmRyZXcuaHV0dG9uQHNpZW1lbnMtZW50ZXJwcmlz ZS5jb20+Og0KPiA+IEkgYWdyZWUgdGhhdCB0aGVyZSB3YXMgY2xlYXIgY29uc2Vuc3VzIG9uIG1h bmRhdGluZyB0aGUgdXNlIG9mIFNSVFANCj4gYnV0IGl0IHdhcyBub3QgY2xlYXIgdG8gbWUgd2hh dCB0aGUgY29uc2Vuc3VzIGlzIHJlZ2FyZGluZyB0aGUgdXNlIG9mDQo+IFNSVFAgd2l0aCBhIG51 bGwgY2lwaGVyLiBEb2VzIHRoZSBzdGF0ZW1lbnQgInRoZXJlIHdhcyBvdmVyd2hlbG1pbmcNCj4g Y29uc2Vuc3VzIHRoYXQgYWxsIFJUUCBwYWNrZXRzIFNIQUxMIGJlIHByb3RlY3RlZCBieSBTUlRQ IiBtZWFuIHRoYXQNCj4gdGhlIG51bGwgY2lwaGVyIHdpbGwgbm90IGJlIGFsbG93ZWQ/DQo+IA0K PiBJTUhPIGl0J3MgdmVyeSBlYXN5Og0KPiANCj4gLSBUaGUgSmF2YVNjcmlwdCBXZWJSVEMgQVBJ IE1VU1QgTk9UIGJlIGFibGUgdG8gc2V0IGEgbnVsbCBjaXBoZXINCj4gKG5ldmVyKS4NCj4gDQo+ IC0gVGhlIGJyb3dzZXIgTUFZIGluY2x1ZGUgYW4gb3B0aW9uIGluIGFib3V0Oi8vY29uZmlnICgi U1JUUDogdXNlcg0KPiBudWxsIGNpcGhlciBmb3IgZGVidWdnaW5nIHB1cnBvc2VzIikuDQo+IA0K PiAtIFN1Y2ggYW4gb3B0aW9uIGlzIHJldmVydGVkIChzbyBkaXNzYWJsZWQpIHVwb24gYnJvd3Nl ciByZXN0YXJ0Lg0KPiANCj4gLS0NCj4gScOxYWtpIEJheiBDYXN0aWxsbw0KPiA8aWJjQGFsaWF4 Lm5ldD4NCg== From ibc@aliax.net Thu Mar 29 08:33:47 2012 Return-Path: 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 4E64321E820F for ; Thu, 29 Mar 2012 08:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 Kpgwsquuuvsx for ; Thu, 29 Mar 2012 08:33:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFE5D21E8200 for ; Thu, 29 Mar 2012 08:33:46 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1844706vcb.31 for ; Thu, 29 Mar 2012 08:33:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=/CNSbPmk7VbdngzAaSg5msYHjD+yK/rwnZqFrBtEjJE=; b=IXaWOYQliVaYX0v10L3cpJw/yvK3/vYfUrvBMmWP10+E1hQi2tYoL7Ftpf1/tBS9RA 46v8ITYJO4jHf5Y5uEGVABiPG794J5n+Wf4+MhBqN3wyYnIyEeizIOd/nZxGO8sgLnwT xYv/HWACUsUYl+JYTJ4RB3VP2BLCFllxfpIGMQj1T4YzL/ggq+Hdv0J1zJaco0A4vMlO jF0EzbAUREn0xSbzNkGWAJGHYwbtlyG2N3otO8JvBASwtB5B8uGdyntCFgiRc8lm9bfl oqpQitXBmqmRTr/VV6DLG7RRoBmG0hTiYL/5ZPqqju7hz+PIie+M8S1lt77Yy7p48p2Z PZiA== Received: by 10.220.157.7 with SMTP id z7mr6002468vcw.2.1333035226218; Thu, 29 Mar 2012 08:33:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 29 Mar 2012 08:33:26 -0700 (PDT) In-Reply-To: References: <4F742344.802@infosecurity.ch> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 29 Mar 2012 17:33:26 +0200 Message-ID: To: Oscar Ohlsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnOPN9XTKhdbr0WDt8H2/bAPZfSwLRriI2R88NPGrpmMrSJsnZfiFZJJBHQha+wHXmIPEN4 Cc: "" Subject: Re: [rtcweb] Support of SDES in WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:33:47 -0000 2012/3/29 Oscar Ohlsson : > Hi Fabio, > > My assumption has always been the following: > > - DTLS-SRTP is the default > - DTLS-SRTP + identity can be turned on via the JavaScript API if the web= app wishes to do so > - SDES can be turned on by a manipulated SDP offer/answer provided the en= tire webapp was retrieved over HTTPS Please check this mail in which I explain that retrieving the web app by means of HTTPS means nothing: http://www.ietf.org/mail-archive/web/rtcweb/current/msg03914.html --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Thu Mar 29 08:33:50 2012 Return-Path: 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 174F721E8225 for ; Thu, 29 Mar 2012 08:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 8HDhjfILW+nJ for ; Thu, 29 Mar 2012 08:33:49 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAD421E8223 for ; Thu, 29 Mar 2012 08:33:49 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1708909yhk.31 for ; Thu, 29 Mar 2012 08:33:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-gm-message-state:content-type; bh=5i3TK4PYenC4CEO/9+uZoAub8K1m9KDXCmKkO0JAA00=; b=Kk2XtdqBmmO9siZ0hORmhnrLDbkvp9BLQjF+OYQtNutBN23i3dE5uoQPL1kSXXuvh6 wNZRIQTPc07FE0d5JojLLcXY2zA14Q1kA0ZP7uq4co9rEM/wEjB+VRx+MHfbAzj4ZjOD bz+T516NJadbq/U/2gv6ileEnKrw1V3r6DxDfCcsI8EcFX6xyxeRz6SZ4nlitmGRScW+ Yb1Ctl6/bfLTmx0BEFhzXK79M90+uwmbsFyKfWp49IUGc8pI8Ozx0LmEPtrLeFnAO2OZ aM9wdNXTeH6C3VESgdYOfnesQgKwxNpnHxzDnnrwjMHFTrS/Zyq8FPpvYR6+UNQB7TXW 40Zg== Received: by 10.68.219.34 with SMTP id pl2mr836915pbc.56.1333035228587; Thu, 29 Mar 2012 08:33:48 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id w6sm5229934pbf.66.2012.03.29.08.33.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 08:33:47 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so274988pbb.31 for ; Thu, 29 Mar 2012 08:33:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.230.99 with SMTP id sx3mr816235pbc.55.1333035227024; Thu, 29 Mar 2012 08:33:47 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 29 Mar 2012 08:33:46 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> Date: Thu, 29 Mar 2012 11:33:46 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= X-Gm-Message-State: ALoCoQlNdvg+qPzokwyMK1Yn2h2YabS8KC8wxuKBeK8z2rFzLFOhfZCyuUH7i7/ypZf9LJWgWVRN Content-Type: multipart/alternative; boundary=047d7b2edf032e0d9104bc63736f Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:33:50 -0000 --047d7b2edf032e0d9104bc63736f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2012 at 11:21 AM, I=F1aki Baz Castillo wrot= e: > You miss something: > > 1) I access some web using HTTPS with a valid certificate and so. > > 2) Some HTML and JavaScript is got. > > 3) The JS code opens a *non* secure WebSocket connection to some other > server (same domain or not, it does not matter here). > > 4) WebRTC signaling goes through the WebSocket connection (so forget > the initial HTTPS hyper-secure-and-verified connection). > > 5) SDES-SRTP is negotiated and accepted by both peers. > > 6) So signaling can be intercepted (unsecure WebSocket connection), > and therefore also the SDES keys. Interception possible regardless the > initial communication was HTTPS. > > 7) FAIL. > First of all, HTTP WebSocket connection are normally not allowed from HTTPS initiated sessions (or generate a warning). Second, my point was that SDES-SRTP is no more secure then plain RTP when signaling is transmitted over clear channel. You are saying the same thing. If SDES-SRTP is allowed, there is no harm in allowing plain RTP from HTTP, since, as far as security is concerned, there is no difference. > _____________ Roman Shpount --047d7b2edf032e0d9104bc63736f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 29, 2012 at 11:21 = AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
You miss something:

1) I access some web using HTTPS with a valid certificate and so.

2) Some HTML and JavaScript is got.

3) The JS code opens a *non* secure WebSocket connection to some other
server (same domain or not, it does not matter here).

4) WebRTC signaling goes through the WebSocket connection (so forget
the initial HTTPS hyper-secure-and-verified connection).

5) SDES-SRTP is negotiated and accepted by both peers.

6) So signaling can be intercepted (unsecure WebSocket connection),
and therefore also the SDES keys. Interception possible regardless the
initial communication was HTTPS.

7) FAIL.
=A0
First of=A0 all, HTTP WebSocket connec= tion are normally not allowed from HTTPS initiated sessions (or generate a = warning).

Second, my point was that SDES-SRTP is no more secure then= plain RTP when signaling is transmitted over clear channel. You are saying= the same thing. If SDES-SRTP is allowed, there is no harm in allowing plai= n RTP from HTTP, since, as far as security is concerned, there is no differ= ence.
_____________
Roman Shpount
--047d7b2edf032e0d9104bc63736f-- From ibc@aliax.net Thu Mar 29 08:43:28 2012 Return-Path: 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 4B9C921F882E for ; Thu, 29 Mar 2012 08:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 gITk5r9xr0-p for ; Thu, 29 Mar 2012 08:43:27 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBC921F875C for ; Thu, 29 Mar 2012 08:43:11 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1853591vcb.31 for ; Thu, 29 Mar 2012 08:43:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=UTUNl2UMTpjlJOuxf4wPZJs6+ebtWt4Mhg0yXRly9iI=; b=fgpWtlar3O71aMfHVCyF+qa7UPTsu0VYyZiHbdQO87heHMJfTOHcM5m0HxDFyeUtvk MkEwJ64te///a9+CesPA785ZbuP+kPaIM5NU9VdYRJKgJ6zTazAd4Yl3eakfcCQ1ZpSi hVPXCSzY4PDUOfJFjQLAczeT75Zxh65GnY+nuaqseqIZlDd50ZfxM/kdINKGXH/F8cCR UPpRpjtI142i26ghfOw2ALMYBZ++gFsnZj3Hg1tKdXbzQ4hahwP10nxlBRVE78I4U3d4 b+Nrb4QUvQjRbckvGUNQ/aGS3Dy1hbWSVISGHAcX0Enusz/v1XND99v196vZdBozoJXN HvHg== Received: by 10.220.157.7 with SMTP id z7mr6018606vcw.2.1333035790724; Thu, 29 Mar 2012 08:43:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 29 Mar 2012 08:42:49 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 29 Mar 2012 17:42:49 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkEBk6Wc2vre1X1XcI9bGBtiAMHXDiCmentveWz+ouNQx0SJJv02E6yM0Jnm/o4XjOui5Bt Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:43:28 -0000 2012/3/29 Roman Shpount : > First of=C2=A0 all, HTTP WebSocket connection are normally not allowed fr= om HTTPS > initiated sessions (or generate a warning). Ok, I didn't check that. > Second, my point was that SDES-SRTP is no more secure then plain RTP when > signaling is transmitted over clear channel. You are saying the same thin= g. Right:) > If SDES-SRTP is allowed, there is no harm in allowing plain RTP from HTTP= , > since, as far as security is concerned, there is no difference. The only I meant is that the signaling must be secured. Otherwise, using SDES-SRTP adds no security at all. But the signaling could be a different connection (i.e. WebSocket) different from the HTTP(s) connection used to retrieve the web. Let's assume this example: - The browser access the web via plain HTTP. - The JS opens two websocket connections: 1) First one for the WebRTC signaling, a secure WS connection. 2) Second one for other realtime stuff, a NON secure WS connection. If the SDES key is carried over the first WS connection (wss) then it's ok, it provides confidenciality. But if the SDES key is carried over the second WS connection (ws, so unsecure) then it's interceptable and therefore also the SRTP. Question: can the WebRTC stack figure which WS connection is being used for WebRTC signaling? Autoanswer: NO, since the signaling protocol is up to the app developer. So Houston we have a problem if we try to make requirements in which SDES-SRTP can be used. I'm in favour of mandating SDES-SRTP in WebRTC, but we need to solve this issue, and it is not easy (AFAIK). Regards. --=20 I=C3=B1aki Baz Castillo From jmvalin@mozilla.com Thu Mar 29 08:50:21 2012 Return-Path: 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 94B0621E80D3 for ; Thu, 29 Mar 2012 08:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 3ziTaTtQiRsj for ; Thu, 29 Mar 2012 08:50:21 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id E8CAB21E80C9 for ; Thu, 29 Mar 2012 08:50:20 -0700 (PDT) Received: from [130.129.71.20] (dhcp-4714.meeting.ietf.org [130.129.71.20]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 3C47F4AED5A; Thu, 29 Mar 2012 08:50:20 -0700 (PDT) Message-ID: <4F7484BA.5030100@mozilla.com> Date: Thu, 29 Mar 2012 11:50:18 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for Theora baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:50:21 -0000 On 29/03/12 11:03 AM, Stephan Wenger wrote: > That's the whole idea behind > sabre-rattling. It's better than sabre-swinging. More diligently put, > warning of potential infringement is better than to punish an infringer. > Cheaper, and serves the purpose. Actually, I thought it was the other way around. Those who actually have valid claims swing without warning to maximize damages. Those who cannot swing, rattle and scare others in the direction of codecs for which they hold patents. Jean-Marc From lists@infosecurity.ch Thu Mar 29 09:56:37 2012 Return-Path: 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 B0F3721F8992 for ; Thu, 29 Mar 2012 09:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.292 X-Spam-Level: X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 dd12vPti+raF for ; Thu, 29 Mar 2012 09:56:36 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C24721F88E9 for ; Thu, 29 Mar 2012 09:56:36 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so203214wib.13 for ; Thu, 29 Mar 2012 09:56:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=NB8/a+YKp6iYAZPRgLXwOv71p/qMd7WC3TL33nAyrf0=; b=es1mVtJW9f7yNA8zVuXN6ItlmhF02h60xk1RoVW+cMm/kza1c18qfz+bRhAGnU1JcS Wxvp7uR3zjmWxqKEivMCK3f9t7n5MWgEeV4ov4ZNjk3PKih45oGFykxJeLGY4uNjJSAF iazsnj95SywZRg1DrvX2Fo33v+OFjdmzMBarmMKZ4gPp1RqOBO+3lgCVIgZmKkLF1Isa 8MdJjcaEMsxtxkgclaQdct5TWajJ+v0jUhFYiy6cI0UqSSsEeRAhwXAHLInxeteKfYCy Wwf/apIc3kl3qcazw0RjNtUaFW/NNNMsRMIWbjZ3Qs4goTFUIJ6GBgQXYd3wqfMo4FGD bphg== Received: by 10.180.94.33 with SMTP id cz1mr7375785wib.13.1333040195591; Thu, 29 Mar 2012 09:56:35 -0700 (PDT) Received: from sonyvaiop13.local (93-57-41-37.ip162.fastwebnet.it. [93.57.41.37]) by mx.google.com with ESMTPS id fn2sm30909421wib.0.2012.03.29.09.56.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 09:56:34 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F749440.3010303@infosecurity.ch> Date: Thu, 29 Mar 2012 18:56:32 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4F742344.802@infosecurity.ch> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQl8Bas/02geNkqvaDt+hruSEuFUHWpB9dlpSTrndr98QMHzxdh5xvdrT1RFlRqGhsFooFMX Cc: "" Subject: Re: [rtcweb] Support of SDES in WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:56:37 -0000 On 3/29/12 5:33 PM, Iñaki Baz Castillo wrote: > 2012/3/29 Oscar Ohlsson : >> Hi Fabio, >> >> My assumption has always been the following: >> >> - DTLS-SRTP is the default >> - DTLS-SRTP + identity can be turned on via the JavaScript API if the webapp wishes to do so >> - SDES can be turned on by a manipulated SDP offer/answer provided the entire webapp was retrieved over HTTPS > > Please check this mail in which I explain that retrieving the web app > by means of HTTPS means nothing: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg03914.html Yeah, but that's an issue that relate to general web and Javascript trust issue. Javascript trust issue is a problem that's already discussed and evaluated in other area and context of w3c, there are several solutions on-going. This kind of issue is the same considered for Javascript encryption. Trusted javascript can be verified/loaded today trough plug-ins and by trusting the 'application delivery source', so that's not an issue. >From 0 up to 100 of security with Javascript you can stay at 0 or reach 100, depending on the way you deploy and use web. Imho making SDES SDP offer/answer available to Javascript it's a great achievement as it will be able to unlock the creativity of the technological ecosystem. People will probably manipulate SDP, sign it, re-encrypt it, pass it trough OOB channels via CORS or as many other options we may envision. -- Fabio Pietrosanti Founder, CTO Tel: +39 02 85961748 (direct) Mobile: +39 340 1801049 E-mail: fabio.pietrosanti@privatewave.com Skype: fpietrosanti Linkedin: http://linkedin.com/in/secret PrivateWave Italia S.p.A. Via Gaetano Giardino 1 - 20123 Milano - Italy www.privatewave.com From pravindran@sonusnet.com Thu Mar 29 10:01:54 2012 Return-Path: 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 C6D3721E80B2 for ; Thu, 29 Mar 2012 10:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.221 X-Spam-Level: X-Spam-Status: No, score=-5.221 tagged_above=-999 required=5 tests=[AWL=1.378, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 MLFssQ2n2OPA for ; Thu, 29 Mar 2012 10:01:54 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id A2B8121E8053 for ; Thu, 29 Mar 2012 10:01:53 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKT3SVgbhtgvPhWfqCxiaRz0Bi5FZLI1+j@postini.com; Thu, 29 Mar 2012 10:01:53 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 29 Mar 2012 13:02:13 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 22:31:47 +0530 From: "Ravindran, Parthasarathi" To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Consensus call regarding media security Thread-Index: AQHNDPJEz8d54ZuGqkmrgP2aJufnWZaBgBgw Date: Thu, 29 Mar 2012 17:02:08 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> References: <4F732531.2030208@ericsson.com> In-Reply-To: <4F732531.2030208@ericsson.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:01:54 -0000 WebRTC trust model has to be considered as one of the main factor for decid= ing the key mechanism. AFAIK, SDES does not fit into WebRTC as Dr.Evil HTTP= S RTCWeb server must be trusted in case of SDES. There is no means to track= or analyze whether Dr.Evil involves in monitoring or recording or terminat= e the media traffic. It will be good in case whoever advocate for SDES exp= lain how SDES fits within WebRTC trust model. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Magnus Westerlund >Sent: Wednesday, March 28, 2012 8:20 PM >To: rtcweb@ietf.org >Subject: [rtcweb] Consensus call regarding media security > >WG, > >In todays RTCWEB WG meeting there was discussion around media security >mechanism. In this meeting there was some clear consensus in the meeting >which we would like to confirm on the list. > >The first was that there was overwhelming consensus that all RTP packets >SHALL be protected by SRTP. > >Secondly that no one objected against making DTLS-SRTP a mandatory to >implement and the default keying mechanism. Additional mechanisms are >not precluded. > >WG participants may state their position regarding these consensus calls >until 12th of April when the chairs will declare the final consensus. If >you where present in the meeting room and comment on this, please >indicate that. > >Best Regards > >Magnus Westerlund >For the WG chairs > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From silviapfeiffer1@gmail.com Thu Mar 29 10:13:25 2012 Return-Path: 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 95CC421F89FC for ; Thu, 29 Mar 2012 10:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 MHuYwkhMadcT for ; Thu, 29 Mar 2012 10:13:24 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B507F21F8444 for ; Thu, 29 Mar 2012 10:13:24 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1815451yhk.31 for ; Thu, 29 Mar 2012 10:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=qari2bzzd81q1vYXmos+GJxzApEBPSzRXXqGdcTVASc=; b=isSTXw80Hll7wAxJTozNtRCVmA/bKGD5+wURbdNiUqACE8rV+64stKCnpBqdvNMOLt GpcuhxSQV8/CWIFyB2FSiZ5BDp0xLLcYq1Yvp+loWth8/a8YWBpL/IAEB55jPvmaVDet 2nVahY4kOHqfRpSvNbT21GaeEmgxHCrL+TLmRtXsSYI8rugd2eHHWk6E5zY+0ns4PfVY kU9eEngWsUSIkg1lKbOv3G4C9CdYrxus76wIm2sWvnakwfBrZwU+NJ4K/VeSCUVIB07L X+Q1bAzfS+I40yF8Nnf7ImCmw/oqml4FGqXl++szKylLKyS86Lkeke9wMvQBR0NeNnGY FLLA== Received: by 10.236.170.165 with SMTP id p25mr34378514yhl.123.1333041204055; Thu, 29 Mar 2012 10:13:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.99.3 with HTTP; Thu, 29 Mar 2012 10:12:52 -0700 (PDT) In-Reply-To: References: <4F746163.5090506@hidayahonline.org> From: Silvia Pfeiffer Date: Thu, 29 Mar 2012 10:12:52 -0700 Message-ID: To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for H.263 baseline codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:13:25 -0000 Very interesting discussion. Out of personal curiosity, I have some questions inline. On Thu, Mar 29, 2012 at 7:20 AM, Stephan Wenger wrote: > > The most commonly cited timeline for a widely in use technology to be > "save" from a patent viewpoint, based on equitable defenses such as lache= s > (in the US) is six years. Very interesting to know the usually used limit on the number of years. IIUC that would make Speex, Vorbis and Theora "save" codecs, since they were released in 2003, 2000, and 2004 respectively? > In addition, as I pointed out in the meeting, the use of a video codec > created by a body such as MPEG or ITU-T SG16 has the advantage of that th= e > patents of all participating players are available at least under > Reasonable and Non Discriminatory (RAND) terms. =A0This may sound like a = Bad > Thing if you operate under a business model that prevents you to pay > anything for patent licenses, but it is surely a Good Thing if you are > willing to dish out a moderate amount of money for a license. So, what is the situation with H.263 and patent licensing? Is what Larry wrote in 2003 in this email still valid? http://lists.mpegif.org/pipermail/mp4-tech/2003-October/002771.html My Web search hasn't turned up any more up-to-date information on this, so it seems there are several patents associated that are still valid for H.263 and there is no patent pool for it, thus requiring every user of H.263 to come to separate license arrangements with each patent holder? Note: These are just questions of clarification - I am not implying any codec preferences in this email. Regards, Silvia. From ibc@aliax.net Thu Mar 29 10:27:44 2012 Return-Path: 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 E5BCE21E80F0 for ; Thu, 29 Mar 2012 10:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 tnfTf5HXXOsY for ; Thu, 29 Mar 2012 10:27:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 65A4B21F879F for ; Thu, 29 Mar 2012 10:27:29 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1946739vcb.31 for ; Thu, 29 Mar 2012 10:27:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=4++g/WVJtyqsPxbnCqdue0otptia+OPSOQ64hrfTyBU=; b=kY+tp9Akt+C93gOa+xwYhILPbhufQgmsB1d32NDI6UT5dRFVbSacBa9R7P9TAbhW/W krx9ENEZYEjRuVP1h/dvmbgvE1D8JbzWyLsMH91im/KEG2fuNjv9kbppR0L64YZwgY9T rUCFqclPagc8+pX7vwiXtlgyDeAPgVwjHEX3OMD5GisZ5qp8wWnKYqlIbtAAntez5pq1 6h5n7dra+S8SqV5VnmQ1ulz05yB60j9NCgzldLwRQoUe04vaTmVSYf9MEKDK9b28rGx9 RWYWXi1f56hY9wl2dSSDgpRFoWJyraU/vs1YQahbHVUiGERNSsBxLKHwFdCvmcnmskOM 3aeg== Received: by 10.52.15.233 with SMTP id a9mr3012679vdd.34.1333042048669; Thu, 29 Mar 2012 10:27:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 29 Mar 2012 10:27:08 -0700 (PDT) In-Reply-To: <4F749440.3010303@infosecurity.ch> References: <4F742344.802@infosecurity.ch> <4F749440.3010303@infosecurity.ch> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 29 Mar 2012 19:27:08 +0200 Message-ID: To: "Fabio Pietrosanti (naif)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm+j/H9jDGQqtMAwbpHUqmfQb7MQgOVg9PxyK2nlREPFAbv9+BkaniNFXNSn/UWrjtEwMVO Cc: "" Subject: Re: [rtcweb] Support of SDES in WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:27:44 -0000 2012/3/29 Fabio Pietrosanti (naif) : > Yeah, but that's an issue that relate to general web and Javascript > trust issue. > > Javascript trust issue is a problem that's already discussed and > evaluated in other area and context of w3c, there are several solutions > on-going. It's nice to know that the issue is already being addressed. > Imho making SDES SDP offer/answer available to Javascript it's a great > achievement as it will be able to unlock the creativity of the > technological ecosystem. Sure, I agree. Regards. --=20 I=C3=B1aki Baz Castillo From lists@infosecurity.ch Thu Mar 29 10:31:51 2012 Return-Path: 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 014C721E80F0 for ; Thu, 29 Mar 2012 10:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 yYZ3Ae+8D0+C for ; Thu, 29 Mar 2012 10:31:50 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1E8E21E8162 for ; Thu, 29 Mar 2012 10:31:49 -0700 (PDT) Received: by werb10 with SMTP id b10so1382097wer.31 for ; Thu, 29 Mar 2012 10:31:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=3hAwc4V+MOF4FaipHTWtZ4d9yk+LFHHk/5K+STeBz/I=; b=SZFOIanzj2f6uks52WgIq6hE2JNsiU3yTHi5TMOXvomDCDLtjKV5TWp4a72Hy0/2lL 2V+U9aDxbi1A60U9urAfSqfslwF9Ne5o6rkPMArhMtXHmlzyUpBfHbRoYtYZABX3mQlx 5OZfeOXagnqAsXLJHi9V5BAK5MW9vUXCL34GFf7TZCKGEG/DcGPNKOBPhcAoQSuBlmuh CNUjmSiJVNCJmrJEPKGtBTcb4Bvd7SVtT2uQUPB9+y4bH18UGGvmf1EVfi7FidE86Nno nOtDQrGotozDckE6Lr+lElIlXHllQUh+NU0X6G3vsMoGR7iDQn1ylc/XsTy9AD8ZUAK4 g5kA== Received: by 10.180.88.199 with SMTP id bi7mr7651249wib.12.1333042308929; Thu, 29 Mar 2012 10:31:48 -0700 (PDT) Received: from sonyvaiop13.local (93-57-41-37.ip162.fastwebnet.it. [93.57.41.37]) by mx.google.com with ESMTPS id fn2sm31263894wib.0.2012.03.29.10.31.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 10:31:47 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F749C82.4070305@infosecurity.ch> Date: Thu, 29 Mar 2012 19:31:46 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Ravindran, Parthasarathi" References: <4F732531.2030208@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkssiDMkFLZRJU/a6gc8tfW/wCFpqH6DCnCLIRg58sEXW9eVSdvJDaFNefbcN/JNj/EWlOg Cc: "" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:31:51 -0000 On 3/29/12 7:02 PM, Ravindran, Parthasarathi wrote: > WebRTC trust model has to be considered as one of the main factor for deciding the key mechanism. AFAIK, SDES does not fit into WebRTC as Dr.Evil HTTPS RTCWeb server must be trusted in case of SDES. There is no means to track or analyze whether Dr.Evil involves in monitoring or recording or terminate the media traffic. It will be good in case whoever advocate for SDES explain how SDES fits within WebRTC trust model. Sure! From: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/?include_text=1 " The basic assumption of this architecture is that network resources exist in a hierarchy of trust, rooted in the browser, which serves as the user's TRUSTED COMPUTING BASE (TCB). Any security property which the user wishes to have enforced must be ultimately guaranteed by the browser (or transitively by some property the browser verifies)." So, it means that if the browser already have a hierarchy of trust to use TLS for HTTPS, then SDES-SRTP will inherit the trust-properties of the HTTPS website from which it's loaded. It seems to me quite easy to fit SDES-SRTP into the browser model, as it allow you to assure that the communication path between the client and the server is secure. Do you expect WebRTC to be only peer-to-peer/client-to-client? I sincerly expect *a lot* of communications to goes trough SIP/RTP media proxy for security purpose, for billing purposes, for value added service purpose. SDES-SRTP provide a very reliable and simple way to let a WebRTC peer to establish security with the server, assuming that it already have established security trough HTTPS/TLS that's a consolidate trust method. -- Fabio Pietrosanti Founder, CTO Tel: +39 02 85961748 (direct) Mobile: +39 340 1801049 E-mail: fabio.pietrosanti@privatewave.com Skype: fpietrosanti Linkedin: http://linkedin.com/in/secret PrivateWave Italia S.p.A. Via Gaetano Giardino 1 - 20123 Milano - Italy www.privatewave.com From ibc@aliax.net Thu Mar 29 10:33:14 2012 Return-Path: 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 8E27A21F884F for ; Thu, 29 Mar 2012 10:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 WROs1nuqnKU1 for ; Thu, 29 Mar 2012 10:33:14 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9511621F8820 for ; Thu, 29 Mar 2012 10:33:13 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1951667vcb.31 for ; Thu, 29 Mar 2012 10:33:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=1EQ/xZM0VtmlgnGeK3it3OJ+u4XBQnBc7MsX/8ZbUe0=; b=nuL7ssQdF/CedQlKBKsFCbFh4ytV8elXFvD8JxUMpIgMOf1Pi0e23F54iKjoyg0br0 0xcVwTHjGkZqJMeNR3W9mcc59Te6CqToHD4ZqitazYUBb3XzWRhlEGJDPZgVyuoao7Hh JFgHIu6PmmaYIf3bq0pw8omTQqusPEMwNYBuyP52XyaPOUOlXriPygLwYCUcreTMLKDC 1HAOOaQXoxxkAx5t6B0lCP/n+idXNsQicOCNmbWMhy8EaimnyrkQ83M0FlHdNrNe17ck viqjUUvr7trHSlBvmy3gYTbjQMDJbS+KzJZ5R3CqceOcaoA2oQqiwDmZTN6O0hJF6wgY f0kA== Received: by 10.52.15.233 with SMTP id a9mr3022004vdd.34.1333042393159; Thu, 29 Mar 2012 10:33:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 29 Mar 2012 10:32:51 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> References: <4F732531.2030208@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 29 Mar 2012 19:32:51 +0200 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmjKhT1jQhgQZCahXLHdtiUmHqfNNys5a8egyjzxLTFA0hh0AAzFu6lqLerd1GhXKCnHsON Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:33:14 -0000 2012/3/29 Ravindran, Parthasarathi : > WebRTC trust model has to be considered as one of the main factor for dec= iding the key mechanism. AFAIK, SDES does not fit into WebRTC as Dr.Evil HT= TPS RTCWeb server must be trusted in case of SDES. There is no means to tra= ck or analyze whether Dr.Evil involves in monitoring or recording or termin= ate the media traffic. =C2=A0It will be good in case whoever advocate for S= DES explain how SDES fits within WebRTC trust model. If Dr. Evil attaks my back webpage and owns it, and then I visit it (HTTPS with valid certificate) and enter my back credentials... for me that is much worse than the case you describe. Should we drop HTTPS then because it does not fit 100% "security" requirements? BTW: previously you wanted to allow plain RTP in WebRTC... and now DTLS-SRTP is the only valid solution? :) --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Mar 29 10:34:36 2012 Return-Path: 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 BEE9321F881F for ; Thu, 29 Mar 2012 10:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 Db1nSM6Y4hyT for ; Thu, 29 Mar 2012 10:34:36 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D345721E801B for ; Thu, 29 Mar 2012 10:34:35 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1912720vbb.31 for ; Thu, 29 Mar 2012 10:34:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=yQbPSWCW2BP9XA4hpPfl2kKVJuf/zDnZ8Oi86BcPazc=; b=AHT/AuTtX20UR0X/qsMLdWKHEMt0NeNSOwUlo/ULEZwlbxwfdtf0e8iXxi1GLI7Sdw LZtVMweIwJThV9u1OBbB6tCHC4aoTx7itENcshdPFTABOSbjQneRgUUjK9My0XvCD7Tr J1Vy2oCcCgQoZSCIrk96VLy+lbaU54R2KabuqfszPXlDxzKuwM9+K6jVD0sIzv3fSsPu m0vhd3o4uinG8hjkWYVJhqpn7ehEWNmhpVBgMYb3zEF6HzFrK2NUJtwc9rLMbTrVgrqG 0lC1LFJiECi0YZpHDMkxfPlkJvbSUjeNYgxu8NonPSTYLb+kXl38fJD7qrg6gq55vqaG H/PA== Received: by 10.52.88.4 with SMTP id bc4mr3547154vdb.51.1333042475358; Thu, 29 Mar 2012 10:34:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 29 Mar 2012 10:34:15 -0700 (PDT) In-Reply-To: <4F749C82.4070305@infosecurity.ch> References: <4F732531.2030208@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> <4F749C82.4070305@infosecurity.ch> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 29 Mar 2012 19:34:15 +0200 Message-ID: To: "Fabio Pietrosanti (naif)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmqPNmVmKzJe+v8IeoPh0blFYiroHUjEagnLiu/jpB3zRWjPbkdVlWQ5rrWiCgndYaVeRGZ Cc: "" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:34:36 -0000 2012/3/29 Fabio Pietrosanti (naif) : > From: > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/?include_= text=3D1 > > " =C2=A0 The basic assumption of this architecture is that network resour= ces > =C2=A0 exist in a hierarchy of trust, rooted in the browser, which serves= as > =C2=A0 the user's TRUSTED COMPUTING BASE (TCB). =C2=A0Any security proper= ty which > =C2=A0 the user wishes to have enforced must be ultimately guaranteed by = the > =C2=A0 browser (or transitively by some property the browser verifies)." > > So, it means that if the browser already have a hierarchy of trust to > use TLS for HTTPS, then SDES-SRTP will inherit the trust-properties of > the HTTPS website from which it's loaded. > > It seems to me quite easy to fit SDES-SRTP into the browser model, as it > allow you to assure that the communication path between the client and > the server is secure. > > Do you expect WebRTC to be only peer-to-peer/client-to-client? > > I sincerly expect *a lot* of communications to goes trough SIP/RTP media > proxy for security purpose, for billing purposes, for value added > service purpose. > > SDES-SRTP provide a very reliable and simple way to let a WebRTC peer to > establish security with the server, assuming that it already have > established security trough HTTPS/TLS that's a consolidate trust method. +2 (I don't use "+1" since I don't use Google+). --=20 I=C3=B1aki Baz Castillo From lists@infosecurity.ch Thu Mar 29 10:56:52 2012 Return-Path: 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 4394021E8125 for ; Thu, 29 Mar 2012 10:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] 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 1vhRjwVcnByz for ; Thu, 29 Mar 2012 10:56:51 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6696C21E8117 for ; Thu, 29 Mar 2012 10:56:51 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so259023wib.13 for ; Thu, 29 Mar 2012 10:56:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:x-gm-message-state :content-type:content-transfer-encoding; bh=u5SGLP1fRrxkQGjxiqngfDWZmGkAQ53PJRIojIVTQn0=; b=SagXzZa/1mkvGqyYcydmHsFkoF/+ckbCzcBmRfYIyisTDnIXryRi8Vj2otQVcVYsw5 lEdLRGoljzW6wJ3RGCXURGIivqzHCtttiZ1MwvAimLVawBvcXHdgE6m91AU5OltXie6Z I5Twzw5ncY93B+fUtvXSJsypsS/4qaxLt/XhMighGeekD8plo8ks/ndUJ/l9iAS7CMjB OPBEs7PhuvGygHCUaxQ+nofJ+nKrVPPS4Hw9/AZdeTTcFFdQg/BcDvqBnj9lQBN0H9F1 1zETQlWqxD4wWl8RXkBGotCUrKZPV65MSrw9wuoAH/cJiDfWgivCaBu7TDjJCSFsPbcC TbtQ== Received: by 10.180.105.69 with SMTP id gk5mr9290713wib.3.1333043810391; Thu, 29 Mar 2012 10:56:50 -0700 (PDT) Received: from sonyvaiop13.local (93-57-41-37.ip162.fastwebnet.it. [93.57.41.37]) by mx.google.com with ESMTPS id b3sm68760917wib.4.2012.03.29.10.56.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 10:56:49 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F74A25F.1050901@infosecurity.ch> Date: Thu, 29 Mar 2012 19:56:47 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F732531.2030208@ericsson.com> <4F745719.5090709@ericsson.com> In-Reply-To: <4F745719.5090709@ericsson.com> X-Enigmail-Version: 1.4 X-Gm-Message-State: ALoCoQkn2bFnt/MOr6/d2r7ac+NRnlx1T7AGI68B6yzheQ3znraVgTPHfhP0Lnik8nPNf8DE6Hka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:56:52 -0000 On 3/29/12 2:35 PM, Magnus Westerlund wrote: > On 2012-03-29 08:02, Bernard Aboba wrote: >> I agree with proposition #1 (SRTP) unconditionally. >> >> With respect to proposition #2 (DTLS-SRTP), perhaps the words "with >> details to be worked out" should have been added. >> >> I believe that the consensus achieved was only on a general direction, >> not an endorsement of particular proposals. >> >> Personally, I would like to have more specifics about the required >> features of DTLS-SRTP in the RTCWEB context. > > I hope someone that knows the details can elaborate on this. I thought > DTLS-SRTP has a core that you will need to implement. Then there is > clearly a question of crypto algorithms to be supported. But that also > applies to SRTP where we also need to select which crypto suites that > are to be implemented if any in addtion to the MITM. The WG will need to > select these details as part of the next steps. Hi Magnus, imho the selection of a crypto algorithms is not the first priority (it will probably goes with some well known AES-stuff), as the first priority is to define which will be the Key Management system to be used for DTLS-SRTP. Given the SRTP standard,the security and trust model radically change depending on the key exchange system details. With DTLS-SRTP the key exchange and security/trust model seems quite opaque and there's not a specific guideline to implement it and/or to satisfy a specific security requirement. While the SDES-SRTP method satisfy all the 4.1.1.* Calling method requirement of http://tools.ietf.org/html/draft-ietf-rtcweb-security-02#section-4.1.1 , because it would just rely on existing TLS/HTTPS method. So it would not even enter into the context/discussion of trust with the server, that has been already managed by the existing TLS/HTTPS. I did not really understand how DTLS-SRTP would like to manage the so-many-complicated trust scenario that TLS/HTTPS already manage. Imho everything should be simplified with two context: - Do you need end-to-site (TLS equivalent) security? SDES-SRTP + TLS/HTTPS - Do you need end-to-end (ZRTP/PGP equivalent) security? DTLS-SRTP with user-driven verification schema (such as Short Authentication String / Fingerprint / Key pinning) -- Fabio Pietrosanti Founder, CTO Tel: +39 02 85961748 (direct) Mobile: +39 340 1801049 E-mail: fabio.pietrosanti@privatewave.com Skype: fpietrosanti Linkedin: http://linkedin.com/in/secret PrivateWave Italia S.p.A. Via Gaetano Giardino 1 - 20123 Milano - Italy www.privatewave.com From lists@infosecurity.ch Thu Mar 29 12:53:40 2012 Return-Path: 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 B827C21E801A for ; Thu, 29 Mar 2012 12:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Zv9kMZDCrQCB for ; Thu, 29 Mar 2012 12:53:37 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB1621E801F for ; Thu, 29 Mar 2012 12:53:34 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so328049wib.13 for ; Thu, 29 Mar 2012 12:53:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:x-gm-message-state:content-type :content-transfer-encoding; bh=TOMxUUTnHFbbSGQR75YfDAN7Ci8q5Utu9rx1lI7rV4A=; b=A/IhC2tQfLLBVlGdpjSvlzi1gldAj1D08nNLOCvupHQNIrTUABVOvwgWaS7PuYlkxU Bg8/ferE7nNd1vLrQ2jxUbaIUx/Zp3458BuIY/h/SE4iLTUVQUSJheVKULaaeJCtqITF TTNiJE1HYne79b5C/jC263HGd53wboR+8y+l0lS+VGMdJSCgmprpvFCTik1bq6abl61L 7Gp9WicNl616mOqvkbNNHMmtN8us5vFM8nPPs/0dgyOLL+6o6+rx3UQWdyMWh4qye7wT yC8GbVB/1Qv/gF/VoTbFwCr4jozXt82IDi19o6mbBTyyQpBOrANYLBb9b1+/Xtmq+8b3 WrlA== Received: by 10.180.101.230 with SMTP id fj6mr8764421wib.13.1333050814056; Thu, 29 Mar 2012 12:53:34 -0700 (PDT) Received: from sonyvaiop13.local (93-32-147-150.ip34.fastwebnet.it. [93.32.147.150]) by mx.google.com with ESMTPS id ff2sm32688146wib.9.2012.03.29.12.53.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 12:53:32 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F74BDBA.4020701@infosecurity.ch> Date: Thu, 29 Mar 2012 21:53:30 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "" X-Enigmail-Version: 1.4 X-Gm-Message-State: ALoCoQlFFHWu8bpXzREMfIrL4MJegTItn8WYHaD2kkvCsmi5QiUdSD9/jbC+HVDYho7EaxOq5yNA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [rtcweb] SDES-SRTP as a platform for multiple key management X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 19:53:40 -0000 Hi all, i've been thinking that one of the very interesting elements about the support of SDES-SRTP, is that, other than providing compatibility with existing telephony ecosystem, it may allow the implementation of custom key managegement systems. Basically if WebRTC would introduce support for SDES-SRTP and w3c would define API to handle SDES SDP call keys, it would become possible to further implement in Javascript additional key management systems. For example someone may implement a javascript application to be provided from an https source or browser extension additional to implement OpenPGPJS based identity verification (http://openpgpjs.org/) or integration with DH based key exchange (https://github.com/kaepora/cryptocat/). So basically a side-effect of introducing SDES-SRTP, could be to let HTML5 application developers, to effectively be able to implement custom security mechanisms for voice applications. -- Fabio Pietrosanti Founder, CTO Tel: +39 02 85961748 (direct) Mobile: +39 340 1801049 E-mail: fabio.pietrosanti@privatewave.com Skype: fpietrosanti Linkedin: http://linkedin.com/in/secret PrivateWave Italia S.p.A. Via Gaetano Giardino 1 - 20123 Milano - Italy www.privatewave.com From Markus.Isomaki@nokia.com Thu Mar 29 13:23:38 2012 Return-Path: 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 6B9EE21E80BE for ; Thu, 29 Mar 2012 13:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.099 X-Spam-Level: X-Spam-Status: No, score=-8.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 k2f+AIz7QpvK for ; Thu, 29 Mar 2012 13:23:38 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id C7DE121E805F for ; Thu, 29 Mar 2012 13:23:36 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2TKNU55023358 for ; Thu, 29 Mar 2012 23:23:31 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 23:23:29 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.245]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Thu, 29 Mar 2012 22:23:29 +0200 From: To: Thread-Topic: Data channel comments and questions Thread-Index: Ac0N59ezjOXJpyb5S8y3N1bZlLMXyA== Date: Thu, 29 Mar 2012 20:23:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [93.158.46.72] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Mar 2012 20:23:29.0863 (UTC) FILETIME=[CE05A570:01CD0DE9] X-Nokia-AV: Clean Subject: [rtcweb] Data channel comments and questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:23:38 -0000 Hi, Some comments on the data channel proposal: 1. Congestion control: If no real-time sessions are on, TCP-style loss-driv= en congestion control is fine. However, if voice/video session is up, such = congestion control would be disasterous to the real-time traffic quality if= sendind or receiving more than a slight amount of data. Especially in mobi= le access networks the user would bloat his/her own buffers very easily. In= that case, some less-than-best-effort congestion control algorithm =E1 la = LEDBAT would be required. It would be best to make this a MUST requirement = on implementations, otherwise we will get a lot of crappy video even if the= codec was better than H.261 :-) 2. Multihoming and interface switching: I don't suggest going for the multi= path support on the SCTP level. I think it would be best to deal with this = through ICE in the same way as for RTP, i.e. adding and removing candidates= as interfaces become available or go. Or let the application handle it by = creating a new data channel and continue from the breakpoint. The most impo= rtant requirement is that the application gets notified about these changes= downstrairs so it can act.=20 3. HTTP tunneling: In practice we are going to need HTTP tunneling last-res= ort option for the data channel as well. If doing so, what will the protoco= l stack look like? Is it SCTP/DTLS/UDP/HTTP/TLS/TCP? Or can we collapse som= e of these layers. I think we'd better. Markus=20 From ekr@rtfm.com Thu Mar 29 13:28:26 2012 Return-Path: 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 DC20821E80EF for ; Thu, 29 Mar 2012 13:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 kvjSFHkAl412 for ; Thu, 29 Mar 2012 13:28:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C149721E80CD for ; Thu, 29 Mar 2012 13:28:24 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2091137vcb.31 for ; Thu, 29 Mar 2012 13:28:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=yv6tk8c80t0xw+OCpV/D2mAItJlGg/J40pb9KM2AVtQ=; b=iiBkkK3fUoEhXeKb07dFKogbCLoyg/KdJN2eQhWxSpNtIt8C+eNXCK12jc18BVejIi NMGwv5g+yxni+p9P+UUdb1fHKhj28n7qJ3GnmSvfcvWrMBGCySS+e3zPBtgEj6ZyxGoo PwgrlYTOCutB5cSqFwItuK6QD6TmT4ehNoA8N0H94IIk8yYmV2XuVZMELrhKl/MM9Ou2 VjAU26YN8WAXiAzkYFPtrecxxsoqcfLHv1ukJ93wePwEXDJPzpoThZw7FKNtTm6vRZYI zstBLurFuHzlfS8bugXFPICuwmB7FRr0snqyatdMBtztXFjEzq4mqnF1/vOdc4MHpuWP LuQg== Received: by 10.52.173.38 with SMTP id bh6mr13733022vdc.43.1333052904331; Thu, 29 Mar 2012 13:28:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Thu, 29 Mar 2012 13:27:44 -0700 (PDT) X-Originating-IP: [2001:df8:0:80:5a55:caff:fef1:5a11] In-Reply-To: References: From: Eric Rescorla Date: Thu, 29 Mar 2012 22:27:44 +0200 Message-ID: To: Markus.Isomaki@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQngVF+nyL0qtjw6u6bdX9tTJn3J/pre7N8IySmofUyuUUfTlR0hVl3RcwWmyftEai1wH7yn Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Data channel comments and questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:28:27 -0000 On Thu, Mar 29, 2012 at 10:23 PM, wrote: > Hi, > > Some comments on the data channel proposal: > > 1. Congestion control: If no real-time sessions are on, TCP-style loss-dr= iven congestion control is fine. However, if voice/video session is up, suc= h congestion control would be disasterous to the real-time traffic quality = if sendind or receiving more than a slight amount of data. Especially in mo= bile access networks the user would bloat his/her own buffers very easily. = In that case, some less-than-best-effort congestion control algorithm =E1 l= a LEDBAT would be required. It would be best to make this a MUST requiremen= t on implementations, otherwise we will get a lot of crappy video even if t= he codec was better than H.261 :-) > > 2. Multihoming and interface switching: I don't suggest going for the mul= tipath support on the SCTP level. I think it would be best to deal with thi= s through ICE in the same way as for RTP, i.e. adding and removing candidat= es as interfaces become available or go. Or let the application handle it b= y creating a new data channel and continue from the breakpoint. The most im= portant requirement is that the application gets notified about these chang= es downstrairs so it can act. > > 3. HTTP tunneling: In practice we are going to need HTTP tunneling last-r= esort option for the data channel as well. If doing so, what will the proto= col stack look like? Is it SCTP/DTLS/UDP/HTTP/TLS/TCP? Or can we collapse s= ome of these layers. I think we'd better. I don't think I understand point 3. Why would we need HTTP tunneling? If we can bring up a bidirectional UDP channel, then why would we need to run HTTP over it? -Ekr From Markus.Isomaki@nokia.com Thu Mar 29 13:36:59 2012 Return-Path: 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 9425A21E80F5 for ; Thu, 29 Mar 2012 13:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.799 X-Spam-Level: X-Spam-Status: No, score=-7.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 aDxP3h1q1E7V for ; Thu, 29 Mar 2012 13:36:59 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id D059A21E80CD for ; Thu, 29 Mar 2012 13:36:58 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2TKauGS002981; Thu, 29 Mar 2012 23:36:57 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 23:36:55 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.245]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.01.0355.003; Thu, 29 Mar 2012 22:36:55 +0200 From: To: Thread-Topic: [rtcweb] Data channel comments and questions Thread-Index: Ac0N59ezjOXJpyb5S8y3N1bZlLMXyP//45QA///dtwA= Date: Thu, 29 Mar 2012 20:36:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [93.158.46.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Mar 2012 20:36:55.0905 (UTC) FILETIME=[AE75E510:01CD0DEB] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Data channel comments and questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:36:59 -0000 Hi, Eric Rescorla [mailto:ekr@rtfm.com] wrote: >> >> 3. HTTP tunneling: In practice we are going to need HTTP tunneling last- >resort option for the data channel as well. If doing so, what will the pro= tocol >stack look like? Is it SCTP/DTLS/UDP/HTTP/TLS/TCP? Or can we collapse some >of these layers. I think we'd better. > >I don't think I understand point 3. Why would we need HTTP tunneling? >If we can bring >up a bidirectional UDP channel, then why would we need to run HTTP over it= ? > Ah, sorry for not being clear. I mean a situation where we can't setup the = UDP channel, if one endpoint is for instance in a corporate network from wh= ere only HTTP or HTTPS is allowed. So presumably we'd have to support some = kind of HTTP or TLS encapsulation/tunneling for the data channel as well, f= rom the endpoint to some kind of relay. But how would the end-to-end data c= hannel look like then? I.e. what would be sent over the tunnel? >-Ekr Markus From ekr@rtfm.com Thu Mar 29 13:48:59 2012 Return-Path: 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 43A0F21F8643 for ; Thu, 29 Mar 2012 13:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 9v25FldkxSt4 for ; Thu, 29 Mar 2012 13:48:58 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 867C421F863B for ; Thu, 29 Mar 2012 13:48:58 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2106551vcb.31 for ; Thu, 29 Mar 2012 13:48:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=XjeYEIDVPMKaM4pbFle4PiXqhifJRKqEGIyhNFnkFMo=; b=miCl6a0XwcvOYHsr6HFSHHxaueK33RjtSFuuhxfFxaayXwMoNZUjti0IWNUO8N2W1+ 0glcV33nmW0+ccOFkHk75iM2tiTkmb1vR2W6F7HmEHC2EqhRyjQSBj7W4JIdqz0PjmVd Eb1XN8qr+al0Z0XGnhZaDMInyFGlOPQ18rQyuOppUTdIvBtNuKPaewhwFwTbIL+5BKCI A/lHhxWsiYx7/8xZOyfgjU58MbErKYbZQb/AzloqpoJLKSs8UwMmDMJwC9qADZaHmF4R Uce5BZNC6mX/z2ZCg6+wm2b1x4ToTHGH/xnonmWqWEDZkIwF5+1cMsT96kFlm2vsHIYU Fk/w== Received: by 10.52.26.103 with SMTP id k7mr14208586vdg.26.1333054138072; Thu, 29 Mar 2012 13:48:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Thu, 29 Mar 2012 13:48:17 -0700 (PDT) X-Originating-IP: [81.253.23.112] In-Reply-To: References: From: Eric Rescorla Date: Thu, 29 Mar 2012 22:48:17 +0200 Message-ID: To: Markus.Isomaki@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlPQhzTm7e6BWT6nCxRUwa+5IWCsJotRg5ZHS2+0f9bdg7Y9d4QE1kihV8mMpKF6rIvqZ4+ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Data channel comments and questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:48:59 -0000 On Thu, Mar 29, 2012 at 10:36 PM, wrote: > Hi, > > Eric Rescorla [mailto:ekr@rtfm.com] wrote: >>> >>> 3. HTTP tunneling: In practice we are going to need HTTP tunneling last= - >>resort option for the data channel as well. If doing so, what will the pr= otocol >>stack look like? Is it SCTP/DTLS/UDP/HTTP/TLS/TCP? Or can we collapse som= e >>of these layers. I think we'd better. >> >>I don't think I understand point 3. Why would we need HTTP tunneling? >>If we can bring >>up a bidirectional UDP channel, then why would we need to run HTTP over i= t? >> > > Ah, sorry for not being clear. I mean a situation where we can't setup th= e UDP channel, if one endpoint is for instance in a corporate network from = where only HTTP or HTTPS is allowed. So presumably we'd have to support som= e kind of HTTP or TLS encapsulation/tunneling for the data channel as well,= from the endpoint to some kind of relay. But how would the end-to-end data= channel look like then? I.e. what would be sent over the tunnel? I had sort of assumed that people would use that HTTP/HTTPS encapsulation o= nly to a relay which emitted UDP, so that that encapsulation wouldn't be end-to= -end in the general case. -Ekr From Markus.Isomaki@nokia.com Thu Mar 29 13:54:01 2012 Return-Path: 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 4590721F8731 for ; Thu, 29 Mar 2012 13:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Vvpf9NrnOPAE for ; Thu, 29 Mar 2012 13:54:00 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1712421F8732 for ; Thu, 29 Mar 2012 13:53:59 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2TKrqwV020218; Thu, 29 Mar 2012 23:53:55 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 23:53:51 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.245]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0355.003; Thu, 29 Mar 2012 22:53:51 +0200 From: To: Thread-Topic: [rtcweb] Data channel comments and questions Thread-Index: Ac0N59ezjOXJpyb5S8y3N1bZlLMXyP//45QA///dtwCAACgHgP//3iZg Date: Thu, 29 Mar 2012 20:53:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [93.158.46.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Mar 2012 20:53:51.0970 (UTC) FILETIME=[0C151C20:01CD0DEE] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Data channel comments and questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:54:01 -0000 Hi, Eric Rescorla wrote: > >I had sort of assumed that people would use that HTTP/HTTPS encapsulation >only to a relay which emitted UDP, so that that encapsulation wouldn't be >end-to-end in the general case. > Makes sense and now that I think of it, it's actually quite clear that it c= an be done in the same way as with TURN. But SCTP/DTLS would be e2e in any = case, and they'd be tunneled over HTTP/HTTPS (and TCP). Well, perhaps that'= s not so bad for the last resort case. >-Ekr Markus From Markus.Isomaki@nokia.com Thu Mar 29 14:04:47 2012 Return-Path: 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 1334721F85D3 for ; Thu, 29 Mar 2012 14:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.456 X-Spam-Level: X-Spam-Status: No, score=-7.456 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Y9FU62RlC7p1 for ; Thu, 29 Mar 2012 14:04:46 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id BD7CC21F85D1 for ; Thu, 29 Mar 2012 14:04:43 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2TL4XUT012616 for ; Fri, 30 Mar 2012 00:04:41 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 00:04:34 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.245]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Thu, 29 Mar 2012 23:04:34 +0200 From: To: Thread-Topic: [rtcweb] Data channel comments and questions Thread-Index: Ac0N59ezjOXJpyb5S8y3N1bZlLMXyP//45QA///dtwD//7aiUA== Date: Thu, 29 Mar 2012 21:04:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [93.158.46.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Mar 2012 21:04:34.0909 (UTC) FILETIME=[8B4DD0D0:01CD0DEF] X-Nokia-AV: Clean Subject: Re: [rtcweb] Data channel comments and questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:04:47 -0000 > >Ah, sorry for not being clear. I mean a situation where we can't setup the= UDP >channel, if one endpoint is for instance in a corporate network from where >only HTTP or HTTPS is allowed. So presumably we'd have to support some kin= d >of HTTP or TLS encapsulation/tunneling for the data channel as well, from = the >endpoint to some kind of relay. But how would the end-to-end data channel >look like then? I.e. what would be sent over the tunnel? > There's by the way at least one other use case where UDP-based data channel= sucks. If you want to keep it up for a long time for some infrequent messa= ging, keeping the NAT state up by a keepalive every ~30s. would drain the b= attery on a mobile device. To solve that case some kind of TCP-based varian= t would be needed, at least between the mobile endpoint and a relay. TURN-T= CP, I guess. If the other end was still using UDP and doing frequent keepal= ives, I suppose the relay would unfortunately forward them as well causing = the same ill effect.=20 I'm not sure if there are apps that would need to keep the data channel up = infrequently used, though. Or should they just use the "signaling" path (HT= TP, websockets) for that type of purposes.=20 Markus=20 From oscar.ohlsson@ericsson.com Thu Mar 29 14:13:43 2012 Return-Path: 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 223AB21E804A for ; Thu, 29 Mar 2012 14:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.835 X-Spam-Level: X-Spam-Status: No, score=-9.835 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 5CgMBt5oEtk8 for ; Thu, 29 Mar 2012 14:13:42 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B3AD821E8028 for ; Thu, 29 Mar 2012 14:13:33 -0700 (PDT) X-AuditID: c1b4fb3d-b7b5aae000002dcb-37-4f74d07b7023 Authentication-Results: mailgw10.se.ericsson.net x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA) Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F4.63.11723.B70D47F4; Thu, 29 Mar 2012 23:13:32 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.51]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 29 Mar 2012 23:13:31 +0200 From: Oscar Ohlsson To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Thu, 29 Mar 2012 23:13:30 +0200 Thread-Topic: [rtcweb] Support of SDES in WebRTC Thread-Index: Ac0NwVWL/pAf3KWyRBuDtl/dfJ3iTAALdbdg Message-ID: References: <4F742344.802@infosecurity.ch> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [rtcweb] Support of SDES in WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:13:43 -0000 Hi, That's why I wrote "the entire webapp" below. If it was not clear I meant t= hat the - main HTML page - all external CSS files, JavaScript files, images, etc=20 - all XmlHttpRequests - all WebSocket connections are protected with TLS. This is obviously verifiable and it's a feature sup= ported by all modern browsers (no mixed content).=20 /Oscar > -----Original Message----- > From: I=F1aki Baz Castillo [mailto:ibc@aliax.net]=20 > Sent: Thursday, March 29, 2012 5:33 PM > To: Oscar Ohlsson > Cc: Fabio Pietrosanti (naif); > Subject: Re: [rtcweb] Support of SDES in WebRTC >=20 > 2012/3/29 Oscar Ohlsson : > > Hi Fabio, > > > > My assumption has always been the following: > > > > - DTLS-SRTP is the default > > - DTLS-SRTP + identity can be turned on via the JavaScript=20 > API if the=20 > > webapp wishes to do so > > - SDES can be turned on by a manipulated SDP offer/answer=20 > provided the=20 > > entire webapp was retrieved over HTTPS >=20 > Please check this mail in which I explain that retrieving the=20 > web app by means of HTTPS means nothing: >=20 > http://www.ietf.org/mail-archive/web/rtcweb/current/msg03914.html >=20 >=20 >=20 > -- > I=F1aki Baz Castillo > > = From oscar.ohlsson@ericsson.com Thu Mar 29 14:23:11 2012 Return-Path: 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 4A7DF21E801F for ; Thu, 29 Mar 2012 14:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.848 X-Spam-Level: X-Spam-Status: No, score=-7.848 tagged_above=-999 required=5 tests=[AWL=-1.599, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 NNP0RYIHa6T8 for ; Thu, 29 Mar 2012 14:23:10 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 15E0021E801A for ; Thu, 29 Mar 2012 14:23:09 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-99-4f74d2bc735b Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA) Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6F.B5.25560.CB2D47F4; Thu, 29 Mar 2012 23:23:08 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.51]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 29 Mar 2012 23:23:07 +0200 From: Oscar Ohlsson To: "Fabio Pietrosanti (naif)" Date: Thu, 29 Mar 2012 23:23:07 +0200 Thread-Topic: [rtcweb] SDES-SRTP as a platform for multiple key management Thread-Index: Ac0N5aWeoPueFkFHTg+96UfvCqhAjQAC0myQ Message-ID: References: <4F74BDBA.4020701@infosecurity.ch> In-Reply-To: <4F74BDBA.4020701@infosecurity.ch> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [rtcweb] SDES-SRTP as a platform for multiple key management X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:23:11 -0000 Hi, While I'm in favour of SDES I don't believe this is a particularly strong a= rgument. To provide any real security gain, any additional signing or encry= ption that you may think of has to be performed outside of the webapp's con= trol. Regards, Oscar > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Fabio Pietrosanti (naif) > Sent: Thursday, March 29, 2012 9:54 PM > To: > Subject: [rtcweb] SDES-SRTP as a platform for multiple key management >=20 > Hi all, >=20 > i've been thinking that one of the very interesting elements=20 > about the support of SDES-SRTP, is that, other than providing=20 > compatibility with existing telephony ecosystem, it may allow=20 > the implementation of custom key managegement systems. >=20 > Basically if WebRTC would introduce support for SDES-SRTP and=20 > w3c would define API to handle SDES SDP call keys, it would=20 > become possible to further implement in Javascript additional=20 > key management systems. >=20 > For example someone may implement a javascript application to=20 > be provided from an https source or browser extension=20 > additional to implement OpenPGPJS based identity verification=20 > (http://openpgpjs.org/) or integration with DH based key=20 > exchange (https://github.com/kaepora/cryptocat/). >=20 > So basically a side-effect of introducing SDES-SRTP, could be to let > HTML5 application developers, to effectively be able to=20 > implement custom security mechanisms for voice applications. >=20 > -- > Fabio Pietrosanti > Founder, CTO >=20 > Tel: +39 02 85961748 (direct) > Mobile: +39 340 1801049 > E-mail: fabio.pietrosanti@privatewave.com > Skype: fpietrosanti > Linkedin: http://linkedin.com/in/secret >=20 > PrivateWave Italia S.p.A. > Via Gaetano Giardino 1 - 20123 Milano - Italy=20 > www.privatewave.com _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From ibc@aliax.net Thu Mar 29 14:54:05 2012 Return-Path: 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 8380621F8738 for ; Thu, 29 Mar 2012 14:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 kq7S8v2gMdzf for ; Thu, 29 Mar 2012 14:54:05 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB62921F8736 for ; Thu, 29 Mar 2012 14:54:04 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2324vcb.31 for ; Thu, 29 Mar 2012 14:53:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=/YEckP9iHmlVvHJFnYoUg+lnLs5o4VrSINWX4otvRJU=; b=c35XDi9Wm/tfOWdgeAApBf6zKdZb7XBf/oojR7aJUrLlvFikaA9xRkSzI02nPq8tgA K0PjmppTpuVLZ9b2XVrTLmJU0iZSg7JfA8oO/jtXthHizI7iuQp1y8ir3GbEFkTA2CTc CN3AnOieLFzoK7+X3ja9jpvMakFNg1lZmj3gmbjdOeuYGmu7s9a+9l2YV6skGlygJdkr JiEca+wz6YQkAoyQPzwb0CJK312KDFutcriltKvNiagahWQrPNuObLPVpgiYTSlGmc4I j6TDyMC7H0lkq0EQxq7qY51QospLVxiolWjH2miS2L3jtxErLUCCLtqgFfRzLn7apisy UN8w== Received: by 10.220.152.205 with SMTP id h13mr939946vcw.12.1333058039233; Thu, 29 Mar 2012 14:53:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 29 Mar 2012 14:53:39 -0700 (PDT) In-Reply-To: References: <4F742344.802@infosecurity.ch> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 29 Mar 2012 23:53:39 +0200 Message-ID: To: Oscar Ohlsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQknldaOioyho5tokxuIPL6O/AhhD0ulziQJ2dVpKfigEKfQH1bSp8C0lD4LfcjuwfKbmB0y Cc: "" Subject: Re: [rtcweb] Support of SDES in WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:54:05 -0000 2012/3/29 Oscar Ohlsson : > Hi, > > That's why I wrote "the entire webapp" below. If it was not clear I meant= that the > > - main HTML page > - all external CSS files, JavaScript files, images, etc > - all XmlHttpRequests > - all WebSocket connections > > are protected with TLS. This is obviously verifiable and it's a feature s= upported by all modern browsers (no mixed content). Good point. --=20 I=C3=B1aki Baz Castillo From gmaxwell@juniper.net Thu Mar 29 14:59:21 2012 Return-Path: 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 6BD2421E8050 for ; Thu, 29 Mar 2012 14:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 6HOrPFvrvN5D for ; Thu, 29 Mar 2012 14:59:20 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id A59C121E802A for ; Thu, 29 Mar 2012 14:59:20 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT3TbNdROHEisdRJ2o4CQ1TwMuWev1oW7@postini.com; Thu, 29 Mar 2012 14:59:20 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 29 Mar 2012 14:59:03 -0700 From: Gregory Maxwell To: Oscar Ohlsson , =?Windows-1252?Q?I=F1aki_Baz_Castillo?= Date: Thu, 29 Mar 2012 14:59:03 -0700 Thread-Topic: [rtcweb] Support of SDES in WebRTC Thread-Index: Ac0NwVWL/pAf3KWyRBuDtl/dfJ3iTAALdbdgAAFEo7Y= Message-ID: References: <4F742344.802@infosecurity.ch> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Support of SDES in WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:59:21 -0000 Oscar Ohlsson [oscar.ohlsson@ericsson.com] wrote: > That's why I wrote "the entire webapp" below. If it was not clear I meant= that the > - main HTML page > - all external CSS files, JavaScript files, images, etc > - all XmlHttpRequests > - all WebSocket connections > are protected with TLS. This is obviously verifiable and it's a feature s= upported by all modern browsers (no mixed content). Even this is insufficient. First, even if it is in principle possible to provide adequate cryptographic security inside the JS applications a great many of them won't (for many reasons). We can't eliminate inconsistency in the security of webrtc applications=97 but we can certainly make it hard to go below a certain level of security especially by accident. In particular, if JS applications provide only authentication services (e.g. by giving them access to hashes of the ephemeral session keys, but not the session keys themselves) then a cryptographically-incompetent application can only fail the user by failing to provide the authentication it promised over and above the platform baseline capability. With HTTPS applications are currently free to do dumb things (mixed content, esp scripts) but at least the browser can detected this and alerts the user with varying degrees of loudness. In a SDES/SRTP world the browser will not be generally able to detect insecure behavior by applications=97 creating something of a lemon market for webrtc based application security. As a resutl its important to narrow the amount of insecurity possible. This is effectively a repeat of the arguments against supporting plaintext. If plaintext is supported it will be commonly used because it's easiest, because users can't easily tell how insecure their connection is, and because users often don't have a good feel for the threat model (e.g. things like firesheep were _very_ surprising to most people)... Because of this the platform should provide the highest level of security that can reasonably be provided in the platform, and that means (among other things) perfect-forward-secrecy=97 while allowing applications to add things like authentication on top (because while strong ephemerally keyed crypto can be done very low in the stack, meaningful authentication needs layer-7/8 hooks). There is also the application/library split issue=97 if a vulnerability is found in a common negotiation procedure what secures users better? Updating a few easily identified browsers / softphone apps? or a much larger base of webapps, many of which would be run by security ignorant/clueless people? (and at least if the webserver is clueful but the client operator is not the app could yell about the insecure client, the other way around doesn't work as well). =97 Really, cryptographic negotiation is not properly an application feature, it belongs lower in the stack, and many applications that roll their own crypto have done a poor job of it. It's also inadequate on purely technical grounds: Javascript provides no mechanism for working with mlocked memory, no mechanism to ensure that garbage collected data gets zeroized. Your crypto app in JS could easily have its long term keying material pulled out of free ram by malware long after it runs, or pulled off the disk from swap. The breakneck pace of fancy JIT systems makes it seem unlikely to me that javascript will provide for that any time soon. From randell-ietf@jesup.org Thu Mar 29 15:00:05 2012 Return-Path: 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 2FB7C21E802A for ; Thu, 29 Mar 2012 15:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599] 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 uIx2DTkNaMXF for ; Thu, 29 Mar 2012 15:00:04 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 75D8321F85C9 for ; Thu, 29 Mar 2012 14:59:59 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SDNNv-0000bu-2i for rtcweb@ietf.org; Thu, 29 Mar 2012 16:59:59 -0500 Message-ID: <4F74DAA1.4080103@jesup.org> Date: Thu, 29 Mar 2012 17:56:49 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> <4F73B2B6.9080008@jesup.org> <6493BD08-5A9B-48AB-8D5C-8778384948A3@acmepacket.com> In-Reply-To: <6493BD08-5A9B-48AB-8D5C-8778384948A3@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 22:00:05 -0000 On 3/29/2012 2:08 AM, Hadriel Kaplan wrote: > On Mar 29, 2012, at 2:54 AM, Randell Jesup wrote: > >> That doesn't mean I don't want to implement a truly secure communications ability. Note that by "secure" here I mean "I can detect if the service MITMd me" -- without reading cert phrases and preferably without having to install client certs and somehow build a working PKI. >> One idea we've had is a non-centralized WebRTC service built on distributed hash tables and a partial-mesh set of connections used to pass signaling on WebRTC (or other) data channels to set up calls, with some type of Id system to validate who you get connected to (since you can't really trust any of the nodes fully). If an intermediary node can downgrade you to SDES and sniff the keys, there is no security. > If you use SDES, no one should be claiming you *have* end-to-end security. You have security from the browser to the HTTPS server, but nothing more. The browser shouldn't be showing a lock icon, for example (and it shouldn't for DTLS-SRTP either). Since the media potentially goes into the PSTN, it can be no more secure than that. No matter how much stronger we make the Browser-to-Gateway link, the end-to-end can't exceed the PSTN's level of security. It's reasonably sufficient security for everyday use, but it won't let you bypass the government. And using DTLS-SRTP to a gateway won't either. And arguably even using IdP won't if the government can force the IdP to lie. Total agreement. SDES cannot be touted as secure. It's more secure against sniffers; that's all. >> An alternative would be to allow a hybrid: SDES at the start of a call and rekey over to DTLS-SRTP after the call is connected. If something blocks the DTLS connection it would be treated as a gateway-to-legacy/PSTN call (i.e. show no security, though it's secure against non-in-path attackers); if the DTLS connection is allowed, we can use it to rekey to DTLS-SRTP and to verify identity. > Why bother? I assume the concern is a bid-down. Let's imagine we were dealing with a malicious website, and the website javascript removed DTLS-SRTP from SDP but put in SDES, so that browser believes it's talking to a gateway and uses SDES. The malicious website now has your SRTP key and can decrypt your media, assuming it has some access to your media. So you build a better browser and try an active check for DTLS-SRTP in the media plane regardless of SDP. If your browser is popular, why wouldn't the malicious website just insert a DTLS-SRTP b2bua gateway, and still be able to listen in? This allows avoiding a gateway ('burning gateway' argument) with PSTN calls while minimizing the risk of bid-down. Note, correctly, that you need Identity+DTLS-SRTP to be secure against in-signaling-path attackers (providers or governments). That's not of no benefit. It's not of real benefit to J. Random Salesman, but even non-political people may worry about someone watching in more than they worry about listening in. (#include lawsuits over schools using laptop computers to take snapshots from student computers at home, etc, etc). > As far as I can see, there is no bid-down issue created by adding SDES - it was already there. It was already possible to insert a DTLS-SRTP B2BUA and be malicious. Yes, we may have made it slightly cheaper to be malicious, but it was already possible. The only thing that prevents a malicious website's DTLS-SRTP B2BUA from working is if then humans verify the fingerprints or having an IdP you can trust. Even if you *do* verify the fingerprints and find they do NOT match, all you know is it went through one or more gateways in the middle - you don't know it's malicious - it could just be going through the PSTN legitimately. Video doesn't go through the PSTN... That's a kinda obvious downgrade. And only people who care will note the insecurity; part of why it must be dead-simple but not overly intrusive (no doorhangers, etc). This is W3C land though, mostly. This just comes back to the argument over whether users care. Some do, and most of them are non-technical. Identity doesn't provide perfect security. It does provide better security and at least makes any tapper be concerned that they're raising red flags, if the person notices/cares. I guarantee the Tunisian rebels/activists mentioned by Tim would care. > With SDES the browser can indicate right-off-the-bat that the call is not end-to-end secure, without having to show the fingerprint and having the user read it out. True :-) >> This minimizes the risk of bid-down - the primary additional risk is that without initial SDES, to tap the signal you'd need to use a WebRTC-enabled B2BUA to accept the DTLS-SRTP connection and siphon it off. Also, a "good" gateway in a pure DTLS-SRTP world might have a identity established ("gateway@L3.com"); with SDES it wouldn't by default (but it could if it wanted to by rekeying via DTLS also). > Yeah I've been trying to figure out if there's some advantage to having a gateway be able to indicate "gateway@telco.com", once there is an IdP model. I would think it's a major pita to deploy such a thing on gateways, unless there's a very popular IdP they could know everyone would trust. It would actually be easier to just give the gateway a real TLS cert for DTLS to use, from a major CA, since gateways are the types of systems real certs would be reasonably possible to install on. > > >> I'm still strongly in favor of pure DTLS-SRTP - as Harald and others say, less moving parts and less things that need to be secured. But this might be a useful compromise if we *need* to support SDES in some cases. > I'm trying to be convinced that DTLS-SRTP is worth the complexity, cost and downsides on the gateways, but I haven't found it yet. I think people are willing to be convinced, myself included, but I have yet to hear a real advantage for DTLS-SRTP in the gateway scenario. Everything put forward today for DTLS-SRTP applied to the browser-to-browser scenarios, but not gateways. Whereas I come at it from "I care about browser-to-browser cases and avoiding doing something that hurts them, and I don't care about security (other than sniffers) for gateway calls". :-) -- Randell Jesup randell-ietf@jesup.org From tterriberry@mozilla.com Thu Mar 29 17:58:58 2012 Return-Path: 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 C049721E808A for ; Thu, 29 Mar 2012 17:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LuUhQAOeDoO9 for ; Thu, 29 Mar 2012 17:58:57 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 817B821E8086 for ; Thu, 29 Mar 2012 17:58:17 -0700 (PDT) Received: from [130.129.69.85] (dhcp-4555.meeting.ietf.org [130.129.69.85]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id C9DBF4AEE7C for ; Thu, 29 Mar 2012 17:58:15 -0700 (PDT) Message-ID: <4F750525.9030806@mozilla.com> Date: Thu, 29 Mar 2012 17:58:13 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> <4F73B2B6.9080008@jesup.org> <6493BD08-5A9B-48AB-8D5C-8778384948A3@acmepacket.com> <4F74DAA1.4080103@jesup.org> In-Reply-To: <4F74DAA1.4080103@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 00:58:58 -0000 Randell Jesup wrote: >> Everything put forward today for DTLS-SRTP applied to the >> browser-to-browser scenarios, but not gateways. > > Whereas I come at it from "I care about browser-to-browser cases and > avoiding doing something that hurts them, and I don't care about > security (other than sniffers) for gateway calls". :-) And the difficulty is, a browser has no way to tell (a priori) when the other end is another browser or a gateway. From roman@telurix.com Thu Mar 29 20:30:00 2012 Return-Path: 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 C45DA21F86BA for ; Thu, 29 Mar 2012 20:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 gxgS-Va5nC4s for ; Thu, 29 Mar 2012 20:30:00 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1CB121F86B6 for ; Thu, 29 Mar 2012 20:29:59 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1051489pbb.31 for ; Thu, 29 Mar 2012 20:29:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-gm-message-state:content-type; bh=zcFmGmN5ino8f55PlLb9+NBb/F861CdFlDycGAwO9F0=; b=colhwiMXYQay6vaoW3GkZX1KRpDK37J3UT+Ks2jRo0zAv0ZzlYG4bPQs7xrWwhZt+D UgNhoGKoE8xxc8ZpbFNzO3zqsVxm4/SaU6THsztqsiEOIXsq+vbdXRA/FqkqLQKGjwle Zs+2+N/s2dMp+hHozfY6nZjdJ6HuGd8Tlp6fI86rKBom9HVoZ7lIl0sBgmmJ1DF8Sj0N WoiMQTdv3yyeqlU017BeqXoWDul36zgAX+9Hi3rP65pQsjHJAbIuUPm5PUp1774Y+pcC X1pFMcAuZVyqwnI+0sh24LkfBn8otB3VtDXv2/GoTFoBvKr6r+cBwqPclOgZGjhJndp5 D73A== Received: by 10.68.234.134 with SMTP id ue6mr5434577pbc.14.1333078199709; Thu, 29 Mar 2012 20:29:59 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id i1sm6358918pbj.70.2012.03.29.20.29.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 20:29:58 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1051459pbb.31 for ; Thu, 29 Mar 2012 20:29:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.196.163 with SMTP id in3mr5481157pbc.118.1333078198064; Thu, 29 Mar 2012 20:29:58 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 29 Mar 2012 20:29:58 -0700 (PDT) In-Reply-To: References: <4F742344.802@infosecurity.ch> Date: Thu, 29 Mar 2012 23:29:58 -0400 Message-ID: From: Roman Shpount To: Gregory Maxwell X-Gm-Message-State: ALoCoQmKRc/7UQtfJuUZ7VvKUNUZ6wuWvykPD6l+VD+IDnfURCldX16pEEC/ZOps7VZjqamfPOPc Content-Type: multipart/alternative; boundary=e89a8ff1c65a7415ad04bc6d7467 Cc: "" Subject: Re: [rtcweb] Support of SDES in WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 03:30:00 -0000 --e89a8ff1c65a7415ad04bc6d7467 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2012 at 5:59 PM, Gregory Maxwell wrot= e: > Even this is insufficient. > > First, even if it is in principle possible to provide adequate > cryptographic security inside the JS applications a great many of them > won't (for many reasons). We can't eliminate inconsistency in the securit= y > of webrtc applications=97 but we can certainly make it hard to go below > a certain level of security especially by accident. In particular, > if JS applications provide only authentication services (e.g. by giving > them access to hashes of the ephemeral session keys, but not the session > keys themselves) then a cryptographically-incompetent application can > only fail the user by failing to provide the authentication it promised > over and above the platform baseline capability. > > With HTTPS applications are currently free to do dumb things (mixed > content, esp scripts) but at least the browser can detected this and > alerts the user with varying degrees of loudness. In a SDES/SRTP > world the browser will not be generally able to detect insecure > behavior by applications=97 creating something of a lemon market > for webrtc based application security. As a resutl its important to > narrow the amount of insecurity possible. > > This is effectively a repeat of the arguments against supporting > plaintext. If plaintext is supported it will be commonly used because it'= s > easiest, because users can't easily tell how insecure their connection > is, and because users often don't have a good feel for the threat model > (e.g. things like firesheep were _very_ surprising to most people)... > Because of this the platform should provide the highest level of security > that can reasonably be provided in the platform, and that means (among > other things) perfect-forward-secrecy=97 while allowing applications to > add things like authentication on top (because while strong ephemerally > keyed crypto can be done very low in the stack, meaningful authentication > needs layer-7/8 hooks). > > There is also the application/library split issue=97 if a vulnerability > is found in a common negotiation procedure what secures users > better? Updating a few easily identified browsers / softphone apps? > or a much larger base of webapps, many of which would be run by security > ignorant/clueless people? (and at least if the webserver is clueful but > the client operator is not the app could yell about the insecure client, > the other way around doesn't work as well). =97 Really, cryptographic > negotiation is not properly an application feature, it belongs lower in > the stack, and many applications that roll their own crypto have done > a poor job of it. > > It's also inadequate on purely technical grounds: Javascript provides > no mechanism for working with mlocked memory, no mechanism to ensure > that garbage collected data gets zeroized. Your crypto app in JS could > easily have its long term keying material pulled out of free ram by > malware long after it runs, or pulled off the disk from swap. > The breakneck pace of fancy JIT systems makes it seem unlikely to me > that javascript will provide for that any time soon. > > I guess what you are saying (and I believe everybody on this list agree) is that SDES-SRTP in combination with JavaScript signaling negotiation does not and cannot provide any meaningful security above preventing simple network sniffing. _____________ Roman Shpount --e89a8ff1c65a7415ad04bc6d7467 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 29, 2012 at 5:59 P= M, Gregory Maxwell <gmaxwell@juniper.net> wrote:
Even this is insufficient.

First, even if it is in principle possible to provide adequate
cryptographic security inside the JS applications a great many of them
won't (for many reasons). We can't eliminate inconsistency in the s= ecurity
of webrtc applications=97 but we can certainly make it hard to go below
a certain level of security especially by accident. =A0 In particular,
if JS applications provide only authentication services (e.g. by giving
them access to hashes of the ephemeral session keys, but not the session keys themselves) then a cryptographically-incompetent application can
only fail the user by failing to provide the authentication it promised
over and above the platform baseline capability.

With HTTPS applications are currently free to do dumb things (mixed
content, esp scripts) but at least the browser can detected this and
alerts the user with varying degrees of loudness. =A0In a SDES/SRTP
world the browser will not be generally able to detect insecure
behavior by applications=97 creating something of a lemon market
for webrtc based application security. As a resutl its important to
narrow the amount of insecurity possible.

This is effectively a repeat of the arguments against supporting
plaintext. If plaintext is supported it will be commonly used because it= 9;s
easiest, because users can't easily tell how insecure their connection<= br> is, and because users often don't have a good feel for the threat model=
(e.g. things like firesheep were _very_ surprising to most people)...
Because of this the platform should provide the highest level of security that can reasonably be provided in the platform, and that means (among
other things) perfect-forward-secrecy=97 while allowing applications to
add things like authentication on top (because while strong ephemerally
keyed crypto can be done very low in the stack, meaningful authentication needs layer-7/8 hooks).

There is also the application/library split issue=97 if a vulnerability
is found in a common negotiation procedure what secures users
better? Updating a few easily identified browsers / softphone apps?
or a much larger base of webapps, many of which would be run by security ignorant/clueless people? =A0(and at least if the webserver is clueful but<= br> the client operator is not the app could yell about the insecure client, the other way around doesn't work as well). =A0=97 =A0 Really, cryptogr= aphic
negotiation is not properly an application feature, it belongs lower in
the stack, and many applications that roll their own crypto have done
a poor job of it.

It's also inadequate on purely technical grounds: Javascript provides no mechanism for working with mlocked memory, =A0no mechanism to ensure
that garbage collected data gets zeroized. =A0Your crypto app in JS could easily have its long term keying material pulled out of free ram by
malware long after it runs, or pulled off the disk from swap.
The breakneck pace of fancy JIT systems makes it seem unlikely to me
that javascript will provide for that any time soon.


I guess what you are sayin= g (and I believe everybody on this list agree) is that SDES-SRTP in combina= tion with JavaScript signaling negotiation does not and cannot provide any = meaningful security above preventing simple network sniffing.
_____________
Roman Shpount

--e89a8ff1c65a7415ad04bc6d7467-- From lists@infosecurity.ch Fri Mar 30 00:30:05 2012 Return-Path: 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 87A6421F860E for ; Fri, 30 Mar 2012 00:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 s+TMn2tpwWpc for ; Fri, 30 Mar 2012 00:30:04 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 826A121F8742 for ; Fri, 30 Mar 2012 00:30:03 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so435553wib.1 for ; Fri, 30 Mar 2012 00:30:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-gm-message-state :content-type:content-transfer-encoding; bh=YFcd9vFHuhZWOKImAx5ojdXLnbAQSdCpqJGcsUUAj1s=; b=YlxTDrDx5rhvAI3cnenSN5pli63j/oT4KqvG9x09MLzWW0m7Hifa/vk2lPjjfyK9cV 6BdoAEuHtrouNmz0pUfq0fkIn2LUfiNf+mumB4PAkfWPkOBj5gWhxw50rCvyti139JVP zGqgWupH1eT08voCNPlqtpwJySO69PUmswbgZviFzN+wetCHC813v4OAvVC6NQ6tUxO/ zci/XzSYBKA0D7hBnkbmmkVJ2/7HFzPU2if97TCelKPHUTN+oeLjX52xAN9qDaxyLD5p ggvdgE4axzSumrjLUXSgHhJZznSCFxp7dhWsZkfA4YY7xS6+NfM/vxGKFudWuyNgTnuD fYaQ== Received: by 10.180.107.104 with SMTP id hb8mr3638122wib.8.1333092603158; Fri, 30 Mar 2012 00:30:03 -0700 (PDT) Received: from sonyvaiop13.local (93-32-152-119.ip34.fastwebnet.it. [93.32.152.119]) by mx.google.com with ESMTPS id ex2sm6804615wib.8.2012.03.30.00.30.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Mar 2012 00:30:01 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F7560F8.8030701@infosecurity.ch> Date: Fri, 30 Mar 2012 09:30:00 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Oscar Ohlsson References: <4F74BDBA.4020701@infosecurity.ch> In-Reply-To: X-Enigmail-Version: 1.4 X-Gm-Message-State: ALoCoQlA31Zy3kzl8SAkNHyk+548UoNGZZs5E1YouPGmJNZamymYkujwS4JBTAq2V4pr4pWuE9bM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [rtcweb] SDES-SRTP as a platform for multiple key management X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:30:05 -0000 Hi Oscar, i totally agree that it's not one of the stronger argument, however when a technology is open and will let third party to work on it, third party WILL work on it applying their creativity. I am confident that we would see inside the crypto-nerds environments a lot of JS-based key management extensions to extend SDES with customer crypto semantic. Then, for security purpose, this must be done outside the webapp, and this can be done in many way such as: - Javascript written browser plugin - Javascript pinned to Browser Cache - Locally loaded javascript Javascript encryption is the next frontieer for Web security and there's a lot of work from that side also from browser manufacturer (DOMCrypt, JS-signing, JS RNG, etc) to provide secure crypto. We are in 2012 and if we speak of an argument that Browser+Crypto we just cannot not consider that Javascript will have a role in that context, one way or another way. Fabio On 3/29/12 11:23 PM, Oscar Ohlsson wrote: > Hi, > > While I'm in favour of SDES I don't believe this is a particularly strong argument. To provide any real security gain, any additional signing or encryption that you may think of has to be performed outside of the webapp's control. > > Regards, > > Oscar > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Fabio Pietrosanti (naif) >> Sent: Thursday, March 29, 2012 9:54 PM >> To: >> Subject: [rtcweb] SDES-SRTP as a platform for multiple key management >> >> Hi all, >> >> i've been thinking that one of the very interesting elements >> about the support of SDES-SRTP, is that, other than providing >> compatibility with existing telephony ecosystem, it may allow >> the implementation of custom key managegement systems. >> >> Basically if WebRTC would introduce support for SDES-SRTP and >> w3c would define API to handle SDES SDP call keys, it would >> become possible to further implement in Javascript additional >> key management systems. >> >> For example someone may implement a javascript application to >> be provided from an https source or browser extension >> additional to implement OpenPGPJS based identity verification >> (http://openpgpjs.org/) or integration with DH based key >> exchange (https://github.com/kaepora/cryptocat/). >> >> So basically a side-effect of introducing SDES-SRTP, could be to let >> HTML5 application developers, to effectively be able to >> implement custom security mechanisms for voice applications. >> >> -- >> Fabio Pietrosanti >> Founder, CTO >> >> Tel: +39 02 85961748 (direct) >> Mobile: +39 340 1801049 >> E-mail: fabio.pietrosanti@privatewave.com >> Skype: fpietrosanti >> Linkedin: http://linkedin.com/in/secret >> >> PrivateWave Italia S.p.A. >> Via Gaetano Giardino 1 - 20123 Milano - Italy >> www.privatewave.com _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Fri Mar 30 01:59:42 2012 Return-Path: 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 BD4EC21F882B for ; Fri, 30 Mar 2012 01:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.77 X-Spam-Level: X-Spam-Status: No, score=-7.77 tagged_above=-999 required=5 tests=[AWL=-1.521, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 U5Abai4XaD0g for ; Fri, 30 Mar 2012 01:59:41 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3C46821F87D0 for ; Fri, 30 Mar 2012 01:59:41 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-50-4f7575fb9b9c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1D.DF.25560.BF5757F4; Fri, 30 Mar 2012 10:59:39 +0200 (CEST) Received: from [150.132.142.230] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Fri, 30 Mar 2012 10:59:39 +0200 Message-ID: <4F7575FB.8010201@ericsson.com> Date: Fri, 30 Mar 2012 10:59:39 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Interaction between MediaStream API and signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:59:42 -0000 The JS API has deals with MediaStreams (this is what you send and receive using PeerConnection from an application perspective). A browser receiving RTP streams, needs side info to be able to assemble those RTP streams into MediaStreams in a correct way. The current model is that this is signaled using SDP exchanges (where Haralds MSID proposal would tell which MediaStream an RTP stream belongs to). As I brought up at the mike yesterday, I think we may have a race condition for the responder. For the initiator side browser, this is clear: once an (PR-)ANSWER is received, the responder has received the SDP, and hence can map incoming RTP streams into MediaStreams. But for the responder side this is less clear to me. Imagine applications where the responder just mirrors the initiator - if one of the parties adds a MediaStream to PeerConnection, the other end would add the corresponding MediaStream. This can happen any time in the session, so ICE can very well be up and running. One example could be that the data channel is used for text chat, when one side clicks a button to start video. And the application can have asked for permission to use all input devices earlier, so no user interaction may be involved. In this situation the responder's (added) RTP streams can very well arrive before the ANSWER if I understand correctly. I think we need to find a way to handle this. One way is to add an "ACK" that indicates to the responder that the initiator has received the ANSWER, but I'm not sure that is the best way. Stefan From HKaplan@acmepacket.com Fri Mar 30 02:43:53 2012 Return-Path: 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 779E821F8878 for ; Fri, 30 Mar 2012 02:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] 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 6NZmfc+NXnsi for ; Fri, 30 Mar 2012 02:43:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id D3A9C21F8874 for ; Fri, 30 Mar 2012 02:43:52 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 30 Mar 2012 05:43:48 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.64]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Fri, 30 Mar 2012 05:43:47 -0400 From: Hadriel Kaplan To: "Timothy B. Terriberry" Thread-Topic: [rtcweb] SRTP and "marketing" Thread-Index: AQHNDlmaa94ISWofdEqW+vJ+k5BOuA== Date: Fri, 30 Mar 2012 09:43:46 +0000 Message-ID: References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> <4F73B2B6.9080008@jesup.org> <6493BD08-5A9B-48AB-8D5C-8778384948A3@acmepacket.com> <4F74DAA1.4080103@jesup.org> <4F750525.9030806@mozilla.com> In-Reply-To: <4F750525.9030806@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <5384ABBEA6A03142986DB31D0A4DD7A4@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:43:53 -0000 On Mar 30, 2012, at 2:58 AM, Timothy B. Terriberry wrote: > And the difficulty is, a browser has no way to tell (a priori) when the o= ther end is another browser or a gateway. You mean before the browser receives an offer/answer? Obviously it won't, = but why does that matter? (I must be missing something obvious) -hadriel From dean.willis@softarmor.com Fri Mar 30 03:19:25 2012 Return-Path: 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 95BD421F8933 for ; Fri, 30 Mar 2012 03:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.474 X-Spam-Level: X-Spam-Status: No, score=-101.474 tagged_above=-999 required=5 tests=[AWL=-1.098, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 Mvq0DpP3ZwrV for ; Fri, 30 Mar 2012 03:19:25 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE4BC21F891A for ; Fri, 30 Mar 2012 03:19:24 -0700 (PDT) Received: by yhkk25 with SMTP id k25so197097yhk.31 for ; Fri, 30 Mar 2012 03:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=X44rhjCUaGwIuNbPq5/9etchdCKo6w7atXMHDx6ZKhs=; b=br1Y0p/FWLBsY/OFP2qoWogVcElsV8d60NDWclC10WqEKTwrEN2m9wZMfhyJ/PvvKl 8h1ZwwhnwEjY/FzaVYlqoQm+PY6UQW+Qyglh1n0f52QKX8oi3AQTrtRS3eTHJuIvAFVJ 2TMFQwbw0C5ScOgS4MUFgEat4bIUQqtjAd79Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:x-gm-message-state :content-type; bh=X44rhjCUaGwIuNbPq5/9etchdCKo6w7atXMHDx6ZKhs=; b=ZmraEjavzLXw/owlvY5w5OYJC4tyNNB0UcPujw0Tx2e0ngkKYUUiMBIYnzbq5m5zhI qFwDhluC0+U0ExKZbUnJfRqGIFEYRoH/RqF3htLv3iStThYdkM3VNFHI7hFONvuoSPpw b7Dz8uEdUGcc5dmtWOCBi/wy+SnyqvscXQd0X72+825iYUGrWK3irt176zvriUQ44r/t Xt/qHQE+3y4DpkwEqIukn/2rLATgLsPI8d4Vh+AVBlvsroseXZYS0dsNbBuQNQbLzT3h 3X6w61Vjsn6Qq8GdegC1C7031q3AilRUHcyVmFn/P8cgB8eSkW2Lr58Om3g2pZYpqWcq 8rnA== MIME-Version: 1.0 Received: by 10.68.240.41 with SMTP id vx9mr8000694pbc.10.1333102764117; Fri, 30 Mar 2012 03:19:24 -0700 (PDT) Received: by 10.68.189.197 with HTTP; Fri, 30 Mar 2012 03:19:24 -0700 (PDT) Received: by 10.68.189.197 with HTTP; Fri, 30 Mar 2012 03:19:24 -0700 (PDT) Date: Fri, 30 Mar 2012 12:19:24 +0200 Message-ID: From: Dean Willis To: "rtcweb@ietf.org" X-Gm-Message-State: ALoCoQniAd/xty/8ZhMTlbEbR/evTndNIg5jzLOrcmRutiitz164P5O4OHZZPwOtXGXDzTIBoEYN Content-Type: multipart/alternative; boundary=047d7b33923db44d5d04bc732c11 Subject: [rtcweb] Quote from Rethink on H.264 patent fight X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 10:19:25 -0000 --047d7b33923db44d5d04bc732c11 Content-Type: text/plain; charset=ISO-8859-1 Note that even when you think you know the landscape of the IPR on something, you can still get nasty surprises. A quote from todays Rethink that brings this out: "However, several key cases are now reaching final judgements, and injunctions are more likely to be granted in that event. Motorola - soon to be owned by Google - has asked for a ban on Microsoft's Xbox 360, Windows and Internet Explorer products, which it claims infringe on its H.264-related patents, if Motorola wins a case to be heard in Mannheim, Germany on April 17. According to IPR expert Florian Mueller of FOSS Patents, the judge is expected to favour Motorola." --047d7b33923db44d5d04bc732c11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Note that even when you think you know the landscape of the IPR on somet= hing, you can still get nasty surprises.

A quote from todays Rethink that brings this out:

"However, several key cases are now reaching final judgements, and = injunctions are more likely to be granted in that event. Motorola - soon to= be owned by Google - has asked for a ban on Microsoft's Xbox 360, Wind= ows and Internet Explorer products, which it claims infringe on its H.264-r= elated patents, if Motorola wins a case to be heard in Mannheim, Germany on= April 17. According to IPR expert Florian Mueller of FOSS Patents, the jud= ge is expected to favour Motorola."

--047d7b33923db44d5d04bc732c11-- From gettysjim@gmail.com Fri Mar 30 06:56:47 2012 Return-Path: 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 E20B121F86BD for ; Fri, 30 Mar 2012 06:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Q-WVf9uSVAnA for ; Fri, 30 Mar 2012 06:56:47 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA8221F85EF for ; Fri, 30 Mar 2012 06:56:47 -0700 (PDT) Received: by qaea16 with SMTP id a16so269740qae.10 for ; Fri, 30 Mar 2012 06:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QjvzFL0oOttby96S531DPShpW6p5P1f9nl8Pjc/ow3w=; b=S+1P8TTQeTDNBophNaelWSNrS8A+dE/xnoVzp/XGBzxUUrwVA2LD287ibpKhJP6aIq 0Me/P1JQf6S1pBCvQaw2oX12jPz/iKjX9A87s4N4mzcFMb6lFLulcsvn+fxAInbHvuzM Pepya+EGVDbvRC3hnGdq7ba7bjpvzdQHSk3RWlUJsuiqarbBmxqN50RbkZs/iTvwRZwL YKNbxxA7NJTKLKdXDDxrKnTivxg7fvPx/Mi8tVdEwS6bNv5wkX1GiXrQ1FrIKSBRZGmX /smlFdEJV0SwDM5USGtnJgSb3PEWZE8VZG7aXZ6ByOp2J3L+sGQ7hc/ICqUG350WiB0O Emuw== Received: by 10.224.39.211 with SMTP id h19mr5650595qae.24.1333115806736; Fri, 30 Mar 2012 06:56:46 -0700 (PDT) Received: from [172.30.48.80] (c-50-138-169-248.hsd1.ma.comcast.net. [50.138.169.248]) by mx.google.com with ESMTPS id fo9sm18381244qab.21.2012.03.30.06.56.44 (version=SSLv3 cipher=OTHER); Fri, 30 Mar 2012 06:56:45 -0700 (PDT) Sender: Jim Gettys Message-ID: <4F75BB9B.8090404@freedesktop.org> Date: Fri, 30 Mar 2012 09:56:43 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Dean Willis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Quote from Rethink on H.264 patent fight X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 13:56:48 -0000 On 03/30/2012 06:19 AM, Dean Willis wrote: > > Note that even when you think you know the landscape of the IPR on > something, you can still get nasty surprises. > > A quote from todays Rethink that brings this out: > > "However, several key cases are now reaching final judgements, and > injunctions are more likely to be granted in that event. Motorola - > soon to be owned by Google - has asked for a ban on Microsoft's Xbox > 360, Windows and Internet Explorer products, which it claims infringe > on its H.264-related patents, if Motorola wins a case to be heard in > Mannheim, Germany on April 17. According to IPR expert Florian Mueller > of FOSS Patents, the judge is expected to favour Motorola." > > Anyone reporter who thinks Florian Mueller is an IPR expert is clueless, demented, or grinding an axe. - Jim From basilgohar@librevideo.org Fri Mar 30 08:07:46 2012 Return-Path: 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 D98AC21F8652 for ; Fri, 30 Mar 2012 08:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] 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 RoiC6nW7eY+E for ; Fri, 30 Mar 2012 08:07:46 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 30D7121F856D for ; Fri, 30 Mar 2012 08:07:45 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id C2A326527A1 for ; Fri, 30 Mar 2012 11:07:44 -0400 (EDT) Message-ID: <4F75CC3D.4040009@librevideo.org> Date: Fri, 30 Mar 2012 11:07:41 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F75BB9B.8090404@freedesktop.org> In-Reply-To: <4F75BB9B.8090404@freedesktop.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Quote from Rethink on H.264 patent fight X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 15:07:47 -0000 On 03/30/2012 09:56 AM, Jim Gettys wrote: > On 03/30/2012 06:19 AM, Dean Willis wrote: >> Note that even when you think you know the landscape of the IPR on >> something, you can still get nasty surprises. >> >> A quote from todays Rethink that brings this out: >> >> "However, several key cases are now reaching final judgements, and >> injunctions are more likely to be granted in that event. Motorola - >> soon to be owned by Google - has asked for a ban on Microsoft's Xbox >> 360, Windows and Internet Explorer products, which it claims infringe >> on its H.264-related patents, if Motorola wins a case to be heard in >> Mannheim, Germany on April 17. According to IPR expert Florian Mueller >> of FOSS Patents, the judge is expected to favour Motorola." >> >> > Anyone reporter who thinks Florian Mueller is an IPR expert is clueless, > demented, or grinding an axe. > - Jim +1 -- Libre Video http://librevideo.org From gmaxwell@juniper.net Fri Mar 30 08:39:29 2012 Return-Path: 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 2756C21F86D1 for ; Fri, 30 Mar 2012 08:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 tfCB0QAKQIPS for ; Fri, 30 Mar 2012 08:39:28 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7F64C21F86D0 for ; Fri, 30 Mar 2012 08:39:28 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKT3XTrk5eje+ekmRSX7KPy9HZW/g1uDPf@postini.com; Fri, 30 Mar 2012 08:39:28 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 30 Mar 2012 08:37:57 -0700 From: Gregory Maxwell To: Randell Jesup , "rtcweb@ietf.org" Date: Fri, 30 Mar 2012 08:37:57 -0700 Thread-Topic: [rtcweb] SRTP and "marketing" Thread-Index: Ac0N903AuI/AsopKSqCZGCBYPaD84QAjG+ne Message-ID: References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> <4F73B2B6.9080008@jesup.org> <6493BD08-5A9B-48AB-8D5C-8778384948A3@acmepacket.com>, <4F74DAA1.4080103@jesup.org> In-Reply-To: <4F74DAA1.4080103@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] SRTP and "marketing" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 15:39:29 -0000 Randell Jesup [randell-ietf@jesup.org] wrote: > That's not of no benefit. It's not of real > benefit to J. Random Salesman, but even non-political people may worry > about someone watching in more than they worry about listening in. > (#include lawsuits over schools using laptop computers to take snapshots > from student computers at home, etc, etc). A point which needs to be emphasized is that undetectable attacks are not at all the same thing as detectable attacks: Even when the chance of detection is somewhat low, if the cost of detection is high the possibility of it can be an effective deterrent. Assuming 'hardcoded' ephemeral key agreement, Users Comparing Tools->PageInfo->Media->session fingerprint =97 especially if documented as a best practice in HowToBeParanoid documents=97 would be likely to detect network level mass interception, even if the chance of detection on a case by case is very low. This makes the development and deployment of _covert_ mass surveillance/censorship infrastructure, the sort with the greatest negative human rights value, less attractive from a cost benefit perspective. (Of course, it does nothing for non-secret monitoring=97 but when the monitoring is not secret the users of protcol have the most important information they need in order to make an informed choice about how they communicate, what public policies they live under, who they have providing their network services, etc) In computer and cryptographic security we're often concerned with absolute protection. This is because absolute security is often achievable in this area, a luxury few other kinds of security have. But where absolute security can't be provided (e.g. we _can't_ prevent MITM without hard to provide and often missing identity service), relative security still has value. When considering the real world context of attacks always being a cost benefit trade-off the removal of nearly-undetectable attacks is as an enormous relative improvement as is the removal of passive sniffing. From salvatore.loreto@ericsson.com Fri Mar 30 12:15:12 2012 Return-Path: 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 2370821F86C7 for ; Fri, 30 Mar 2012 12:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.124 X-Spam-Level: X-Spam-Status: No, score=-110.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 pOwizo6hYCU0 for ; Fri, 30 Mar 2012 12:15:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E12F621F86C6 for ; Fri, 30 Mar 2012 12:15:10 -0700 (PDT) X-AuditID: c1b4fb3d-b7c4fae00000507f-4d-4f76063da11e Authentication-Results: mailgw10.se.ericsson.net x-tls.subject="/CN=esessmw0247"; auth=fail (cipher=AES128-SHA) Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0247", Issuer "esessmw0247" (not verified)) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 74.D2.20607.D36067F4; Fri, 30 Mar 2012 21:15:09 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Fri, 30 Mar 2012 21:15:03 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A55B02321 for ; Fri, 30 Mar 2012 22:15:03 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A57D15261B for ; Fri, 30 Mar 2012 22:15:03 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2FCD152619 for ; Fri, 30 Mar 2012 22:15:03 +0300 (EEST) Message-ID: <4F760634.207@ericsson.com> Date: Fri, 30 Mar 2012 21:15:00 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Data channel comments and questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 19:15:12 -0000 Hi Markus, see in line On 3/29/12 10:23 PM, Markus.Isomaki@nokia.com wrote: > Hi, > > Some comments on the data channel proposal: > > 1. Congestion control: If no real-time sessions are on, TCP-style loss-driven congestion control is fine. However, if voice/video session is up, such congestion control would be disasterous to the real-time traffic quality if sendind or receiving more than a slight amount of data. Especially in mobile access networks the user would bloat his/her own buffers very easily. In that case, some less-than-best-effort congestion control algorithm á la LEDBAT would be required. It would be best to make this a MUST requirement on implementations, otherwise we will get a lot of crappy video even if the codec was better than H.261 :-) good point worth to discuss the congestion control algorithm in the actual SCTP open source userland implementation is a TCP-friendly congestion control. As I said during the presentation we can change it if we see the reason not to use it (and you have already some good one)... however it should be clear that at moment SCTP does not have any way to negotiate the congestion control algorithm to use in an association. So whatever we choose it will be the one used in all the possible scenarios (e.g. voice/video session up or down, etc). > > 2. Multihoming and interface switching: I don't suggest going for the multipath support on the SCTP level. I think it would be best to deal with this through ICE in the same way as for RTP, i.e. adding and removing candidates as interfaces become available or go. Or let the application handle it by creating a new data channel and continue from the breakpoint. The most important requirement is that the application gets notified about these changes downstrairs so it can act. that is exact the proposal in the data-channel draft. Anyway you can not use multihoming because of the fact that SCTP runs on top of DTLS > > > 3. HTTP tunneling: In practice we are going to need HTTP tunneling last-resort option for the data channel as well. If doing so, what will the protocol stack look like? Is it SCTP/DTLS/UDP/HTTP/TLS/TCP? Or can we collapse some of these layers. I think we'd better. this is something to figure it out. Eric proposal make sense to me; another possibility would be use WebSocket when you have to tunneling data over HTTP/HTTPS. Salvatore -- Salvatore Loreto, PhD www.sloreto.com From randell-ietf@jesup.org Fri Mar 30 13:46:55 2012 Return-Path: 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 CB0E721F86C7 for ; Fri, 30 Mar 2012 13:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_BACKHAIR_24=1] 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 mhzj22cSz8ep for ; Fri, 30 Mar 2012 13:46:55 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 34C1A21F85F9 for ; Fri, 30 Mar 2012 13:46:54 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SDiij-0003AH-KH for rtcweb@ietf.org; Fri, 30 Mar 2012 15:46:53 -0500 Message-ID: <4F761AFC.5090503@jesup.org> Date: Fri, 30 Mar 2012 16:43:40 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F760634.207@ericsson.com> In-Reply-To: <4F760634.207@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Data channel comments and questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 20:46:55 -0000 On 3/30/2012 3:15 PM, Salvatore Loreto wrote: > On 3/29/12 10:23 PM, Markus.Isomaki@nokia.com wrote: >> Some comments on the data channel proposal: >> >> 1. Congestion control: If no real-time sessions are on, TCP-style >> loss-driven congestion control is fine. However, if voice/video >> session is up, such congestion control would be disasterous to the >> real-time traffic quality if sendind or receiving more than a slight >> amount of data. Especially in mobile access networks the user would >> bloat his/her own buffers very easily. In that case, some >> less-than-best-effort congestion control algorithm á la LEDBAT would >> be required. It would be best to make this a MUST requirement on >> implementations, otherwise we will get a lot of crappy video even if >> the codec was better than H.261 :-) > good point worth to discuss > > the congestion control algorithm in the actual SCTP open source userland > implementation is a TCP-friendly congestion control. > As I said during the presentation we can change it if we see the reason > not to use it (and you have already some good one)... Correct; please also see the presentation from the rtcweb Interim meeting in February that I gave; one issue it covered was congestion control. We definitely want to both be able to balance bandwidth used by data channels versus media and to avoid data channels causing congestion that forces the media channels to degrade. This could be done by: a) developing a 'merged' congestion control regime for the media channels and the data channels. As we're already getting a "total bandwidth" notification from the receiver, that calculation could include data channels, and let the sender allocate bits to media and the data channels according to that information. In this scenario, the data channel code itself would be slaved to a wider congestion control. b) run separate congestion control for the data channels based on a low-delay variant of classic TCP, such as Cx-TCP. It so happens that the FreeBSD SCTP implementation includes a low-delay congestion algorithm based on an ancestor of the current Cx-TCP work. Cx-TCP (for links see the Interim slides) runs in a low-delay fashion unless it's fighting with long-lived/saturating TCP flows, where it will transition into a loss-based behavior (with longer delay), and transition back if the TCP flows drop below bottleneck bandwidth. c) run classic loss-based congestion control (the default), but put an external bandwidth limiter on it controlled by the main application and congestion code, limiting the data channels to a specified amount or fraction of the media channels. d) run classic loss-based congestion control and let it compete with media; don't send large amounts of data, or pace it in the application. Or live with the data channel killing your media. > however it should be clear that at moment SCTP does not have any way to > negotiate the congestion control algorithm to use in an association. Correct, though we could fix that - and we could give the JS control and let the app decide, since data channels are largely within-app proprietary connections. >> 2. Multihoming and interface switching: I don't suggest going for the >> multipath support on the SCTP level. I think it would be best to deal >> with this through ICE in the same way as for RTP, i.e. adding and >> removing candidates as interfaces become available or go. Or let the >> application handle it by creating a new data channel and continue from >> the breakpoint. The most important requirement is that the application >> gets notified about these changes downstrairs so it can act. > that is exact the proposal in the data-channel draft. > Anyway you can not use multihoming because of the fact that SCTP runs on > top of DTLS Correct, though there was some in-room discussion of running it over multiple DTLS connections to support smooth handoff across interfaces (think mobile and 4g<->WiFi switchover). -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Fri Mar 30 14:42:46 2012 Return-Path: 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 DF46D21F85D2 for ; Fri, 30 Mar 2012 14:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599] 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 XNqh42IuFGAm for ; Fri, 30 Mar 2012 14:42:46 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 4523A21F85D1 for ; Fri, 30 Mar 2012 14:42:45 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SDjam-0008BQ-HD for rtcweb@ietf.org; Fri, 30 Mar 2012 16:42:44 -0500 Message-ID: <4F762813.6040506@jesup.org> Date: Fri, 30 Mar 2012 17:39:31 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F7575FB.8010201@ericsson.com> In-Reply-To: <4F7575FB.8010201@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Interaction between MediaStream API and signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 21:42:47 -0000 On 3/30/2012 4:59 AM, Stefan Hakansson LK wrote: > The JS API has deals with MediaStreams (this is what you send and > receive using PeerConnection from an application perspective). > > A browser receiving RTP streams, needs side info to be able to > assemble those RTP streams into MediaStreams in a correct way. The > current model is that this is signaled using SDP exchanges (where > Haralds MSID proposal would tell which MediaStream an RTP stream > belongs to). > > As I brought up at the mike yesterday, I think we may have a race > condition for the responder. > > For the initiator side browser, this is clear: once an (PR-)ANSWER is > received, the responder has received the SDP, and hence can map > incoming RTP streams into MediaStreams. > > But for the responder side this is less clear to me. Imagine > applications where the responder just mirrors the initiator - if one > of the parties adds a MediaStream to PeerConnection, the other end > would add the corresponding MediaStream. > > This can happen any time in the session, so ICE can very well be up > and running. One example could be that the data channel is used for > text chat, when one side clicks a button to start video. And the > application can have asked for permission to use all input devices > earlier, so no user interaction may be involved. > > In this situation the responder's (added) RTP streams can very well > arrive before the ANSWER if I understand correctly. Yes. Just like in SIP. And so when you send an OFFER (or modified re-OFFER), you must be ready to receive data per that offer even if no ANSWER has been received - just like in SIP. And if its a re-offer, you need to accept the old, and accept the new (though you could probably use reception of obviously new-OFFER media to turn off decoding/rendering old-OFFER in preparation for the ANSWER). The flip side of this is the responder has to infer when the sender switches over to the result of the ANSWER from the media. For example: A B <--- H.261 ---> re-OFFER(VP8) ---> <-- ANSWER(VP8) (delayed in reception) <-----------VP8 (A should infer that B ANSWERed and accepted VP8) ----------> H.261 <-- ANSWER(VP8) (received) <--------VP8----------> (B should infer by reception of VP8 that ANSWER was received) (Personally, I hate inferences, but without a 3 (or 4) way handshake, you have to). If you switches of codecs are staged, then this isn't (much) of a problem. Either leave old codec on the list, or leave it on the list until accept, and then re-OFFER to remove the un-used codec. One problem is what to do in the switchover window when you might get a mixture of old and new media, especially if you moved them to different ports and so can't count on RTP sequence re-ordering to un-mix them; in the past I dealt with that (and long codec-switch times) by locking out codec changes for a fraction of a second after I do one. Not a huge deal, however. My apologies if I've missed something in JSEP; I've been heads-down enough in Data Channels and bring-up that I could have a disconnect here and be saying something silly. > I think we need to find a way to handle this. One way is to add an > "ACK" that indicates to the responder that the initiator has received > the ANSWER, but I'm not sure that is the best way. If you need to know that, you need a SIP-style ACK. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Fri Mar 30 14:47:45 2012 Return-Path: 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 75D3121F84FC for ; Fri, 30 Mar 2012 14:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] 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 jtcOXq+VOiwS for ; Fri, 30 Mar 2012 14:47:45 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 028C921F84E4 for ; Fri, 30 Mar 2012 14:47:44 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SDjfc-0001qL-CS for rtcweb@ietf.org; Fri, 30 Mar 2012 16:47:44 -0500 Message-ID: <4F76293F.2000005@jesup.org> Date: Fri, 30 Mar 2012 17:44:31 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F742344.802@infosecurity.ch> , In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Support of SDES in WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 21:47:45 -0000 On 3/29/2012 5:59 PM, Gregory Maxwell wrote: > Oscar Ohlsson [oscar.ohlsson@ericsson.com] wrote: >> That's why I wrote "the entire webapp" below. If it was not clear I meant that the >> - main HTML page >> - all external CSS files, JavaScript files, images, etc >> - all XmlHttpRequests >> - all WebSocket connections >> are protected with TLS. This is obviously verifiable and it's a feature supported by all modern browsers (no mixed content). > > Even this is insufficient. [long nice analysis of security in JS vs in the stack deleted] > Really, cryptographic > negotiation is not properly an application feature, it belongs lower in > the stack, and many applications that roll their own crypto have done > a poor job of it. > > It's also inadequate on purely technical grounds: Javascript provides > no mechanism for working with mlocked memory, no mechanism to ensure > that garbage collected data gets zeroized. Your crypto app in JS could > easily have its long term keying material pulled out of free ram by > malware long after it runs, or pulled off the disk from swap. > The breakneck pace of fancy JIT systems makes it seem unlikely to me > that javascript will provide for that any time soon. I rarely do this sort of reply for obvious reasons, but: I agree! :-) -- Randell Jesup randell-ietf@jesup.org From stefan.lk.hakansson@ericsson.com Fri Mar 30 22:01:51 2012 Return-Path: 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 5316021F8672 for ; Fri, 30 Mar 2012 22:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.697 X-Spam-Level: X-Spam-Status: No, score=-7.697 tagged_above=-999 required=5 tests=[AWL=-1.448, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 dfDb0QWhnPFR for ; Fri, 30 Mar 2012 22:01:50 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8F021F8661 for ; Fri, 30 Mar 2012 22:01:49 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-11-4f768fba106b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 30.04.25560.ABF867F4; Sat, 31 Mar 2012 07:01:46 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Sat, 31 Mar 2012 07:01:45 +0200 Message-ID: <4F768FB9.50708@ericsson.com> Date: Sat, 31 Mar 2012 07:01:45 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Jim Barnett References: <4F7575FB.8010201@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Interaction between MediaStream API and signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 05:01:51 -0000 On 03/30/2012 04:26 PM, Jim Barnett wrote: > Doesn't the basic model require that the offer be ready to receive media > as soon as it sends the offer? If that's the case then the offer must > be ready and able to map RTP streams to media streams (using the mapping > specified in the SDP for its offer) as soon as it sends the offer. Yes, the basic SDP o/a model requires that the offerer is ready to receive media as soon as the offer is sent. But as I tried to explain (but obviously failed to) is that there is an additional constraint here: the JS application deals with MediaStreams, which often has more than one track, e.g. one video and one audio track. A track in turn would correspond to an RTP stream. And you can have several concurrent MediaStreams in action. Say now that the offerer, before getting an ANSWER with info, receives three RTP streams; two video and one audio. The offerer would in this situation not have a clue how these belong together. One could be video from a front facing camera (that is supposed to be displayed on a large video screen), the other video RTP stream could contain the video from the rear facing camera and is supposed to together with the audio RTP stream be one MediaStream that is supposed to be played in sync in a thumbnail video display. Without the offerer having the info about what these RTP streams represent it can't do anything sensible. Stefan > > - Jim > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Stefan Hakansson LK > Sent: Friday, March 30, 2012 5:00 AM > To: rtcweb@ietf.org > Subject: [rtcweb] Interaction between MediaStream API and signaling > > The JS API has deals with MediaStreams (this is what you send and > receive using PeerConnection from an application perspective). > > A browser receiving RTP streams, needs side info to be able to assemble > those RTP streams into MediaStreams in a correct way. The current model > is that this is signaled using SDP exchanges (where Haralds MSID > proposal would tell which MediaStream an RTP stream belongs to). > > As I brought up at the mike yesterday, I think we may have a race > condition for the responder. > > For the initiator side browser, this is clear: once an (PR-)ANSWER is > received, the responder has received the SDP, and hence can map incoming > RTP streams into MediaStreams. > > But for the responder side this is less clear to me. Imagine > applications where the responder just mirrors the initiator - if one of > the parties adds a MediaStream to PeerConnection, the other end would > add the corresponding MediaStream. > > This can happen any time in the session, so ICE can very well be up and > running. One example could be that the data channel is used for text > chat, when one side clicks a button to start video. And the application > can have asked for permission to use all input devices earlier, so no > user interaction may be involved. > > In this situation the responder's (added) RTP streams can very well > arrive before the ANSWER if I understand correctly. I think we need to > find a way to handle this. One way is to add an "ACK" that indicates to > the responder that the initiator has received the ANSWER, but I'm not > sure that is the best way. > > Stefan > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Fri Mar 30 22:17:51 2012 Return-Path: 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 5A49921F8731 for ; Fri, 30 Mar 2012 22:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.807 X-Spam-Level: X-Spam-Status: No, score=-9.807 tagged_above=-999 required=5 tests=[AWL=0.792, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 CekcsJ1nNVhO for ; Fri, 30 Mar 2012 22:17:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 254AF21F8730 for ; Fri, 30 Mar 2012 22:17:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7c4fae00000507f-e7-4f76937cbe29 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CF.49.20607.C73967F4; Sat, 31 Mar 2012 07:17:48 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Sat, 31 Mar 2012 07:17:47 +0200 Message-ID: <4F76937B.9020901@ericsson.com> Date: Sat, 31 Mar 2012 07:17:47 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F7575FB.8010201@ericsson.com> <4F762813.6040506@jesup.org> In-Reply-To: <4F762813.6040506@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Interaction between MediaStream API and signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 05:17:51 -0000 On 03/30/2012 11:39 PM, Randell Jesup wrote: > On 3/30/2012 4:59 AM, Stefan Hakansson LK wrote: >> The JS API has deals with MediaStreams (this is what you send and >> receive using PeerConnection from an application perspective). >> >> A browser receiving RTP streams, needs side info to be able to >> assemble those RTP streams into MediaStreams in a correct way. The >> current model is that this is signaled using SDP exchanges (where >> Haralds MSID proposal would tell which MediaStream an RTP stream >> belongs to). >> >> As I brought up at the mike yesterday, I think we may have a race >> condition for the responder. >> >> For the initiator side browser, this is clear: once an (PR-)ANSWER is >> received, the responder has received the SDP, and hence can map >> incoming RTP streams into MediaStreams. >> >> But for the responder side this is less clear to me. Imagine >> applications where the responder just mirrors the initiator - if one >> of the parties adds a MediaStream to PeerConnection, the other end >> would add the corresponding MediaStream. >> >> This can happen any time in the session, so ICE can very well be up >> and running. One example could be that the data channel is used for >> text chat, when one side clicks a button to start video. And the >> application can have asked for permission to use all input devices >> earlier, so no user interaction may be involved. >> >> In this situation the responder's (added) RTP streams can very well >> arrive before the ANSWER if I understand correctly. > > Yes. Just like in SIP. And so when you send an OFFER (or modified > re-OFFER), you must be ready to receive data per that offer even if no > ANSWER has been received - just like in SIP. And if its a re-offer, you > need to accept the old, and accept the new (though you could probably > use reception of obviously new-OFFER media to turn off > decoding/rendering old-OFFER in preparation for the ANSWER). > > The flip side of this is the responder has to infer when the sender > switches over to the result of the ANSWER from the media. For example: > > A B > <--- H.261 ---> > re-OFFER(VP8) ---> > <-- ANSWER(VP8) (delayed in reception) > <-----------VP8 (A should infer that B ANSWERed and accepted VP8) > ----------> H.261 > <-- ANSWER(VP8) (received) > <--------VP8----------> (B should infer by reception of VP8 that ANSWER > was received) > > (Personally, I hate inferences, but without a 3 (or 4) way handshake, > you have to). If you switches of codecs are staged, then this isn't > (much) of a problem. Either leave old codec on the list, or leave it on > the list until accept, and then re-OFFER to remove the un-used codec. I think I understand what you mean, and this would work fine as long as you just switch codecs that are used in already set-up MediaStreams. But if A in this case, as part of re-OFFERING the session, not only offers a new codec (VP8) for the already flowing video but also adds a new outgoing video stream (e.g. front cam), and then (without receiving the ANSWER - delayed in reception) starts receiving VP8 video it could not really know if this VP8 video is new video from the responders front cam or just a new codec for the existing (back cam) video from the responder to the sender. > > One problem is what to do in the switchover window when you might get a > mixture of old and new media, especially if you moved them to different > ports and so can't count on RTP sequence re-ordering to un-mix them; in > the past I dealt with that (and long codec-switch times) by locking out > codec changes for a fraction of a second after I do one. Not a huge > deal, however. > > My apologies if I've missed something in JSEP; I've been heads-down > enough in Data Channels and bring-up that I could have a disconnect here > and be saying something silly. Actually I don't think this is very JSEP related; it is the generic problem that the browser receiving RTP streams need some side info about them before being able to do anything sensible with them. > >> I think we need to find a way to handle this. One way is to add an >> "ACK" that indicates to the responder that the initiator has received >> the ANSWER, but I'm not sure that is the best way. > > If you need to know that, you need a SIP-style ACK. As explained, I do think we need to know that. > From stefan.lk.hakansson@ericsson.com Fri Mar 30 22:41:09 2012 Return-Path: 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 E0A8021F86B6 for ; Fri, 30 Mar 2012 22:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.666 X-Spam-Level: X-Spam-Status: No, score=-7.666 tagged_above=-999 required=5 tests=[AWL=-1.417, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 VpDQDh1zKA6n for ; Fri, 30 Mar 2012 22:41:07 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5612E21F865C for ; Fri, 30 Mar 2012 22:41:06 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-42-4f7698f0106f Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA) Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AB.76.25560.0F8967F4; Sat, 31 Mar 2012 07:41:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Sat, 31 Mar 2012 07:41:03 +0200 Message-ID: <4F7698EF.1090306@ericsson.com> Date: Sat, 31 Mar 2012 07:41:03 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F7575FB.8010201@ericsson.com> <4F762813.6040506@jesup.org> <4F76937B.9020901@ericsson.com> In-Reply-To: <4F76937B.9020901@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Interaction between MediaStream API and signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 05:41:09 -0000 On 03/31/2012 07:17 AM, Stefan Hakansson LK wrote: > On 03/30/2012 11:39 PM, Randell Jesup wrote: >> On 3/30/2012 4:59 AM, Stefan Hakansson LK wrote: >>> The JS API has deals with MediaStreams (this is what you send and >>> receive using PeerConnection from an application perspective). >>> >>> A browser receiving RTP streams, needs side info to be able to >>> assemble those RTP streams into MediaStreams in a correct way. The >>> current model is that this is signaled using SDP exchanges (where >>> Haralds MSID proposal would tell which MediaStream an RTP stream >>> belongs to). >>> >>> As I brought up at the mike yesterday, I think we may have a race >>> condition for the responder. >>> >>> For the initiator side browser, this is clear: once an (PR-)ANSWER is >>> received, the responder has received the SDP, and hence can map >>> incoming RTP streams into MediaStreams. >>> >>> But for the responder side this is less clear to me. Imagine >>> applications where the responder just mirrors the initiator - if one >>> of the parties adds a MediaStream to PeerConnection, the other end >>> would add the corresponding MediaStream. >>> >>> This can happen any time in the session, so ICE can very well be up >>> and running. One example could be that the data channel is used for >>> text chat, when one side clicks a button to start video. And the >>> application can have asked for permission to use all input devices >>> earlier, so no user interaction may be involved. >>> >>> In this situation the responder's (added) RTP streams can very well >>> arrive before the ANSWER if I understand correctly. >> >> Yes. Just like in SIP. And so when you send an OFFER (or modified >> re-OFFER), you must be ready to receive data per that offer even if no >> ANSWER has been received - just like in SIP. And if its a re-offer, you >> need to accept the old, and accept the new (though you could probably >> use reception of obviously new-OFFER media to turn off >> decoding/rendering old-OFFER in preparation for the ANSWER). >> >> The flip side of this is the responder has to infer when the sender >> switches over to the result of the ANSWER from the media. For example: >> >> A B >> <--- H.261 ---> >> re-OFFER(VP8) ---> >> <-- ANSWER(VP8) (delayed in reception) >> <-----------VP8 (A should infer that B ANSWERed and accepted VP8) >> ----------> H.261 >> <-- ANSWER(VP8) (received) >> <--------VP8----------> (B should infer by reception of VP8 that ANSWER >> was received) >> >> (Personally, I hate inferences, but without a 3 (or 4) way handshake, >> you have to). If you switches of codecs are staged, then this isn't >> (much) of a problem. Either leave old codec on the list, or leave it on >> the list until accept, and then re-OFFER to remove the un-used codec. > > I think I understand what you mean, and this would work fine as long as > you just switch codecs that are used in already set-up MediaStreams. > > But if A in this case, as part of re-OFFERING the session, not only > offers a new codec (VP8) for the already flowing video but also adds a > new outgoing video stream (e.g. front cam), and then (without receiving > the ANSWER - delayed in reception) starts receiving VP8 video it could > not really know if this VP8 video is new video from the responders front > cam or just a new codec for the existing (back cam) video from the > responder to the sender. This may have been a very bad example. Probably you can tell them apart on the SSRC. But even so, the A browser won't know what the VP8 stream (if it has an unknown SSRC) represents without receiving the ANSWER. > >> >> One problem is what to do in the switchover window when you might get a >> mixture of old and new media, especially if you moved them to different >> ports and so can't count on RTP sequence re-ordering to un-mix them; in >> the past I dealt with that (and long codec-switch times) by locking out >> codec changes for a fraction of a second after I do one. Not a huge >> deal, however. >> >> My apologies if I've missed something in JSEP; I've been heads-down >> enough in Data Channels and bring-up that I could have a disconnect here >> and be saying something silly. > > Actually I don't think this is very JSEP related; it is the generic > problem that the browser receiving RTP streams need some side info about > them before being able to do anything sensible with them. > >> >>> I think we need to find a way to handle this. One way is to add an >>> "ACK" that indicates to the responder that the initiator has received >>> the ANSWER, but I'm not sure that is the best way. >> >> If you need to know that, you need a SIP-style ACK. > > As explained, I do think we need to know that. > >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Fri Mar 30 23:40:35 2012 Return-Path: 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 5FC1A21F8601 for ; Fri, 30 Mar 2012 23:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599] 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 AGyGl6JdoJYP for ; Fri, 30 Mar 2012 23:40:34 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1F34921F85FD for ; Fri, 30 Mar 2012 23:40:33 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SDrzE-00042y-V2 for rtcweb@ietf.org; Sat, 31 Mar 2012 01:40:33 -0500 Message-ID: <4F76A61E.80602@jesup.org> Date: Sat, 31 Mar 2012 02:37:18 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F73697D.5080006@infosecurity.ch> <4F7409C4.407@infosecurity.ch> In-Reply-To: <4F7409C4.407@infosecurity.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] DTLS-SRTP implementation diffusion: Why not SDES-SRTP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 06:40:35 -0000 On 3/29/2012 3:05 AM, Fabio Pietrosanti (naif) wrote: > On 3/28/12 9:53 PM, Iñaki Baz Castillo wrote: >> 2012/3/28 Fabio Pietrosanti (naif): >>> Hi all, >>> >>> i read that 80% of Sipit participant support SDES-SRTP but 0% support >>> DTLS-SRTP https://www.sipit.net/SIPit29_summary . >>> >>> At SIPit there were 34 attendees from 17 companies visiting from 12 >>> countries with 25 distinct VoIP implementations. >> >> Right, but this is rtcweb, not SIP. >> >> >> >>> I do not really see which is the rationale in making DTLS-SRTP mandatory >>> while plain SRTP with SDES key exchange is already so well know and used. >> >> That's a good reason to *also* allow (and mandate) SDES-SRTP support >> in WebRTC clients, much better than the interoperability with SIP >> (again: this is rtcweb, not SIP world). > > That's true, but it's also true that the "rtcweb world" will strictly > inter-operate with the "sip world". The meaning of this statement is unclear. If you mean "some rtcweb clients will connect to SIP gateways", or "some rtcweb clients will translate JSEP into SIP and send it to a SIP server", then that's true. Some (many) rtcweb clients will never talk to any sip equipment. > It would be reasonable to expect that current existing PBX software > would evolve also with support for Rtcweb, to provide Web phone systems. Which is no problem, the PBX can act as a WebRTC server, and provide the WebRTC JS app to the browsers, and also act as a gateway to SIP. There's no reason it can't terminate DTLS-SRTP for calls that connect to SIP devices. > In particular all opensource software will setup the path for the > adoption of the standard, as we know history will repeat. > > It appear me as natural behavior of diffusion of implementation, and for > that reason i see the need to "easily" inter-operate with the SIP world > is a key value point. Being able to gateway to SIP and to PSTN are both useful abilities for certain (popular) classes of potential apps. Note the earlier discussions showed that one requirement (consent) makes it hard (though not impossible) to directly connect WebRTC clients to PSTN gateways or to other SIP devices, even if you allow SDES. If consent forces you through a gateway (or some device that knows WebRTC), DTLS-SRTP-only becomes a much smaller hump. > Creating an incompatible "media format" would require a lot of more > effort because the "amount of compatibility testing to be done with > DTLS-SRTP will be significantly higher than SDES-SRTP" . > > So it would provide an advantage for the *few vendor* supporting it, > practically introducing a *technological entrance barrier*. Given the expectation that there will be a quality open-source version available (and Mozilla's implementation is of course open source), the barrier should be quite low. > This is a bad practice already see in other standard bodies. > >> >> >>> Anyone can provide some very strong and valuable point about using >>> DTLS-SRTP (considering it's weak diffusion and incompatibility risks)? >> >> Lot of recent threads about this topic in this maillist. But also >> check a recent presentation (yesterday in IETF Pairs): >> >> http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf > > I would like to strongly argue against the SLIDE 3 statement that > "DTLS-SRTP meets RTCWEB's technical requirements" . > > DTLS-SRTP doesn't meet the RTCWEB's technical requirements because: > > - It does NOT provide inter-operation with existing SIP endpoints That is not an rtcweb requirement. The only mention of SIP in the use-case and requirements doc is the ability to use SIP to provide federation (F27). > This is confirmed by the October 2011 SIPit data, with 80% of > participants supporting, with good interoperability, SDES but with 0% > supporting DTLS-SRTP . As discussed, this is an only partially-relevant fact. SIPit is self-selected; most devices there are not representative of average devices in use, and devices deployed may not enable options used in SIPit tests. > In order to try to "try to improve it's non-interoperability issue" the > DTLS-SRTP is re-proposing him-selves as DTLS-SRTP-EKT . I wasn't particularly enthused about EKT. > To speaking about the fact that even EKT draft explain that: > " Today, Security Descriptions [RFC4568] is used for distributing SRTP > keys in several different IP PBX systems and is expected to be used > by 3GPP's Long Term Evolution (LTE). " > > http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-01#section-6.1 I have no belief that LTE devices will ever connect directly to WebRTC devices directly (even if they're the same device); that's just not how they work. > So: > - Internt is using SDES-SRTP > - 3GPP LTE is using SDES-SRTP > - WebRTC is going to use DTLS-SRTP > > I do not really see how we can rationally accept to follow this > different direction. > > I mean, we are discussing about a "new standard" that's based on "new > technologies" rather than using existing, widely implemented technology. > > Do we really understand how much effort we are going to cause on the > overall technological and security ecosystem by selecting DTLS-SRTP > rather than SDES-SRTP? > > All US Federal Government will not be able to use WebRTC because NSA > standardized SDES-SRTP for use in Classified communication: > http://www.nsa.gov/ia/programs/mobility_program/index.shtml They realize SDES is fundamentally insecure, and secure it by running it over a VPN link to their protected servers (and my understanding is that they consider even that a compromise). And the devices must be TOTALLY locked down to any unencrypted network access. These will not be using WebRTC anytime soon, under any circumstance. > The argument that DTLS is *more secure* must face the reality that > no-one is using it and that SDES-SRTP is *widely diffused and > interoperable*. Widely diffused and interoperable may be (mostly) true, though I'll tell you that probably 99.x% of *deployed* VoIP devices do not *use* SDES (even if they support it), so arguments about deployment numbers are mostly irrelevant. Not totally irrelevant, of course. > All Internet operators will have to introduce Protocol Gateway. Due to the 'consent' requirement and other issues, this is likely anyways. And who are the "internet operators" in your estimation? > All mobile operators will have to introduce Protocol Gateway. They will anyways I believe. > All that subjects, if using just SDES-SRTP, would just need to "update > the software they already use to run VoIP infrastructure" with no need > to handle modification to the Media for Interworking. > > So definitely the choice to go for DTLS-SRTP is imho a wrong choice, > against any rationale for the diffusion of WebRTC standard, introducing > artificially complexity where it may be possible to keep it simple. There certainly is an argument for SDES. I don't agree about what it leads us to, but it's a reasoned argument. However, many of your assertions here I would not accept. -- Randell Jesup randell-ietf@jesup.org From pravindran@sonusnet.com Sat Mar 31 03:06:39 2012 Return-Path: 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 B278521F86CF for ; Sat, 31 Mar 2012 03:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.112 X-Spam-Level: X-Spam-Status: No, score=-5.112 tagged_above=-999 required=5 tests=[AWL=1.187, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 h34Ni5bTb2bn for ; Sat, 31 Mar 2012 03:06:38 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5877921F86C1 for ; Sat, 31 Mar 2012 03:06:38 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKT3bXLV2IjkwCLMMzbS4txGg0kbM/yOHM@postini.com; Sat, 31 Mar 2012 03:06:38 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 31 Mar 2012 06:06:59 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Sat, 31 Mar 2012 15:36:33 +0530 From: "Ravindran, Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] Consensus call regarding media security Thread-Index: AQHNDPJEz8d54ZuGqkmrgP2aJufnWZaBgBgw//+tvoCAAwF88A== Date: Sat, 31 Mar 2012 10:06:56 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E222F4B@inba-mail01.sonusnet.com> References: <4F732531.2030208@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> In-Reply-To: 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call regarding media security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 10:06:40 -0000 SW5ha2ksDQoNCkkgYWdyZWUgd2l0aCB5b3VyIGFyZ3VtZW50IG9mIGFsbG93aW5nIEhUVFAgYXMg aXQgZml0IHdpdGggdGhpcyB0cnVzdCBtb2RlbC4gDQoNClBsZWFzZSBub3RlIHRoYXQgSSByZXF1 ZXN0IGZvciBwbGFpbiBSVFAgd2l0aCB1c2VyIGNvbnNlbnQgKGNvbmZpZ3VyYXRpb24pIGFzIGl0 IHdpbGwgZml0IHdpdGhpbiB0cnVzdCBtb2RlbCB3aXRoIGV4Y2VwdGlvbi4gSSdtIHNheWluZyB0 aGF0IFNSVFAtRFRMUyBpcyB0aGUgb25seSBtZWNoYW5pc20gd2hpY2ggbWVldHMgYWxsIHRoZSBy ZXF1aXJlbWVudCBhcyBvZiBub3cgaW4gdGhlIGxpc3RlZCBjYW5kaWRhdGVzLiBIYXZpbmcgc2Fp ZCB0aGF0LCBpbiBjYXNlIGFueWJvZHkgY29udmluY2UgZm9yIGNoYW5naW5nIHRoZSB0cnVzdCBt b2RlbCB0aGVuIFNERVMgc2hhbGwgYmUgY29uc2lkZXJlZCBvciBTREVTIG1heSBiZSBwcmVmZXJy ZWQgb3ZlciBTUlRQLURUTFMuIElNTywgdHJ1c3QgbW9kZWwgc2hvdWxkIGhlbHAgZm9yIHNlbGVj dGluZyBzZWN1cml0eSBrZXkgbWVjaGFuaXNtLg0KDQpJJ2xsIHJlcGx5IHRvIGFub3RoZXIgdGhy ZWFkIHNlcGFyYXRlbHkuDQoNClRoYW5rcw0KUGFydGhhDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPkZyb206IEnDsWFraSBCYXogQ2FzdGlsbG8gW21haWx0bzppYmNAYWxpYXgubmV0 XQ0KPlNlbnQ6IFRodXJzZGF5LCBNYXJjaCAyOSwgMjAxMiAxMTowMyBQTQ0KPlRvOiBSYXZpbmRy YW4sIFBhcnRoYXNhcmF0aGkNCj5DYzogcnRjd2ViQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFty dGN3ZWJdIENvbnNlbnN1cyBjYWxsIHJlZ2FyZGluZyBtZWRpYSBzZWN1cml0eQ0KPg0KPjIwMTIv My8yOSBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkgPHByYXZpbmRyYW5Ac29udXNuZXQuY29tPjoN Cj4+IFdlYlJUQyB0cnVzdCBtb2RlbCBoYXMgdG8gYmUgY29uc2lkZXJlZCBhcyBvbmUgb2YgdGhl IG1haW4gZmFjdG9yIGZvcg0KPmRlY2lkaW5nIHRoZSBrZXkgbWVjaGFuaXNtLiBBRkFJSywgU0RF UyBkb2VzIG5vdCBmaXQgaW50byBXZWJSVEMgYXMNCj5Eci5FdmlsIEhUVFBTIFJUQ1dlYiBzZXJ2 ZXIgbXVzdCBiZSB0cnVzdGVkIGluIGNhc2Ugb2YgU0RFUy4gVGhlcmUgaXMgbm8NCj5tZWFucyB0 byB0cmFjayBvciBhbmFseXplIHdoZXRoZXIgRHIuRXZpbCBpbnZvbHZlcyBpbiBtb25pdG9yaW5n IG9yDQo+cmVjb3JkaW5nIG9yIHRlcm1pbmF0ZSB0aGUgbWVkaWEgdHJhZmZpYy4gwqBJdCB3aWxs IGJlIGdvb2QgaW4gY2FzZQ0KPndob2V2ZXIgYWR2b2NhdGUgZm9yIFNERVMgZXhwbGFpbiBob3cg U0RFUyBmaXRzIHdpdGhpbiBXZWJSVEMgdHJ1c3QNCj5tb2RlbC4NCj4NCj5JZiBEci4gRXZpbCBh dHRha3MgbXkgYmFjayB3ZWJwYWdlIGFuZCBvd25zIGl0LCBhbmQgdGhlbiBJIHZpc2l0IGl0DQo+ KEhUVFBTIHdpdGggdmFsaWQgY2VydGlmaWNhdGUpIGFuZCBlbnRlciBteSBiYWNrIGNyZWRlbnRp YWxzLi4uIGZvciBtZQ0KPnRoYXQgaXMgbXVjaCB3b3JzZSB0aGFuIHRoZSBjYXNlIHlvdSBkZXNj cmliZS4gU2hvdWxkIHdlIGRyb3AgSFRUUFMgdGhlbg0KPmJlY2F1c2UgaXQgZG9lcyBub3QgZml0 IDEwMCUgInNlY3VyaXR5IiByZXF1aXJlbWVudHM/DQo+DQo+QlRXOiBwcmV2aW91c2x5IHlvdSB3 YW50ZWQgdG8gYWxsb3cgcGxhaW4gUlRQIGluIFdlYlJUQy4uLiBhbmQgbm93IERUTFMtDQo+U1JU UCBpcyB0aGUgb25seSB2YWxpZCBzb2x1dGlvbj8gOikNCj4NCj4tLQ0KPknDsWFraSBCYXogQ2Fz dGlsbG8NCj48aWJjQGFsaWF4Lm5ldD4NCg==