RFR: 8283795: Add TLSv1.3 and CNSA 1.0 algorithms to implementation requirements

[Sean Mullan]

On Thu, 2 Jan 2025 23:05:53 GMT, Bernd <duke at openjdk.org> wrote:

>> Periodically, we review the security algorithm requirements to see if new algorithms should be added or existing ones should be removed. The requirements are intended to improve interoperability across different SE implementations by requiring a set of commonly used algorithms. The algorithms are not always based on the strength of the algorithm; the requirements are also based on how common the algorithms are, so some weaker algorithms are still on the list in order to support legacy use cases.
>> 
>> Add TLSv1.3 to the list of requirements. TLSv1.3 is the most secure protocol version and is in wide use. Add all cryptographic algorithms that are needed to implement the TLSv1.3 cipher suites and signature mechanisms defined by https://www.rfc-editor.org/rfc/rfc8446 as MUST or SHOULD requirements. Also add algorithms that are required by CNSA 1.0, which was added in JDK 19: https://bugs.openjdk.org/browse/JDK-8267319.
>> 
>> No required algorithms or protocols are being removed at this time.
>> 
>> See the CSR for the complete list of new requirements: https://bugs.openjdk.org/browse/JDK-8346684
>
> src/java.base/share/classes/java/security/KeyPairGenerator.java line 120:
> 
>> 118:  * algorithms, implementations must support the key sizes in parentheses.
>> 119:  * <ul>
>> 120:  * <li>{@code DiffieHellman} (1024, 2048, 3072, 4096)</li>
> 
> Will there be a separate initiative to remove the 1024 from the requirements (or make clear that implementations are allowed to denn it by default policy).
> 
> I also wonder if more SHA3 should be added to the required algorithms.
> 
> The ticket Talks about tlsv1.3 and CNA 1.0, is the curve25519/chacha20 made mandatory due to TLS or just best practice?

Thanks for the comments.

As mentioned in the PR description, these requirements are not always based on the strength of the algorithm. We also want to support legacy use cases of algorithms that were commonly used for a long time. For 1024-bit keys, I referred to other standard bodies for guidance, for example NIST still allows verification of signatures signed with 1024 bit keys for legacy use cases. That said, 1024 bit keys will probably be a candidate to remove from the requirements in a future revision.

I considered adding SHA-3, but I wanted to focus on TLSv1.3 and CNSA 1.0 for this revision.

The curve25519/chacha20 requirements are based on the SHOULD requirements of https://www.rfc-editor.org/rfc/rfc8446#section-9.1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22904#discussion_r1901769955