Thanks for the detailed review. Please see inline
On Wed, 23 Jul 2025 at 17:01, Mališa Vučinić via Datatracker <noreply@xxxxxxxx> wrote:
Document: draft-ietf-pquip-pqc-engineers
Title: Post-Quantum Cryptography for Engineers
Reviewer: Mališa Vučinić
Review result: Not Ready
I have reviewed draft-ietf-pquip-pqc-engineers-13 as an assigned IOTDIR
reviewer. At the moment, the document is somewhat of a tutorial, a guideline
document and a survey on different PQC techniques. The document gathers a LOT
of information, and in many instances I found the information helpful for
understanding the threats and peculiarities of post-quantum crypto. However, I
believe the document could use a heavy editing pass as I do not believe it is
well structured and lacks a clear scope. In the following, I first provide some
high-level points that I think need to be addressed before this document is
published, and then go on to giving a set of concrete comments as I went
through the document.
Who is the target audience of this document? The document states that it is
targeted to "engineers working on crypto libraries, network security and
infrastructure planning". I believe the document in its current version does
not answer the needs of these audiences. Engineers working on crypto libraries
are arguably interested in the implementation considerations around different
algorithms. Some implementation aspects are indeed present in the document,
e.g. caveats on implementing properly the ML-DSA or FN-DSA schemes, but
completely hidden in the forest of details on cryptographic constructs
underlying the different schemes. Network security engineers are arguably
interested in deploying the available protocols, as designed by the IETF, and
understanding the properties those protocols provide. Given the state of things
at the IETF with respect to PQC and as presented by this document, most of
these works are still in progress. Again, the information is scattered around
the document making the interested reader on this aspect go through the
background of cryptographic constructs. Finally, the document also compares the
sizes of different PQC algorithms, stressing how state-of-the-art PQC affects
the existing protocols, and the available transports. An audience that I think
benefits the most from the information present in this document are protocol
designers in the IETF. I would urge the authors to restructure the document
such that each section has a clearly identified audience. Most of the
information is there, it is a matter of presenting it coherently.
It is not feasible to assign a target audience to each section. By using this guide, readers can efficiently extract the information relevant to their needs while also gaining an understanding of the broader PQC ecosystem.
>From the IoT perspective, an aspect that seems to be missing from the document
are constrained devices and the constrained radio technologies that are
particularly affected by the transition to PQC. In the IoT space, we often work
with radio technologies that have MTUs on the order of several tens of bytes
and low data rates. We did a lot of effort in the IETF (e.g. in LAKE, CoRE,
ACE,...) on defining optimized versions of the security protocols that are fit
for such environments. An aspect to consider is how PQ transition affects these
environments given that currently standardized PQC algorithms significantly
increase the key, ciphertext, signature sizes.
Good point, work is going on in PQC WG to discuss the challenges with constrained devices, for example, see https://datatracker.ietf.org/doc/draft-ietf-pquip-pqc-hsm-constrained/.I added a new section in the draft to discuss about it.
Specific comments:
Section 1: "PQC algorithms are intended to be resistant to attacks by quantum
computers ..." Mention classical as well as quantum computer here.
The original text is correct as is. The key point is that PQC is designed to solve a quantum threat, and the text is focused on that.
Section 1: "at a scale never before undertaken". This is IMO a bit of an
exaggeration. We have deployed new cipher suites before, and we have also
deployed new protocol versions before. Perhaps tone down.
The intention is to describe the complexity of a much larger and more holistic change. Unlike previous ciphersuite transitions, this one involves a massive, coordinated update to the entire cryptographic ecosystem, including changes to protocols, cryptographic libraries, HSMs, trust stores, and PKI.
Section 1: "but differs on some of the guidance". State briefly on what aspects
do they differ or do not mention at all.
Thanks, fixed.
Section 1: "It is crucial for the reader to understand that when the word 'PQC'
is mentioned in the document..." Sentence seems out of context, please rephrase.
Please clarify which sentence you are referring to !
Section 1: The paragraph on "There is ongoing discussion about whether to use
the term 'post-quantum', 'quantum-ready',..." Move to Section 2 on Terminology.
Done.
Section 4: Consider merging the section with Section 3 as the content seems to
belong there.
Section 5: Again, consider merging the section with Section 3 into a single
section.
We prefer to keep the current structure. The distinct sections are intentionally designed.
Section 8: Define 'HDNL' upon first use. Same for 'PQ/T'.
Fixed.
Section 10.1: Citing I-D.draft-ietf-lake-edhoc (now RFC9528) in this context is
a bit misleading as it based on ECDH. Perhaps cite specifically Section 9.4 of
RFC9528.
Thanks, fixed.
Section 10.2: Is this section exhaustive? If not, why do you describe some
properties and not the others.
The security properties described in this section (IND-CCA2 and binding) are not an exhaustive list of all possible KEM security considerations. They were selected because they are fundamental to evaluating KEM suitability in protocol design and are commonly discussed in current PQC work.
I also added the above text to clarify.
Section 10.2.1: You state the understanding IND-CCA2 for protocol designers yet
you do not give enough details in the section to understand IND-CCA2. Why
including it then?
The goal of this section is not to provide a full definition or proof of IND-CCA2 security, which is well-covered in the cryptographic literature, but to highlight its relevance for evaluating KEMs. Readers needing a rigorous treatment would refer to the references in the section.
Section 10.3: I am perhaps missing something obvious but I did not understand
why you included a section on HPKE here.
Added text to justify the reason HPKE is included, the previous sections explained important security properties of KEMs, such as IND-CCA2 security and binding, and emphasized that these properties must be supported by proper protocol design. One widely deployed scheme that achieves this is HPKE (Hybrid Public Key Encryption) {{RFC9180}} which is used by several protocols (e.g., TLS, MLS, JOSE).
Section 11.4.1: There is a different level of detail throughout your document.
Here, you go ahead and give details on the parameter sets for the LMS scheme.
Why is this useful in the context of this document?
The document provides parameter sets not only for LMS but also for other PQC algorithms, including their signature sizes. This information is intended to give readers a consistent overview of the available options .
Section 11.5: The paragraph on "Note that the vast majority of Internet
protocols..." You seem to state that there is no issue with IETF protocols, yet
there might be with proprietary protocols. If you do not cite specific examples
of such protocols, then the whole paragraph can be reduced to the first
sentence.
The paragraph is intended as a general caution, not as an assertion that specific proprietary protocols are known to be vulnerable.
Section 12: "The following table". Reference the table properly.
The table is already properly referenced in Section 12 using “The following table,” so there should be no confusion.
Section 14.3.2: The last paragraph which reads "At least one scheme has been
proposed...". I believe the intent of this document is not to serve as a survey
document of everything that is proposed in the IETF. Then, why include this?
Its purpose is to illustrate that work is already underway to address the challenge of managing paired certificates in a single object.
Cheers,
-Tiru
--
Pqc mailing list -- pqc@xxxxxxxx
To unsubscribe send an email to pqc-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
