RFR JDK-8247630: Use two key share entries

[Jamil Nimeh]

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
>>>