[OPS-DIR]Re: [Last-Call] Opsdir last call review of draft-ietf-pquip-hybrid-signature-spectrums-06

[Paul Wouters <[e-mail]>]

On Fri, May 16, 2025 at 11:55 AM <[e-mail]> wrote:

> Re-,
>
> I also send a nudge recently as I saw no follow-up.
>
> ccing Paul as he may have more context.
>

I advanced the document because I didn't see any blocker issues during IETF
Last Call. I did take note of the secdir
review, but disagreed with its severity. It states:

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.


It seems to assume that "hybrid" means "more parameters for the
administrator to figure out", but that is not the case.
A hybrid algorithm is just like any other algorithm. It could be selected
from a drop down menu. The hybriddy parts are
all specified in RFCs with mandatory behaviour and selections to be
qualified as a certain named hybrid, eg "mlkem-25519".
There are no servicable parts inside for the IT administrator. Eg there are
different strengths of ML-KEM, but those have
different algorithm identifiers and are unrelated to the "hybrid" part.

As such, I moved the document forward. I was going to ping Med about
reducing his DISCUSS level issue to a COMMENT
level issue, which I guess I am now doing via this email thread and then
ask the authors if I should wait on a revised ID for
changed language or not, leaving it up to the discretion of the authors as
is the practise for non-blocking comments.

Paul




> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Adrian Farrel <[e-mail]>
> > Envoyé : vendredi 16 mai 2025 16:42
> > À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> > [e-mail]
> > Objet : RE: [OPS-DIR]Re: [Last-Call] Opsdir last call review of
> > draft-ietf-pquip-hybrid-signature-spectrums-06
> >
> >
> > Sure, Med.
> >
> > But how has this reached a telechat?
> > The authors told me they would be updating the draft for all of my
> > small issues. Yet I see no revision since January.
> > Is Paul being a bit over-keen?
> >
> > A
> >
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: 16 May 2025 13:05
> > To: Adrian Farrel <[e-mail]>; [e-mail]
> > Subject: [OPS-DIR]Re: [Last-Call] Opsdir last call review of draft-
> > ietf-pquip-hybrid-signature-spectrums-06
> >
> > Hi Adrian,
> >
> > Thanks again for this great review.
> >
> > I inherited your major point as a DISCUSS in the ballot I sent
> > right now:
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm
> > ailarchive.ietf.org%2Farch%2Fmsg%2Fpqc%2Fi6p3vkj70v_D9CNDj5PHYVKnRF
> > w%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5cb7b0efc89840
> > afb72e08dd9487cffd%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> > 830033204730962%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY
> > iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7
> > C0%7C%7C%7C&sdata=XT%2BSENs4zGrbOIVvOOOAhq7dWBTv0atcWxdV8ao27ec%3D&
> > reserved=0.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Adrian Farrel via Datatracker <[e-mail]> Envoyé :
> > > mercredi 26 mars 2025 17:19 À : [e-mail] Cc :
> > > [e-mail];
> > > [e-mail]; [e-mail]
> > > 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 -- [e-mail] To unsubscribe send
> > an
> > > email to [e-mail]
> > ___________________________________________________________________
> > _________________________________________
> > 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.
> > _______________________________________________
> > OPS-DIR mailing list -- [e-mail] To unsubscribe send an
> > email to [e-mail]
>
>
> ____________________________________________________________________________________________________________
> 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.
>
>