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

Justin Uberti <juberti@google.com> Wed, 05 March 2014 14:26 UTC

Return-Path: <juberti@google.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 9D4E01A0505 for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 06:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Level:
X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 1Gj45SXzpHMy for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 06:26:10 -0800 (PST)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id C01B41A0537 for <rtcweb@ietf.org>; Wed, 5 Mar 2014 06:26:06 -0800 (PST)
Received: by mail-ob0-f169.google.com with SMTP id va2so1050838obc.14 for <rtcweb@ietf.org>; Wed, 05 Mar 2014 06:26:03 -0800 (PST)
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; bh=u7JF0CPe+VH8de1q3u1Tq//sBgUeR9DJMpeMWCB0Wec=; b=QHNEccdfGHgyfQEsi4V9s6WP/YgprwC/5je4zn+YD3H3x69Ez9SGgA5HJ8ZGLuYJvA /SrxqxeomxM6tXIfa56ZNgUQn4XnfOK0FoTj9OpFPR+AafdFutVcMBNliy0pVF9CLz6n aHN9FC5NDToQ751SJ1yN2SRMC4LGJ3UeAIfwQfKjsusucuELIUn4FxiZ6292pYX9Pmhy mdpfsvms8SJSism/uk6O8CK6QgGv59AFO2WFKgjcSxPDHfxq/J9o+Fx90pFzLypAyRs5 4rEO175QoFDkCaTEiC7WElL04nl2NaHk3UrQpefhu0IPyuRYKV7eNPd6S2332qcKwh7d umxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=u7JF0CPe+VH8de1q3u1Tq//sBgUeR9DJMpeMWCB0Wec=; b=BeEfzwE8Q9AJ3xwlugjMzbIt5ufRTAJI2z6vy+2fkQWFyw41JmNbgIut2eKFc2o5k8 Yziu52T1PWjqBu12mN0jY14qvXLf1ULx+qJIq2DG3nDs0tNK8z2mGY3FqI5S1fkfxbMl 6mawvZfHGspzE8o4/qWVMud0lXXxTc0s5xZytpNiVlqmQaZZqyFw46BDjJZ1X6jwOb7y QF4GDa8MXpvvR+8Er77Mb3ywTJiG+WqId7hHMRyXsvFjsxM53s3Az7FhFfOMKvlyMeJ+ rSESi48xzVwvY4dlhe3RMUWoLfC49aKcNb7ANMlPtVC7ukXJtYxKPr6G/oPvpgYjzzF2 scGA==
X-Gm-Message-State: ALoCoQnlPuB6yHvgzLUcNaDlB70yqw+t5zhsMb61hWQMhl2nQEI3EejZ+L48e17D44jeSMhIUVjYQoIjM/dH+u9Qep6u8c6PEZ1wg84Wzyzj/z66e1jSvFMcnXS2npch48A3hyAMLZfVJkGth6J69Z26XM08K6h+WAf+fWKKCUOVqPV02j+5Rb5Ho0870+Cle9M5nvS1eiFh
X-Received: by 10.60.119.73 with SMTP id ks9mr568955oeb.75.1394029563014; Wed, 05 Mar 2014 06:26:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.96.230 with HTTP; Wed, 5 Mar 2014 06:25:42 -0800 (PST)
In-Reply-To: <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com>
References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <EEF5B1D0-7782-4EB8-90DF-F1D56B2D2ADC@phonefromhere.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 5 Mar 2014 14:25:42 +0000
Message-ID: <CAOJ7v-3JAKZDHtrx9J2v=hqksQ9xdz7XW_1HbqioEzWMqUrn7A@mail.gmail.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Content-Type: multipart/alternative; boundary=047d7b33cddce9149404f3dccc44
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/soGJf0bIx08sK88cPxn5vik4VFc
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 14:26:13 -0000

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>wrote;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> 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
>