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

[fippo]

From trying to experimentally enable PQC in Chromium/WebRTC it looks like we might want to expose the TLS group id as defined in
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
in webrtc stats similar to
https://w3c.github.io/webrtc-stats/#dom-rtctransportstats-dtlscipher
(which is a string)?
The numeric id, e.g. 4588 for X25519MLKEM768 should be sufficient, resolving that to the IANA string seems a bit of a hassle.
@Frosne would that work from the NSS side too?

How to opt in remains a good question, by default boringssl generated a key share which has impact on the size of the handshake which is going to be a headache.

[Frosne]

Hi,
If I understood the question correctly:

We do use the id (like for the mentioned X25519MLKEM768 we use only the id - see here: https://searchfox.org/mozilla-central/source/security/nss/lib/ssl/sslt.h#263) for TLS/DTLS

[alvestrand]

Seems like exposing the ID of the DTLS cipher to stats seems like the right choice here, given that the IANA strings are not universally used across the industry.
What would be the result for traditional ciphers like EC and RSA?

[fippo]

OpenSSL (and BoringSSL) have a "human-friendly" SSL_CIPHER_standard_name which takes the result of SSL_get_current_cipher and turns it into the standard name that we use for dtlsCipher (this seems to be "recent", I found vestiges of a libWebRTC trying to do a mapping to standard names).
Currently you get something like TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 which is the translated equivalent of 0xC0,0x2B from the registry.
We could add dtlsCipherId and deprecate dtlsCipher but we know we have no way to actually remove stats (looking at you, mediaType aka kind).

[fippo]

Current 🤔:

const pc = new RTCPeerConnection({cryptoOptions:{
  dtls: {
    groups: ["X25519MLKEM768"],
  }
}});

with a list of MTI IANA group names. cryptoOptions maps nicely to an existing implementation and can be extended to give more control over SRTP ciphers as requested in #113.

Combined with RTCTransportStats dtlsGroup that gives the algorithm identifier as integer because of this and I'd rather not have a reverse mapping of group names.