Hi Kris, No. Let’s not move the discussion away from the draft and from the extremely relevant context of TLS.
Restoring the hash is reasonable and NIST’s removal wasn’t well motivated or justified, their silence to reasonable questions now is suspicious when we consider the relevant history. There may be better designs but they will only slow down deployment. The best course of action is restoring the hash over m. It lasted for three rounds without a security issue being found by NIST or NSA. I am going to update the golang hpqc library and the katzenpost mixnet project will take the defense in depth route. David Stainton Founder and core developer, Katzenpost post quantum mixnet On Sun, Jul 12, 2026 at 1:08 PM Kris Kwiatkowski <[email protected]> wrote: > > > On 12/07/2026 09:06, John Mattsson wrote: > > > Regarding Jakob Appelbaum's suggested text, I agree that wording along the > lines of "the m value is recoverable by the decapsulating peer" should be > added to draft-ietf-tls-ecdhe-mlkem, draft-ietf-tls-mlkem, and likely to > future IETF KEM specifications as well. > > > I agree with the points below, including that the broader CSPRNG guidance > discussion belongs in a wider IETF context such as an RFC4086bis effort. > > On where the suggested text about 'm' being recoverable by the decapsulating > peer should go: I think draft-sfluhrer-cfrg-ml-kem-security-considerations is > the proper home for it, rather than the documents that merely define code > points for TLS. The TLS drafts could then simply reference it. Duplicating > ML-KEM security considerations across draft-ietf-tls-ecdhe-mlkem, > draft-ietf-tls-mlkem, and every future KEM code point document seems fragile, > and a single CFRG document keeps the guidance consistent. This follows the > same logic as your RFC4086bis suggestion: put the guidance where it can be > referenced, not in each protocol-specific draft. > > For the same reason, the discussion itself belongs in CFRG, where it would > get review from the crowd focused on cryptographic mechanisms. > > Cheers, > Kris > > _______________________________________________ > 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]
