[CFRG] Re: PQ KEM Security Considerations

[Nick Sullivan <[e-mail]>]

Hi CFRG,

Thanks to everyone who replied to the April 13 note, and thanks in
particular to the people who are preparing per-KEM
security-considerations documents.

We are extending the requested submission date from May 22, 2026 to
Monday, June 22, 2026.

This remains a call for per-KEM security-considerations /
security-evaluation documents intended to help protocol designers and
implementers understand how a KEM can be used safely in IETF
protocols. It is not an algorithm-approval exercise, and it is not a
ranking of KEMs.

The eligibility point from the earlier note also remains the same:
this call is aimed at KEMs that have had substantial public
cryptanalysis in an open process. A document can still be useful as a
discussion document even if the underlying KEM is not yet at that
level of maturity, but at this point we're interested in KEMs that
have short-term deployment targets, especially those in IETF
protocols.

To make list review more uniform, please structure per-KEM documents
so that they explicitly answer the following points.

First, is this safe to use?

What is the authoritative specification, and which parameter sets are in scope?
What security strength is being targeted, and what security notion
does the calling protocol rely on?
What assumptions, underlying hard problems, attacker model,
implementation conditions, and practical conditions are needed for the
claim to hold?
What is the basis for confidence, i.e., what public review and
cryptanalysis record are we relying on? Pointing to external standards
and their public review is completely reasonable here, the goal is not
to reinvent proofs in CFRG.
What protocol-relevant caveats, hybrid-composition concerns, and
watchpoints should protocol designers know about?

Second, how do we safely use it?

What are the exact sizes, encodings, and canonicalization rules for
keys, ciphertexts, and shared secrets?
What validation is required, and which checks must not be skipped?
What randomness is required, and what breaks if it is weak, stale, or reused?
What should implementers do on failures and invalid inputs, and what
side-channel, oracle, and fault-injection considerations matter?
What are the key-lifecycle, reuse, storage, zeroization, and PFS implications?
What interop artifacts should exist, including test vectors and
malformed-input tests?
If the underlying standard offers variants or options, what is the
default recommendation, and when should a protocol designer choose
something else?


A -00 or outline is fine if it clearly establishes scope, structure,
and initial answers, and if the authors are prepared to revise it
toward this checklist based on review.

If you are working on a document, please reply to the chairs naming
the KEM by June 8.

Best,
Nick (for the CFRG chairs)

