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

From: Richard Barnes <[email-masked]>
Date: Fri, 1 Feb 2019 11:18:00 -0500

Hi Bernard,

Thanks for taking a fresh look at this.

On Thu, Jan 31, 2019 at 10:51 PM Bernard Aboba <[email-masked]>
wrote:

> My review of draft-ietf-perc-private-media-framework-08, found below,
> represents my personal opinion.
>
> In reading this document, I was disappointed to find that it did not
> address some key issues that have been encountered by implementers. I
> therefore feel that the document is not ready for publication.
>
> Problem #1:  Definition of a Trusted Endpoint
>
> The document defines a "Trusted Endpoint" as follows:
>
>    Trusted Endpoint: An RTP flow terminating entity that has possession
>    of E2E media encryption keys and terminates E2E encryption.  This may
>    include embedded user conferencing equipment or browsers on
>    computers, media gateways, MCUs, media recording device and more that
>    are in the trusted domain for a given deployment.
>
>
> In practice, this definition has created considerable confusion among implementers, particularly those who have attempted to
>
> implement Web-based applications.
>
>
> In these situations, an "endpoint" may represent a unitary native application, or potentially an application written in
>
> Javascript or WASM running on a browser platform.  In such a situation, portions of the application code may
>
> be provided by multiple parties, which might include the domain in control of the key management server, a party
>
> unrelated to the provider of the MDD or key management server, etc.  In such situations, the definition of
>
> "trusted endpoint" provided in this document becomes difficult to apply.
>
>
> This point has been underlined by a recent IESG note sent to the W3C WEBRTC WG which has been attempting to
>
> develop use cases based upon the PERC framework, and has found itself unable to come to consensus on the
>
> meaning of a "trusted endpoint":
>
> https://lists.w3.org/Archives/Public/public-webrtc/2018Nov/0114.html
>
>
> In beginning my review of this document, I was hoping to find material relating to the points made in the IESG
>
> relating to the nature of a "trusted endpoint", but was disappointed that few of the points made by the IESG
>
> were expounded upon in the document.  Since the IETF generally requires documents to stand on their own without the
>
> need for IESG interpretation, this appears to represent a serious inadequacy in the current framework document.
>
>
I appreciate that there's confusion here, and I think we can clarify.

It seems pretty clear from the other documents in this suite
(draft-ietf-perc-srtp-ekt-diet and draft-ietf-perc-double) that this system
only really makes sense in the case where the browser is trusted and the JS
is not.  Otherwise, you would not need the DTLS parts of EKT, since you
could rely on some external thing to provide the key encryption key.  (Note
that this latter architecture was proposed, considered, and rejected by the
WG.)

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

