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
