Webrtc-pc: Is there an API to set DTLS-SRTP protection profile in js?

[amjy]

The default SRTP protection profile in DTLS extension is 'SRTP_AES128_CM_HMAC_SHA1_80'.
How to set 'SRTP_AEAD_AES_256_GCM' and others.

'SSL_CTX_set_tlsext_use_srtp' in openssl and 'srtp_crypto_policy_set_aes_gcm_256_16_auth' in libsrtp.

[Sean-Der]

For context GCM is dramatically faster (thanks to hardware acceleration), I think this could have a good impact on people doing video calls. The downside is the auth tag is bigger.

I posted performance numbers here

[amjy]

For context GCM is dramatically faster (thanks to hardware acceleration), I think this could have a good impact on people doing video calls. The downside is the auth tag is bigger.

I posted performance numbers here

But how to enable SRTP_AEAD_AES_256_GCM in web ?

[Sean-Der]

There is none that I am aware of @amjy sorry. Members of RTCWeb hopefully will give this attention, there is nothing I can do though.

[lgrahl]

AFAIK Firefox prefers AES GCM by default. Chrome still puts it at the bottom of the negotation list (for whatever reason) even when opting in but I think there's a CL for that - just can't find it. @fippo will know for sure.

But in any case, there's nothing the W3C spec should do about this. IMO this is an IETF and implementation matter. And in fact, it is recommended by draft-ietf-rtcweb-security-arch-20 sec 6.5:

[...] The DTLS-SRTP protection profile
SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.
Implementations MUST favor cipher suites which support (Perfect
Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD
over non-AEAD cipher suites.

[Sean-Der]

@lgrahl 100% agree with everything you said.

My only hope is a knob could unblock people using implementation that aren’t doing what users want. Not the right thing to do though. It’s a shame Chromium isn’t following the spec.

[fippo]

The main reason for not landing GCM at highest priority was that this was quite a risky change. Which was the reason this was stuck in the basement for three (four?) years without any progress. I hope that we can revisit that once some people have provided numbers on SFU impact which should be possible in the current form.

Controlling the algorithm might be interesting, e.g. https://tools.ietf.org/html/draft-omara-sframe-00#section-4.5.2 suggests using the truncated _32 ciphersuites in certain cases. But it is going to be tricky to specify this without weakening security.

[aboba]

We are closing this issue for WebRTC-PC because it appears to be an implementation problem. But it might be appropriate to file it elsewhere such as in Insertable Streams (relating to SFrame) or WebRTC-NV Use Cases.

[alvestrand]

Choosing an algorithm seems to be an implementation problem.
Having an API to let the app choose the algorithm seems to be an API problem, and probably needs to go in as an extension.