Re: [Perc] Last Call: <draft-ietf-perc-private-media-framework-08.txt> (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard

Bernard Aboba <bernard.aboba@gmail.com> Thu, 14 February 2019 23:19 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC9D131249; Thu, 14 Feb 2019 15:19:53 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LKkl0qauWD9I; Thu, 14 Feb 2019 15:19:52 -0800 (PST)
Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0353812F1A5; Thu, 14 Feb 2019 15:19:52 -0800 (PST)
Received: by mail-vk1-xa2b.google.com with SMTP id e131so1811759vkf.10; Thu, 14 Feb 2019 15:19:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uCEXu+KCEP4UMf50Jzp6WoPqrDEap8uMHWklEobRNjI=; b=AijcLakIWaw6N3YYdKl+DuH8oDHO8oR4ETq6uo+/EvJ8W0b2NPUfoWhAlhXLeh2G2q z158kk0yI4/ch45NfEcI3ZH1AtZfQQa5M/lq/HI2Iguyr0OJakDR21ORz89jj0hLS5V8 Aj16BVz1rCeQpJ8CfXLIYz202vbQvLzRZ66zS9nVOCk17Q6CCWdSWo7tmeqBSnMb+fT5 FE0RhInsbUqda6ac5AsZWZI3MLK9ag2+E9p2mMEhGAUB7bmtXWArDHJz/ejDQ8OVnrpe aB7nm57SSIQUewWo/smBlsjqCwGYhqOHDUbqR8nJvLw9zHteV7t2VbUXbdarJ6eVwH0H nzlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uCEXu+KCEP4UMf50Jzp6WoPqrDEap8uMHWklEobRNjI=; b=Z1lFO6v/W7GzOJpaEGnFFCgQoX2+x948F38+FtSg/XT1nnJNmr2P69xv0md/vVItk/ hfC7nYB9GFEMA7If3/s22nomK7EEWB0V4+zqCKbpfSwh3cQXJTsYYr9NZqqljdUTG/TC 3UTumVMEO2FuN1GV/DisiDrlPbVjjyvi7lKSU7NlGrQaXmNDhOrmEFrV82IKBc4tz04s Bn4m6jv9TPjOuqcBkHF/OLU7WwdfeZHbd680i8+FHwA8iusb8qOjPRycosGMMUxoxtXp ija2NWxj79d65NqOpINRZUqJfeh92iNEC3QcKRna9EPDAjFEwWnvpsTiCkftFNq+E8pN IyUw==
X-Gm-Message-State: AHQUAuZ4ukzp0V1O57B9sexGO9RPy6IrVu9eaUwcvz9keMohcmtNVNX3 a+8jprcyjOaR3BoOgxhlw1K14LBy/YSYPUdeNeM=
X-Google-Smtp-Source: AHgI3IY7q4F3baHeNZzmNK/neRhkNRce9mNxEUPR3GlZlJqyuXfM0LqfcNnTmC+C2QfI6waSBRFFec0m69lGDWxQnVc=
X-Received: by 2002:a1f:82ce:: with SMTP id e197mr3530800vkd.58.1550186390468; Thu, 14 Feb 2019 15:19:50 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com> <CAOW+2dtxnSYOPPWxodN633O=dPOQaUnu7eYvgUYkPYRt6iWbaw@mail.gmail.com> <CAPvvaaK_VUXvy2=1TBGfBWWYxiBdXBzuR=Y-rnAdJyg=M8OfQQ@mail.gmail.com> <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com> <C6FEAEB9-CF8E-48AF-B03F-1406FF9CB303@cosmosoftware.io> <CAOW+2ducgj400pk3xPFAkRYxnYvqwhMsE9rOO0u9PgLpniaaRA@mail.gmail.com> <CAPvvaaLYFeNkZ4Pfdh4pa2btNW6EGZBnAOvXzVZ9egU8V-gBNQ@mail.gmail.com> <CAOW+2dvom822NgjF7OAa2A8YDeqZ+mbCqA=fUcq-Y49oFyGpsA@mail.gmail.com> <CAPvvaa+EzwgMXB_t7ZVTBgZH2y4=neUm1RymUNKnMV-6zyGPaQ@mail.gmail.com> <a74a8239-27dc-5704-096b-05cc5e02bd18@gmail.com> <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> <CAPvvaaJDo6vYj00NMVQEKHnrMHr1EoQydTsZ+7WtdEgyoy_GAQ@mail.gmail.com> <1F1100AC-B9D2-4650-8663-A6D380721688@mozilla.com> <2807c153-60ba-a741-f0ad-72c98d8d77bb@gmail.com> <753988DB-FC9A-4E8F-B495-347AD943B6C8@gmail.com> <CA+ag07bixdC9Uyj26XMf_PtNZQjgvGLm0RMLpSZmdmS5ndzS6A@mail.gmail.com>
In-Reply-To: <CA+ag07bixdC9Uyj26XMf_PtNZQjgvGLm0RMLpSZmdmS5ndzS6A@mail.gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Thu, 14 Feb 2019 15:19:40 -0800
Message-ID: <CAOW+2dskwDGb-6XvWP0dE7+M=V3z0aDBOYcPmrXDEXvePs3g4A@mail.gmail.com>
Subject: Re: [Perc] Last Call: <draft-ietf-perc-private-media-framework-08.txt> (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: Nils Ohlmeier <nohlmeier@mozilla.com>, Emil Ivov <emcho@jitsi.org>, IETF discussion list <ietf@ietf.org>, Emad Omara <emadomara@google.com>, perc@ietf.org, "hta@google.com" <hta@google.com>, Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io>, Lorenzo Miniero <lorenzo@meetecho.com>
Content-Type: multipart/alternative; boundary="00000000000023c22e0581e2e5eb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/80uAHrRPVhIuy3qHJ2oyjbohk9g>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2019 23:19:59 -0000

"I don’t recall, and I don’t see anything in the notes or email consensus
call, that would suggest the consensus included anything along the lines
“it’s okay to let the js application have the media keys.”

[BA] The PERC framework document only mentions that the endpoint is
trusted, but does not go into further detail.  That detail becomes
important when attempting to understand the provable security properties of
PERC (e.g. what attacks are prevented, what attacks are still allowed). As
an example, if the goal is not only to protect against access to cleartext
media within the MDD, but also the ability of endpoints to mis-use the
cleartext media (e.g. to create "deep fakes"), then it is necessary to
restrict access to cleartext media within the PERC application itself (e.g.
no ability to record or even modify cleartext media).  That goes beyond the
"no access to media keys in JS" dictum to "no access to cleartext media for
any PERC application, native or Web".  Once you've gone there, the
distinction between the problem solved by PERC and content protection
technologies begins to disappear.  Keep in mind though that technologies
such as EME are transport-independent - EME can be used when transporting
media over the SCTP data channel, for example.

On Wed, Feb 13, 2019 at 11:16 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

>
>
> El jue., 14 feb. 2019 2:01, Bernard Aboba <bernard.aboba@gmail.com>
> escribió:
>
>> On Feb 13, 2019, at 3:47 PM, Sergio Garcia Murillo <
>> sergio.garcia.murillo@gmail.com> wrote:
>>
>> All SFUs I am aware of performs SSRC rewriting, it is much more than
>> implementation convenience.
>>
>> [BA] In particular, reusing an SSRC for the “dominant speaker” (which can
>> change)  is a common practice with switching of audio and video going
>> together.
>>
>
> would love to see how simulcast is expected to work without ssrc rewriting
> (and without mid)
>
> Best regards
> Sergio
>
>>