Hi Xuelei,
Sean wrote:
> I haven't had time to look at this in detail yet. I would like a
> couple more weeks to review the draft.
We've been looking closely at RFC 8879 and your proposal to add support
into JSSE. I think we're in agreement that this would be a good
addition for the reasons you outline.
We are currently busy with some high-priority projects so reviewing this
JEP will need more time. This means that we'll need to wait a release or
two for proper and thorough discussion and review. Timeline wise this is
reasonable as other TLS implementations such as OpenSSL and GoLang are
at a similar assessment stage [1][2].
On the technical side, while having a pluggable API for supporting
different/additional compression types has its merits, my preference is
to have some/all of these compression types directly supported within
JSSE so that this works out-of-the-box, and developers don't introduce
unexpected/hard-to-debug compression errors. Otherwise everyone would
have to copy the same compression code everywhere. Seems a bit painful
when a simple implementation could be provided that works for many/most.
The other big benefit is that this will allow for trivial backports as
no API will be needed for earlier releases.
When more implementations start supporting this Certificate Compression
RFC, I think Zlib might be the most widely used. Adding the ZLIB
extension seems a natural first target as there is already an
implementation in JDK, and you demonstrated how easy encoding in ZLIB
is. I see Chrome already has brotli, and zstd seems like it would be a
faster algorithm with tighter compression, though without prototyping,
I'm not sure how much gain we'll get with smallish cert chains (i.e.
10's of kb) vs. large data sets that I've seen numbers for[3]. Patrick
McManus/Fastly felt anecdotally that the difference between the three
wasn't that different, compared to not having compression at all.
The TLS certificate compression specification allows any of the
deflate, brotli, or zstd formats for compression. Anecdotally, the
differences between them were very small compared to the difference
between compressed and uncompressed representations. [4]
Brad
[1] https://github.com/openssl/openssl/issues/13597
[2] https://github.com/golang/go/issues/42967
[3] https://facebook.github.io/zstd/
[4]
https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study
