[Galene] End-to-end encryption [was: User management]

[Juliusz Chroboczek <jch@irif.fr>]

> talking to a trusted videoconferencing server. I did rather like the
> insertable streams idea:
> 
> https://webrtchacks.com/true-end-to-end-encryption-with-webrtc-insertable-streams/

I like the idea of end-to-end encryption, but I feel that I'm not ready to
implement it yet.

Insertable streams gives you the ability to perform end-to-end encryption,
but it does not define the encryption format.  So you end up having to
design your own crypto, with all the dangers that this entails.  Before we
can use insertable streams, we need to have a clear specification of
a recommended encrypted format to use with it.  There is an IETF effort to
do that, but it's IETF, so it won't conclude before a few years.  (Last
time I checked, they were discussing the benefits of two approaches,
SFrame and Spacket, if memory serves, and there was no clear consensus yet.)

There are two other issues.  First, in order to do simulcast and keyframe
optimisation, Galene needs to look inside the packets.  Jitsi works around
the issue by not encrypting the first 8 octets of every packet, even one
that does not start a frame, but it's difficult to tell what amount of
information this leaks.  The proper solution to the issue is to have an
unencrypted header extension that contains the required information, but
that's only available with AV1 and not implemented yet (Chrome uses
a nonstandard format for AV1).

Second, simulcast for VP8 requires rewriting the packet contents, which is
obviously impossible if the data is encrypted.  This is solved with VP9,
but what it means is that you cannot have encrypted simulcast with VP8,
something has to give.

In short, Dave, I have given some serious thought to the issue of
end-to-end encryption, and I feel that it will need to wait a couple of
years before we can deploy it in production.

-- Juliusz