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

[Xuelei Fan]

It makes sense to me.  I will update the example before I push the 
changeset.

Thanks,
Xuelei

On 8/12/2019 11:36 AM, Sean Mullan wrote:
> * java.security
> 
> 702 # Example:
> 703 #   jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048,
> 704 #       rsa_pkcs1_sha256, secp224r1
> 
> Since this is a property that is typically used for disabling weak 
> algorithms, I think we should use a weaker signature scheme in this 
> example. Suggest:
> 
> 704 #       rsa_pkcs1_sha1, secp224r1
> 
> Looks good otherwise.
> 
> --Sean
> 
> On 8/8/19 12:41 AM, Xuelei Fan wrote:
>> The latest webrev:
>>      http://cr.openjdk.java.net/~xuelei/8226374/webrev.04/
>>
>> Updated the java.security to use the right document for standard names.
>>
>> Xuelei
>>
>>
>> On 7/29/2019 8:55 AM, Xuelei Fan wrote:
>>>
>>>
>>> On 7/29/2019 7:57 AM, Sean Mullan wrote:
>>>> On 7/28/19 1:42 PM, Xuelei Fan wrote:
>>>>> On 7/26/2019 7:08 AM, Xuelei Fan wrote:
>>>>>> New webrev:
>>>>>> http://cr.openjdk.java.net/~xuelei/8226374/webrev.03/
>>>>>>
>>>>>
>>>>>>
>>>>>>> * 
>>>>>>> src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java 
>>>>>>>
>>>>>>>
>>>>>>> 114             if ((namedGroup == null) || 
>>>>>>> (!namedGroup.isAvailable)) {
>>>>>>>
>>>>>>> You don't do this check for null and isAvailable in other places, 
>>>>>>> for example 
>>>>>>> ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() - 
>>>>>>> should you?
>>>>>>>
>>>>>> Good point!  Currently, the restriction is only checked for the 
>>>>>> supported group extension.  I should add more check points in 
>>>>>> other places where named groups are used, for example client key 
>>>>>> exchange and certificate.  Stay tune for the next webrev.
>>>>>>
>>>>> The ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() 
>>>>> should be fine as the namedGroup has been checked in the previous 
>>>>> steps 
>>>>> (X509Authentication.X509PossessionGenerator.createServerPossession()).
>>>>>
>>>>> However, I missed the check for certificate.  The consumer of 
>>>>> certificate should check the named groups to make sure the 
>>>>> supported named group is used.  It was not a problem in the past as 
>>>>> the supported named groups are used to indicate the EC curve or DH 
>>>>> group is able to be handled in both side.
>>>>>
>>>>> It could be a problem now when we want to restrict named groups. 
>>>>> The named groups used in a certificate should be checked in key 
>>>>> manager and trust manager for TLS 1.2 and prior versions.  Similar 
>>>>> to the signature schemes for TLS 1.3.  As may required new APIs 
>>>>> (SSLParameters.getPeerSupportedNamedGroups()) for a generic solution.
>>>>>
>>>>> Would you mind if I file a new RFE and make the improvement in JDK 
>>>>> 14 later?
>>>>
>>>> Ok. I had a comment/question on the CSR [1]. In the Solution 
>>>> section, you list the legacy signature schemes as:
>>>>
>>>> dsa_sha256
>>>> ecdsa_sha224
>>>> rsa_sha224
>>>> dsa_sha224
>>>> ecdsa_sha1
>>>> rsa_pkcs1_sha1
>>>> dsa_sha1
>>>> rsa_md5
>>>>
>>>> However, the IANA registry for TLS defines them differently: 
>>>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 
>>>>
>>>>
>>>> Can you clarify why we have this difference and how the JDK uses 
>>>> these legacy algorithms?
>>> I added some description above these legacy signature schemes.
>>>
>>>      https://bugs.openjdk.java.net/browse/JDK-8227445
>>>
>>>> I don't want to define them as standard names unless I can reference 
>>>> a TLS specification.
>>>>
>>> These names should not be used for future applications.  It's fine to 
>>> me if they are not part of the standard names.
>>>
>>> Thanks,
>>> Xuelei