Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/tls: add support for Certificate Compression (RFC 8879) #42967

Open
marten-seemann opened this issue Dec 3, 2020 · 3 comments
Open

crypto/tls: add support for Certificate Compression (RFC 8879) #42967

marten-seemann opened this issue Dec 3, 2020 · 3 comments
Labels
FeatureRequest NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@marten-seemann
Copy link
Contributor

marten-seemann commented Dec 3, 2020

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:

  1. Add support for zlib compression first. zlib is already a part of the standard library, so support could be added without any API changes to crypto/tls and without any changes outside of that package.
  2. Also add support for brotli, to get the performance benefits when serving a Chrome client. brotli is not implemented in the standard library though. One could:
    1. include brotli in the standard library (either as an internal package, or an exposed package), then use it in crypto/tls
    2. define a callback for the tls.Config: GetCertificateCompressor(enum int) CertificateCompressor
@mvdan mvdan added FeatureRequest NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Dec 3, 2020
@mvdan
Copy link
Member

mvdan commented Dec 3, 2020

cc @FiloSottile

@FiloSottile
Copy link
Contributor

FiloSottile commented Dec 3, 2020

Chrome doesn't support zlib at all?

(We are not adding an exposed API. Including a brotli implementation would require one to be submitted under the CLA or at leeeast as a BSD 1-clause, which would still require an exception.)

@marten-seemann
Copy link
Contributor Author

marten-seemann commented Dec 3, 2020

Chrome doesn't support zlib at all?

This is the commit that added certificate compression support: https://chromium.googlesource.com/chromium/src.git/+/93cbfad1add58d084010138d90d7ab3f74e913d2, and it doesn't look like they added another algorithm after that: https://source.chromium.org/chromium/chromium/src/+/master:net/socket/ssl_client_socket_impl.cc?q=ssl_client_socket_impl.cc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

4 participants