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

John Mattsson <john.mattsson@ericsson.com> Wed, 05 March 2014 15:21 UTC

Return-Path: <john.mattsson@ericsson.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 C3B691A0270 for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 07:21:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 0NJlF4CN9OhD for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 07:21:14 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 08A981A014F for <rtcweb@ietf.org>; Wed, 5 Mar 2014 07:21:13 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-8a-531740e58efc
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F7.58.23809.5E047135; Wed, 5 Mar 2014 16:21:09 +0100 (CET)
Received: from ESESSMB307.ericsson.se ([169.254.7.220]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Wed, 5 Mar 2014 16:21:08 +0100
From: John Mattsson <john.mattsson@ericsson.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, tim panton <tim@phonefromhere.com>
Thread-Topic: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level
Thread-Index: AQHPOG7/fizbxTQF/UyT77go6S8SfprSdIKAgAAB5oCAABTlAA==
Date: Wed, 5 Mar 2014 15:21:07 +0000
Message-ID: <CF3CEC11.F93A%john.mattsson@ericsson.com>
References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <EEF5B1D0-7782-4EB8-90DF-F1D56B2D2ADC@phonefromhere.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com>
In-Reply-To: <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="utf-8"
Content-ID: <7C09A8FC97FB634DB2B5FF0198AD03F4@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje5TB/Fgg+8vTSw6JrNZrP3Xzm5x cfstRgdmjym/N7J6LFnyk8ljyaRGtgDmKC6blNSczLLUIn27BK6M7Zu3Mhb8UqnYsCKkgbFB pYuRk0NCwERi77+TTBC2mMSFe+vZQGwhgUOMErdX5HQxcgHZixkl5i9cCVbEJmAgMXdPA1iR iEC4xMd9f5lBbGYBdYk7i8+xg9jCAkESU9omAMU5gGqCJdqaRCDKnSSW729jBLFZBFQkVj56 BVbOK2AmcWbNIRaIvasYJSZvNASxOQVsJW7P7gQbzwh02/dTa5ggVolL3HoyH+pmAYkle84z Q9iiEi8f/2MFsUUF9CTuPZrLAhFXklh7eDsLyDnMApoS63fpQ4yxlpi+/BoLhK0oMaX7IdQ5 ghInZz5hmcAoMQvJtlkI3bOQdM9C0j0LSfcCRtZVjOy5iZk56eVGmxiBUXdwy2/VHYx3zokc YpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+OM0gpzZungeb1O05fs3zbJ 6TrbFYEv73iPmiYfuFSdOXF60MaNt5d3Ovk2XyyTW//im3PnzhObw5W/2vkeirJdbx20/+Ry I8t9Gf5zbrcnCMSyB09UdXfJr9RfvfYzp3/cwc7PaWu4U4xbbz80/nTE9bwF64tFJr7PzXWr Tp/REv9avXHvsZ1KLMUZiYZazEXFiQDxwVoGiAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MKtUgR8UZG1OWvhOyM0ycTkHjas
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [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 15:21:17 -0000


On 05/03/14 14:05, "Cullen Jennings (fluffy)" <fluffy@cisco.com> wrote:

>
>Well if people don’t want to allow the application to choose to encrypt
>this header or not, I will be arguing for MUST NOT encrypt the RTP
>headers - all of them.
>
>A recurring theme at IETF is that people trying to protect E2E privacy,
>do things that result in the real world having the only way they can
>build applications is to build middle boxes that pretend to to be an end
>to the things on both sides. This means that the middle boxes end up with
>100% ability to change everything and we loose all the protection we
>hoped to get with E2E security.

Yes, and I think this all-or-nothing problem is going to pop up a lot more
in the future. I think Cullen’s conferencing use case is a good example
where it would have been good to be able to encrypt media client-to-client
but certain rtp headers client-to-mixer (optimally with integrity still
being client-to-client).

John

> 
>
>
>On Mar 5, 2014, at 1:59 PM, tim panton <tim@phonefromhere.com> wrote:
>
>> 
>> On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy) <fluffy@cisco.com>
>>wrote:
>> 
>>> 
>>> 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 have to ask:
>> Does that matter enough to weaken user security for everyone else?
>> 
>> 
>>> 
>>> I would like to propose that the JS application can control  if the
>>>header is encrypted or not.
>> 
>> I am deeply uncomfortable about that. I am not a good enough
>>cryptographer to know, but my instinct
>> is that exposing the fact that (for example) most of the top bits of
>>the ulaw data are zeros in this packet
>> must be a risk.
>> 
>> I’m pretty confident that one could detect the pitch of the speaker and
>>probably fingerprint that down
>> to individuals or languages with enough data.
>> 
>>> 
>>> 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 am also uncomfortable about the number of little ad-hoc control
>>surfaces that we seem to be mandating
>> without an overall design.
>> 
>> My take is that we should push this out to 2.0 when hopefully we will
>>have a designed control surface in place.
>> 
>>> 
>>> 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.
>> 
>> That isn’t the line we have taken in any other encryption discussion.
>> 
>> Tim.
>> 
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb