On 7/10/2019 8:29 AM, Sean Mullan wrote:
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.
I updated CSR for the java.security update.
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?
Yes, it is an issue now. The AlgorithmConstraints is able to accept
parameters, but the current jdk.tls.disabledAlgorithms property cannot.
That's also why I used the TLS names (ecdsa_secp256r1_sha256,
rsa_pss_rsae_sha256, etc) rather than standard names (SHA256withECDSA,
RSASSA-PSS).
I agree with you that it is confusing. The use of rsa_pss_rsae_sha256
may be fine, but the name "dsa_sha256" rather then "SHA256withDSA" could
be confusing.
I was planned to add TLS signature algorithms into the standard names,
as we will do for the named groups. But it looks like a duplicate of
the crypto Signature algorithms.
It is an option to support crypto Signature algorithm with the specific
parameters, for example "SHA256withECDSAofSECP256R1",
"SHA256withRSASSA-PSS". I don't like it as a provider need to enum all
known parameters.
Maybe, we can introduce something new in jdk.tls.disabledAlgorithms.
For example, "signature_algorithm with parameters" ("SHA256withECDSA
with Secp256R1", "RSASSA-PSS with SHA256"). However, it does not sound
generic or simple.
We may want to introduce new system property or APIs to customize the
signature algorithms of TLS connections. Using the TLS signature
algorithms is an acceptable option to me, but it is far from satisfied
because the duplication with the crypto Signature algorithm.
Let's discuss the issue more. Any feedback are welcome!
Thanks,
Xuelei
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
