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

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 06 March 2014 13:57 UTC

Return-Path: <magnus.westerlund@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 197351A0156 for <rtcweb@ietfa.amsl.com>; Thu, 6 Mar 2014 05:57:25 -0800 (PST)
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=[BAYES_00=-1.9, 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 7r2PzJPOm-SZ for <rtcweb@ietfa.amsl.com>; Thu, 6 Mar 2014 05:57:21 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 137EA1A0078 for <rtcweb@ietf.org>; Thu, 6 Mar 2014 05:57:20 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-7c-53187ebc4eed
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 07.9F.04249.CBE78135; Thu, 6 Mar 2014 14:57:16 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.347.0; Thu, 6 Mar 2014 14:57:15 +0100
Message-ID: <53187EB1.4010106@ericsson.com>
Date: Thu, 6 Mar 2014 13:57:05 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Justin Uberti <juberti@google.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>
References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <EEF5B1D0-7782-4EB8-90DF-F1D56B2D2ADC@phonefromhere.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> <CAOJ7v-3JAKZDHtrx9J2v=hqksQ9xdz7XW_1HbqioEzWMqUrn7A@mail.gmail.com>
In-Reply-To: <CAOJ7v-3JAKZDHtrx9J2v=hqksQ9xdz7XW_1HbqioEzWMqUrn7A@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+Jvje6eOolgg3fTtSw6JrNZbJ0qZLH2 Xzu7A7PHlN8bWT0WbCr1WLLkJ1MAcxSXTUpqTmZZapG+XQJXxpvPE9gLVulWvJy5gLWBcbZS FyMnh4SAicTpq3PZIWwxiQv31rN1MXJxCAkcYZRof7mOFSQhJLCMUWLrkmIQm1dAW+Lf5+9g DSwCKhKbrk0Cs9kELCRu/mhkA7FFBYIldh74zQhRLyhxcuYTli5GDg4RgXCJaRtVQMLMAuoS dxafA2sVFgiSmNI2gRli1WtGiStdcSA2p0CgxLTDXYwgrRIC4hI9jUEQrQYSRxbNYYWw5SWa t86GatWWaGjqYJ3AKDQLyeJZSFpmIWlZwMi8ipGjOLU4KTfdyGATIzBsD275bbGD8fJfm0OM 0hwsSuK8H986BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgrFm8vcKDqey+hGtYqOa2+X4d hRqfHvQ5PbZi5F7O32thvOKHj+ukJfGvS+M2LdhysOVkj8Jh7wLBqzf+uvnFbda1bG/X3SLN vLh+tpKEuOfuQ2uu2ofOiBblvF/8TMUw9t2buyKvNn9YXrz5cWeHUJ38sRXMzGkeYjOv7nK8 d6yh9lnQ/wO+SizFGYmGWsxFxYkAqRryXSkCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qO_YpR68TXhdV-NyTRK6yzac6Zw
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: Thu, 06 Mar 2014 13:57:25 -0000

Hi,

I am not okay with changing 1). I think we MUST mandate implementation
of Header Extension encryption if you implement the audio level header
extensions.

When it comes to use level I am fine with reducing this to RECOMMENDED,
with a reasonable motivation, like enabling middleboxes that can avoid
to be in the security context to read these headers. Thus resulting in a
trade-off between what information one leaks, versus the impact of
having the middlebox in the security context. It may also need to be
made clear that the trade-off for this may further be changed as we
learn more about the feasibility of performing the attack of learning
the content of the voice communication based on the audio levels.

I realize that the above is mostly useful if one actually gets a control
knob for this. But, that is a question for the API.

>From my perspective, allowing for exceptions to the default encryption
on, when so indicated, is the best way forward.

Cheers

Magnus


On 2014-03-05 14:25, Justin Uberti wrote:
> So there are three things here:
> 1) MUST the implementation offer encrypted header extensions? (i.e.
> mandatory-to-implement)
> 2) MUST the implementation use encrypted header extensions? (i.e.
> mandatory-to-use)
> 3) MUST the implementation expose an API to control this? (i.e. no SDP
> munging needed)
> 
> I think we want yes for #1, no for #2, and #3 is potentially interesting
> but out of scope for 1.0.
> That gives encrypted headers for audio on by default, but remote parties
> can negotiate this off using RFC 6904 mechanisms.
> 
> 
> 
> On Wed, Mar 5, 2014 at 2:05 PM, Cullen Jennings (fluffy)
> <fluffy@cisco.com <mailto: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.
> 
> 
>     On Mar 5, 2014, at 1:59 PM, tim panton <tim@phonefromhere.com
>     <mailto:tim@phonefromhere.com>> wrote:
> 
>     >
>     > On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy)
>     <fluffy@cisco.com <mailto: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 <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------