Spec: https://datatracker.ietf.org/doc/html/rfc8879 (It is not a draft anymore)
> Firefox: No public signals Enabled in Nightly builds (Brotli / Zlib compression) https://bugzilla.mozilla.org/show_bug.cgi?id=1885138 https://bugzilla.mozilla.org/show_bug.cgi?id=1881027 пятница, 6 июля 2018 г. в 22:33:47 UTC+3, David Benjamin: > As additional motivation, this is part of the path towards QUIC > standardization. QUIC has certificate compression today, which is > particularly useful in some DoS scenarios. (QUIC can send certificates a > roundtrip earlier than TCP, so the protocol must worry about > amplification.) The future standardized version of QUIC will use TLS 1.3. > This extension allows that future to maintain feature parity. > > On Fri, Jul 6, 2018 at 2:16 PM Adam Langley <a...@chromium.org> wrote: > >> *Contact emails* >> a...@chromium.org >> >> *Spec* >> https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-03 >> >> *Summary* >> TLS 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 >> <https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-03> 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. >> >> *Motivation* >> X.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 risk* >> Firefox: No public signals >> Edge: No public signals >> Safari: No public signals >> >> We can disable this feature at will as TLS will automatically fall back >> to sending uncompressed certificates. >> >> *Compatibility risk* >> We often ship new TLS extensions without breaking existing servers >> therefore we do not expect any issues here. >> >> *Ongoing technical constraints* >> None >> >> *Will 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 bug* >> https://bugs.chromium.org/p/chromium/issues/detail?id=860767 >> >> *Link to entry on the Chrome Platform Status* >> https://www.chromestatus.com/features/5696925844111360 >> >> *Requesting approval to ship?* >> Yes. >> >> >> Cheers >> >> AGL >> > -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/53f3178c-3d9d-4e4f-bf8d-a236780f05fbn%40chromium.org.
