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. >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. Specific comments: Section 1: "PQC algorithms are intended to be resistant to attacks by quantum computers ..." Mention classical as well as quantum computer here. 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. Section 1: "but differs on some of the guidance". State briefly on what aspects do they differ or do not mention at all. 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. 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. 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. Section 8: Define 'HDNL' upon first use. Same for 'PQ/T'. 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. Section 10.2: Is this section exhaustive? If not, why do you describe some properties and not the others. 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? Section 10.3: I am perhaps missing something obvious but I did not understand why you included a section on HPKE here. 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? 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. Section 12: "The following table". Reference the table properly. 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? -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
