On Thu, 8 May 2025, Flo D wrote:
Thank you for following up. We have been working on incorporating Adrian's comments into the draft, as well as Yaron's and Ines's for other areas. Unfortunately, we've been a bit delayed due to other commitments, but the work is underway, and we will upload a new version of the draft once it is ready. We are very grateful to the reviewers for their thorough reviews, and will follow up on list shortly. Flo (on behalf of the authors)
A lot of feedback came in the last few days as the document is on today's IESG Telechat. Unfortunately, we haven't heard from the authors as promised. Note that I will keep this document in Revised I-D needed state until the DISCUSS and the COMMENTS (some of which are close to DISCUSS level) have been addressed by the authors. Paul
__________________________________________________________________________________________________________________________ From: mohamed.boucadair@xxxxxxxxxx <mohamed.boucadair@xxxxxxxxxx> Sent: Tuesday, May 6, 2025 4:47 pm To: draft-ietf-pquip-hybrid-signature-spectrums.all@xxxxxxxx <draft-ietf-pquip-hybrid-signature-spectrums.all@xxxxxxxx>; Adrian Farrel <adrian@xxxxxxxxxxxx> Cc: last-call@xxxxxxxx <last-call@xxxxxxxx>; pqc@xxxxxxxx <pqc@xxxxxxxx>; ops-dir@xxxxxxxx <ops-dir@xxxxxxxx> Subject: RE: [Last-Call] Opsdir last call review of draft-ietf-pquip-hybrid-signature-spectrums-06 Dear Authors, Unless I'm mistaken, I didn't see any follow-up to Adrian's review. Can you please update us about your plan to consider this review? Thanks. Cheers, Med > -----Message d'origine----- > De : Adrian Farrel via Datatracker <noreply@xxxxxxxx> > Envoyé : mercredi 26 mars 2025 17:19 > À : ops-dir@xxxxxxxx > Cc : draft-ietf-pquip-hybrid-signature-spectrums.all@xxxxxxxx; > last-call@xxxxxxxx; pqc@xxxxxxxx > Objet : [Last-Call] Opsdir last call review of draft-ietf-pquip- > hybrid-signature-spectrums-06 > > > 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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
