Last Call Review of draft-ietf-pquip-hybrid-signature-spectrums-06
review-ietf-pquip-hybrid-signature-spectrums-06-opsdir-lc-farrel-2025-03-26-00

Hello,

I have reviewed this document as part of the Operational Directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written with the intent of improving the operational
aspects of the IETF drafts. Comments that are not addressed in last call
may be included in AD reviews during the IESG review.  Document editors
and WG chairs should treat these comments just like any other last call
comments.

Regards,
Adrian

===

Reviewer: Adrian Farrel
Draft reviewed: draft-ietf-pquip-hybrid-signature-spectrums-06
Review Result: Has issues

This Informational document describes hybrid digital schemes setting out
motivations for their use, design goals, and general security
considerations.

This document is basically ready for publication with a few minor points
and nits that could be usefully cleared up.

However, I found no discussion of manageability in the document and I
recommend the AD to check with the authors whether this is a valid
situation. I am marking the document as "has issues" while this point is
discussed.

= Manageability =

I think I would have liked to see some commentary on the configurability
of algorithms and keys because the increased variability of component
algorithms in hybrid systems seems to imply a more dynamic configuration
of security. And (presumably) we reach a point where the chief
vulnerability is not the algorithm but the configuration. Similarly,
management mechanisms used to inspect the operation of secure systems 
provide both a valuable tool to the user/operator and a significant way
for an attacker to find out how the system is behaving.

I can't say I'm an expert in any of this, but it was a surprise to find
no mention of manageability or configuration in the document.

= Petty points =

Section 1

   Still, there have been successful attacks against proposals using
   post-quantum cryptography.

I don't know what it means to attack a proposal. Form later in the
paragraph, I think you are talking about "Algorithms and mechanisms 
proposed as potential approaches in Rounds 1 and 2 of the NIST Post-
Quantum Cryptography Standardization Project." I think it is worth using
this long form with precision.

---

Section 1

You refer to "traditional" algorithms and signature schemes. Asides from
this word causing  some concern in editorial circles (it apparently has
overtones in North America), it is also amusing to think of my great 
grandfather using these algorithms while whittling packets out of
firewood. You may prefer "previous", "legacy", "historic", or
"pre-quantum".

---

I believe you have used draft-ietf-pquip-pqt-hybrid-terminology and 
draft-ietf-tls-hybrid-design as well as RFC 4949 as Normative references
in that you are relying on them for terminology. The implication is that
I may need to read those documents n order to understand this one.

---


Section 2 has

   For schemes achieving the most demanding security notion, Strong Non-
   Separability with Simultaneous Verification, verification succeeds
   not only when both of the component signatures are present but also
   only when the verifier has verified both signatures.

When you say "verification succeeds not only when..." it reads like you 
mean that there are two paths to verification as in "either or". But I
suspect (what do I know?) that you intend that verification only succeeds
when both conditions are met.

---

Table 2 case 7 is not mentioned in the text.

= Nitz =

As noted by idnits, you have some non-ASCII characters showing up. Some 
of these are accented letters in proper names (good) while others seem
be artefacts of an editor (bad), e.g., smart quotes in 1.3.3.

---

You are missing a (null) IANA section.

---

Abbreviations and references

It would be nice to expand abbreviations and provide references

1.1 mentions EUF-CMA

1.2.1 mentions ML-DSA, Fiat-Shamir, Falcon, Rainbow, GeMSS, and RSA

1.3.1.1 introduces SUF-CMA

1.3.2 uses KDF

3.1 has ECDSA

4 has FIPS

---

Section 1

s/for to/to/

---

Section 1.1 

s/NIST define/NIST defines/

---

A number of section titles are not in Title Case. For example, 1.2, 
1.3.7, 1.3.8, 1.3.9, 1.3.10, 2, 3.1

---

You have both "artefact" and "artifact". Make a choice.

---

5.

s/Consider for example/Consider, for example,/

OLD
   in cases hybrid algorithm
   selection that provides only weak non-separability
NEW
   in cases of hybrid algorithm
   selection that provide only weak non-separability

---

6.

s/Internet draft/Internet-Draft/

---