IETF Last Call Review of draft-ietf-pquip-hbs-state-02
review-ietf-pquip-hbs-state-02-secdir-lc-sheffer-2026-01-19-00

This document reads a bit strange, like an exhortation not to use this
technology. I for one am totally convinced... Nevertheless, here are some
comments.

At a high level, the document suffers from having an unclear audience
definition. Some recommendations are aimed at implementers while others require
cryptographic expertise or are even described as research problems. The problem
may stem from my own expectations: this level of vagueness could be acceptable
in a CFRG document but less so as the deliverable of an IETF working group.

- Terminology confusion around "private key". In the Intro it is a set of OTS
keys. But in the Terminology it is the seed for the OTS keys.

- "Limited number of signatures": this is mentioned in Sec. 1.1, with no
background information or justification. Please add some explanation or a
pointer to where this is described.

- Similarly, Sec. 1.1 mentions special hardware, add a forward reference to
where you explain why this is recommended (clearly this makes the stateful
solution even more niche).

- A bit more background on parameters would be useful here, because this
reviewer keeps wondering why we cannot solve everything with very long
counters, e.g. 128-bit long, which would be "essentially infinite".

- 2.2: "split state and/or private key" - what is it exactly, does it refer to
(e.g.) multiple cluster members?

- "to guarantee the availability of both the private key and its state across
the lifetime of the key" - I'm not sure what this means.

- "no parts of the system are allowed to read any version of the key during
procedures which load, write or modify keys" - do you mean to say, any other
version?

- "similar assumptions for the verifier" - but I don't think there's any common
use case where an ECDSA verifier actively checks the nonce's uniqueness.
Moreover, depending on the use case there may be privacy issues associated with
CT, and this proposal may address the threat only if verifiers always check the
certificate log.

- 5.1: I can guess why "multiple public keys" is a useful thing but it would be
better if you pointed out exactly what this solution mitigates.

- 5.2: please reconsider this advice/section. It veers too much towards
defining a crypto algorithm in an otherwise totally operational document. For
example, shouldn't there be an RFC to recommend parameters for these things?

- And the same applies to Sec. 5.3.

- And even more so for Sec. 5.6, "Such dynamically extensible constructions are
research-class and are not currently standardized or deployed." It may be
better to break Sec. 5 into practical suggestions in one section, and "future
research" in another (or an appendix).

- Sec. 6 again defines a new cryptographic algorithm, but the algorithm is not
fully specified (see e.g. wording about "domain separation").

- Also, “irreversibly delete” should be tempered: real hardware often cannot
guarantee secure erase under all fault models. Consider rephrasing to “delete
and render unrecoverable under the device’s threat model (e.g., by destroying
wrapping keys)”.