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

[Sergio Garcia Murillo <[e-mail]>]

On 14/02/2019 4:51, Ben Campbell wrote:
> (+Cullen)
> (as individual)
>
> Hi Sergio,
>
> 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.”

I have never said that there was a consensus around that.

> That is, even if the idea was to let PERC do it’s thing and let other 
> groups spin their own key management systems, I don’t think there’s a 
> consensus that everyone would be okay with that particular approach.

We don't know because the discussion has been prevented from even starting.


>
> Cullen: As the other join presenter, do you have thoughts?
>
> Thanks!
>
> Ben.
>
>> On Feb 13, 2019, at 2:49 PM, Sergio Garcia Murillo 
>> <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Hi Ben,
>>
>> The consensus we reached in Prague was that while many of us didn't 
>> like the proposed solution, we managed to put together a solution 
>> that was technically feasible, so we were not going to prevent the 
>> ones in favor of it for getting it done as it could be possible to 
>> advance with perc lite and alternative key management in different 
>> forums (namely w3c).
>>
>> When the use case was presented in the w3c webrtc for nv, the liaison 
>> statement was sent to prevent the discussion to even get started. So 
>> I personally consider the consensus is invalidated (and so seems 
>> others), others even question that the consensus was even reached on 
>> the first place.
>>
>> Best regards
>> Sergio
>>
>>
>>
>> On 13/02/2019 21:21, Ben Campbell wrote:
>>> (as individual)
>>>
>>> Hi Sergio,
>>>
>>> Can you elaborate on that comment? The statement you reference was 
>>> explicitly about preserving the PERC trust model. How does it 
>>> overturn any consensus in PERC?
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>>> On Feb 13, 2019, at 4:53 AM, Sergio Garcia Murillo 
>>>> <[e-mail] 
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>> You are missing an important piece on the timeline:
>>>>
>>>> Statement from the IETF ART and SEC Area Directors regarding the 
>>>> "Trusted application, untrusted intermediary" use case
>>>> https://datatracker.ietf.org/liaison/1614/
>>>>
>>>> This liaison statement basically blows away any rough consensus 
>>>> from IETF 99 as the basis of my joint proposal was that it could be 
>>>> possible to proceed with the PERC lite proposal and that 
>>>> alternative keying mechanism could be studied without involving the 
>>>> PERC group.
>>>>
>>>> Best regards
>>>> Sergio
>>>>
>>>> On 13/02/2019 2:34, Nils Ohlmeier wrote:
>>>>> Thank you for the input on the framework and the double documents 
>>>>> from everyone.
>>>>>
>>>>> The points raised by the individuals here are not new and have 
>>>>> been discussed before by the WG at several occasions. And for 
>>>>> these issues there has be no WG consensus.
>>>>>
>>>>>
>>>>> Specifically on the points regarding double encryption:
>>>>> At IETF 95 double had consensus and got adopted (after 4 design 
>>>>> team meetings and 3 IETF meetings).
>>>>> https://www.ietf.org/proceedings/95/minutes/minutes-95-perc
>>>>>
>>>>> At IETF 96 the WG chairs re-opened the discussions around SSRC 
>>>>> mutability and Emil got asked to submit a draft on the security 
>>>>> impact of SSRC mutability
>>>>> https://www.ietf.org/proceedings/96/minutes/minutes-96-perc
>>>>>
>>>>> At IETF 98 SSRC immutability and RTX considerations were discussed 
>>>>> but no proposal made on security implications
>>>>> https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00
>>>>>
>>>>> At IETF 99 the double authors and Sergio presented a joint 
>>>>> proposal. The WG chairs called for consensus in the room and on 
>>>>> the list and concluded that with rough consensus, the proposal got 
>>>>> adopted.
>>>>> https://datatracker.ietf.org/meeting/99/materials/minutes-99-perc-01
>>>>> https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7wkf4-bc
>>>>>
>>>>> Best regards
>>>>>  Nils & Suhas
>>>>>  PERC WG chairs
>>>>>
>>>>>> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo 
>>>>>> <[e-mail] 
>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>
>>>>>> PERC may be a valid solution for some scenarios, maybe SIP.
>>>>>>
>>>>>> But in regards of WebRTC, my personal opinion is that it is not 
>>>>>> well suited and that we should do a fresh start, with an analysis 
>>>>>> of the requirements and specifics of webrtc, define trust models, 
>>>>>> role of the js apps, UI/UX, IdP and isolated media streams, key 
>>>>>> management within browser, compatibility with webrtc 1.0, if we 
>>>>>> need to support it in SDP or not, QUIC, WASM, etc.. and then 
>>>>>> check if PERC is able to fulfill them or what parts can be 
>>>>>> reused, if any.
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Sergio
>>>>>>
>>>>>>>
>>>>>>> On 02/02/2019 21:42, Bernard Aboba wrote:
>>>>>>>> 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 
>>>>>>>> <[e-mail] 
>>>>>>>> <mailto:[e-mail]>> 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 
>>>>>>>>>> <[e-mail] <mailto:[e-mail]>> 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
>>>>>>>>>>     <[e-mail] <mailto:[e-mail]>> 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
>>>>>>>>>>         <[e-mail]
>>>>>>>>>>         <mailto:[e-mail]>> 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 <[e-mail]
>>>>>>>>>>             <mailto:[e-mail]>> 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
>>>>>>>>>>                 <[e-mail]
>>>>>>>>>>                 <mailto:[e-mail]>> wrote:
>>>>>>>>>>
>>>>>>>>>>>                 +1, SSRC rewriting is pretty much
>>>>>>>>>>>                 fundamental to all SFUs out there.
>>>>>>>>>>>
>>>>>>>>>>>                 Lorenzo
>>>>>>>>>>>
>>>>>>>>>>>                 Il 2 febbraio 2019 10:19:06 CET, Emil Ivov
>>>>>>>>>>>                 <[e-mail] <mailto:[e-mail]>>
>>>>>>>>>>>                 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 <[e-mail]
>>>>>>>>>>>                     <mailto:[e-mail]>> 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
>>>>>>>>>>>                         <[e-mail]
>>>>>>>>>>>                         <mailto:[e-mail]>>
>>>>>>>>>>>                         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
>>>>>>>>>>>                             [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>                             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
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>>>>>
>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Perc mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>
>>>>
>>>> _______________________________________________
>>>> Perc mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/perc
>>>
>>
>