[rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Wed, 05 March 2014 12:32 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62D91A0489 for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 04:32:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.048
X-Spam-Level:
X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_njRJopSAfw for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 04:32:49 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id BE3F11A0424 for <rtcweb@ietf.org>; Wed, 5 Mar 2014 04:32:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1194; q=dns/txt; s=iport; t=1394022761; x=1395232361; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=8CY5jp6faeYRz9GGg2EgY0FN1Z8rO809mKSwJhkUP+g=; b=QLw4rDdGJKGnPDTbl9Gmb1wSa7q0eR5NJIx0zfY3XYtvDYRNbdOmJYN4 YocUR2a9jUOWE+BfpGdOyhkddliOxiAHjandg/Jb/PfTTfmRkZQABxWc8 n+kLvVNCEt1bP1ypsij45Iqnp3qk8wM0GcJEpBZZoTHEDG3NDdprDUdJz 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Am0KAEkYF1OtJXG//2dsb2JhbAA5IYMGgRLCJBZ0giw6UQE+QicEiAyeBq9sF5F8gRQEmD2SK4Mtgio
X-IronPort-AV: E=Sophos;i="4.97,592,1389744000"; d="scan'208";a="25075710"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-5.cisco.com with ESMTP; 05 Mar 2014 12:32:41 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s25CWeok006577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <rtcweb@ietf.org>; Wed, 5 Mar 2014 12:32:40 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.113]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 06:32:40 -0600
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level
Thread-Index: AQHPOG7/fizbxTQF/UyT77go6S8Sfg==
Date: Wed, 05 Mar 2014 12:32:39 +0000
Message-ID: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.107.238]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D29C47EF421B5E47B631B7D48816AD52@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MmGLRmDLuYzNWkeln38wMl492FQ
Subject: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Mar 2014 12:32:54 -0000

I am opposed to mandating that Client-to-Mixer Audio Level RTP header is REQUIRED to be encrypted. It means that we can not really build conferencing system where the mixers do not have access to decrypt the media.

I would like to propose that the JS application can control  if the header is encrypted or not.  

I am aware of the paper that suggests these audio levels can reveal the contents of the conversation. There is some element of truth to this. There is also some element of truth to the point that if this was true, speech recognition system would work better than they do. Encrypting this or not is a risk that the application using the header extension needs to evaluate, and WebRTC system needs to provide the applications with a control surfaces that allows them to use this in the way the applications desires.

I will note that an normal application that used this header could decide if it was encrypted or not, what is different in RTCWeb is that we are building a platform and my view is that this platform should allow the applications build on the platform to decide the tradeoffs of risk for encrypting this or not.