crypto/tls: add support for Certificate Compression (RFC 8879) #42967
Labels
FeatureRequest
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
RFC 8879 has recently been published. The RFC describes a way to compress the TLS certificate chain when using TLS 1.3.
Compressing the certificate chain reduces the number of bytes exchanged during the handshake. While sending fewer bytes is always a win for performance, this becomes especially important for QUIC, where due to the lack of the TCP 3-way handshake, the server's first flight (which contains the certificate chain) is limited to 3x the number of bytes that it received from the client, see https://www.fastly.com/es/blog/quic-handshake-tls-compression-certificates-extension-study for real world data.
Since the Certificate message is encrypted in TLS 1.3, it is not possible to implement certificate compression without access to the keys derived during the handshake, i.e. outside of the standard library.
The RFC describes 3 different compression algorithms that TLS endpoints can advertise support for: zlib, zstd and brotli.
Chrome has had support for this extension since version 69 using the brotli algorithm: https://www.chromestatus.com/feature/5696925844111360.
Implementation-wise, there are a few options here:
tls.Config
:GetCertificateCompressor(enum int) CertificateCompressor
The text was updated successfully, but these errors were encountered: