Fwd: RFR JDK-8247630: Use two key share entries

Jamil Nimeh jamil.j.nimeh at oracle.com
Tue Jul 21 17:48:52 UTC 2020


Ping.

--J

-------- Forwarded Message --------
Subject: 	RFR JDK-8247630: Use two key share entries
Date: 	Wed, 8 Jul 2020 15:57:15 -0700
From: 	Jamil Nimeh <jamil.j.nimeh at oracle.com>
To: 	security-dev at openjdk.java.net



Hello all,

This is a small enhancement to the TLS 1.3 client hello.  With this 
change JSSE will make a best-effort attempt to select the most-preferred 
XDH and ECDHE named group.  In most cases this will be x25519 and 
secp256r1.  This was done to help reduce the number of times our clients 
get HelloRetryRequests due to servers wanting secp256r1 when we would 
just assert x25519.

The asserted key shares can be affected by different settings for the 
jdk.tls.namedGroups System property.  If x25519 and/or secp256r1 are 
missing, the next-most-preferred named group of that class will be 
selected.  If no other named group in that class is in the 
supported_groups extension, then it will be skipped.  In the unlikely 
event that no XDH or ECDHE supported group is asserted, then the client 
will assert one key share, the most preferred one out of the supported 
groups.

This also fixes one minor spec compliance issue where we weren't 
throwing an exception when a server returned an illegal 
HelloRetryRequest with a named group that was in the original key_shares 
extension from the client hello.

Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.01/

JBS: https://bugs.openjdk.java.net/browse/JDK-8247630

--Jamil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200721/9a7670a0/attachment.htm>


More information about the security-dev mailing list