Problem #2:  Relationship to RTP topology model (RFC 7667)
>
>
> The document defines a Media Distributor (MD) as follows:
>
>
>    Media Distributor (MD): An RTP middlebox that forwards endpoint media
>    content (e.g., voice or video data) unaltered, either a subset or all
>    of the flows at any given time, and is never allowed have access to
>    E2E encryption keys.  It operates according to the Selective
>    Forwarding Middlebox RTP topologies [RFC7667 <https://tools.ietf.org/html/rfc7667>] per the constraints
>    defined by the PERC system, which includes, but not limited to,
>    having no access to RTP media unencrypted and having limits on what
>
>       RTP header field it can alter.
>
>
> The Selective Forwarding Middlebox is described in RFC 7667 Section 3.7 as follows:
>
>    Another method for handling media in the RTP mixer is to "project",
>    or make available, all potential RTP sources (SSRCs) into a per-
>    endpoint, independent RTP session.  The middlebox can select which of
>    the potential sources that are currently actively transmitting media
>    will be sent to each of the endpoints.  This is similar to the Media-
>    Switching Mixer but has some important differences in RTP details...
>
>    As the middlebox selects the source in the
>    different RTP sessions that transmit media to the endpoints, each RTP
>    stream requires the rewriting of certain RTP header fields when being
>    projected from one session into another.  In particular, the sequence
>
>    number needs to be consecutively incremented based on the packet
>    actually being transmitted in each RTP session.  Therefore, the RTP
>    sequence number offset will change each time a source is turned on in
>    an RTP session.  The timestamp (possibly offset) stays the same.
>
>    The RTP sessions can be considered independent, resulting in that the
>    SSRC numbers used can also be handled independently.  This simplifies
>    the SSRC collision detection and avoidance but requires tools such as
>    remapping tables between the RTP sessions.  Using independent RTP
>    sessions is not required, as it is possible for the switching
>    behavior to also perform with a common SSRC space.  However, in this
>    case, collision detection and handling becomes a different problem.
>    It is up to the implementation to use a single common SSRC space or
>    separate ones.
>
>    Using separate SSRC spaces has some implications.  For example, the
>    RTP stream that is being sent by endpoint B to the middlebox (BV1)
>    may use an SSRC value of 12345678.  When that RTP stream is sent to
>    endpoint F by the middlebox, it can use any SSRC value, e.g.,
>    87654321.  As a result, each endpoint may have a different view of
>    the application usage of a particular SSRC.  Any RTP-level identity
>    information, such as SDES items, also needs to update the SSRC
>    referenced, if the included SDES items are intended to be global.
>    Thus, the application must not use SSRC as references to RTP streams
>    when communicating with other peers directly.  This also affects loop
>    detection, which will fail to work as there is no common namespace
>    and identities across the different legs in the Communication Session
>    on the RTP level.  Instead, this responsibility falls onto higher
>    layers.
>
> [BA] I interpret the above text as potentially allowing the MDD to rewrite
> the SSRC of
>
> RTP and RTCP packets.  Yet my reading of the framework document is that such rewriting
>
> could be problematic, since Section 4.3 of the framework document notes that the SSRC
>
> is utilized to identify which E2E keys are to be used to decrypt a given RTP media flow:
>
> 4.3 <https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-08#section-4.3>.  E2E Keys and Endpoint Operations
>
>    Any given RTP media flow is identified by its SSRC, and an endpoint
>    might send more than one at a time and change the mix of media flows
>    transmitted during the life of a conference.
>
>    Thus, an endpoint MUST maintain a list of SSRCs from received RTP
>    flows and each SSRC's associated E2E key information.  An endpoint
>    MUST discard old E2E keys no later than when it leaves the conference
>    (see Section 4.5.2 <https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-08#section-4.5.2>).
>
>
> [BA] Given the above, it is not clear to me whether the framework document
> has added restrictions on
>
> the behavior of the Selective Forwarding Middlebox (such as no SSRC rewriting), and if so, what the
>
> implications are for existing implementations.
>
>
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.

I'll leave it to Paul to propose concrete fixes here, since I'm less
familiar with these points.

--Richard

>
> On Wed, Jan 30, 2019 at 7:45 PM The IESG <[email-masked]> wrote:
>
>>
>> The IESG has received a request from the Privacy Enhanced RTP
>> Conferencing
>> WG (perc) to consider the following document: - 'A Solution Framework for
>> Private Media in Privacy Enhanced RTP
>>    Conferencing'
>>   <draft-ietf-perc-private-media-framework-08.txt> as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final
>> comments on this action. Please send substantive comments to the
>> [email-masked] mailing lists by 2019-02-13. Exceptionally, comments may be
>> sent to [email-masked] instead. In either case, please retain the
>> beginning of
>> the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>    This document describes a solution framework for ensuring that media
>>    confidentiality and integrity are maintained end-to-end within the
>>    context of a switched conferencing environment where media
>>    distributors are not trusted with the end-to-end media encryption
>>    keys.  The solution aims to build upon existing security mechanisms
>>    defined for the real-time transport protocol (RTP).
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/
>>
>> IESG discussion can be tracked via
>>
>> https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>>
>>
>> _______________________________________________
>> Perc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/perc
>>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 Feb 2019 11:58:21 -0500

Comments below.

On Fri, Feb 1, 2019 at 11:18 Richard Barnes <[email-masked]> wrote:

> is not.

[BA] Does this depend on the origin of the JS and how it is delivered?
Development frameworks such as Electron are now quite popular for
delivering native applications. Are you saying that the framework
intrinsically distinguishes a native C/C++ application utilizing the WebRTC
APIs from one partially written in JS?

Seems to me that this Is really about access to media and keys, not
development methodology.

I would also note that DRM frameworks such as EME have their own key
management requirements and definition of “trust” rooted in hardware such
as the TPM.

Otherwise, you would not need the DTLS parts of EKT, since you could rely
> on some external thing to provide the key encryption key.  (Note that this
> latter architecture was proposed, considered, and rejected by the WG.)
>

[BA] This is a framework document. As such, it needs to explain the
requirements for key management.

> for DTLS-SRTP in one-to-one calls)."

[BA] Given that WebRTC APIs are frequently used to develop native
applications, and that existing Web APIs such as EME support handling of
encrypted content, I do not think the above text is adequate. The document
actually needs to articulate the key management requirements.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 1 Feb 2019 18:28:04 +0100

On 01/02/2019 17:18, Richard Barnes wrote:
> "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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 2 Feb 2019 01:29:08 -0500

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 <
[email-masked]> wrote:

> for DTLS-SRTP in one-to-one calls).
>
>
> within the https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-17
> doc ?
>
>
> 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:
>
>

---

From: Emil Ivov <[email-masked]>
Date: Sat, 2 Feb 2019 09:19:06 +0000

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 <[email-masked]> 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
> 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.
>
>
>
>
>> "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
>> to the RTCWEB group to decide what is a trusted endpoint and what is not in
> --
sent from my mobile

---

From: Lorenzo Miniero <[email-masked]>
Date: Sat, 02 Feb 2019 11:18:15 +0100

+1, SSRC rewriting is pretty much fundamental to all SFUs out there.

Lorenzo

Il 2 febbraio 2019 10:19:06 CET, Emil Ivov <[email-masked]> ha scritto:
>between

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Sat, 2 Feb 2019 17:40:54 +0700

+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 <[email-masked]> wrote:
> 
>> 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.
>> 
>>> "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 <[email-masked]> wrote:
>>>>> "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 ?
>>>> 
>>>> 
>>>> 
>>>> 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:
>>>>

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 2 Feb 2019 07:30:33 -0500

"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 <
[email-masked]> wrote:

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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 2 Feb 2019 07:58:38 -0500

Emil said:

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

[BA] Can you articulate why you consider SSRC rewriting essential to SFU
operation?

I can think of one scenario where SSRC rewriting does seem to be *required*
-  Massive Online Courses (MOOCs). In these scenarios, there can be
hundreds or even thousands of students, most of whom never speak during
class, and teachers, who send media frequently.  MOOCs can be implemented
via streaming media instead of RTP, but this complicates the interactive
aspect.

So there are implementations of MOOCs that use RTP, and I believe that SSRC
rewriting is an important part of the design of these systems. For example,
there are currently limitations in browsers as to the number of
transceivers that can be active, so that providing a transceiver for each
of the participants in the conference could conceivably cause the browser
to run out of memory.

This is circumvented by not exposing participants to the SSRCs of all of
the users.  For example, the SFU may only allocate SSRCs for the professor
and the "last N" students who have asked questions, so that a participant
will only be aware of those SSRCs plus their own, instead of potentially
needing to deal with the SSRCs of all the participants in the conference.
This also has the effect of limiting the transceivers needed, most of which
are in "recv-only" mode from the perspective of the course participants.

