[CFRG] PQ KEM Security Considerations

[Nick Sullivan <[e-mail]>]

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)