I think we should modify the description of the
jdk.tls.disabledAlgorithms property to state that named groups can also
be restricted. For example:
diff -r a7b9d6d4940e src/java.base/share/conf/security/java.security
--- a/src/java.base/share/conf/security/java.security Thu Jun 20
09:35:41 2019 -0700
+++ b/src/java.base/share/conf/security/java.security Wed Jul 10
11:21:32 2019 -0400
@@ -678,7 +678,7 @@
# when using SSL/TLS/DTLS. This section describes the mechanism for
disabling
# algorithms during SSL/TLS/DTLS security parameters negotiation,
including
# protocol version negotiation, cipher suites selection, peer
authentication
-# and key exchange mechanisms.
+# and key exchange mechanisms, and named groups.
#
# Disabled algorithms will not be negotiated for SSL/TLS connections, even
# if they are enabled explicitly in an application.
This should also be in the CSR.
Also, in the CSR you list all the different signature algorithms that
could be disabled, but you use the TLS names, and not the standard JCE
names. I found this a bit confusing, since if you added those exact TLS
names to jdk.tls.disabledAlgorithms, I don't think it will work, or if
it does we need additional changes to the jdk.tls.disabledAlgorithms
definition - and maybe that is what we should do? Also, I don't think
it is possible to disable individual RSASSA-PSS algorithms, I think you
can just disable all or none of them because the parameters are
specified separately and not part of the standard JCE name. Similar to
other algorithms - how would I just disable ecdsa_secp256r1_sha256 and
nothing else? Is that an issue?
Thanks,
Sean
On 7/9/19 12:43 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
webrev: http://cr.openjdk.java.net/~xuelei/8226374/webrev.01/
CSR: https://bugs.openjdk.java.net/browse/JDK-8227445
During handshaking, the selection of signature algorithms was not
checked with the algorithm constraints. Then the available signature
algorithms may be ignored if a restricted algorithm get selected. The
connection should be able to be established as there are available
algorithms.
Within this update, more algorithm constraints checking are introduced
in the signature algorithms and named groups code.
The significant changes are in NamedGroup.java and SignatureScheme.java,
in order to introduce the checking and algorithm parameters and specs.
Note that the following JDK 13 review thread was close out.
https://mail.openjdk.java.net/pipermail/security-dev/2019-July/020348.html
I targeted this enhancement to JDK 14, and come up with a CSR request.
Thanks,
Xuelei
