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

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".

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