LWN: Comments on "Firefox 35.0"

Firefox 35.0 Hello Room Encryption

ekj — Wed, 04 Feb 2015 13:27:02 +0000

That's not how you use public-key crypto. Public-key crypto is typically CPU-intensive and sometimes also for other reasons unadvised to use on the actual data.

What you do is, you pick a RANDOM session-key; then you encrypt this key with the recipients public key, and the rest of the actual stream with the random one-time session-key by way of conventional symetrical crypto.

This gives you the speed and security of traditional crypto with the key-distribution-advantages of public-key crypto.

It also means if you want to send LARGE_STREAM to 5 people you only need to encrypt the (very small) session-key 5 times with the slow PK-crypto, and the large stream itself is encrypted only once with fast symmetrical crypto.

Firefox 35.0 Hello Room Encryption

Vertana — Fri, 16 Jan 2015 14:42:08 +0000

Thank you very much! I think that cleared up the last piece of this puzzle for me!

Firefox 35.0 Hello Room Encryption

peter-b — Fri, 16 Jan 2015 09:26:28 +0000

Not correct. You can encrypt the video you're sending with a stream cipher, and then encrypt the stream cipher key with the public keys of each of your participants. So you only suffer the cost of encrypting the video once, and only the intended recipients can decrypt it *or retransmit it without fully reencrypting it*. This works okay with a central server, as long as you trust the central server. ;-)

Firefox 35.0 Hello Room Encryption

Lennie — Thu, 15 Jan 2015 19:47:01 +0000

Ohh, that is unfortunate. But luckily it looks like it's being solved.

"The key issue at this point is that this behavior would be out-of-spec (and I expect Chrome to begin deprecating it sometime soon-ish to match specified behavior). The most recent agreement about how to handle unannounced SSRCs is captured here: https://github.com/w3c/webrtc-pc/pull/29

Note that there has been substantial progress on Bug 784517 following our SDP rewrite, and the proper, spec-compliant mechanism for multistream handling should land very soon now."

But I guess it's better to remove the wrong behaviour from the implementations now than later having to add some hacky workaround in the specifications.

Firefox 35.0 Hello Room Encryption

deepfire — Thu, 15 Jan 2015 19:13:47 +0000

What about text chat?

Firefox 35.0 Hello Room Encryption

tzafrir — Thu, 15 Jan 2015 17:18:19 +0000

which will redirect you to https://meet.jit.si/chromeonly.html fi you connect from Firefox.

Bugs in question:
https://github.com/jitsi/jitsi-meet/issues/4
https://bugzilla.mozilla.org/show_bug.cgi?id=784517

or rather:
https://bugzilla.mozilla.org/show_bug.cgi?id=1095218

which has seem some action lately.

Firefox 35.0 Hello Room Encryption

Vertana — Thu, 15 Jan 2015 16:48:45 +0000

Thank you for your input. Your comment and the ensuing discussion is helping me piece this together much better than I could on my own. The encryption answer sounds like it's encrypted with DTLS between each direct connection in a peer-to-peer setup, so although it is encrypted, it has natural limits due to CPU load and network load and thus isn't scalable without the implementation of a video bridge as you suggested.

Firefox 35.0 Hello Room Encryption

Vertana — Thu, 15 Jan 2015 16:46:31 +0000

So if this is using a peer-to-peer connection amongst each individual, then that means the encryption is only good between direct connections correct? Implying that with each connection you are increasing the CPU load which imposes a natural limit on how many participants can be in a room. Is there a server required to manage user states and such or is it really as "simple" as peer-to-peer DTLS connections where packet loss is not considered as much?

Firefox 35.0 Hello Room Encryption

drag — Thu, 15 Jan 2015 15:08:20 +0000

Unfortunately SIP sucks for most 'ad-hoc' type things. Unless you have knowledgeable people to manage the network connections on either side the chances of getting SIP working well in a P2P fashion is pretty small.

Even if you manage to get STUN setup and get people configured correctly things like 'bufferbloat' and such things play havoc with latency. Especially any sort of network tunneling that goes over tcp.

If we lived in a better world were people had proper firewalls and IPv6 then SIP may of worked well, but we don't so it doesn't.

Hopefully the ubiquity of chrome and firefox browsers can be leveraged to finally get realtime P2P communication to be a practical solution.

Firefox 35.0 Hello Room Encryption

Lennie — Thu, 15 Jan 2015 13:52:03 +0000

WebRTC does peer-to-peer.

Usually the rule of thumb for video is: no more than 4 people.

If you want more, use a video bridge, Jitsi gets a lot of attention:
https://jitsi.org/Projects/JitsiVideobridge

Firefox 35.0 Hello Room Encryption

josh — Thu, 15 Jan 2015 06:34:27 +0000

In particular, if using a UX similar to Hangouts, where the person speaking takes up most of the screen and others show up very small, switching to low-resolution video for those small images would work.

Firefox 35.0 Hello Room Encryption

zlynx — Thu, 15 Jan 2015 03:32:42 +0000

Could do it by only sending full resolution video when talking. Use a very low bandwidth stream the rest of the time.

Firefox 35.0 Hello Room Encryption

roc — Thu, 15 Jan 2015 03:24:25 +0000

That sounds good for audio, but less good for video.

Firefox 35.0 Hello Room Encryption

Cyberax — Thu, 15 Jan 2015 02:30:55 +0000

It can actually be pretty scalable, if participants can coordinate the send/receive periods. There can't be more than one (or two) speakers at the same time.

Firefox 35.0 Hello Room Encryption

roc — Thu, 15 Jan 2015 01:56:31 +0000

Right, I don't think we support multiple video tracks from a single peer yet, so we only support the secure-but-not-scalable approach where every participant streams directly to every other participant.

Firefox 35.0 Hello Room Encryption

dowdle — Wed, 14 Jan 2015 22:26:50 +0000

I couldn't find much info about the "rooms" feature so far as I can tell it is still just two participants max. If it did do more than two... I believe it would require n-1 inbound streams for each participant which really isn't doable for most people. That's why video-bridge type products exist... to aggregate the streams so that each participant is still only getting 1 inbound stream. Does that answer the encryption question?

Firefox 35.0 Hello Room Encryption

Vertana — Wed, 14 Jan 2015 21:20:42 +0000

I was searching around the Internet and I can't seem to find anything substantial on this topic. I know Firefox Hello implements end-to-end encryption through the use of WebRTC, but does it maintain end-to-end encryption even while in a 'room' with multiple users? If so, how does it do this? I saw how WebRTC sends data using DTLS, but I'm not sure how that's maintained with multiple users. My apologies if this is easy to find, perhaps my Google-fu is just off today.