Re: [webrtc-extensions] Post-Quantum Crypto (PQC) support in WebRTC (#207)

The SHA1_80 ciphersuites (if I remember correctly) are because of overhead
on audio packets.
Completely different discussion - bandwidth usage, not negotiation cycles.

I'm happy with "measure first, then decide if we have a problem". The
metrics are sensitive enough that they eventually caught the 2-lost-packets
regression that jonas just fixed; from what davidben is saying, we have
multiple dimensions that may cause metrics to move, and not all of them in
a negative direction.



On Thu, Aug 28, 2025 at 3:42 PM David Benjamin ***@***.***>
wrote:

> *davidben* left a comment (w3c/webrtc-extensions#207)
> <https://github.com/w3c/webrtc-extensions/issues/207#issuecomment-3233558154>
>
> That works for changes without a regression in a metric folks care about.
> Given that PQC makes the client hello go from one to two packets I'd expect
> reliability issues which negatively affect the "call setup time" (DTLS 1.3
> will be a win).
>
> That is not quite how (D)TLS 1.3 works. Offering *and predicting* PQC
> makes the ClientHello go to two packets. There are clear reasons to want to
> predict PQC given we intend for traffic to migrate to it. But if
> mispredicting PQC against non-PQC peers is too much a transitionary
> performance problem, those are things we can explore to refine that
> behavior. On the HTTPS side, there's a DNS hint at TLSWG to adjust the
> predicted set (but *not* the supported set).
>
> However, thus far, I'm not aware of problems with the current launch
> strategy. ***@***.*** <https://github.com/alvestrand>, do you know how
> we are looking on that so far?) If problems develop, we can figure that
> out. But given that the performance baseline was a 2-RTT DTLS 1.2
> handshake, it's not obvious to me that 1-RTT with two-packet ClientHello
> will be worse.
>
> Services and servers not having another option but to not negotiate PQC
> might be a blocker for adoption.
>
> That is not how (D)TLS works. The client and server both support multiple
> options. Adding PQ does not remove the classical options when speaking to
> legacy servers.
>
> We've seen that before and it is the reason why SRTP in Chrome is still
> the AES_CM_128_HMAC_SHA1_80 ciphersuites instead of the GCM ones.
>
> This also does not make any sense. I have not been involved with Chrome
> WebRTC's use of SRTP, but there's an entire TLS extension jammed in there
> so that the TLS handshake can negotiate an SRTP profile. It should have
> been possible to do a smooth transition where the client offers both old +
> new and then servers support both old + new.
>
> @alvestrand <https://github.com/alvestrand> do you know what's up with
> this?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/webrtc-extensions/issues/207#issuecomment-3233558154>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AADVM7LOZ677RLJH3LIQNGL3P4BMRAVCNFSM6AAAAABIH3NTCSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMZTGU2TQMJVGQ>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>


-- 
GitHub Notification of comment by alvestrand
Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/207#issuecomment-3233619123 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 28 August 2025 13:58:56 UTC