-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8283795: Add TLSv1.3 and CNSA 1.0 algorithms to implementation requirements #22904
Conversation
/csr |
👋 Welcome back mullan! A progress list of the required criteria for merging this PR into |
@seanjmullan This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 79 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
@seanjmullan an approved CSR request is already required for this pull request. |
@seanjmullan The following labels will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes look good to me.
* <ul> | ||
* <li>{@code DiffieHellman} (1024, 2048, 4096)</li> | ||
* <li>{@code DiffieHellman} (1024, 2048, 3072, 4096)</li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
… Signature requirements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updates look good.
/integrate |
Going to push as commit 3bfa952.
Your commit was automatically rebased without conflicts. |
@seanjmullan Pushed as commit 3bfa952. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
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
Progress
Issues
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22904/head:pull/22904
$ git checkout pull/22904
Update a local copy of the PR:
$ git checkout pull/22904
$ git pull https://git.openjdk.org/jdk.git pull/22904/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 22904
View PR using the GUI difftool:
$ git pr show -t 22904
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22904.diff
Using Webrev
Link to Webrev Comment