[Internet]Re: Re: JEP Review Request: TLS Certificate Compression

Bradford Wetmore bradford.wetmore at oracle.com
Tue Aug 2 21:55:59 UTC 2022

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]


[1] https://github.com/openssl/openssl/issues/13597
[2] https://github.com/golang/go/issues/42967
[3] https://facebook.github.io/zstd/

More information about the security-dev mailing list