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

[Emad Omara <[e-mail]>]

Since Google was called out, I'd like to repeat what Justin wrote earlier
that the proposed encryption overhead was never discussed, I personally
raised this issue with Cullen and Richard and they were welcome to
cooperate on improving this, and I did share the frame encryption proposal
but never heard back! Also some corrections below

On Thu, Feb 14, 2019 at 3:05 PM Cullen Jennings <[e-mail]> wrote:

>
> Mostly I view this thread as the same set of people that failed to get
> consensus in the WG trying to reopen issues that was clearly not consensus
> for so I have mostly ignored this thread … but let me comment on the “JS
> access to media keys” issue.
>
> "JS access to media keys" is exactly the heart of the issue of the SDES
> keying of SRTP vs. DTLS keying of SRTP - the WebRTC group had a huge
> discussion on that topic.  This discussion finalized in a large meeting at
> IETF-87 that including many of the SIP, WebRTC, and Security folks at IETF.
> The consensus was extremely strong for not doing the SDES solution that put
> the keys in JS. ( See
> https://www.ietf.org/proceedings/87/minutes/minutes-87-rtcweb )
>
> In some cases Google and other are fans of of what I think of as End to
> Middle security. That is things need to be secure from User A to Google and
> from Google to user B but no need to be secure from A to B. In some cases
> that is fine but in other cases we want security from A to B. PERC is all
> about making things strong from A to B. Since IETF 87, I do not think the
> IETF consensus on things like SDES has gotten weaker - in fact we have
> moved to a stronger desire for the best security we can design and making
> end to end possible where we can.
>
There is a big difference between SDES and JS having access to the key,
SDES implies that the key is sent in plaint text through the server, thus
the server always has access to the key. Where JS has access to the key
assumes the key was exchanged securely between the clients (in this case A
& B) without letting the server accessing it which is a big difference and
not not the End of Middle Security!

>
>
Bit more inline …
>
>
>
>
> On Feb 13, 2019, at 8:51 PM, Ben Campbell <[e-mail]> 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.” 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.
>
> Cullen: As the other join presenter, do you have thoughts?
>
>
> Mostly the agreement was we would the way EKT and double was done breaking
> all the existing implementation if Sergio and Emil agreed they would
> support that approach.  Before the meeting, Emil decided he did not support
> it which made the many of us regret making the breaking changes. We were
> hoping to find a way to move forward without the constant problem of people
> saying the did not like the solution in the WG while not being able to
> present an alternative that addressed the security requirements and issues
> that had been raised (such as the splicing attack).
>
> Any group at IETF or other organization can always do some other form of
> perc-lite and nothing the PERC WG had done limits that in any way and
> simular nothing done in PERC WG can for some other WG or organization to do
> anything in particular. That was clear then and clear now.
>
>
>
> Thanks!
>
> Ben.
>
> On Feb 13, 2019, at 2:49 PM, Sergio Garcia Murillo <
> [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]> 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]> 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]> 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]> 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]> 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]>
>>> 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] <[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]> 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]> 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]>
>>>>>> 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]> 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]
>>>>>>>> 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 [e-mail]://www.ietf.org/mailman/listinfo/perc
>
>
> _______________________________________________
> Perc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perc
>
>
>
> _______________________________________________
> Perc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perc
>
>
>
>
>
>