RFR JDK-8247630: Use two key share entries

Xuelei Fan xuelei.fan at oracle.com
Mon Jul 27 15:21:14 UTC 2020


I was just wondering, could we just simplify the implementation by using 
two named groups for the top two-preferred categories, without limited 
to XDH and ECDHE?  For example, if FFDHE is on the top 2, FFDHE will be 
used as well.  Normally, XDH and ECDHE will be used, but the simplifying 
is a little bit more flexible if FFDHE is preferred.  What do you think?

Xuelei

On 7/8/2020 3:57 PM, Jamil Nimeh wrote:
> 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
> 



More information about the security-dev mailing list