Telechat Review of draft-ietf-pquip-hbs-state-03
review-ietf-pquip-hbs-state-03-secdir-telechat-sheffer-2026-02-14-00

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 <thom@thomwiggers.nl>
Date: Wednesday, 4 February 2026 at 10:05
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: secdir@ietf.org <secdir@ietf.org>, draft-ietf-pquip-hbs-state.all@ietf.org
<draft-ietf-pquip-hbs-state.all@ietf.org>, last-call@ietf.org
<last-call@ietf.org>, pqc <pqc@ietf.org> 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
<noreply@ietf.org> 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)”. > >