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> Sat, 02 February 2019 20:42 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 7790012F1AB; Sat, 2 Feb 2019 12:42:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 9W3zyDHfkWei; Sat, 2 Feb 2019 12:42:51 -0800 (PST)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 8FE44130E6D; Sat, 2 Feb 2019 12:42:51 -0800 (PST)
Received: by mail-yb1-xb34.google.com with SMTP id s76so653306ybs.10; Sat, 02 Feb 2019 12:42:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wM5K3DyEdJ1UJUK+K64sWjhZbAcDQ7t2uKv9G119VZE=; b=IdmzA6uGPXZcyhEabUwiLZfPfpPJn51VEPz5SWwLOXh75I71/6o2/HB3p+4VnCyJUp 7eTrW4yvv4ExDpv2rHgRJ3OcY8O3jxKDyW+F+peM4pbQkvi5SnIPDNnfNTyzXzqSIxHh OJz76ySICuAgVY6x6tENSrdnL2Emdhp1UxaOGwZqvMdl5VXWdVbICA4RxZe+5BYP511A X9tRxupMvCM3m3RE/06V74gwvD3lvSNssEK809krlr4fKr8oYufLiv1Y8SIn8imdkE6f XY+XUlfdyLcE7dvhPs0LTIfwfkAhtL7R/wilRKSrdnX5WzYEkMHfgvWuBopwZwP+75BB hbFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wM5K3DyEdJ1UJUK+K64sWjhZbAcDQ7t2uKv9G119VZE=; b=HoRqu2RliD0O53wcyiv9SCFllhSt7Oz3U1Tfi8rPJABvJw9+vi5GrW/2vyxNdi3Dzz xn2+284segowmpJyuv1KCPFx7ywEmc2iMlXG50D5JOyfzM+/Rc2JzThGy8z2Rwm2dB9b lJ1OXPSASbH7QAjTFUHQqhwTkyMFu82KernC9hNxxN5k7o5q7LtxvVmAWfFpOvmWgMNb k1EeM5L4VekCMHvAo7u4aQfUGJOgqveCo02oWo/OeT/Y1Px5FLjGmctoRlO4mxevT9Or DuO3hgE4o5gly2sJG+Wmk1O7oEgn/o/DkeUVsxZvoQ7IUI1mVmxelI8AUNnoCNZxzflm 5PAA==
X-Gm-Message-State: AHQUAuYSncC8nkv74H7QftiJWVUJAtkfBW0auQz6fxhl9oqBcFh3QjQu hpzb62wcKX48k8dGSxFM2QlUm5kC
X-Google-Smtp-Source: AHgI3IZdOui0XxByUMTRS+ZASSmTTcqJNT71WBa+ppNuncDGUaojLgWWfKvyG8syBdlXgNMHtJWKcA==
X-Received: by 2002:a25:76d0:: with SMTP id r199mr10838918ybc.70.1549140170047; Sat, 02 Feb 2019 12:42:50 -0800 (PST)
Received: from ?IPv6:2600:380:4d18:80a5:b191:5743:b4d3:96d3? ([2600:380:4d18:80a5:b191:5743:b4d3:96d3]) by smtp.gmail.com with ESMTPSA id z2sm4248257ywe.32.2019.02.02.12.42.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Feb 2019 12:42:48 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-91A19C17-CF5D-4C74-B994-FF36330BF48C"
Mime-Version: 1.0 (1.0)
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
From: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: iPhone Mail (16D39)
In-Reply-To: <a74a8239-27dc-5704-096b-05cc5e02bd18@gmail.com>
Date: Sat, 02 Feb 2019 15:42:46 -0500
Cc: Emil Ivov <emcho@jitsi.org>, Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io>, IETF discussion list <ietf@ietf.org>, Emad Omara <emadomara@google.com>, perc@ietf.org, "hta@google.com" <hta@google.com>, Sergio Garcia Murillo <sergio.garcia.murillo@cosmosoftware.io>, Lorenzo Miniero <lorenzo@meetecho.com>
Content-Transfer-Encoding: 7bit
Message-Id: <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com>
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com> <CAOW+2dui_imxyysOCrtdH7OiDcbooi83qtCDifEY3HQ6MpigWA@mail.gmail.com> <CAL02cgSip2cLr8a1+zfK2cg+n8gqUMc9CKPmb7mWd2iLSiRf-g@mail.gmail.com> <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.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>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/6AfhjNLLRA0UBi4B9lp62MCPk-w>
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: Sat, 02 Feb 2019 20:42:56 -0000

