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]
