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

Bernard Aboba <bernard.aboba@gmail.com> Tue, 11 March 2014 04:47 UTC

Return-Path: <bernard.aboba@gmail.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 CED8F1A0361 for <rtcweb@ietfa.amsl.com>; Mon, 10 Mar 2014 21:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 pJhrWLWtPTKg for <rtcweb@ietfa.amsl.com>; Mon, 10 Mar 2014 21:47:55 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id E88FC1A04AE for <rtcweb@ietf.org>; Mon, 10 Mar 2014 21:47:54 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id n15so326820wiw.5 for <rtcweb@ietf.org>; Mon, 10 Mar 2014 21:47:49 -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; bh=YiSk2Mgy7qbBi5jV4CWMGuGJ1QmnUzwo4iYCl8aHO/g=; b=y/Gv7MxDQhDyXY9mn+y8AXgJNdPAkdPTF7UjpqIoCB8mHq5IlNIESHeIaDm9qjKyua iEPW20RfMml9rcNxCt330ZNcEOgGqFN56sWlvWbEeGLeaJvv8+eK2ABvRjgKKYvBcSaa YnDbI+C+gFVqGGQuxsOx9gyOQ5CK+1G1LriONE0+VC34ydo3ww/JLxjs7Zn22Ir+iUav KVzjXGGUAfjtoo7s1PWsxcynrJWNuL7HKH664cGRFbiZLwSnLxQJjlRnc1o5voD9jh38 ryH0IWMleIRtnB7ph/JlTBW7kdz+jDnfX6OS01RpXiA1+e+PrJ2kBbfJSZxXYDroMIlP wIpA==
X-Received: by 10.180.98.200 with SMTP id ek8mr1304555wib.4.1394513268910; Mon, 10 Mar 2014 21:47:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.161.66 with HTTP; Mon, 10 Mar 2014 21:47:28 -0700 (PDT)
In-Reply-To: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com>
References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 10 Mar 2014 21:47:28 -0700
Message-ID: <CAOW+2dugjdQvXtFczz6fAmMzyU104VkcjnmoT8h4+bV1yQa9aQ@mail.gmail.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Content-Type: multipart/alternative; boundary=f46d0442886007319104f44d6c59
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8S-q1Xi3GlgbIGgUPRsskoeCSzk
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: Tue, 11 Mar 2014 04:47:58 -0000

Cullen said:

"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."

[BA] I am also not enthused about mandating encryption of header
extensions. However, in the interest of fairness, it is worth pointing out
that header extensions are optional, so if a particular extension is
encrypted, the mixer can always ignore it (and in this case, thereby do
more work mixing muted audio streams).  So my take would be to say SHOULD
encrypt Client-to-MIxer Audio level, but leave this up to negotiation so
that if the mixer doesn't want it encrypted, it can turn that off.


On Wed, Mar 5, 2014 at 4:32 AM, Cullen Jennings (fluffy)
<fluffy@cisco.com>wrote;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 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.
>
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>