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

Emil Ivov <emcho@jitsi.org> Sat, 02 February 2019 19:08 UTC

Return-Path: <emcho@jitsi.org>
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 5F8ED12785F for <ietf@ietfa.amsl.com>; Sat, 2 Feb 2019 11:08:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level:
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=jitsi-org.20150623.gappssmtp.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 ZXR0GEmYtQvc for <ietf@ietfa.amsl.com>; Sat, 2 Feb 2019 11:08:06 -0800 (PST)
Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (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 5AB121228B7 for <ietf@ietf.org>; Sat, 2 Feb 2019 11:08:06 -0800 (PST)
Received: by mail-vs1-xe44.google.com with SMTP id v205so6291250vsc.3 for <ietf@ietf.org>; Sat, 02 Feb 2019 11:08:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xhx39yTIz6c9yDM5RUtmgeCrs8oCjei3eD0KLPyZ0e0=; b=WiEF1Ytf2DbGTd+CoZq0vm/X9qJaCNKmjgHymFp/RSuoZNq4Y27Q6NK8+Scc+sQ0nN AJk4EdBpejGecepmLUI1GksgEuMIay71dIT8uAy9EEivog3deoEj1LTMWP6eBL3jR0Nt 8w1JvL+5QunNTvqkbIbtOTSak5uoJFrbptlQePN5AyJwLwO89I4uETo8PK2O0FfA9ez0 gC2vMDdb8hjeKql0plh0qigLs1/4VjcEUpHmn4UzyRCKdpz3dJd0wnAOkr2UIXyGHFt+ WC9NPRNWVbl7xX1F6vyqBR4X1hQChnf3drueVf5/3Fz1sKBn/K3vUKzhAjNvhp5pzzCh 1r8g==
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=xhx39yTIz6c9yDM5RUtmgeCrs8oCjei3eD0KLPyZ0e0=; b=lk0oOlNRDW37xKPA/L8bTWGmJscjJRxhBvgKPkFHG5AvtBXHKalJdAZDcXtV3Li/uq c0vTy9QlxjgGXFb+2VutHURI1C9PSPlt7HAAviRbONSwMRz19DCLg9JtV848Gtv4FYLE pR2qISmwLYpxfcMqYQZYFFTF1H7kHBr+Y6ocy8fARf7b+gexExJLFvHS4KsM0PWEwlQ9 w1aNffxwNUBSQrKdNz1FU8Dqw82Khf8Gj/j4yAHw65mGCOQN/W3y15WFfl7zLCOIot/Q UJKrulra3v4/4qpN2tbA/HEHEFlqNwjU4zKRsAdcXVyCl+16ky9THpLxJ/3L6eLKFdGT z1/g==
X-Gm-Message-State: AJcUukcua3ruebHz35ff2vEilHLwIjg6pmTEcqZKhLr0yUali0EGQ5LT 9Q9mjfiQFjYWgUF4fzFUbwUANylRwxpfmst3q6Xoxg==
X-Google-Smtp-Source: ALg8bN6lzb65zttb4Bp/55yOdjzvdCUe4lWmSNUbPRaw/PMjHjsIjLMntm8tiUqjjhecGg+bEXk1lh64srY3hAvci94=
X-Received: by 2002:a67:784e:: with SMTP id t75mr17652011vsc.236.1549134484935; Sat, 02 Feb 2019 11:08:04 -0800 (PST)
MIME-Version: 1.0
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> <CAOW+2dsM0pe+EgFBJD_3bGZFwa5a+zOVBC4CdvwYM5WX3X3wvw@mail.gmail.com>
In-Reply-To: <CAOW+2dsM0pe+EgFBJD_3bGZFwa5a+zOVBC4CdvwYM5WX3X3wvw@mail.gmail.com>
From: Emil Ivov <emcho@jitsi.org>
Date: Sat, 02 Feb 2019 19:07:52 +0000
Message-ID: <CAPvvaaL1ghV4kEHQpEp9jgpPthPikD2gyYLoLFa+CS2ymRHKwQ@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: Bernard Aboba <bernard.aboba@gmail.com>
Cc: Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io>, Emad Omara <emadomara@google.com>, IETF discussion list <ietf@ietf.org>, Lorenzo Miniero <lorenzo@meetecho.com>, Sergio Garcia Murillo <sergio.garcia.murillo@cosmosoftware.io>, "hta@google.com" <hta@google.com>, perc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000af3c230580edfa3a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/k83vNwdScrVtWBbYrDWM6zkC4fA>
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 19:08:11 -0000

On Sat 2 Feb 2019 at 18:53, Bernard Aboba <bernard.aboba@gmail.com> wrote:

> Emil said:
>
> "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."
>
> [BA] Thank you for this explanation.  The PERC Framework document has no
> discussion of this problem at all.
>
> "The discussions around this topic were highly contentious."
>
> [BA] Since this IETF last call, wherein IETF-wide consensus is to be
> determined, I take it you are against the "triple encryption" decision and
> believe that FEC/RTX should be applied only to the encrypted payload and
> then SRTP applied afterward?
>

That is correct.

Emil


>
>
>
>
>
>
> On Sat, Feb 2, 2019 at 12:43 PM Emil Ivov <emcho@jitsi.org> 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
>>
> --
sent from my mobile