Re: Call for adoption - use case for "Trusted application, untrusted intermediary"

I'm in favor of adopting this use case.  Right now, all group calls done
with WebRTC via SFUs are done in a way that SFUs can decrypt the media,
which is clearly suboptimal, and adopting this use case and providing a
solution for it would allow for a large improvement in security.


Most of the objection to adoption seems to be along the lines of either "we
can't trust the web app to do the extra encryption" and/or "this isn't
*real* e2ee".  I don't buy those arguments for 3 reasons:

1.  Adding an extra level of encryption controlled by the web app is, at
worst (even if the web app screws it up), just as secure as everything is
today.  If we're happy with the security model of what we have today, we
should be happy with giving the web app the chance to add more.  If it
messes up, everything falls back to what we have now.  But adding new APIs
will give web apps the opportunity to make things more secure, which it
can't do today.  By not providing these new APIs, we're basically requiring
web apps to behave as if they had the APIs and screwed up using them.

2.  "real" e2ee where the user doesn't trust the web app doesn't exist and
probably never will exist.  Isolate streams have never happened.  PERC-like
security models don't seem like they will ever happen.  Meanwhile, users
trust the web apps with camera and mic access all the time.  If they trust
the web app with raw access to the media, then why not trust web app with
the ability to add some encryption to it?  This seems to me a classic
"perfect is the enemy of the good" situation.  It's saying we can't have
something better than the status quo simply because there is some
unobtainable ideal that would be better if it ever happened.  But it's
never going to happen.

3.  Web apps can already do the "not real" version of e2ee proposed in this
use case, it's just a pain, and adopting this use case is just making it
more achievable.  A web app can, today, do its own media capture, encoding,
encryption, and then send all of that over a data channel to a server.  But
it's a pain and is slow.  So saying we shouldn't allow the web app to
control extra encryption is saying it shouldn't be allowed to do things
it's already able to do.



By the way, I think if the WebRTC WG doesn't adopt this use case then the
best way to proceed is to add APIs to give access to encoded media (such as
with low-level encoders and decoders).  That would give web apps everything
they need to fulfill this use case, even if the WebRTC WG has not adopted
the use case.




On Tue, Nov 20, 2018 at 2:00 AM Harald Alvestrand <harald@alvestrand.no>
wrote:

> *From the Lyon summary of actions: “The WG adopts the E2E use case where
> we trust the application, but not the relay. (to be verified on the list)”*
>
>
> * The question is whether we should include in our “NV Scenarios” document
> the scenario currently described in
> https://w3c.github.io/webrtc-nv-use-cases/#securecommunications*
> <https://w3c.github.io/webrtc-nv-use-cases/#securecommunications*> - where
> the application (Web page) is fully trusted, but uses a relay service that
> should not be able to decode the transmitted media. The consensus in the
> meeting in Lyon was that this use case should be included; this call serves
> to verify that consensus on the list. Unless objections are raised and
> verified to be widely held in the discussion, the chairs will assume that
> the WG has consensus to include this use case. If you object to this
> document being adopted, please say so to the list before or on Wednesday,
> November 28. Harald, for the chairs *
>
>