> What's the point of FATT review if we wait until after adopting a draft to check if it has security consequences?
Documents can change significantly between adoption and leaving the working group (can, but don't necessarily always) On Sat, Feb 28, 2026, 1:02 PM Nadim Kobeissi <[email protected]> wrote: > What's the point of FATT review if we wait until after adopting a draft to > check if it has security consequences? > > On Sat, Feb 28, 2026, at 2:03 AM, Joseph Salowey wrote: > > 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] > > > Nadim Kobeissi > Symbolic Software • https://symbolic.software > > _______________________________________________ > 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]
