Hi Xuelei, I've updated the webrev based on your suggestion. It
actually made the logic a lot simpler so that was a good suggestion for
sure.
I also added a couple additional tests in ClientHelloKeyShares.java to
cover a few different namedGroup orderings.
https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.02/
--Jamil
On 7/27/20 9:11 AM, Jamil Nimeh wrote:
Yes, I think I could restructure this to support that approach. You're
right in that FFDHE gets the short end of the stick in the current
scheme unless it's the only type in the namedGroups property and even
then it takes the longest in terms of time. I'll restructure this and
issue a new webrev.
--Jamil
On 7/27/2020 8:21 AM, Xuelei Fan wrote:
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