When students wish to ask a question, permission is requested to access
their devices (but not before).  Then once the student is speaking, their
SSRC is translated, so that participants do not necessary see a new SSRC
but only the SSRC of "the current speaking student".  Also, the SFU will
typically consume the RTCP packets from students who are sending.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 2 Feb 2019 16:41:19 +0100

On 02/02/2019 13:30, Bernard Aboba wrote:
> 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?

The consensus we reached in Prague almost two years ago was that despite 
many of us didn't like the solution and while it would huge impact to 
implement it in current deployed based, it was technically feasible and 
we would not oppose getting this go trough as that it could be possible 
to progress alternative solutions (namely PERC lite and js keying) in 
other forums.

However the end to end encryption with trusted application use case had 
to be removed from the w3c nv scope because it was against what has been 
defined within this group. Given that, I would say that the previous 
consensus has been broken.

Best regards

Sergio

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 2 Feb 2019 11:18:55 -0500

Sergio said:

"However the end to end encryption with trusted application use case had
to be removed from the w3c nv scope because it was against what has been
defined within this group. Given that, I would say that the previous
consensus has been broken."

[BA] Here is the consensus determination posted on the W3C WEBRTC WG
mailing list relating to that discussion:
https://lists.w3.org/Archives/Public/public-webrtc/2018Dec/0041.html

As noted in this email, there was considerable confusion relating to the
posted use case, with individuals interpreting the use case (and the
associated requirements) very differently.

To be able to develop one or more alternative use cases, I was hoping to be
able to rely upon the PERC framework document to tease apart the issues.
Unfortunately the current framework document barely even mentions the
points that have proven most contentious.

At this point, it is very difficult for me to even pinpoint whether the
discussion represents a lack of consensus about the whole PERC architecture
(e.g. throw it all away and start over based on frame encryption), or some
portions of the architecture are considered salvageable (e.g. continue with
packet payload encryption but use "PERC-lite" instead of Double, possibly
with a different key management scheme).  Assuming that the problems are
more in the latter category, there are a few questions which it would be
nice to have an answer to:

1. What are the requirements for replacing the PERC key management scheme?
Do other key management standards (e.g. EME) meet those requirements?
2. Are the problems with "Double " addressable via adoption of alternatives
such as PERC-lite? Or is the problem more fundamental (e.g. requiring
adoption of encryption at the frame rather than packet payload level)?
3. Is lack of support for SSRC-rewriting a limitation for implementation of
key scenarios (e.g. MOOCs). Does this imply a set of implementation
requirements (e.g. simulcast reception and associated features) that are
unlikely to be fulfilled in practice?  Is there a viable alternative to
SSRC-rewriting (e.g. involving RIDs)?

Without a clear framework document clearly discussing the relationships
between the aspects of the PERC architecture, describing the design choices
and how things fit together, it is very difficult to figure a way out of
this swamp.

To some extent this debate reminds me of the discussions relating to IPsec
and key management proposals, but at least in that case we had a well
articulated framework document (RFC 4301) that helped make the architecture
understandable and enabled its evolution over time.

---

From: Emil Ivov <[email-masked]>
Date: Sat, 2 Feb 2019 16:41:12 +0000

The scenario you outline may be one. I call that SSRC rewriting for Last N

Simulcast through SSRC rewriting (that you describe) is the one that
concerns us currently.

On Sat 2 Feb 2019 at 12:51, Bernard Aboba <[email-masked]> wrote:

> I can think of one scenario where SSRC rewriting does seem to be
> *required* -  Massive Online Courses (MOOCs). In these scenarios, there can
> be hundreds or even thousands of students, most of whom never speak during
> So there are implementations of MOOCs that use RTP, and I believe that
> SSRC rewriting is an important part of the design of these systems. For
> example, there are currently limitations in browsers as to the number of
sent from my mobile

---

From: Emil Ivov <[email-masked]>
Date: Sat, 2 Feb 2019 16:46:10 +0000

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 <[email-masked]> wrote:

> 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
>>> 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.
>>>
>>>>> 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
sent from my mobile

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 2 Feb 2019 11:50:40 -0500

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 <[email-masked]> wrote:

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

---

From: Emil Ivov <[email-masked]>
Date: Sat, 2 Feb 2019 17:42:51 +0000

On Sat 2 Feb 2019 at 16:50, Bernard Aboba <[email-masked]> 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."
>

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

>> 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]  Not being able to rewrite SSRCs has some major implications
>>>>>> with respect to requirements on PERC endpoints.  Typically today's MDD will
sent from my mobile

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 2 Feb 2019 13:53:38 -0500

Emil said:

"Applications will apply SRTP-double first and, those that need to use FEC
and RTX would have to apply them only after.

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?

On Sat, Feb 2, 2019 at 12:43 PM Emil Ivov <[email-masked]> wrote:

> 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.
>
> This approach was referred to as “wedging RTX and FEC” as it places them
> in between the two encryption operations.
>
>>>> 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?
>>>>
>>>>>>>> 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:
>>>>>>>>
>>>>>>>>

---

From: Emil Ivov <[email-masked]>
Date: Sat, 2 Feb 2019 19:07:52 +0000

> then SRTP applied afterward?

That is correct.

Emil

