Yup, we already shipped this feature some 6 years ago and kept up with the standards process. (I don't recall there being any changes needed in the first place, but it was 6 years ago. I believe the mechanism was already settled by then and the final codepoint already allocated.) There's no need to bump old threads for things that already shipped.
On Thu, Jun 27, 2024 at 8:17 AM Поджог Саплаев <[email protected]> wrote: > 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 <[email protected]> wrote: >> >>> *Contact emails* >>> [email protected] >>> >>> *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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaBV0fbDXZ7vxKiBheM_G%2BGiXeQx18KYSKGF8u9yWU-92w%40mail.gmail.com.
