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