Sergio -

In your opinion, what portions of PERC are salvageable, if any? Is this a situation where we need to start over or could some aspect of PERC (e.g. Double if the triple encryption problem were fixed) be suitably modified and then implemented?

> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
> 
> I think Emil and Bernard have described quite precisely where we are and how we managed to get here.
> 
> In my opinion it would be a big mistake to consider PERC as *THE* solution for end to end encryption for multiconferencing, as if there was a one size fits all solution for the problem.
> 
> Speaking from a WebRTC perspective, PERC, apart of have taken some controversial technical decisions (OHB as header, the ssrc rewriting issue and reverse the the order of FEC/RTX and SRTP), does not take into consideration the specifics of WebRTC (it could be argued that that was not in the scope of this group), like the role of the js app, the possibility of allowing key management in js, or the interaction with Idp and isolated media streams. Not to speak about the recent discussions about full frame vs per packet encryption or QUIC.
> 
> Best regards
> Sergio
> 
> 
>> On 02/02/2019 18:42, Emil Ivov wrote:
>> 
>> 
>>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>>> Emil said:
>>> 
>>> "The need to do a triple encryption for example is a particularly egregious consequence of the order problem. That’s a problem specific to the “double” documents."
>>> 
>>> [BA] Can you describe how the need for "triple               encryption" arises?  The framework document doesn't even mention the issues with ordering of FEC/RTX/RED and encryption, let alone the need for "triple encryption". 
>> 
>> One of the goals that some members of the group seemed to have was to allow specific applications to become PERC-compliant without changing the app code itself and by simply replacing the libsrtp library with a PERC-enabled one. 
>> 
>> I don’t know that this goal is a direct consequence of the framework’s conceptual approach (contrary to the imposition of key distribution and negotiation). I think it simply carries a promise for some minimal pragmatic value to some implementers.
>> 
>> The issue with this approach is that it leaves hop-by-hop protection mechanisms such FEC and RTC unavailable to the SFU as they are usually performed before SRTP, which would make them e2e encrypted.
>> 
>> The solution to that is simple. One merely needs to perform e2e encryption first, then apply FEC and/or RTX and only then apply the second (hop-by-hop) layer of SRTP.
>> 
>> This approach was referred to as “wedging RTX and FEC” as it places them in between the two encryption operations.
>> 
>> While wedging appeared to have overall support in hallway discussions by all SFU implementors except potentially one, it was mysteriously rejected by a subset of the WG and replaced with the following:
>> 
>> Applications will apply SRTP-double first and, those that need to use FEC and RTX would have to apply them only after. 
>> 
>> It was quickly pointed out that this not only destroys the stated “don’t-change-the-app” goal, but also leaves RTX and mostly FEC unprotected and FEC receivers vulnerable to DoS. To this the proponents of this approach simply replied with: “well, those of you who use FEC/RTX will simply do a third round of SRTP”, thus arriving at a total of three encryptions for every packet..
>> 
>> The discussions around this topic were highly contentious.
>> 
>> Hope this makes things clear,
>> Emil
>> 
>> 
>>> 
>>>> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov <emcho@jitsi.org> wrote:
>>>> Yes pretty much those.
>>>> 
>>>> The need to do a triple encryption for example is a particularly egregious consequence of the order problem. That’s a problem specific to the “double” documents.
>>>> 
>>>> I would however also say that the decision to bake one specific way of performing key negotiation into the framework rather than leaving it open was both unnecessary and quite problematic.
>>>> 
>>>> Emil
>>>> 
>>>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>>>>> "on the consensus not reached on this and other topics."
>>>>> 
>>>>> [BA] Out of curiosity, what other topics do you consider to be problematic within the framework?  I am aware of at least two others where implementers have chosen different paths than in the PERC framework:
>>>>> 
>>>>> * Order of application of encryption versus FEC/RTX/RED
>>>>> * Whole frame encryption versus payload encryption
>>>>> 
>>>>> With respect to consensus, this is IETF last call, one of whose purposes is to determine whether there is IETF consensus to publish this document as a Proposed Standard.  Are you saying that you do not agree that there is an IETF consensus to publish this document as a Proposed Standard?  Or that there is no IETF consensus to publish *any* of the PERC WG output as a Proposed Standard? 
>>>>> 
>>>>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io> wrote:
>>>>>> +1 on ssrc rewriting, and on the consensus not reached on this and other topics.
>>>>>> 
>>>>>> Sent from my iPhone
>>>>>> 
>>>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero <lorenzo@meetecho.com> wrote:
>>>>>> 
>>>>>>> +1, SSRC rewriting is pretty much fundamental to all SFUs out there.
>>>>>>> 
>>>>>>> Lorenzo
>>>>>>> 
>>>>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov <emcho@jitsi.org> ha scritto:
>>>>>>>> 
>>>>>>>> I want to second that as it is a particularly major problem: not allowing SSRC rewriting makes the entire framework unusable with SFU implementation I represent as well as every other SFU I am familiar with.
>>>>>>>> 
>>>>>>>> I am also not sure that I agree with “SSRC rewriting could not be allowed” is a conclusion that ever had any consensus in PERC, regardless of what WG leadership is trying to make everyone believe.
>>>>>>>> 
>>>>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>>>>>>>>> Richard said:
>>>>>>>>> 
>>>>>>>>> "Again, the answer is clear here, but the document should be clearer.  The working group discussed SSRC rewriting several times, and concluded that SSRC rewriting could not be allowed in this system.  This decision is reflected, e.g., in the fact that the Double transform does not allow modification of SSRCs."
>>>>>>>>> 
>>>>>>>>> [BA]  Not being able to rewrite SSRCs has                                                 some major implications with respect to requirements on PERC endpoints.  Typically today's MDD will switch between the simulcast streams provided by an endpoint, forwarding only a single stream to other participants, based on the bandwidth, resolution and framerates.  If rewriting of SSRCs is not possible, do PERC endpoints need to be able to receive simulcast? If PERC endpoints do need to be able to receive simulcast, what are the requirements for endpoints?  For example, should endpoints expect the MDD to use RID header extensions to identify the incoming simulcast streams? 
>>>>>>>>> 
>>>>>>>>> Receiving of simulcast is tricky because the endpoint is receiving multiple streams with different sequence number spaces which may contain holes because of reordering or loss. This not only complicates the application of RTX, RED and FEC, but also the operation of the endpoint.  As a result, as noted in the WEBRTC specification Section 5.4.1, support for reception of simulcast is optional. I am aware of two ORTC implementations that have attempted to support simulcast reception, neither of which is robust in scenarios with considerable loss and/or reordering.  And neither implementation supports the RID header extension on received simulcast streams.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
>>>>>>>>>>> On 01/02/2019 17:18, Richard Barnes wrote:
>>>>>>>>>>> So I would propose we add something like the following to this definition: 
>>>>>>>>>>> 
>>>>>>>>>>> "In the context of WebRTC, where control of a session is divided between a JavaScript application and a browser, the browser acts as the Trusted Endpoint for purposes of this framework (just as it acts as the endpoint for DTLS-SRTP in one-to-one calls).
>>>>>>>>>> 
>>>>>>>>>> If we decide to adopt perc (big if) in webrtc, shouldn't this be defined within the https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-17 doc ?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>    Optimally, we would not rely on trust in any entities other than the
>>>>>>>>>>    browser.  However, this is unfortunately not possible if we wish to
>>>>>>>>>>    have a functional system.  Other network elements fall into two
>>>>>>>>>>    categories: those which can be authenticated by the browser and thus
>>>>>>>>>>    can be granted permissions to access sensitive resources, and those
>>>>>>>>>>    which cannot be authenticated and thus are untrusted.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> WebRTC already IdP as trusted for identity purposes, so it should be up to the RTCWEB group to decide what is a trusted endpoint and what is not in webrtc. As Bernard is stating, we could decide that there are other key management solutions trusted (even in JS or WASM), as for for example is being                                                     done in EME:
>>>>>>>>>> 
>>>>>>>>>> https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryption
>>>>>>>>>> 
>>>>>>>>>> Best regards
>>>>>>>>>> 
>>>>>>>>>> Sergio
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Perc mailing list
>>>>>>>>>> Perc@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>>>> -- 
>>>>>>>> sent from my mobile
>>>>>>> 
>>>>>>> -- 
>>>>>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
>>>> -- 
>>>> sent from my mobile
>> -- 
>> sent from my mobile
>> 
>> 
>> _______________________________________________
>> Perc mailing list
>> Perc@ietf.org
>> https://www.ietf.org/mailman/listinfo/perc
>