Hi Nick,
I agree that making this document depend on a CFRG publication would be
overkill.
That said, I think this discussion is worthwhile. While it is certainly
relevant to TLS, it is not specific to TLS; other protocols using ML-KEM
face the same considerations. That's why I thought it would be
appropriate to capture this guidance in a more general document, such as
draft-sfluhrer-cfrg-ml-kem-security-considerations (or any other, that
one just looks like right place).
Probably it's reasonable for this guidance to appear in both places: in
the TLS drafts and a CFRG document, so that it can serve as common
guidance for other protocols.
Cheers,
Kris
On 12/07/2026 13:44, Nick Sullivan wrote:
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]
