RFR [14] JDK-8226374 Restrict signature algorithms and named groups

[Xuelei Fan]

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