[CFRG] Re: PQ KEM Security Considerations

[Songbo Bu <[e-mail]>]

Hi Usama, Nick, all,

I think the distinction here is useful.

Section 5 of draft-usama-tls-risks-of-mlkem seems relevant as a
protocol-use and implementation-boundary input, rather than as a substitute
for a per-KEM cryptographic security-considerations document.

For the common checklist, I would find it helpful to keep those layers
separate:

   1. the KEM-level claim: specification, security notion, public review,
   parameter sets, and known cryptanalytic caveats;
   2. the protocol-use claim: which protocol inputs must be bound to the
   KEM result, such as negotiated group, transcript, role/context, and
   key-schedule input;
   3. the implementation-boundary claim: what must fail closed around
   parsing, malformed shares/ciphertexts, HRR or retry paths, downgrade
   behavior, and error reporting.

In TLS, the second and third layers are where a lot of implementation
mistakes become visible, even when the KEM-level statement is correct.

So I would support using the ML-KEM/TLS text as one input into the “how do
we safely use it?” part of the CFRG checklist, while keeping the actual
per-KEM safety document scoped to the algorithm and its assumptions.

If useful, I can help review the ML-KEM/TLS text against the common
criteria from an implementer/protocol-boundary perspective.

Best,
Songbo

On Mon, 22 Jun 2026 22:58:48 +0200, Muhammad Usama Sardar
[e-mail] wrote:

Hi all,

I did not submit a separate draft because as a non-cryptographer, I
don’t think I will be able to handle the revisions. Nevertheless, with
the help of several contributors, I summarized some security analysis of
ML-KEM [0] in my draft under review at ISE, which may be helpful in this
discussion. Sec. 5 [0] sort of answers the two questions at a high
level: is this safe to use? and how do we safely use it (in TLS)?

I hope to be understanding more from the cryptographers here.

I welcome any feedback.

Best regards,

-Usama

[0]
https://www.ietf.org/archive/id/draft-usama-tls-risks-of-mlkem-04.html#section-5