>> 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
sent from my mobile

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 2 Feb 2019 21:31:31 +0100

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Emil said:
>
>     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".
>
>
> 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.
>
> conceptual approach (contrary to the imposition of key distribution 
> and negotiation). I think it simply carries a promise for some minimal 
> 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.
>
> “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..
>
>     On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov <[email-masked]
>     <mailto:[email-masked]>> 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
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             [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:
>
>             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
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 On 2 Feb 2019, at 17:18, Lorenzo Miniero
>                 <[email-masked] <mailto:[email-masked]>>
>                 wrote:
>
>>                 Il 2 febbraio 2019 10:19:06 CET, Emil Ivov
>>                 <[email-masked] <mailto:[email-masked]>> 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
>>                     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
>>                     <[email-masked]
>>                     <mailto:[email-masked]>> 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 <[email-masked]
>>                         <mailto:[email-masked]>> wrote:
>>
>>>                             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
>>                             management solutions trusted (even in JS
>>                             or WASM), as for for example is being
>>                             done in EME:
>>
>>                             [email-masked] <mailto:[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 2 Feb 2019 15:42:46 -0500

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 <[email-masked]> 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
> 
> 
>>> "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 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
>>>> 
>>>>> [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:
>>>>> 
>>>>> 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 <[email-masked]> wrote:

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 2 Feb 2019 22:37:36 +0100

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 
>> <[email-masked] 
>>> solution for end to end encryption for multiconferencing, as if 
>>> there was a one size fits all solution for the problem.
>>>
>>> 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
>>>
>>>
>>>>     "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."
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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..
>>>>
>>>>         specific way of performing key negotiation into the
>>>>         framework rather than leaving it open was both unnecessary
>>>>         and quite problematic.
>>>>
>>>>         Emil
>>>>
>>>>             [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:
>>>>
>>>>             With respect to consensus, this is IETF last call, one
>>>>             of whose purposes is to determine whether there is IETF
>>>>             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?
>>>>
>>>>                 <[email-masked]
>>>>                 <mailto:[email-masked]>> wrote:
>>>>
>>>>>                     major problem: not allowing SSRC rewriting
>>>>>                     makes the entire framework unusable with SFU
>>>>>                     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.
>>>>>
>>>>>                         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."
>>>>>
>>>>>                         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,
>>>>>                         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
>>>>>                         On Fri, Feb 1, 2019 at 12:23 PM Sergio
>>>>>                         Garcia Murillo
>>>>>                         <[email-masked]
>>>>>                             webrtc, shouldn't this be defined
>>>>>                             within the

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 12 Feb 2019 17:34:33 -0800

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 <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 <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 <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://datatracker.ietf.org/meeting/99/materials/minutes-99-perc-01>
  https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7wkf4-bc <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 <[email-masked]> wrote:
> 
> 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 Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> Emil said:
>>>>> 
>>>>> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> Yes pretty much those.
>>>>> 
>>>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov <[email-masked] <mailto:[email-masked]>> ha scritto:
>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> Richard said:
>>>>>> 
>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 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 <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-17> doc ?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryption <https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryption>
>>>>>> Best regards
>>>>>> 
>>>>>> Sergio
>>>>>> 
>>>>>> https://www.ietf.org/mailman/listinfo/perc <https://www.ietf.org/mailman/listinfo/perc>
>>>>>> -- 
>>>>>> sent from my mobile
>>>>>> 
>>>>>> -- 
>>>>> https://www.ietf.org/mailman/listinfo/perc <https://www.ietf.org/mailman/listinfo/perc>
>>>>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Feb 2019 17:55:57 -0800

Within our team, we have evaluated this design carefully. Beyond the issues
noted here, we believe that the current design suffers from high overhead
(e.g. additional bytes on the wire), as well as latent issues that have not
yet been discussed.

On Tue, Feb 12, 2019 at 5:34 PM Nils Ohlmeier <[email-masked]> wrote:

> 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.
>
>
>  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
>
>  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
>
> 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
>
>
> 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?
>
> 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.
>
> 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
>
>
> encryptions for every packet..
>
>>>> [email-masked] <[email-masked]>>
>>>> wrote:
>>>>
> Perc mailing [email-masked]://www.ietf.org/mailman/listinfo/perc
>
>

---

From: Emil Ivov <[email-masked]>
Date: Wed, 13 Feb 2019 10:37:21 +0000

Nils,

I'd like to correct you on a point here:

>  https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00

This is really quite misleading:

We did indeed have a discussion on this was on IETF 96 (Berlin) where I was
asked
to describe how this works in a draft, which we did:

https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

We then talked about it in Chicago (IETF 98) . No one implied security
issues any more. This never was a problem.

No decision was reached and the topic was left open but it had nothing to
do with the security implications of either approach and the lack of
consensus was primarily driven by implementation convenience.

The discussion then morphed into RTX/FEC handling for which we've also made
submissions.

https://mailarchive.ietf.org/arch/msg/perc/eR_1o1Aj8fDBmrEzA0jgL4IL1e4

Eventually, at some point the chairs decided to declare consensus where
there wasn't any and the WG just ploughed through. That's where I
personally disconnected and I have been waiting for last call to voice
these concerns ever since.

The entire WG mode of operation has been an egregious violation of the main
principles that the IETF stands for.

Regards,
Emil

-- 
https://jitsi.org

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 13 Feb 2019 11:53:17 +0100

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:
> discussed before by the WG at several occasions. And for these issues 
> there has be no WG consensus.
>
>
> 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
> At IETF 98 SSRC immutability and RTX considerations were discussed but 
> no proposal made on security implications
> 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.
>> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo 
>> 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
>>
>>>
>>>> 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?
>>>>
>>>>> 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 Sat 2 Feb 2019 at 16:50, Bernard Aboba 
>>>>>>     That’s a problem specific to the “double” documents."
>>>>>>
>>>>>>     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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> discussions by all SFU implementors except potentially one, it 
>>>>>> was mysteriously rejected by a subset of the WG and replaced with 
>>>>>> the following:
>>>>>>
>>>>>>         framework rather than leaving it open was both
>>>>>>         unnecessary and quite problematic.
>>>>>>
>>>>>>         Emil
>>>>>>
>>>>>>             consider to be problematic within the framework?  I
>>>>>>             am aware of at least two others where implementers
>>>>>>             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?
>>>>>>
>>>>>>>                     SSRC rewriting makes the entire framework
>>>>>>>                     unusable with SFU implementation I represent
>>>>>>>                     as well as every other SFU I am familiar with.
>>>>>>>
>>>>>>>                         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
>>>>>>>                         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
>>>>>>>                         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?
>>>>>>>
>>>>>>>                         the endpoint is receiving multiple
>>>>>>>                         streams with different sequence number
>>>>>>>                         spaces which may contain holes because
>>>>>>>                         of reordering or loss. This not only
>>>>>>>                             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:
>>>>>>>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Feb 2019 07:41:24 -0800

On Feb 13, 2019, at 2:53 AM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> 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.

[BA] Is there documentation on the PERC-lite proposal? Does it avoid the problems with FEC/RTX processing and Triple protection? Has it been deployed?

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 13 Feb 2019 18:17:12 +0100

On 13/02/2019 16:41, Bernard Aboba wrote:
> On Feb 13, 2019, at 2:53 AM, Sergio Garcia Murillo<[email-masked]>  wrote:
> [BA] Is there documentation on the PERC-lite proposal?

The original proposal and slides can be found here:

https://docs.google.com/presentation/d/1cwwg36z8bZlgUaBifiuQU9vWhwx4fbbdIrlvQ77578M

https://www.dropbox.com/s/8qxielk88y1veol/draft-perc-lite.txt.pdf?dl=0

Also:

https://ieeexplore.ieee.org/document/8169749

https://ieeexplore.ieee.org/document/8169752

> Does it avoid the problems with FEC/RTX processing and Triple protection?

The information required to decrypt the outer payload is bundled withing 
the inner encrypted payload, so there is no issue with FEC/RTX, triple 
or ssrc rewriting. Only framemarking support is required.

> Has it been deployed?

As only frame marking is required, it is supported in Jitsi, Janus and 
Medooze SFUs. We have two deployments with PERC-Lite, one with VP8 and 
with Jitsi for Symphony and another one with VP9 SVC and Medooze. We are 
also working alternative per frame encryption methods for lower 
bandwidth overhead.

Best regards

Sergio

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Feb 2019 09:26:48 -0800

On Wed, Feb 13, 2019 at 9:12 AM Sergio Garcia Murillo <
[email-masked]> wrote:

>
> We have two deployments with PERC-Lite, one with VP8 and with Jitsi for
> Symphony and another one with VP9 SVC and Medooze.

[BA] Wow. That makes PERC-lite the defacto standard for Finance. How do you
deal with the SSRC immutability issue?

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 13 Feb 2019 18:39:32 +0100

On 13/02/2019 18:26, Bernard Aboba wrote:
> On Wed, Feb 13, 2019 at 9:12 AM Sergio Garcia Murillo 
>     We have two deployments with PERC-Lite, one with VP8 and with
>     Jitsi for Symphony and another one with VP9 SVC and Medooze. 
>
>
> [BA] Wow. That makes PERC-lite the defacto standard for Finance. How 
> do you deal with the SSRC immutability issue?

The original rtp packet payload (without extension headers) is included 
in the outer encrypted payload, so any rtp params may be changed by the 
SFU as it would normally do. We proposed this to be consistent with perc 
double so it was less disruptive, but we have been working on 
alternative encryption algorithms with less overhead including full 
frame encryption ones.

Best regards

Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 13 Feb 2019 21:57:10 +0100

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 
>> 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
>>
>>> discussed before by the WG at several occasions. And for these 
>>> issues there has be no WG consensus.
>>>
>>>
>>> mutability and Emil got asked to submit a draft on the security 
>>> impact of SSRC mutability
>>> At IETF 98 SSRC immutability and RTX considerations were discussed 
>>> but no proposal made on security implications
>>>> 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
>>>>
>>>>>
>>>>>> 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?
>>>>>>
>>>>>>> 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 
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>>     issues with ordering of FEC/RTX/RED and encryption, let
>>>>>>>>     alone the need for "triple encryption".
>>>>>>>>
>>>>>>>>
>>>>>>>> without changing the app code itself and by simply replacing 
>>>>>>>> the libsrtp library with a PERC-enabled one.
>>>>>>>>
>>>>>>>> protection mechanisms such FEC and RTC unavailable to the SFU 
>>>>>>>> as they are usually performed before SRTP, which would make 
>>>>>>>> them e2e encrypted.
>>>>>>>>
>>>>>>>> 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..
>>>>>>>>
>>>>>>>>         particularly egregious consequence of the order
>>>>>>>>         problem. That’s a problem specific to the “double”
>>>>>>>>         documents.
>>>>>>>>
>>>>>>>>             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?
>>>>>>>>
>>>>>>>>>                     unusable with SFU implementation I
>>>>>>>>>                     represent as well as every other SFU I am
>>>>>>>>>                     familiar with.
>>>>>>>>>
>>>>>>>>>                         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
>>>>>>>>>                         multiple streams with different
>>>>>>>>>                         sequence number spaces which may
>>>>>>>>>                         contain holes because of reordering or
>>>>>>>>>                         loss. This not only complicates the
>>>>>>>>>                         support simulcast reception, neither
>>>>>>>>>>                             So I would propose we add
>>>>>>>>>>                             something like the following to
>>>>>>>>>>                             this definition:
>>>>>>>>>>
>>>>>>>>>>                             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).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                             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:
>>>>>>>>>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Feb 2019 13:56:54 -0600

Hi Bernard,

Full disclosure: I asked the chairs to send that email. I gather from your response that you saw it as an attempt to shut down discussion. I don’t think that is the case at all.

I interpreted Nils’s email to be providing useful context about the discussions that occurred in the working group. I hope that context will be useful to people evaluating the current discussion. Several of the points currently under discussion were discussed in the WG, and they made tradeoffs. Not everyone was happy about each tradeoffs; that’s the “rough” in rough consensus.

It’s perfectly reasonable to open those issues again if new information has come up since then, or if people who were not participants in the WG have opinions to offer.  But we should also be careful about simply replaying the same discussions over again. I don’t mean to say that the entire discussion falls into the second category; I think we have some of both.

I would encourage participants in this discussion to focus on what we might have learned since the WG discussions, whether that means new implementation experience, new voices, new analyses, etc.

Thanks!

Ben.

> On Feb 12, 2019, at 9:10 PM, Bernard Aboba <[email-masked]> wrote:
> 
> Nils --
> 
> This is IETF Last Call.  Its purpose is to determine if there is IETF consensus to publish the PERC documents (and the framework, in particular) as proposed standards.
> 
> As described on this list, a number of potential implementers have seriously considered the PERC framework, but for reasons described in the IETF last call comments, they have encountered problems that have either prevented them from implementing the framework at all, or have caused them to choose a modified approach to one or more parts of it.
> 
> The overall picture is therefore not one of "rough consensus" in the IETF community - but rather of problems with the work that have caused implementers to seek alternatives either within the IETF or outside of it. In at least one case, such an implementation has achieved considerable usage, and other alternative implementations appear inevitable. Overall, this level of dissent is relatively rare within an IETF last call - and so is something for the IESG to take note of.
> 
> I will let the disputants speak for themselves, but the statements made in this IETF last call appear to indicate at least the following points of contention:
> 
> 1.  Problems with implementation of "Double" to the issues encountered with attempted support for FEC/RTX/RED, and the potential need for "triple protection".  These problems appear to have been fixed by implementers who have taken an alternative approach (e.g. "PERC-LITE").  The perceived excessive overhead of "Triple" has also lead to consideration of alternatives with respect to the scope of encryption (e.g. frame encryption versus payload encryption).
> 
> 2. Problems with SSRC-based key identification (leading to the requirement for immutability).  The effects of SSRC immutability have been pointed out, namely the inability to  support some scenarios (such as MOOCs) and also a requirement for support of simulcast reception that is perceived of as difficult to meet (e.g. multiple implementations that are less than robust). I'll let the implementers describe how their alternatives to dealing with this problem, but some of these have been transport independent so as to not allow for dependencies on RTP-specific constructs such as the SSRC.
> 
> 3. Problems with the DTLS-EKT Diet key management scheme.  I believe that this issue may be the impetus for the use of alternative approaches taken with respect to key management (e.g. consideration of EME).
> 
> Given this level of dissent, there would seem to be little chance that the PERC framework as currently described in the WG documents will ever be widely implemented. But despite that, it does seem possible for the WG to make a meaningful contribution - by laying out the problem and solution requirements well enough to guide future discussions.  The current PERC Framework document does not accomplish this goal.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> In trying to understand the issues, it is
> 
> 
>  PERC framework document were to at least layout the basic principles that such experiments need to follow.
> 
> As an example, it would be helpful to understand the implications of utilizing alternative key management schemes.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, Feb 12, 2019 at 5:34 PM Nils Ohlmeier <[email-masked] <mailto:[email-masked]>> wrote:
>> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba <bernard.aboba@gmail..com <mailto:[email-masked]>> wrote:
>>>>>>> Richard said:
>>>>>>> 
>>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>> https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryption <https://github.com/WICG/media-capabilities/blob/master/explainer..md#encryption>
>>>>>>> Best regards
>>>>>>> 
>>>>>>> Sergio
>>>>>>>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Feb 2019 14:21:46 -0600

(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 <[email-masked]> wrote:
> 
> Statement from the IETF ART and SEC Area Directors regarding the "Trusted application, untrusted intermediary" use case
> https://datatracker.ietf.org/liaison/1614/ <https://datatracker.ietf.org/liaison/1614/>
> 
>>> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 13 Feb 2019 14:48:39 -0800

Hi Emil,

> On 13Feb, 2019, at 02:37, Emil Ivov <[email-masked]> wrote:
> 
> On Wed, Feb 13, 2019 at 1:34 AM Nils Ohlmeier <[email-masked] <mailto:[email-masked]>> wrote:
> We did indeed have a discussion on this was on IETF 96 (Berlin) where I was asked
> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 <https://tools.ietf.org/html/draft-grozev-perc-ssrc-00>
> 
> We then talked about it in Chicago (IETF 98) . No one implied security issues any more. This never was a problem.

I wasn’t a WG chair at the time but quoting from the IETF 96 meeting minutes section about “SSRC Immutability Discussion":

"- Emil asked to submit draft explaining the impact of ssrc mutability on
    security/ssrc collision/end-point procedures in the perc context.”

And the security considerations section of the above draft is empty.

> No decision was reached and the topic was left open but it had nothing to do with the security implications of either approach and the lack of consensus was primarily driven by implementation convenience.

While implementation convenience was part of the discussion it was raised a few times that the people in favor of allowing SSRC mutability never provided any written description of why mutating the SSRC is not a problem as pointed out by the design team.

Best
  Nils

> The discussion then morphed into RTX/FEC handling for which we've also made submissions.
> 
> https://mailarchive.ietf.org/arch/msg/perc/eR_1o1Aj8fDBmrEzA0jgL4IL1e4 <https://mailarchive.ietf.org/arch/msg/perc/eR_1o1Aj8fDBmrEzA0jgL4IL1e4>
> 
> Eventually, at some point the chairs decided to declare consensus where there wasn't any and the WG just ploughed through. That's where I personally disconnected and I have been waiting for last call to voice these concerns ever since.
> 
> The entire WG mode of operation has been an egregious violation of the main principles that the IETF stands for.
> 
> Regards,
> Emil
>  
> 
> https://jitsi.org <https://jitsi.org/>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 14 Feb 2019 00:47:23 +0100

On 13/02/2019 23:48, Nils Ohlmeier wrote:
> While implementation convenience was part of the discussion it was 
> raised a few times that the people in favor of allowing SSRC 
> mutability never provided any written description of why mutating the 
> SSRC is not a problem as pointed out by the design team.

All SFUs I am aware of performs SSRC rewriting, it is much more than 
implementation convenience.

I assume that the ssrc rewriting security issue comes from the splicing 
attack described in:

https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01

        7.2.4
        <https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4>.
        Splicing Attack

    The splicing attack is an attack where a MDD receiving multiple media
    sources splices one media stream into the other.  If the MDD would be
    able to change the SSRC without the receiver having any method for
    verifying the orignal source ID, then the MDD could first deliver
    stream A.  And if the sequence numbers and other information allows
    it, the MDD can forward stream B under the same SSRC as stream A was
    previously forwarded.

    This attack is mitigated by requiring each rtp stream to have unique
    source IDs that are provided to the receiver.  That way the receiver
    would detect when the source ID switches for these streams.

Note that this attack happens also for perc double even without ssrc 
rewriting as there is no way of verifying that a particular ssrc is from 
a given participant as all participants share the same key and there is 
no protocol in place for mapping ssrcs to participants.

Also note that we have solved this in one of our deployments using PERC 
lite allowing ssrc rewriting and app key management, using a different 
ssrc for the OHB payload used for inner encryption and the outer/HBH rtp 
packet. The inner/OHB ssrc(=participant Id) is then assigned by the key 
management server together with the encryption key for each participant 
so it can be used for mapping ssrcs to participants and allows verifying 
the origin of a packet end to end.

Best regards

Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 14 Feb 2019 01:03:08 +0100

> SSRC is not a problem as pointed out by the design team.
Moreover, in the (maybe not so) near future of ssrc-less signaling (at 
least in webrtc), where the MID extensions are HBH, how would ssrc 
rewriting even be a potential risk?

Has this group analyzed the implications and new attacks that this may 
cause?

Best regards

Sergio

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Feb 2019 17:01:05 -0800

On Feb 13, 2019, at 3:47 PM, Sergio Garcia Murillo <[email-masked]> wrote:
> All SFUs I am aware of performs SSRC rewriting, it is much more than implementation convenience.
> 
[BA] In particular, reusing an SSRC for the “dominant speaker” (which can change)  is a common practice with switching of audio and video going together. 
> Also note that we have solved this in one of our deployments using PERC lite allowing ssrc rewriting and app key management, using a different ssrc for the OHB payload used for inner encryption and the outer/HBH rtp packet. The inner/OHB ssrc(=participant Id) is then assigned by the key management server together with the encryption key for each participant so it can be used for mapping ssrcs to participants and allows verifying the origin of a packet end to end.
> 
[BA] This solves the key identification issue, and can also be used to notify participants that the origin has changed if that is a concern.  This potential solution was pointed out during the discussion as I recall.

Far more serious than splicing attacks is access to cleartext media which thanks to ML can be used to create realistic “fake news”.  PERC does not address that threat, but schemes with stricter trust models might.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Feb 2019 21:51:14 -0600

(+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?

Thanks!

Ben.

> On Feb 13, 2019, at 2:49 PM, Sergio Garcia Murillo <[email-masked]> 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 Feb 13, 2019, at 4:53 AM, Sergio Garcia Murillo <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 14 Feb 2019 08:16:35 +0100

El jue., 14 feb. 2019 2:01, Bernard Aboba <[email-masked]>
escribió:

> [BA] In particular, reusing an SSRC for the “dominant speaker” (which can
> change)  is a common practice with switching of audio and video going
> together.
>

would love to see how simulcast is expected to work without ssrc rewriting
(and without mid)

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 14 Feb 2019 10:56:30 +0100

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.

>> On Feb 13, 2019, at 2:49 PM, Sergio Garcia Murillo 
>> 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).
>>
>> 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
>>
>>
>>
>>> explicitly about preserving the PERC trust model. How does it 
>>> overturn any consensus in PERC?
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>>> 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
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> 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.
>>>>>> 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
>>>>>>
>>>>>>>
>>>>>>>> aspect of PERC (e.g. Double if the triple encryption problem 
>>>>>>>> were fixed) be suitably modified and then implemented?
>>>>>>>>
>>>>>>>>> *THE* solution for end to end encryption for 
>>>>>>>>> multiconferencing, as if there was a one size fits all 
>>>>>>>>> solution for the problem.
>>>>>>>>>
>>>>>>>>> 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 
>>>>>>>>>>     [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.
>>>>>>>>>>
>>>>>>>>>> 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 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.
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> mostly FEC unprotected and FEC receivers vulnerable to DoS. 
>>>>>>>>>> To this the proponents of this approach simply replied with: 
>>>>>>>>>>     On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov
>>>>>>>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>>
>>>>>>>>>>         Yes pretty much those.
>>>>>>>>>>
>>>>>>>>>>         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
>>>>>>>>>>             consider to be problematic within the framework? 
>>>>>>>>>>             I am aware of at least two others where
>>>>>>>>>>             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
>>>>>>>>>>             Standard?  Or that there is no IETF consensus to
>>>>>>>>>>             On Sat, Feb 2, 2019 at 5:40 AM Alexandre
>>>>>>>>>>             GOUAILLARD <[email-masked]
>>>>>>>>>>>                     SSRC rewriting makes the entire
>>>>>>>>>>>                     framework unusable with SFU
>>>>>>>>>>>                     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
>>>>>>>>>>>                     On Sat 2 Feb 2019 at 06:21, Bernard
>>>>>>>>>>>                     Aboba <[email-masked]
>>>>>>>>>>>                         The working group discussed SSRC
>>>>>>>>>>>                         rewriting several times, and
>>>>>>>>>>>                         decision is reflected, e.g., in the
>>>>>>>>>>>                         fact that the Double transform does
>>>>>>>>>>>                         not allow modification of SSRCs."
>>>>>>>>>>>
>>>>>>>>>>>                         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?
>>>>>>>>>>>
>>>>>>>>>>>                         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
>>>>>>>>>>>                         attempted to support simulcast
>>>>>>>>>>>                         reception, neither of which is
>>>>>>>>>>>                         robust in scenarios with
>>>>>>>>>>>                         considerable loss and/or reordering.
>>>>>>>>>>>                         On Fri, Feb 1, 2019 at 12:23 PM
>>>>>>>>>>>                         Sergio Garcia Murillo
>>>>>>>>>>>>                             "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).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                             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:
>>>>>>>>>>>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 14 Feb 2019 15:19:40 -0800

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

[BA] The PERC framework document only mentions that the endpoint is
trusted, but does not go into further detail.  That detail becomes
important when attempting to understand the provable security properties of
PERC (e.g. what attacks are prevented, what attacks are still allowed). As
an example, if the goal is not only to protect against access to cleartext
media within the MDD, but also the ability of endpoints to mis-use the
cleartext media (e.g. to create "deep fakes"), then it is necessary to
restrict access to cleartext media within the PERC application itself (e.g.
no ability to record or even modify cleartext media).  That goes beyond the
"no access to media keys in JS" dictum to "no access to cleartext media for
any PERC application, native or Web".  Once you've gone there, the
distinction between the problem solved by PERC and content protection
technologies begins to disappear.  Keep in mind though that technologies
such as EME are transport-independent - EME can be used when transporting
media over the SCTP data channel, for example.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 15 Feb 2019 00:53:04 +0100

On 15/02/2019 0:19, Bernard Aboba wrote:
> "I don’t recall, and I don’t see anything in the notes or email 
> important when attempting to understand the provable security 
> properties of PERC (e.g. what attacks are prevented, what attacks are 
> still allowed). As an example, if the goal is not only to protect 
> against access to cleartext media within the MDD, but also the ability 
> of endpoints to mis-use the cleartext media (e.g. to create "deep 
> fakes"), then it is necessary to restrict access to cleartext media 
> within the PERC application itself (e.g. no ability to record or even 
> modify cleartext media).  That goes beyond the "no access to media 
> keys in JS" dictum to "no access to cleartext media for any PERC 
> application, native or Web".  Once you've gone there, the distinction 
> between the problem solved by PERC and content protection technologies 
> begins to disappear.  Keep in mind though that technologies such as 
> EME are transport-independent - EME can be used when transporting 

Indeed. Any true end to end encryption for webrtc that must be 
integrated with IdP and isolated media streams IMHO.

Best regards

Sergio

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 14 Feb 2019 16:05:51 -0700

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

Bit more inline … 

> On Feb 13, 2019, at 8:51 PM, Ben Campbell <[email-masked]> wrote:
> 
> (+Cullen)
> (as individual)
> 
> Hi Sergio,
> 

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 <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Ben,
>>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 14 Feb 2019 16:10:51 -0700

> On Feb 13, 2019, at 5:03 PM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> Moreover, in the (maybe not so) near future of ssrc-less signaling (at least in webrtc), where the MID extensions are HBH, how would ssrc rewriting even be a potential risk?
> 
> Has this group analyzed the implications and new attacks that this may cause?
> 
> Best regards
> 
> Sergio

I know you understand this stuff too well to really believe what you just wrote so it comes across as feeling like FUD. You know that most WebRTC does not use any SSRC in the signaling at all and the WebRTC security dose not change if the ssrc are signaled or not. 

Has it been analyzed? YES OF COURSE IT HAS - the whole of webrtc security drafts and security section of of the related WebRTC drafts are written based on the security being ssrc-less signaling.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 14 Feb 2019 23:54:43 +0000

On Thu, Feb 14, 2019 at 5:05 PM Cullen Jennings <[email-masked]> wrote:

>
> Mostly I view this thread as the same set of people that failed to get
> consensus in the WG trying to reopen
>

Aha! I am glad we agree on the lack of consensus in the  WG! I feel that we
are making progress here! All hope is not lost! ;)

issues that was clearly not consensus for

Agreed again!

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

Now this bit here is somewhat vexing. Of course I am sure it is entirely
unintentional so let me just correct this:  "Before the meeting, Emil
decided he did not support it" is quite an, obviously accidental but still,
misrepresentation of reality!

You had discussions with people. I was not an active part of them. You put
my name on a slide of "supporters" and you were about to present to that to
the WG. I saw that and asked you to remove my name. Please do not imply
sudden whimsical changes of positions.

Next time my support is important to you, please simply reach out and I'd
be happy to hear you out.

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

Ah! That "splicing attack"! You often refer to it and have yet to explain
it ... I am confident that you only mean well of course, and promise that,
as soon as you provide details, we will come back with explanations and
security considerations on how to protect against the specific vectors that
concern you.

My very best regards!
Emil

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Fri, 15 Feb 2019 08:00:46 +0800

I do not agree with everything culled say, but still,
I wanted to say something for his defence on his point where i think he is
being given credits for my mistake.

> sudden whimsical changes of positions.

I am the culprit for bringing your name in at IETF 99. Sergio and I spoke
with cullen to try to find a consensus, and we brought to the table what we
though was important for you. As you clearly stated later, you had not
asked us to do that, so it s my bad. When I thought we found a consensus, i
kindly asked cullen tot put your name before presenting it, to show we had
also included your concerns in our discussion and teh corresponding
solution.

this one is on me, and I apologise, again, for it.