Sergio said:
defined within this group. Given that, I would say that the previous
"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:
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 <sergio.garcia.murillo@xxxxxxxxx> 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
