Hi Thom, Thank you for your response. I am (finally) replying while referencing -03 which was published since my review. Please see below, prefixed "YS". In general, I understand your point about the different audiences and I'm suggesting below some changes to help readers cope with the different levels of expected background. Thanks,       Yaron From: Thom Wiggers Date: Wednesday, 4 February 2026 at 10:05 To: Yaron Sheffer Cc: secdir@ietf.org , draft-ietf-pquip-hbs-state.all@ietf.org , last-call@ietf.org , pqc Subject: Re: draft-ietf-pquip-hbs-state-02 ietf last call Secdir review Dear Yaron, PQUIP working group, Thank you for your review. Sorry for taking a bit longer to get organized before responding. Below, we respond to your comments one-by-one. On the subject of the audience definition: this draft is aimed at people trying to take stateful HBS into production. This may include both less cryptographically inclined people but also those who know a bit more cryptography. We tried to set out advice that is helpful both for those just buying some HSMs from a vendor (for whom in particular section 3 may be instructive), but some of the advice is also intended to be an “are you sure you are being smart about this” to those who know just enough to be dangerous. We tried to organize the draft in such a way that it is easy enough to skip and ignore sections that are a bit more technical—the rest of the draft should still be comprehensible. Our responses to the remaining points follow below; please find them in a PR at https://github.com/hbs-guidance/draft-hbs-state/pull/48. Regards and thanks again, On behalf of my co-authors, Thom > - 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. The seed is theoretically speaking an optimization to avoid having to generate and store (a potentially very large amount of) OTS ahead of time. I think we can hint at this in the introduction, but I do not want to get that specific in this document as I don’t want to get that distracted by specific schemes. **Proposed change:** Added “typically expanded from a seed” in the introduction. YS: sorry, it's still very messy. Especially "private key [is defined as] the static, long-lived secret(s) from which OTS private keys are derived." If you can fix the ambiguity around the term without a major change to the document, it would be helpful. > - "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. In the introduction, it is already mentioned that the number of OTS is finite. The referenced S-HBS standards all clearly advertise that the number of signatures is finite. I do not think we need to further clarify this. In more detail: Hash-based signature schemes are based on (Merkle) trees. The leaves of the trees are one-time signature scheme (public) keys. The root of the Merkle tree is the public key of the tree; signatures are a proof of inclusion of the OTS public key in the tree. If the size of the tree is not fixed ahead of time, we can’t compute the root of the public tree. If the size of the tree is very large, the size of signatures goes up (*stateless* HBS SPHINCS+/SLH-DSA, dumbed down, is essentially just a *very large* stateful HBS so that you are cryptographically unlikely to randomly pick the same state twice). YS: so could you include this clarification in the text? Alternatively, if there is introductory material (in an RFC or elsewhere) that's a prerequisite to understanding this draft, why not point it out in the Intro. There's a large number of references but nothing is singled out as "must read" background material. > - 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). **Proposed change:** \[…] It seems likely that in many scenarios, it is only possible to meet the requirements set out in {{req-state}} when using purpose-designed hardware, such as hardware-security modules. \[…] > > - 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". See the discussion above. > > - 2.2: "split state and/or private key" - what is it exactly, does it refer to (e.g.) multiple cluster members? **Proposed rewording:** […] - to set up Stateful HBS where the state is separated in distinct, non-overlapping parts, so that signatures can be generated from either part without risk of state reuse, […] > > - "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. We mean that the system doesn’t go down unexpectedly in the broadest sense, which includes (recovery from) backups and exhausting available signatures. We are open to suggested rephrasings. > - "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? I think “any” is correct, as access needs to be exclusive. YS: the text still reads strange - of course you need to read (a version of) the key when you load keys. > - "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. While I think you are right that this does not exist for ECDSA, I think that for Stateful HBS it is a little bit more practical to consider such approaches. For example, there are LMS parameter sets that allow only `2^5=32` total signatures over the key’s lifetime. YS: the sentence (and my comment) is specifically about ECDSA. I'm sure you are right about the HBS situation, but the comparison with ECDSA is apparently incorrect/imprecise. > - 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. **Added:** Secondary Stateful HBS keys can be kept in storage until the first keypair is exhausted or lost. > - 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? I do not understand this comment. This section briefly, at a high level, describes an algorithm described in another standard, and explains using that algorithm that affects operation concerns. YS: on second reading, understood. > - And the same applies to Sec. 5.3. I do not understand this comment. This section briefly, at a high level, describes an algorithm described in another standard, and explains using that algorithm that affects operation concerns. YS: so please provide a reference in 5.3 to clarify this point. > - 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). Section 5.6 is not a proposal or an encouragement for further research. I think the message of this section is “if you go down this road, you need to start inventing a lot of stuff, don’t take this lightly.” > - Sec. 6 again defines a new cryptographic algorithm, but the algorithm is not fully specified (see e.g. wording about "domain separation"). While this paragraph may go a little beyond the other sections in that it sketches an approach to avoid the problems with the SP-800-208’s multi-tree solution, I think the level of detail is appropriate for an informational document that provides guidance. If developing this into an interoperable approach is necessary, this work should be taken into a separate document (and likely in another WG). YS: fair enough. So why not add a warning at the top of the section saying that this is a sketch solution, it is lacking detail for an interoperable (or secure) approach, but may be used as the basis for a future standard. > - 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)”. I think that we have elaborated on requirements on hardware enough in sections 3 and 4; I don’t think that we need to go further. > Op 19 jan 2026, om 20:31 heeft Yaron Sheffer via Datatracker het volgende geschreven: > > Document: draft-ietf-pquip-hbs-state > Title: Hash-based Signatures: State and Backup Management > Reviewer: Yaron Sheffer > Review result: Has Issues > > 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)”. > >