On Wed, 28 Jan 2026 16:53:59 GMT, Artur Barashev <[email protected]> wrote:
>> Implement certificate compression in TLS 1.3 using internally supported ZLIB >> compression algorithm. See RFC 8879 for more details: >> https://datatracker.ietf.org/doc/html/rfc8879 > > Artur Barashev has updated the pull request incrementally with one additional > commit since the last revision: > > Force cache limit per compression algorithm > _Mailing list message from [Xuelei Fan](mailto:[email protected]) on > [security-dev](mailto:[email protected]):_ > > > > Yes, strangely Chrome supports only brotli although I didn't see any > > > difference in compression ration between zlib and brotli when manually > > > testing certificate compression. > > Did you have a chance to compress certification path with multiple > certificates? It is said Brotli has better ratio. > > It is said decompression is fas for Brotli. An entry may cache certificate > compression and thus decompression performance could play a role for the > algorithm selection in practice. > > Xuelei > > > > > -------------- next part -------------- An HTML attachment was scrubbed... > URL: > <https://mail.openjdk.org/pipermail/security-dev/attachments/20260128/82032b40/attachment.htm> - Yes, I tested 3-certificate "EC" and "ML-DSA" chains in DER format. There is no significant difference with default compression settings between gzip and brotli: - 1771 EC_chain.der - 1029 EC_chain.der.br - 1006 EC_chain.der.gz - 16992 ML-DSA_chain.der - 16487 ML-DSA_chain.der.br - 16555 ML-DSA_chain.der.gz - Decompression is generally much faster than compression for any algorithm, so while brotli decompression is faster than ZLIB it's not going to be a major performance factor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28682#issuecomment-3812856696
