V53 Cryptographic requirements for WebRTC

[randomstuff]

Spinoff of #2215.

Is there any need for cryptographic requirements for WebRTC channels?

Possible topics:

• forward secrecy;
• peer authentication;
• encryption method/ciphersuites.

I would not expect much verification would be needed in practice. Maybe when a backend server acts as a WebRTC peer?

References

WebRTC requires Perfect Forward Secrecy (PFS) starting in Firefox 38 indicates that forward secrecy was not always enabled.

WebRTC Security: What You Need to Know in 2021 seems to imply that it is (was) not always automatic.

RFC8826:

It is this consideration that makes an automatic, public key-based key exchange mechanism imperative for WebRTC (this is a good idea for any communications security system), and this mechanism SHOULD provide Forward Secrecy (FS). The signaling channel/calling service can be used to authenticate this mechanism.

RFC8827:

Implementations MUST favor cipher suites which support Forward Secrecy (FS) over non-FS cipher suites and SHOULD favor Authenticated Encryption with Associated Data (AEAD) over non-AEAD cipher suites. .

[randomstuff]

ping @tghosth

[randomstuff]

ping @danielcuthbert

[tghosth]

I think we should actually ping @sandrogauci about this :) Sandro do you have any thoughts on this issue?

[sandrogauci]

Hi @randomstuff, thanks for the question. Here's my take:

The cryptographic requirements for WebRTC's DTLS implementation align with standard TLS requirements. Therefore, existing cryptographic requirements can be referenced where needed. This includes Perfect Forward Secrecy (PFS) considerations as part of the cipher suite requirements.

We've already addressed this in ASVS through requirement 53.2.2, which uses intentionally broad terms like "strong" and "secure" to remain adaptable to evolving cryptographic standards. This requirement was included for two key reasons:

1. Server-side cryptographic vulnerabilities can exist in WebRTC media gateways, regardless of browser security capabilities
2. Testing DTLS in WebRTC requires different methodologies than traditional TLS/HTTPS testing (e.g., testssl.sh approaches aren't applicable)

We want to avoid duplicating the cryptographic requirements already covered in the Cryptography chapter.

Regarding peer authentication, WebRTC implements mutual authentication during DTLS key establishment. This process uses certificate fingerprints transmitted via SDP (signaling), often with self-signed certificates. Both parties verify these fingerprints against the certificates. While self-signed certificates are typically considered insecure in other contexts, they are acceptable in WebRTC's security model. We address this in requirement 53.2.8, which ensures proper fingerprint verification.

Does this answer your question?