On Mon, Feb 23, 2026 at 12:20 AM Muhammad Usama Sardar < [email protected]> wrote:
> > Since this draft clearly seems to be controversial, I am still failing to > see why chairs are not asking for expert review of FATT to resolve the > matter. So, I once again request the chairs to initiate FATT process. Maybe > chairs can collect all related analysis and send these pointers along with > the request. > It's not clear to me what you're hoping to learn from the FATT analysis. Is there some question about the properties of the combination of ML-KEM with TLS assuming that ML-KEM is in fact IND-CCA secure? I understand the question to be about the security of ML-KEM proper, which the FATT process is not designed to assess. The question of key reuse seems orthogonal, as key reuse in this draft is allowed to essentially the same extent as it is allowed with traditional ECC algorithms. Again, what is it you're expecting formal review to tell us? > S 5.2. > > While it is recommended that implementations avoid reuse of ML-KEM > keypairs to ensure forward secrecy, implementations that do reuse > MUST ensure that the number of reuses abides by bounds in [FIPS203] > or subsequent security analyses of ML-KEM. > > Implementations MUST NOT reuse randomness in the generation of ML-KEM > ciphertexts. > > This kind of normative language doesn't belong in Security > Considerations. If it's important it should go elsewhere. > > I believe an informative draft should not use normative language * > anywhere* in the draft. Please correct me if I am wrong. > That's not correct. An Informational draft can still have normative language which tells you how to implement the spec. [0] https://www.netmeister.org/blog/images/kyber-kex-wireshark-ch.png > > It's the source for the text "If we look at John Schauman's helpful breakdown of a hybrid CH that" but I bungled the footnotes markers. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
