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

[Sean Mullan]

Hi Xuelei,

Please start this discussion in a new thread with a new subject (ex: 
Proposal for potential new feature: TLS Certificate Compression) as it 
should be evaluated on its own prior to reaching consensus and deciding 
if a JEP should be drafted.

Also, keep in mind that it may take a few days or longer for members of 
the Security Group and other interested participants to find time to 
review new proposals for significant features.

Thanks,
Sean

On 2/28/22 3:33 PM, xueleifan(XueleiFan) wrote:
> Hi,
> 
> It may be better to have more detail here, rather than refer you to the 
> draft JEP.  The first question maybe, if TLS Certificate Compression is 
> something we want it in OpenJDK?
> 
> The TLS Certificate Compression standard was described in RFC 8879, and 
> has been enabled in browser Chrome and Safari. But, what’s TLS 
> Certificate Compression and what’s the benefits of this feature?
> 
> For TLS connections, a client must authenticate the identity of the 
> server. This typically involves verification that the identity of the 
> server is included in a certificate and that the certificate is issued 
> by a trusted entity.
> 
> Where servers provide certificates for authentication, the size of the 
> certificate chain can consume a large number of bytes. Controlling the 
> size of certificate chains is critical to performance and security in 
> QUIC. TLS certificate compression has the potential to ameliorate the 
> attacks/problems by reducing the size of the handshakes to a size 
> compatible with the security restriction.  The TLS Certificate 
> Compression feature is an essential part for QUIC-TLS protocols.
> 
> For more details, please refer to section 4.4 in RFC 9001 (Using TLS to 
> Secure QUIC):
> ---------
> Note: Where servers provide certificates for authentication, the size of 
> the certificate chain can consume a large number of bytes. Controlling 
> the size of certificate chains is critical to performance in QUIC as 
> servers are limited to sending 3 bytes for every byte received prior to 
> validating the client address; see Section 8.1 of [QUIC-TRANSPORT]. The 
> size of a certificate chain can be managed by limiting the number of 
> names or extensions; using keys with small public key representations, 
> like ECDSA; or by using certificate compression [COMPRESS].¶
> ---------
> 
> and a more detailed description in the blog “Does the QUIC handshake 
> require compression to be 
> fast?”(https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study 
> <https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study>). 
>   I just copy part of the conclusion section of the bog here for your 
> quick reference.
> ---------
> First, the TLS certificate compression extension has a very large impact 
> on QUIC performance. Even though the extension is new and being 
> introduced fairly late in the process when compared to overall QUIC 
> deployment schedules, it seems quite important for both clients and 
> servers to implement the new extension so that the QUIC handshake can 
> live up to its billing. Without some help, 40% of QUIC full handshakes 
> would be no better than TCP, but compression can repair most of that 
> issue. I have heard of other non-standardized approaches to reducing the 
> size of the certificate chain, and they seem reasonable, but this is a 
> problem worth addressing immediately with the existing compression 
> extension.
> 
> ...
> 
> Lastly, data from the real world again proves to be more insightful than 
> intuition and is invaluable in making protocol design and implementation 
> decisions. When I started this work I expected the impact of compression 
> to be positive but marginally focused on a few edge cases. The data 
> shows this optimization lands right on the sweet spot that ties 
> configurations and the QUIC specification together and impacts a large 
> portion of QUIC handshakes. My thanks to the authors of the compression 
> extension.
> ---------
> 
> 
> Besides, reducing the amount of information exchanged during a TLS 
> handshake to a minimum helps to improve performance in environments, for 
> example Internet of Things, where devices are connected to a network 
> with a low bandwidth and lossy radio technology.
> 
> This feature is a part to improve the performance of TLS connections, 
> and it is also a part of the path towards QUIC standards.
> 
> Chrome support TLS certificate compression with Brotil compression 
> algorithm, and Safari support TLS certificate compression with Zlib 
> compression algorithm.
> 
> In a summary, JDK could benefits from support RFC 8879 in the following 
> areas:
> 
>      Performance - Reduce latency and improve performance of TLS and 
> QUIC connections by support the TLS certificate compression standard in JDK.
>      Security - Mitigate the impact of amplification attacks threat by 
> reducing the size of the TLS handshakes with compressed certificates.
> 
> Please feel free to share you comments, if it is something we want in 
> OpenJDK?
> 
> Thanks,
> Xuelei
> 
> 
>> On Feb 28, 2022, at 10:57 AM, xueleifan(XueleiFan) 
>> <xueleifan at tencent.com <mailto:xueleifan at tencent.com>> wrote:
>>
>> Hi,
>>
>> Could I have this JEP reviewed?  One or more qualified Committers 
>> review is required to move it forward.
>>
>> Here is the PR if you want to have a further look at the 
>> implementation and test:
>> https://github.com/openjdk/jdk/pull/7599 
>> <https://github.com/openjdk/jdk/pull/7599>
>>
>> Thanks,
>> Xuelei
>>
>>> On Feb 15, 2022, at 9:30 PM, xueleifan(XueleiFan) 
>>> <xueleifan at tencent.com <mailto:xueleifan at tencent.com>> wrote:
>>>
>>> Hi all,
>>>
>>> The JDK Enhancement Proposal, TLS Certificate Compression, has been 
>>> opened for community review.  Detailed, please refer to the draft:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8281710 
>>> <https://bugs.openjdk.java.net/browse/JDK-8281710>
>>>
>>> Feel free to make comment and send your feedback to the alias.  I may 
>>> submit this JEP in the beginning of next week if I hear no objections 
>>> by the end of this week.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>
>