Re: [Perc] Last Call: <draft-ietf-perc-private-media-framework-08.txt> (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard

[Bernard Aboba <[e-mail]>]

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.







On Sat, Feb 2, 2019 at 10:36 AM Sergio Garcia Murillo <
[e-mail]> wrote:

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