[Last-Call] draft-ietf-pquip-pqc-hsm-constrained-09 telechat Secdir review

[Ionuț Mihalcea via Datatracker <[e-mail]>]

Document: draft-ietf-pquip-pqc-hsm-constrained
Title: Adapting Constrained Devices for Post-Quantum Cryptography
Reviewer: Ionuț Mihalcea
Review result: Has Issues

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

I have previously reviewed -06 of this draft [1]. My summary of -09 is Almost
Ready.

My feedback from the previous review has been addressed - many thanks to the
authors for the effort of identifying and patching the sensible concerns.
Sharing some more observations below, with the caveat that I'm not that
familiar with the PQ primitives involved. Apologies for noticing these late in
the spec lifecycle.

In section 5, pre-hashing is offered as an option "for any PQC signature
algorithm, whether it is ML-DSA, SLH-DSA". SLH-DSA is brought up as an example:
"algorithms like SLH-DSA present challenges due to their construction, which
requires two passes over the message during the signing process". However, if I
understand slh_sign_internal in FIPS-205 [2] correctly, both those passes over
the message for pure SLH-DSA require access to (parts of) the secret key
signing the message. This means either those parts would need to be exported
from the cryptographic module (which is not recommended), or the message must
be provided in full for the signing process.

Staying on the topic of SLH-DSA, FIPS-205 makes the same point about hedged vs
deterministic signing as FIPS-204, regarding side-channel protection. 2nd
paragraph of section 9.1 could point to both ML-DSA and SLH-DSA.

I'm a bit confused about the messaging on misbinding attacks in section 2.1.1.
The paragraph discussing these attacks makes the point that this doesn't apply
when the protected environment is holding the private keys. However, the last
paragraph then goes on to talk about importing private keys. Should this last
paragraph also point to something like RFC9881 sec. 8.2 for required checks
when importing?

Section 3.2 advocates for use of Externalmu-ML-DSA, with mu computed in
software before being sent for signing to the protected environment that holds
the key. However, mu is a hash computed over more than just the message being
signed - M' contains the domain separator (pre-hash vs pure) and the context
string ctx [3]. If a device is expected to use both pre-hash and pure ML-DSA,
or if there are multiple context strings used by calling applications, this
interface could allow "impersonation" on those two dimensions. For example, an
authentication app could generate a mu with a "device-attestation" context or
vice-versa. The cryptographic module cannot check mu (though it might have
access to provenance metadata for mu), but it might be worth highlighting this
concern.

[1]
https://datatracker.ietf.org/doc/review-ietf-pquip-pqc-hsm-constrained-06-secdir-lc-mihalcea-2026-07-06/

[2] https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.205.pdf

[3]
https://datatracker.ietf.org/doc/html/rfc9881#name-pre-hashing-external-ml-dsa