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 <[e-mail]>]

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]> 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