[11u] RFR: 8171279: Support X25519 and X448 in TLS

[Lindenmaier, Goetz]

Hi Martin, 

I implemented the FIPS stuff that I first had left out
And pushed the change along with it.
Anyways, I would not have removed all of the FIPS support, 
only the code that had to be ported for the change.
But the code is untested.

If you know how, you might want to test it.

Best regards,
  Goetz.

> -----Original Message-----
> From: Martin Balao <mbalao at redhat.com>
> Sent: Tuesday, November 17, 2020 9:06 PM
> To: jdk-updates-dev at openjdk.java.net; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>
> Cc: Severin Gehwolf <sgehwolf at redhat.com>
> Subject: Re: [11u] RFR: 8171279: Support X25519 and X448 in TLS
> 
> Hi,
> 
> Apologize for being so late on this one -was on CPU and leave after
> that-. I know this has been committed already, but I have some concerns
> about the decisions taken.
> 
> > file src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java
> > Deleting class DHEKAKeyDerivation failed because the code in 11 uses
> JsseJce.getKeyAgreement()
> > where the patch uses KeyAgreement.getInstance().
> 
> Yes, because SunJSSE may be initialized with a specific crypto provider
> for 'FIPS mode' in 11 (note that KeyAgreement.getInstance may choose any
> enabled security provider in order of preference). This feature was
> later removed.
> 
> >
> > As I understand 8217835, the experimental FIPS feature cannot be used in
> > 11, it just remained in the code. So I skipped adapting NamedGroups to the
> > old behaviour, I can not test it anyways.
> > What do you think, do we need to add this code to NamedGroupd.java
> again?
> >
> 
> The conclusion in 8217835 that SunJSSE FIPS mode cannot be used in JDK9+
> was never accurate and, today, not true. In particular, the provider
> load ignored the extra parameter (from java.security configuration line)
> because there was a bug that was fixed later [1].
> 
> In my opinion, we should not remove SunJSSE FIPS mode in 11u. This would
> be removing an API from a stable release. Our users and us rely on that.
> My suggestion would be to make the necessary changes so the crypto
> provider used by SunJSSE remain to be the one obtained from JsseJce,
> even for the key derivation schemes here.
> 
> Thoughts?
> 
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8230923