[CFRG] Re: PQ KEM Security Considerations

[Simon Josefsson <[e-mail]>]

All,

Please consider the following two per-KEM security-considerations
documents as part of the CFRG PQ KEM effort.

For Streamlined NTRU Prime:

https://datatracker.ietf.org/doc/html/draft-josefsson-cfrg-sntrup-considerations

For Classic McEliece:

https://datatracker.ietf.org/doc/html/draft-josefsson-cfrg-mceliece-considerations

The Classic McEliece I-D specification has also been updated:

https://datatracker.ietf.org/doc/html/draft-josefsson-mceliece

What do you think?  Review and feedback is appreciated.

Thanks,
/Simon


Nick Sullivan <[e-mail]> writes:

> 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)
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]