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

[Sean Mullan]

On 7/11/19 11:56 AM, Xuelei Fan wrote:

>> 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.

I would lean towards this option. We could extend the 
jdk.tls.disabledAlgorithms property to allow you to specify TLS 
signature schemes as defined in 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme

We would also need to add a section to the Standard Names specification 
listing these schemes.

The reason I like this option is because it fits well with the TLS 
namespace, and it is more flexible than the JCE names and we can more 
easily restrict new TLS signature schemes that are defined later.

--Sean

> 
> 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