RFC 8870 : DTLS-SRTP extension support in the browser

[shakeeb nazmus]

WebRTC uses SRTP to encrypt media. SRTP key is derived from the DTLS session. Now a days all like to use elliptic curve cipher for security so using the same key for the two sessions is almost impossible. For this reason, media needs to be encrypted with separate key for every user. This is not an efficient approach specially in the LAN, where we could use multicast to save much bandwidth.

So I think we should support RFC 8870.     

Thanks,

Shakeeb

 

[Harald Alvestrand]

WebRTC doesn't support multicast, so the question of use of multicast in LAN is rather moot.

There are other arguments for supporting EKT (Encrypted Key Transport, RFC 8870), but supporting multicast would require a rather thorough revamping of the WebRTC model - in particular, NACK doesn't have good solutions in an any-source-multicast environment, and end-user utilization of single-source-multicast is not a thing I know that anyone has good solutions for.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7e489365-e63d-4e96-8324-cabb11a2b0e3n%40googlegroups.com.

[Sean DuBois]

Hi,

This would be useful in a few cases for me.

Broadcasting - I see WebRTC developers building things with 1,000+ viewers of the same video. They don’t do NACK and just do a keyframe every n (usually two seconds). Supporting this would massively reduce CPU cycles. Pretty great win to save on wasted energy :)

Embedded - These developers end up running a SFU to support 2 or 3 viewers. With EKT they could do p2p still. The reduction in complexity could empower a lot more in the space!

Harald I don’t understand all the downsides. However the eternal optimist in me would like to try and make this work. If I built MVPs/wrote explainers do you see a world where this could happen?

On Jun 8, 2023, at 3:38 AM, 'Harald Alvestrand' via discuss-webrtc <discuss...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVEkXpdDj0fjijW-jAuWuFHSXcVg9V5PSAbvZbUn8mfaOQ%40mail.gmail.com.

[Nils Ohlmeier]

I agree with Harald in that multicast is probably not a great use case for EKT, because lots of other areas of webrtc would break if you try to run them over multicast, e.g. ICE.

But I also agree with Sean that it would be awesome to get EKT support in libwebrtc, because it could open a few interesting use cases especially around bigger conferences.

Best
  Nils Ohlmeier

[Harald Alvestrand]

I was specifically referring to multicast. Multicast is a lot more complicated than one would think (speaking as someone who has watched it fail to get deployed on the Internet since the 1990s).

Using EKT to force the same key on multiple outgoing sessions so that you can save on encryption cost is an interesting proposition. But - the encryption cost is on the order of microseconds per packet, and you can still send the same encoded format (encode once, send many) to multiple recipients without touching the encryption. Is this the right place to try to optimize?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8DCB7E6C-CD12-47FD-8C8C-4656B0F50F58%40pion.ly.

[se...@pion.ly]

I spent some time measuring this. I wrote a simple WebRTC server that serves pre-recorded H264+Opus and sends it to clients. I deployed my code to a t4g.xlarge instance.

Without EKT I was able to reach ~1750 clients when I started to see my freeze count rising. With EKT I was able to hit ~2500. I have attached a CPU profile + CSV with this data also.

A ~25% reduction in cost to run WebRTC servers is an exciting optimization. I am also encourage by the fact that it has zero API impact. This is just something that server operators *may* deploy. 

[bdrtc]

It seems that few people pay attention to the Webrtc-extension draft. I think it is a good place for such enhancement.

https://github.com/w3c/webrtc-extensions 

Best regards

-------------------------

ByteDance VolcEngineRTC Team Engineer

From: "Sean DuBois"<se...@pion.ly>

Date:  Thu, Jun 8, 2023, 23:38

Subject:  [External] Re: [discuss-webrtc] RFC 8870 : DTLS-SRTP extension support in the browser

To: <discuss...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8DCB7E6C-CD12-47FD-8C8C-4656B0F50F58%40pion.ly.

[Philipp Hancke]

Am Mo., 12. Juni 2023 um 06:22 Uhr schrieb se...@pion.ly <se...@pion.ly>:

I spent some time measuring this. I wrote a simple WebRTC server that serves pre-recorded H264+Opus and sends it to clients. I deployed my code to a t4g.xlarge instance.

