>RFC8446bis explicitly defines key reuse as a SHOULD NOT. 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. Cheers, John Preuß Mattsson From: Joseph Salowey <[email protected]> Date: Saturday, 28 February 2026 at 02:04 To: <[email protected]> Subject: [TLS] Clarification on the FATT Process In the FATT process, working group chairs decide at the time of adoption whether a document needs FATT review. >From https://github.com/tlswg/tls-fatt: "When a document is adopted by the working group the chairs will make a determination whether the change proposed by the document requires review by the FATT to determine if formal protocol analysis is necessary for the change. For example a proposal that modifies the TLS key schedule or the authentication process or any other part of the cryptographic protocol that has been formally modeled and analyzed in the past would likely result in asking the FATT, whereas a change such as modifying the SSLKEYLOG format would not. The working group chairs will inform the working group of this decision." The chairs made this decision because the mechanism in this draft fits into a well defined place in the TLS protocol and does not change the protocol itself. The purpose of the FATT is to evaluate the potential security impact of a change in the protocol, not to evaluate the merits of a specific cryptographic algorithm such as ML-KEM. Unfortunately, the chairs did not announce this decision on the list (this is something that should be corrected in the process) This decision is supported by references from Thom Wiggers and others on the list that identify the security properties required by TLS 1.3 key exchange. The ML-KEM draft does not modify the TLS key schedule or protocol messages in any way other than what is anticipated by RFC 8446/8446bis. RFC8446bis explicitly defines key reuse as a SHOULD NOT. The considerations applied also for ecdhe-mlkem, which has already gone through the WG process and also did not undergo FATT review. Joe
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
