> If static keys are allowed, RFC8446bis should tone down statements like “all public-key based key exchange mechanisms now provide forward secrecy."
I agree On Sun, Mar 1, 2026, 7:16 AM John Mattsson <john.mattsson= [email protected]> wrote: > I made a PR based on my mail > https://github.com/tlswg/tls13-spec/pull/1408 > > I do not agree that RFC 8446 permits static keys, but I do agree that it > is unclear. I have no use of static keys for visibility, but clearly > describing the security consequences is better than the current situation. > > If static keys are allowed, RFC8446bis should tone down statements like “all > public-key based key exchange mechanisms now provide forward secrecy." > > Cheers, > John > > *From: *John Mattsson <[email protected]> > *Date: *Sunday, 1 March 2026 at 12:57 > *To: *Joseph Salowey <[email protected]>, > <[email protected]> > *Subject: *Re: [TLS] Clarification on the FATT Process > > >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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
