Contact emailsSpecSummaryTLS 1.3 encrypts the server's certificates. With that protection in place, we finally have the confidence that we can implement certificate compression without causing middlebox issues.Certificate compression is an IETF TLS WG draft and we plan on implementing that specification, supporting the Brotli algorithm.This feature is negotiated with the TLS server for each connection. We have high confidence that advertising support for certificate compression will not cause problems itself because we often add new TLS extensions (and have active GREASEing of them).This feature will be transparent to web developers: if their server implements certificate compression it will save a few bytes of TLS handshake but everything will otherwise be the same.MotivationX.509 certificates are not terribly compact and dominate the TLS handshake when sent. Compressing them has been a desiderata for many years but it's only now, with TLS 1.3, that we think it viable. The savings are modest (mail.google.com saves 553 bytes per handshake right now), but every little helps—especially as the number of third-party sub-resources used by sites, and thus the number of resulting TLS handshakes, increases.Interoperability riskFirefox: No public signalsEdge: No public signalsSafari: No public signalsWe can disable this feature at will as TLS will automatically fall back to sending uncompressed certificates.Compatibility riskWe often ship new TLS extensions without breaking existing servers therefore we do not expect any issues here.Ongoing technical constraintsNoneWill this feature be supported on all six Blink platforms (Windows, Mac, Linux,Chrome OS, Android, and Android WebView)?Yes: it'll take effect wherever we ship the Chromium network stack and don't explicitly disable Brotli support.Tracking bugLink to entry on the Chrome Platform StatusRequesting approval to ship?Yes.CheersAGL
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaBKHw1w%2BJTyW6KBvd7Cr7qsyhzO75J8enROTdfYSz4VVA%40mail.gmail.com.--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_uWHtz%3D-H-v81LZK12h6VW3PzqTh1-Nv__9bkFrJCa3Vpz_w%40mail.gmail.com.
I am also not any kind of expert in this area so please forgive me if I ask basic/stupid questions:The Intent lists "no signals" from any other vendor. Have anyone asked them or at least filed a bug in their bug databases?
Similar to Philip's question but more general (or maybe the same), what ensures implementation interoperability today?The RFC is classified as a draft that expires in a month. How stable is it?
We've seen in other security areas that compression has leaked information since not all data is equally compressible. That is not mentioned in the security section of the spec. Is it an oversight or is this completely irrelevant (I warned that the questions might be stupid!)
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/18ea8a44-cd00-41fa-83c8-19db2ccd1472%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaBYyBNVR1hqorbd1Th_6_OdvCy7EpnvCZjrECjnb%3DcK9A%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DeMUXCyR5eX9UOD9YQMEE%2Btz__M1Gmw6Qyh34AXo47fzQ%40mail.gmail.com.