On Mon, Apr 13, 2026 at 10:10 AM Nick Sullivan
<[e-mail]> wrote:
>
> Hi CFRG,
>
> At IETF 125 I gave a short talk on "KEM Security Considerations" and a
> path forward for PQ KEMs.
>
> The problem we are trying to solve is simple: the IETF needs guidance
> on which PQ KEMs are reasonable to use in standards-track protocols.
> Candidates that come up repeatedly include ML-KEM, NTRU, Classic
> McEliece, FrodoKEM, NTRU Prime, and HQC.
>
> There is also clear process history here: at IETF 123 the poll result
> was that we should first produce a KEM security requirements document.
> We still do not have that requirements document, and today we
> effectively only have one per-KEM security considerations writeup (for
> ML-KEM).
>
> Current gap and proposed approach (from the IETF 125 slides)
> - Current gap: no requirements document exists; one individual draft
> covers ML-KEM only.
> - Path forward: adopt per-KEM security evaluation /
> security-considerations documents.
> - Eligibility: KEM has had extensive public cryptanalysis via an open process.
> - Target: on the order of weeks, not years.
>
> Links:
> - IETF 125 minutes (CFRG session 1):
> http://datatracker.ietf.org/doc/minutes-125-cfrg-202603190100/
> - Slides: http://datatracker.ietf.org/meeting/125/materials/slides-125-cfrg-pq-kems-02
> - ML-KEM security considerations draft:
> http://datatracker.ietf.org/doc/draft-sfluhrer-cfrg-ml-kem-security-considerations/
>
> Scope and what the output means
>
> This is not about CFRG "approving" algorithms. The intended output is
> a set of documents that protocol working groups can read to understand
> security properties and security considerations for protocol use. This
> is guidance for protocol designers and implementers, not a ranking
> exercise, and not a re-run of the underlying competition or
> standardization processes.
>
> Request to the list
>
> Before we talk about adoption of any single KEM-specific document, I
> want to ask a simpler question:
>
> Are there plans, or willingness, to write similar
> security-considerations documents for other PQ KEMs being discussed
> here?
>
> If you are willing to contribute (author or co-author), please reply with:
> - which KEM(s) you have in mind
> - whether you can produce a draft or outline within a six week
> timeframe from today (before May 22)
> - whether you think we need a small design team to converge on common
> criteria, or whether mailing list discussion is sufficient
>
> Proposed questions (criteria) for per-KEM documents (open for debate)
>
> To make the request concrete, here is my starting point for the kinds
> of questions each document should answer. These are intentionally up
> for debate. If you think this is too much, too little, or missing key
> items, please say so.
>
> I am also separating "is this safe to use" from "how to safely use it":
>
> A) Is this safe to use? (claims, assumptions, evidence)
> - Spec and scope: what is the authoritative specification (or specs)
> for the KEM, and which parameter sets are in scope for this document.
> - Security strength and notion: what security strength is being
> targeted (e.g., NIST category / bits of security), what security
> notion a protocol would rely on (e.g., IND-CCA-style KEM security for
> HPKE-like use), and what the KEM claims under that notion.
> - Assumptions and conditions: what attacker model and assumptions the
> claim relies on (classical vs PQ, any non-standard assumptions), and
> what conditions are required for the claim to hold in practice
> (required checks, failure handling, implementation assumptions,
> underlying hard problem).
> - Basis for confidence: what open, public process and cryptanalysis
> record we are relying on. Pointing to an external standard and its
> public review is valid here; the goal is not to reinvent proofs in
> CFRG.
> - Protocol-relevant caveats: known limitations or results that could
> affect protocol designs (binding/misbinding properties,
> robustness/contributory behavior, misuse sensitivity, and hybrid
> composition considerations if applicable), plus a short list of
> watchpoints (what would change the assessment).
>
> B) How to safely use it? (protocol designer and implementer guidance)
> - Inputs/outputs and encoding: exact sizes and encodings for public
> key, ciphertext, and shared secret, plus any required formatting or
> canonicalization rules.
> - Validation: what input validation is required (public key checks,
> ciphertext checks), and what must not be skipped.
> - Randomness: what randomness is required for KeyGen and Encaps
> (strength and freshness), and what breaks if those requirements are
> not met.
> - Failures and leakage: correct behavior on decapsulation failure and
> invalid ciphertexts, constant-time expectations, and what error
> signaling is safe (avoid oracles). State whether fault injection is in
> scope or explicitly out of scope.
> - Key lifecycle: reuse guidance (static vs ephemeral), PFS
> implications, storage and zeroization expectations.
> - Interop artifacts: minimum test vectors and negative tests
> (malformed inputs), where implementers should pull them from (spec
> appendices, reference code, published vector sets), and any evidence
> of multi-implementation interop if it exists.
> - Decision points in the underlying standard: if the authoritative
> spec offers options (variants, modes, knobs), point to the relevant
> sections and give protocol designers a clear default and a short
> decision guide for when a different option is appropriate. The ML-DSA
> security considerations individual draft is a good example of the
> level of guidance here
> (http://datatracker.ietf.org/doc/draft-connolly-cfrg-ml-dsa-security-considerations/)
>
>
> About adoption and completeness
>
> If we adopt this topic and/or adopt individual documents, the adoption
> call should not be read as "this document is complete." A -00 that
> establishes scope, structure, and initial answers is fine, as long as
> the authors agree that if the document is adopted they will work it
> towards conformance with the (eventual) common criteria and
> incorporate review feedback.
>
> Thanks. Please reply if you are willing to write (or co-write) a
> document for a specific KEM, and please also reply with suggested
> edits to the criteria above.
>
> Nick (for the CFRG chairs)