[TLS] Re: Clarification on the FATT Process

[Deirdre Connolly <[e-mail]>]

> 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 <[e-mail]>
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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>