Post-Quantum Crypto (PQC) support in WebRTC

[aboba]

We are now seeing PQC support added to TLS implementations:
https://docs.aws.amazon.com/kms/latest/developerguide/pqtls.html

In the announcement, s2n-tls was modified to add support for Kyber, NIST's first post-quantum key agreement standard.

The question is whether any changes are needed for WebRTC to support PQC algorithms such as Kyber:

• In SDP Offer/Answer.
• In the WebRTC-PC API.

[alvestrand]

The only things I know about PQC at the moment is that 1) it's implemented in TLS for Chrome, and 2) the keys are awfully big and 3) it requires TLS 1.3
In order to use PQC with WebRTC, we need DTLS 1.3 support. Once that's in place, the big worry is the size of the handshake - if it's now taking many more UDP packets, it will fail more often.

[ris-work]

I would love to have it supported too, and have hybrid key exchanges (preferably with different cryptographic problems rather than algorithms from the same problem set (e.g. LWE)). I know it is beyond the scope of WebRTC, but DTLS1.3 should have at least some basic PQ resistance and should work for us!

[maciejkra]

Hi any updates here? Is anyone tried to add pqc to webrtc?

[alvestrand]

There's work underway to implement DTLS 1.3 in boringssl. That's a precondition to adding the PQ cryptosuites in libwebrtc.
The tracking bug is https://issues.chromium.org/issues/42290594
Usage should be straightforward - "just" pass the necessary parameters to the generateCertificate method.
But I think we can't mandate support for this until we have gathered some experience, so there should be no need to update the standards at this time.

[maciejkra]

Thanks!
I just stared the mentioned ticket!

[Frosne]

The only things I know about PQC at the moment is that 1) it's implemented in TLS for Chrome, and 2) the keys are awfully big and 3) it requires TLS 1.3 In order to use PQC with WebRTC, we need DTLS 1.3 support. Once that's in place, the big worry is the size of the handshake - if it's now taking many more UDP packets, it will fail more often.

Hi, we (Firefox) currently support ssl_grp_kem_mlkem768x25519 in WebRTC in Nightly. My approach was to enable ssl_grp_kem_mlkem768x25519 in the list of supported groups, but not to generate a key share, such that the message does not get fragmented