Thank you for the suggestion, Sean. Hi all, please discuss the proposal in the new thread: https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html
Xuelei > On Mar 7, 2022, at 10:16 AM, Sean Mullan <sean.mul...@oracle.com> wrote: > > 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) <xuelei...@tencent.com >>> <mailto:xuelei...@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) <xuelei...@tencent.com >>>> <mailto:xuelei...@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 >>>> >>> >
