Hi, This feature had been implemented in OpenSSL [1] and Chrome browser [2] for a while. Maybe, it is time to pick this request up for further discussion and review if there are resources available. What do you think?
Best, Xuelei [1]: https://github.com/openssl/openssl/issues/13597 [2]: https://chromestatus.com/feature/5696925844111360 > On Aug 2, 2022, at 7:53 PM, Xuelei Fan <xuele...@gmail.com> wrote: > >> >> On Aug 2, 2022, at 2:55 PM, Bradford Wetmore <bradford.wetm...@oracle.com> >> wrote: >> >> 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]. > > Thanks for the feedback. The timeline sounds reasonable to me. > > >> >> 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. >> > > It’s fine to me to add default compression implementations, while we are > keeping the flexibility for customization. I may come back for a revised > design at around version 22. > > >> 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] >> > > I’m not sure if the performance really plays a critical role in practice. > The support of compression algorithms could be an impact of interoperability > (for example, work with Internet browsers such as Chrome). > > > Thanks for the feedback! > > Best, > Xuelei > > >> Brad >> >> [1] >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fissues%2F13597&data=05%7C01%7Cxueleifan%40global.tencent.com%7Cc21799c52d1540bd324b08da74fa8a0a%7Ca32856f21731405cb53d480e26413adf%7C1%7C0%7C637950916681863507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EGu0LBAOv9KVtgP5ivRjFI9HLLelX4mIVy5raBQm0EU%3D&reserved=0 >> [2] >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgolang%2Fgo%2Fissues%2F42967&data=05%7C01%7Cxueleifan%40global.tencent.com%7Cc21799c52d1540bd324b08da74fa8a0a%7Ca32856f21731405cb53d480e26413adf%7C1%7C0%7C637950916681863507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eOwziZmg2Kee8KdO31pvfiXAzIxOu9plShJ11bngo2I%3D&reserved=0 >> [3] >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffacebook.github.io%2Fzstd%2F&data=05%7C01%7Cxueleifan%40global.tencent.com%7Cc21799c52d1540bd324b08da74fa8a0a%7Ca32856f21731405cb53d480e26413adf%7C1%7C0%7C637950916682019740%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TBR0haf0nGvb73pqbzcsbJlUvpSuARCSlgjUMt140As%3D&reserved=0 >> [4] >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fastly.com%2Fblog%2Fquic-handshake-tls-compression-certificates-extension-study&data=05%7C01%7Cxueleifan%40global.tencent.com%7Cc21799c52d1540bd324b08da74fa8a0a%7Ca32856f21731405cb53d480e26413adf%7C1%7C0%7C637950916682019740%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jmMY1Y4876EvoxfU%2F0XUPUnuEN0z2466JxnQfOC%2BX7k%3D&reserved=0
