> 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 > >
