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 don't want to define them as standard names unless
I can reference a TLS specification.
Thanks,
Sean
