Subject: [rtcweb] Efficient crypto for conferences

From: Emil Ivov <[email-masked]>
Date: Wed, 23 Jul 2014 10:37:13 -0400

Hey all,

Lately, we have been working on SFU-based conferencing. SFUs and WebRTC 
go together quite well: SFUs scale beautifully and are very latency 
friendly which makes them great for cloud deployment.

But!

There is a glass ceiling currently that I was hoping we could discuss.

Performance.

Currently the only way an SFU can operate is by terminating DTLS/SRTP 
for every participant. This means decrypting and (worse) re-encrypting 
all traffic that traverses the SFU. This easily accounts for 90% of the 
CPU use on the SFU.

This is not a difficult problem to solve and AVTCORE even has a WG 
document that addresses it. It removes the need for decrypting and 
allows SFUs to just forward packets.

However, while chatting with many others in Toronto it appeared that 
most of us are focused on solving a slightly different problem:

Privacy.

Or in other words: making it impossible (as opposed to unnecessary) for 
SFUs to decrypt.

While this is a notable effort, it is also much more complex and parts 
of it (i.e. not requiring end users to trust their web provider) would 
be arguably very hard to solve.

Therefore, my question to the working group is: wouldn't it make sense 
to try and solve the efficiency issue as a first step and then worry 
about the privacy one on a later stage?

Emil

-- 
https://jitsi.org

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Jul 2014 07:46:05 -0700

On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov <[email-masked]> wrote:

> Hey all,
>
> Lately, we have been working on SFU-based conferencing. SFUs and WebRTC go
> together quite well: SFUs scale beautifully and are very latency friendly
> which makes them great for cloud deployment.
>
> But!
>
> Currently the only way an SFU can operate is by terminating DTLS/SRTP for
> every participant. This means decrypting and (worse) re-encrypting all
> traffic that traverses the SFU. This easily accounts for 90% of the CPU use
> on the SFU.
>
> document that addresses it. It removes the need for decrypting and allows
> SFUs to just forward packets.
>
> However, while chatting with many others in Toronto it appeared that most
> of us are focused on solving a slightly different problem:
>
> Privacy.
>
> While this is a notable effort, it is also much more complex and parts of
> it (i.e. not requiring end users to trust their web provider) would be
> arguably very hard to solve.
>
> Therefore, my question to the working group is: wouldn't it make sense to
> try and solve the efficiency issue as a first step and then worry about the
> privacy one on a later stage?

In what way is the efficiency issue not solved by EKT?

-Ekr

>
> Emil
>
> --
> https://jitsi.org
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 23 Jul 2014 07:54:13 -0700

I'd be in favor of seeing if solving both is possible before in a good
way before committing to a "first step" which might end up a dead-end.

In terms of timeline and scope, I think this is out of scope for
WebRTC 1.0, so even a small "first step" might be quite a ways off.

On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov <[email-masked]> wrote:
> This is not a difficult problem to solve and AVTCORE even has a WG document
> that addresses it. It removes the need for decrypting and allows SFUs to
> just forward packets.
>
> However, while chatting with many others in Toronto it appeared that most of
> us are focused on solving a slightly different problem:
>
> Privacy.
>
> Or in other words: making it impossible (as opposed to unnecessary) for SFUs
> to decrypt.
>
> While this is a notable effort, it is also much more complex and parts of it
> (i.e. not requiring end users to trust their web provider) would be arguably
> very hard to solve.
>

---

From: Emil Ivov <[email-masked]>
Date: Wed, 23 Jul 2014 10:59:04 -0400

