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
