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

[Xuelei Fan]

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