Security considerations for reusing keys in multiple key establishments#1408
Open
emanjon wants to merge 1 commit intotlswg:mainfrom
Open
Security considerations for reusing keys in multiple key establishments#1408emanjon wants to merge 1 commit intotlswg:mainfrom
emanjon wants to merge 1 commit intotlswg:mainfrom
Conversation
dconnolly
approved these changes
Mar 1, 2026
muhammad-usama-sardar
suggested changes
Mar 1, 2026
| Clients and Servers SHOULD NOT reuse a key share for multiple connections. Reuse | ||
| of a key share allows passive observers to correlate different connections. Reuse | ||
| of a client key share to the same server additionally allows the server to correlate different connections. | ||
| Additionally, if a key is reused in multiple key-establishment operations, i.e., a static key, this |
Contributor
There was a problem hiding this comment.
I propose to add a reference to static key.
| some application data, at the cost of certain security properties. | ||
|
|
||
| - Static RSA and Diffie-Hellman cipher suites have been removed; | ||
| all public-key based key exchange mechanisms now provide forward secrecy. |
Contributor
There was a problem hiding this comment.
Suggested change
| public-key based key exchange mechanisms generally provide forward secrecy. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See https://mailarchive.ietf.org/arch/msg/tls/KepJCOX3F_ABti_JYDWrvQGx07U/
It would be good if RFC8446bis could clarify what this 'key reuse' means. As discussed earlier, this term can have at least three very different meanings. Many formal analysis experts have understood TLS 1.3 as specifying that keys should be used for only one execution of key establishment.
https://mailarchive.ietf.org/arch/msg/tls/MOqSAplAYQuA6AwkKfHCphQUlKU/
If 'key reuse' includes using the same key in more than one execution of key establishment, RFC 8446bis should explain that such 'key reuse' undermines forward secrecy and makes exploitation of side-channel attacks and implementation flaws much easier.
While RFC 8446 fails to define the term 'ephemeral', specifications using ML-KEM points normatively to FIPS 203, which in turn points normatively to SP 800-227, which has very precise definitions for 'ephemeral' and 'static'. Since X25519MLKEM768 is already the de facto standard for TLS key exchange, TLS specifications should avoid using the terms 'ephemeral' and 'static' in ways that conflict with FIPS 203.
I do not oppose other people using static keys in TLS for visibility; I just strongly agree with SP 1800-37 that it is a bad solution for visibility, and if allowed in a TLS WG document, the security implications should be clearly described.
I am not sure whether the current situation is the result of ideological fighting, privacy theater, or a combination of both. Beyond the existing uncertainty regarding whether static keys are permitted, the current approach of not explicitly negotiating static keys is strictly worse than the solutions in TLS 1.2 and in draft-rhrd-tls-tls13-visibility.