Hi Kris, I think we agree, but I want to be clear on one point: we should restrain ourselves from creating a hard dependency on the CFRG publishing a draft for this document. The security considerations document for ML-KEM has been discussed in the CFRG but is has not yet been adopted (discussion is ongoing). Given the targeted nature of this suggestion and the attention it has from experts participating in this WG, having to block on a CFRG publication for one recommendation would be overkill. Working groups are free to make their own cryptographic decisions.
I agree that entropy and RNG compromise should be taken into consideration in a CFRG draft on this topic if adopted so that other working groups can benefit from this type of advice, but not as a blocker for this document. The TLS WG chairs always have the option to solicit an expert review from the Crypto Review Panel on any sensitive cryptographic elements of a protocol if they deem it necessary. Best, Nick On Sun, Jul 12, 2026 at 12:07 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]
