saghul
commented
4 years ago Hey there! Thanks for the feedback!
It relies on keeping a URL secret
It relies on keeping a URL secret forever
The URL parameter is just a quick way to change it. We now have some proper UI to change the key:
* it does not allow key rotation
That is coming. We are now working on using olm for key distribution, and once we have it in place the plan is to rotate keys when a participant joins or leaves.
* it does not allow to change meeting mode at will
Not sure what you mean, can you please clarify?
plus it does not allow repudiation, once you have the URL you can, also retroactively start decoding streams, and you cannot prevent access to the streams without terminating the meeting and sharing a whole new secret URL.
As I mentioned the plan is to do automatic key rotation. The URL parameter is our current prototype, but won't be the final solution.
A better method to handle E2EE which would allow to turn it on at any given time is the following:
iamveritas
luixxiul
Serphentas
simo5
The E2EE document describe a scheme where PBKDf2 is used on a ''private'' URL to derive an initial encryption scheme. This is weak in various ways:
plus it does not allow repudiation, once you have the URL you can, also retroactively start decoding streams, and you cannot prevent access to the streams without terminating the meeting and sharing a whole new secret URL.
A better method to handle E2EE which would allow to turn it on at any given time is the following:
What all these steps give you? (1) A. gives you the ability to freely share meeting URLs w/o fear of accidentally giving access to the encrypted stream because the host (or by proxy other meeting members if authorized) can always control whether they want to give access to a participant. B. requires active participation in order to access the stream, no hidden observers using stolen URLs. C. It allows the client to show a public key (or fingerprint) for each participant before authorization is granted so that out of band methods (if wanted) can be used by participants to authenticate each other. For example by pasting the public key in a 3rd party chat where participants already trust each other (say via IRC/signal/whatsapp/slack/etc...) D. allows also private conversation between individual participants so that other participants can't see what individuals exchange with each other. (additional ECDH between just the 2 participant allows this) E. When a participant leaves the stream a key rotation can occur so that said participant is cryptographically excluded from the rest of the meeting.
(2) A. allows converting a meeting to encrypted at any time, just signal to clients they need to start the ECDH dance and switch to encrypted scheme right away without interruption of the stream. Existing participants can be pre-approved by the host' client. B. any participant is allowed to add new participants to alleviate the need for the host to approve every single client, if this is unwanted it would require the host to encrypt each video stream multiple times with a different key for each participant, could be considered in future, but not in scope for current scheme either.
(3) A. This is the bit that gives you forward secrecy, as the key exchanged via ECDH is never transmitted so that an attacker cannot decrypt the stream even after the fact. Frequent rotation means an attacker needs to brute force multiple AES keys or needs to break at least one participant ECC key. B. this gives you for free the ability to rekey, that you mention in the doc and say you can't implement yet.
Additionally
For (1) you have 2 options. 1.a: Client generates new ECC keys for each meeting 1.b: client stores keys in browser storage for reuse over multiple meetings
In 1.a you avoid key reuse and reduce the chance of exposing keys that can be used to brute force older recorded streams. However it means the host needs to re-approve individual participant on each meeting. This can be mitigated by additional authentication schemes on top.
In 1.b you can allow the host to pre-authorize in their client configuration specific individuals to join a E2EE meeting at any time, without explicit interaction.
Note: ECC and ECDH are just a choice, you could equally use DH or RSA key exchanges to the same effect, and in future PQC safe algorithms, ECC/ECDH are just currently the most efficient in terms of key sizes and key generation. X25519, X448 or any of the NIST curves could be supported. Supporting multiple key types at the same time may be complicated, but it can be handled in the ephemeral case and with an additional layer of ephemeral key negotiation, it is probably sufficient to standardize on a single curve like x25519 initially.