[Internet]Re: Re: Re: JEP Review Request: TLS Certificate Compression
Xuelei Fan
xuelei.f at gmail.com
Wed Aug 3 02:53:19 UTC 2022
> On Aug 2, 2022, at 2:55 PM, Bradford Wetmore <bradford.wetmore at 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
>
>
More information about the security-dev
mailing list