RFR (RFE-13): JDK-8224520: Support X25519 and X448 in TLS

[Bradford Wetmore]

Good morning/afternoon/evening/night,

This RFE adds TLS protocol versions 1->1.3 support for the x25519/x448 
curves in the SunJSSE provider.  These algorithms are preferred by many 
of the major browsers for their efficiency and security properties.

This work is the natural extension of JDK-8181595/JEP 324[2] which added 
the RFC 7748 [1] Curve25519 and Curve448 (ECDH) to the Java Crypto 
Mechanism in JDK 11.

RFE:     https://bugs.openjdk.java.net/browse/JDK-8171279
CSR:     https://bugs.openjdk.java.net/browse/JDK-8224520

Webrev:  http://cr.openjdk.java.net/~wetmore/8171279/webrev.00/

There is a fair amount of change, so the webrevs are hard to follow in 
spots.  I'll introduce many of the implementation changes here:

1.  The JCE design choice of using a parallel set of APIs and Names 
ECPublicKey/XECPublicKey, KeyExchange.getInstance("EC"/"XDH"), etc. for 
these curves made things more challenging than expected.

2.  The key agreement key derivation code was identically replicated 3 
times (FFDHE/ECDHE/XDH), so this was consolidated into KAKeyDerivation.

3.  NamedGroups were broken out of SupportedGroupsExtension.

3a.  Added a function table to do NamedGroup operations in an 
algorithm-independent and consistent fashion for FFDHE/ECDHE/XDH. 
Things like checking Constraints, getting parameters, encoding/decoding 
Possession keys, creating possession, and whether the algorithms are 
available.

For example, given a negotiated group:

     namedGroup->encodePossessionPublicKey->Functions->
         ((XDHKeyExchange.XDHEPossession)poss).encode()

Both the ECDHE/XDH functions call into the existing ECDHE code, as they 
use some of the same underlying structures/messages, which needed to be 
updated a bit to be algorithm independent.  This is for TLSv1->1.3.

The FFDHE functions for TLSv1.3 also call into the existing DH code, but 
I did not update the existing FFDHE code for TLSv1-1.2 to use the 
function tables since it was not necessary.  If reviewers feel this is 
desired, I can do this as an enhancement later.

4.  Added NamedGroupPossession/NamedGroupCredentials interfaces to make 
code cleaner/less error prone.

5.  The ciphersuite KeyExchanges (K_EC*_*) were updated to reflect that 
either ECDHE/XDH can be used.

6.  Create a new ECDHKeyExchange.ECDHEXDHKAGenerator class to handle 
creating TLSv1-1.2 KeyDerivations, based on whether it was ECDHE/XDH.

7. RFC 8422 (Appendix B) deprecated/removed the TLS_ECDH_* ciphersuites. 
  Our KeyManager APIs currently do not allow for selecting specific 
curve entries.  I've made a best effort for supporting client-side ECDH, 
but we won't support server-side ECDH at this point.  TBD if we'll add 
support as API changes will be necessary, and not be worth the time if 
no one should/will be using ECDH.

8.  Is there a common byte array reverse function?  Seems so simple, but 
seems to be duplicated in different modules/packages.

9.  A few minor tweaks that helped code readability (typos/comments).  ;)

Thanks to Adam Petcher, who started work on this project last year.  I 
took several of his ideas in my final implementation.

Thanks,

Brad

[1] https://tools.ietf.org/html/rfc7748
[2] https://bugs.openjdk.java.net/browse/JDK-8181595