Kris Kwiatkowski wrote: >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.
Agree >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. I intentionally did not suggest CFRG, as I do not think the main need is the specification of new cryptographic mechanisms. Rather, what I think is needed are implementation guidelines covering issues such as trust, supply-chain security, compromise, and malicious entropy sources and malicious PRNGs. and the use of entropy sources. I think that is more IETF than CFRG, but would be happy with the work being done in CFRG. RFC 4086 is quite outdated and should either be updated or moved to Historic status. Maybe we can have a discussion in SAAG@IETF126? Cheers, John Preuß Mattsson From: Kris Kwiatkowski <[email protected]> Date: Sunday, 12 July 2026 at 13:07 To: [email protected] <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) 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]
