JDK-8225766 : Curve in certificate should not affect signature scheme when using TLSv1.3
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 11,12,13
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-06-14
  • Updated: 2020-11-19
  • Resolved: 2019-06-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 14 JDK 8 Other
11.0.7-oracleFixed 13 b27Fixed 14Fixed 8u261Fixed openjdk8u272Fixed
Related Reports
Duplicate :  
Description
In TLSv1.3, the signature schemes are listed by extension signature_algorithms.
The scheme selection would not be affected by the curve in certificate.

For example, the key store contains only one ECDSA certificate, which uses secp256r1 curve, and the extension supported_groups contains only secp521r1.

With JSSE logs, ClientHello lists this extension as below,
    "signature_algorithms (13)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1]
    },

But when try to produce Certificate message, it raises errors:
CertificateMessage.java:1062|Unavailable authentication scheme: ecdsa_secp256r1_sha256
...
CertificateMessage.java:1062|Unavailable authentication scheme: ecdsa_secp521r1_sha512
...
javax.net.ssl|ERROR|0C|MainThread|2019-06-14 11:01:39.752 CST|TransportContext.java:312|Fatal (HANDSHAKE_FAILURE): No available authentication scheme (
"throwable" : {
  javax.net.ssl.SSLHandshakeException: No available authentication scheme
  	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
  	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
  	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307)
  	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263)
  	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:254)
  	at java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:951)
  	at java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:940)
  	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
  	at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1225)
  	at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1161)
  	at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
  	at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
  	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
  	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
  	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
  	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:177)
  	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
  	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1383)
  	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1291)
  	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:436)
  	at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:806)
  	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:897)
  	at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:857)
  	at SSLSocketTemplate.runServerApplication(SSLSocketTemplate.java:93)
  	at SSLSocketTemplate.doServerSide(SSLSocketTemplate.java:275)
  	at SSLSocketTemplate.startServer(SSLSocketTemplate.java:644)
  	at SSLSocketTemplate.bootup(SSLSocketTemplate.java:558)
  	at SSLSocketTemplate.run(SSLSocketTemplate.java:82)
        ...
)

I suppose scheme ecdsa_secp256r1_sha256 could be selected.

In fact, if the supported_groups contains secp256r1 only, CertificateVerify message selectes ecdsa_secp256r1_sha256.
Comments
Fix request (11u) I would like to downport this for parity with 11.0.7-oracle. I had to do a trivial resolve: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-December/002304.html
27-12-2019

See the implementation in SignatureScheme.java: static SignatureScheme getPreferableAlgorithm( List<SignatureScheme> schemes, X509Possession x509Possession, ProtocolVersion version) { ... if (params != null && ss.namedGroup == NamedGroup.valueOf(params)) { ... } For TLS 1.2 and prior versions, the public key of a EC cert MUST use a curve and point format supported by the client. But in TLS 1.3, signature algorithms are negotiated independently via the "signature_algorithms" extension. The impact should be low as in practice the client side should offer the sufficient named groups for TLS 1.2 connections.
14-06-2019

The attached SignatureSchemeTest.java can reproduce this issue.
14-06-2019

Signature Algorithm: ecdsa-with-SHA256
14-06-2019

What's the signature algorithm of the cert?
14-06-2019