For multiparty conferencing (and many other scenarios) one has to deal with stamping TWCC extension ids and potentially SSRC/CSRC rewriting which means EKT doesn't work as you need to encrypt different packets for different participants?

Without EKT I was able to reach ~1750 clients when I started to see my freeze count rising. With EKT I was able to hit ~2500. I have attached a CPU profile + CSV with this data also.

A ~25% reduction in cost to run WebRTC servers is an exciting optimization. I am also encourage by the fact that it has zero API impact. This is just something that server operators *may* deploy. 

Given that some EKT support was removed from libsrtp recently, how do you think this should be enabled in browsers?

 

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/becdf57f-797e-43b5-9644-50c36c06d84cn%40googlegroups.com.

[se...@pion.ly]

On Monday, June 12, 2023 at 10:52:36 AM UTC-4 Philipp Hancke wrote:

Am Mo., 12. Juni 2023 um 06:22 Uhr schrieb se...@pion.ly <se...@pion.ly>:

I spent some time measuring this. I wrote a simple WebRTC server that serves pre-recorded H264+Opus and sends it to clients. I deployed my code to a t4g.xlarge instance.

For multiparty conferencing (and many other scenarios) one has to deal with stamping TWCC extension ids and potentially SSRC/CSRC rewriting which means EKT doesn't work as you need to encrypt different packets for different participants?

It definitely wouldn’t work in all cases! I would maintain a stream of packets for each ‘remote type’. In practice I think you will end up having the same IDs because most people use Chrome?

 

Without EKT I was able to reach ~1750 clients when I started to see my freeze count rising. With EKT I was able to hit ~2500. I have attached a CPU profile + CSV with this data also.

A ~25% reduction in cost to run WebRTC servers is an exciting optimization. I am also encourage by the fact that it has zero API impact. This is just something that server operators *may* deploy. 

Given that some EKT support was removed from libsrtp recently, how do you think this should be enabled in browsers? 

I would be happy to re-implement it in libsrtp myself.

[Harald Alvestrand]

10 seconds out of 47 seconds total is certainly a significant part of the total!

I take it you wrote a custom receiver (supporting EKT? or just hardcoding the encryption key?) and used that in both cases?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/becdf57f-797e-43b5-9644-50c36c06d84cn%40googlegroups.com.

[se...@pion.ly]

I just hardcoded the key on both sides

Happy to do a full EKT implementation if that brings more clarity/confidence :)

[Sean DuBois]

On Jun 12, 2023, at 10:52 AM, 'Philipp Hancke' via discuss-webrtc <discuss...@googlegroups.com> wrote:

Am Mo., 12. Juni 2023 um 06:22 Uhr schrieb se...@pion.ly<se...@pion.ly>:

I spent some time measuring this. I wrote a simple WebRTC server that serves pre-recorded H264+Opus and sends it to clients. I deployed my code to a t4g.xlarge instance.

For multiparty conferencing (and many other scenarios) one has to deal with stamping TWCC extension ids and potentially SSRC/CSRC rewriting which means EKT doesn't work as you need to encrypt different packets for different participants?

It definitely wouldn’t work in all cases! I would maintain a stream of packets for each ‘remote type’. In practice I think you will end up having the same IDs because most people use Chrome?

Without EKT I was able to reach ~1750 clients when I started to see my freeze count rising. With EKT I was able to hit ~2500. I have attached a CPU profile + CSV with this data also.

A ~25% reduction in cost to run WebRTC servers is an exciting optimization. I am also encourage by the fact that it has zero API impact. This is just something that server operators *may* deploy. 

Given that some EKT support was removed from libsrtp recently, how do you think this should be enabled in browsers? 

I would be happy to re-implement it in libsrtp myself. 

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiLymeAOeuR3%3DzcE1TfNFxBkK1CZNt-tPJ5nmGg1NdS%3Dew%40mail.gmail.com.

[Sean DuBois]

I just hardcoded the key both sides

Happy to do a full EKT implementation if that brings more clarity/confidence :)

On Jun 13, 2023, at 3:26 PM, 'Harald Alvestrand' via discuss-webrtc <discuss...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVH6ZKfGsP%2BP%2Bm3HoKL%2BFtuCt9HnYgd60JQUngidRnA%3D3Q%40mail.gmail.com.