On 23.07.14, 10:46, Eric Rescorla wrote:
>
>
>
> On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hey all,
>
>     Lately, we have been working on SFU-based conferencing. SFUs and
>     WebRTC go together quite well: SFUs scale beautifully and are very
>     latency friendly which makes them great for cloud deployment.
>
>     But!
>
>     Currently the only way an SFU can operate is by terminating
>     DTLS/SRTP for every participant. This means decrypting and (worse)
>     re-encrypting all traffic that traverses the SFU. This easily
>     accounts for 90% of the CPU use on the SFU.
>
>     Or in other words: making it impossible (as opposed to unnecessary)
>     for SFUs to decrypt.
>
>     While this is a notable effort, it is also much more complex and
>     parts of it (i.e. not requiring end users to trust their web
>     provider) would be arguably very hard to solve.
>
>     Therefore, my question to the working group is: wouldn't it make
>     sense to try and solve the efficiency issue as a first step and then
>     worry about the privacy one on a later stage?
>
>

EKT is exactly the AVTCORE solution I was referring to.

Emil

---

From: Justin Uberti <[email-masked]>
Date: Wed, 23 Jul 2014 11:41:43 -0400

>From an efficiency perspective, doesn't AES-NI make this much less of an
issue, especially when the SFU has to do real work like rate shaping?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Jul 2014 09:41:06 -0700

> EKT is exactly the AVTCORE solution I was referring to.

In that case, I am in favor of this work. I think it also is a step towards
better privacy.

-Ekr

---

From: Emil Ivov <[email-masked]>
Date: Wed, 23 Jul 2014 13:58:39 -0400

> way before committing to a "first step" which might end up a dead-end.

Let's look at the privacy challenge though. First let's agree on who we 
are protecting from whom. Most of the solutions that are currently being 
mentioned here and there are about making sure that an SFU will not have 
the possibility to decrypt. It never sees the keys.

Well, while that does solve some part of the privacy concerns we should 
be aware that it does very little to guarantee privacy to end users.

In other words, consider a scenario where Alice connects to a video 
conference at SuperCollaboration.com. SuperCollaboration rely on 
CloudSFU.com for the actual conference support.

While not providing CloudSFU with the keys makes it easier for 
SuperCollaboration to trust and use them, it does nothing to protect 
Alice from SuperCollaboration performing MitM attacks on it. That is a 
much harder problem to solve (if at all with WebRTC).

On the other hand, making SFUs very lightweight (e.g., with EKT) would 
make it easier for Alice to deploy her own SFU on infrastructure that 
matches her security concerns, regardless of whether that means a VM she 
has root for, or a data center protected by her own private militia.

> WebRTC 1.0, so even a small "first step" might be quite a ways off.

The good thing about EKT is that it's already there, it's relatively 
straightforward and does not require a lot more spec work. It's 
primarily a matter of implementation. So it shouldn't be delaying anytihng.

Emil

-- 
https://jitsi.org

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 23 Jul 2014 14:50:47 -0400

Emil said:

"While not providing CloudSFU with the keys makes it easier for
SuperCollaboration to trust and use them, it does nothing to protect Alice
from SuperCollaboration performing MitM attacks on it."

[BA] I think there is also additional questions:
a. Do we trust SuperCollaboration not to add additional participants to the
conference, or to forward information about the conference to an
unauthorized party?  Meta-data about the conference can be valuable.  To
use Jonathan's example, knowing that BigCompany X and potential acquisition
Y are in a conference is valuable information, even with no knowledge of
the media.
b. Do we trust the IdP to authenticate the participants, so that we can
verify that they are authorized to join the conference before providing
them with the keys?

On Wed, Jul 23, 2014 at 1:58 PM, Emil Ivov <[email-masked]> wrote:

> Well, while that does solve some part of the privacy concerns we should be
> aware that it does very little to guarantee privacy to end users.
>
> SuperCollaboration to trust and use them, it does nothing to protect Alice
> from SuperCollaboration performing MitM attacks on it. That is a much
> harder problem to solve (if at all with WebRTC).
>
> straightforward and does not require a lot more spec work. It's primarily a
> matter of implementation. So it shouldn't be delaying anytihng.
>
> Emil
>
>
>
>>> go
>>> document
>>> most of
>>> SFUs
>>> of it

