Oh we missed one:
---
Addressed in https://github.com/dconnolly/draft-ietf-pquip-hybrid-signature-spectrums/commit/29c034c0bb936d406fd701fede45d817fe8d9b67
---
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.
Addressed in https://github.com/dconnolly/draft-ietf-pquip-hybrid-signature-spectrums/commit/29c034c0bb936d406fd701fede45d817fe8d9b67
---
On Wed, Jun 11, 2025 at 2:54 AM Deirdre Connolly <durumcrustulum@xxxxxxxxx> wrote:
We have pushed a lot of changes out of the Last Call Review to https://github.com/dconnolly/draft-ietf-pquip-hybrid-signature-spectrums, currently blocked on being published to datatracker as a new version as one of our coauthors is on leave.
---Section 1Still, 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.
Addressed in https://github.com/dconnolly/draft-ietf-pquip-hybrid-signature-spectrums/commit/84c6695c6488f8367e0a368d674dd2c956f71f46 by talking about "algorithms" instead of "proposals"
---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".
We're following https://www.ietf.org/archive/id/draft-ietf-pquip-pqt-hybrid-terminology-06.html guidance on this terminology as noted
---Section 2 hasFor 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.
Reworded accordingly in https://github.com/dconnolly/draft-ietf-pquip-hybrid-signature-spectrums/commit/84c6695c6488f8367e0a368d674dd2c956f71f46
---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.
Fixed in https://github.com/dconnolly/draft-ietf-pquip-hybrid-signature-spectrums/commit/84c6695c6488f8367e0a368d674dd2c956f71f46
---You are missing a (null) IANA section.
Fixed in https://github.com/dconnolly/draft-ietf-pquip-hybrid-signature-spectrums/commit/84c6695c6488f8367e0a368d674dd2c956f71f46
---Abbreviations and referencesIt would be nice to expand abbreviations and provide references1.1 mentions EUF-CMA1.2.1 mentions ML-DSA, Fiat-Shamir, Falcon, Rainbow, GeMSS, and RSA1.3.1.1 introduces SUF-CMA1.3.2 uses KDF3.1 has ECDSA4 has FIPS
EUF-CMA definition fixed in https://github.com/dconnolly/draft-ietf-pquip-hybrid-signature-spectrums/commit/b075b21b5671a9147d3623d264a557aa2964c8d9
ML-DSA, Fiat-Shamir, Falcon, Rainbow, GeMSS, and RSA referenced in https://github.com/dconnolly/draft-ietf-pquip-hybrid-signature-spectrums/commit/ab9289ef7f9acbbd5ebb834cc6256203d0884574
SUF-CMA defined in https://github.com/dconnolly/draft-ietf-pquip-hybrid-signature-spectrums/commit/1b48f38d020d38d22e187186e783b55d605aa4d1KDF replaced with the full form in https://github.com/dconnolly/draft-ietf-pquip-hybrid-signature-spectrums/commit/ab9289ef7f9acbbd5ebb834cc6256203d0884574
Removed mention of ECDSA in https://github.com/dconnolly/draft-ietf-pquip-hybrid-signature-spectrums/commit/ab9289ef7f9acbbd5ebb834cc6256203d0884574
---s/for to/to/
Fixed somewhere on the way to https://github.com/dconnolly/draft-ietf-pquip-hybrid-signature-spectrums/commit/793bd62ed0490cd522ac1837b2c430b857137ff2
---s/NIST define/NIST defines/A number of section titles are not in Title Case.---> You have both "artefact" and "artifact". Make a choice.---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---s/Internet draft/Internet-Draft/On Wed, Mar 26, 2025 at 12:18 PM Adrian Farrel via Datatracker <noreply@xxxxxxxx> wrote:Reviewer: Adrian Farrel
Review result: Has Issues
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/
---
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
