On 3/14/22 2:21 PM, xueleifan(XueleiFan) wrote:
Hi Jamil,
Thank you for the support of this proposal. I am happy to move on to
the next JEP process if no objections or comments in the coming weeks.
Hi All,
Please let me know if more time is required for the review of the proposal.
I suggest you send a new message to security-dev with a link to the JEP
Draft for review as the next step (even though you already posted it).
Don't post any code yet, and don't move it to Submitted until there has
been enough time for review and consensus has been reached that this is
an idea that is worthy of being added to the JDK Roadmap.
Thanks,
Sean
Thanks,
Xuelei
On Mar 11, 2022, at 7:25 AM, Jamil Nimeh <jamil.j.ni...@oracle.com
<mailto:jamil.j.ni...@oracle.com>> wrote:
Hi Xuelei,
After reading over your descriptions and the supporting documentation
this certainly seems like it would be a nice addition to JSSE. It
definitely seems like a performance win for QUIC and also for
bandwidth-constrained devices. I'm all for seeing this JEP proceed.
I'll likely have more comments down the line and I have taken a look
at the proposed code changes and will go back and do a deeper dive on
it. I just don't want to jump any of the JEP process hoops by talking
about code changes before some of the important first steps for the
JEP have been cleared. But you've got my support on this one!
--Jamil
On 3/7/2022 11:46 AM, xueleifan(XueleiFan) wrote:
Hi,
The TLS Certificate Compression standard was described in RFC 8879,
and has been enabled in browser Chrome and Safari. 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).
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 supporting 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.
What do you think? Do you want it a part of OpenJDK? Please feel
free to share you comments.
Thanks,
Xuelei