---

From: Dan Wing <[email-masked]>
Date: Wed, 23 Jul 2014 14:54:13 -0400

On Jul 23, 2014, at 1:58 PM, Emil Ivov <[email-masked]> wrote:

> Let's look at the privacy challenge though. First let's agree on who we are protecting from whom. Most of the solutions that are currently being mentioned here and there are about making sure that an SFU will not have the possibility to decrypt. It never sees the keys.
> 
> Well, while that does solve some part of the privacy concerns we should be aware that it does very little to guarantee privacy to end users.
> 
> In other words, consider a scenario where Alice connects to a video conference at SuperCollaboration.com. SuperCollaboration rely on CloudSFU.com for the actual conference support.
> 
> While not providing CloudSFU with the keys makes it easier for SuperCollaboration to trust and use them, it does nothing to protect Alice from SuperCollaboration performing MitM attacks on it. That is a much harder problem to solve (if at all with WebRTC).

I believe the weakness is how identity is provided.  If SuperCollaboration.com provides identity over the a=fingerprint's, it could be lying and if it provides the Javascript to do identity generation/validation, it is probably as weak as Javascript encrypting email.  Perhaps part of all of the identity generation/validation needs to be done by the browser (rather than Javascript) much like some of the ICE transaction is done by the browser (and inaccessible to Javascript) such as the ICE transaction-id.

-d

> 
> On the other hand, making SFUs very lightweight (e.g., with EKT) would make it easier for Alice to deploy her own SFU on infrastructure that matches her security concerns, regardless of whether that means a VM she has root for, or a data center protected by her own private militia.
> 
> The good thing about EKT is that it's already there, it's relatively straightforward and does not require a lot more spec work. It's primarily a matter of implementation. So it shouldn't be delaying anytihng.
> 
> Emil
> 
>>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 23 Jul 2014 15:36:03 -0400

On Wed, Jul 23, 2014 at 1:58 PM, Emil Ivov <[email-masked]> wrote:

> from SuperCollaboration performing MitM attacks on

it. That is a much harder problem to solve (if at all with WebRTC).
​Sorry, what MitM attack are you looking at here?  In the example I thought
you were giving, SuperCollaboration has the keys but CloudSFU is the entity
on path.  What am I getting wrong?

Ted​

---

From: Emil Ivov <[email-masked]>
Date: Wed, 23 Jul 2014 16:57:47 -0400

On 23.07.14, 15:36, Ted Hardie wrote:
>
> On Wed, Jul 23, 2014 at 1:58 PM, Emil Ivov <[email-masked]
>     Let's look at the privacy challenge though. First let's agree on who
>     we are protecting from whom. Most of the solutions that are
>     currently being mentioned here and there are about making sure that
>     an SFU will not have the possibility to decrypt. It never sees the keys.
>
>     Well, while that does solve some part of the privacy concerns we
>     should be aware that it does very little to guarantee privacy to end
>     users.
>
>     Alice from SuperCollaboration performing MitM attacks on
>
> ​Sorry, what MitM attack are you looking at here?  In the example I
> thought you were giving, SuperCollaboration has the keys but CloudSFU is
> the entity on path.  What am I getting wrong?

I was referring to the fact that since SupperCollaboration controls the 
signalling, it can silently put itself on the path between the browser 
and CloudSFU and terminate encryption.

Emil

> Ted​
>
>     On the other hand, making SFUs very lightweight (e.g., with EKT)
>     would make it easier for Alice to deploy her own SFU on
>     infrastructure that matches her security concerns, regardless of
>     whether that means a VM she has root for, or a data center protected
>     by her own private militia.
>
>
>             DTLS/SRTP for
>             _________________________________________________
>             rtcweb mailing list
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/__listinfo/rtcweb
>             <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>
>     --
>     https://jitsi.org
>
>     _________________________________________________
>     rtcweb mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>

-- 
https://jitsi.org