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

[Sean Mullan]

* 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