Open WGLC comments for pqc-for-engineers

[ounsworth]

OOPS. I put this issue on the wrong repo, and now it's a pain to move it.

Scraping comments from this thread:

https://mailarchive.ietf.org/arch/msg/pqc/LbdN12fhjsjPz3tzkEJdPAvrBY8/

• Ben S3
• MCR
• Orie
• Jan Schaumann -- Contributed a PR, which has been merged.
• Thibaud Ecarot
• Yaakov Stein

Full comments are broken out below.

[ounsworth]

Comments from Ben S3:

"I think we’re most of the way there, but I’m not sure we’re quite ready."

https://mailarchive.ietf.org/arch/msg/pqc/eznVZNG5Sr__Q1TzKRHZYqEDCqM/

• The main outstanding issue, as I see it, is that it’s not clear to me who the audience of this draft is. That’s not to say there is no audience (there definitely is!), but rather that in its current form, the draft is trying to pitch itself at too wide an audience, which makes it less useful for everyone. In my view, this draft should make it clear in the introduction who its audience is (and possibly who it isn’t), and then tailor the content to that audience.

[ounsworth]

Comments from MCR:

• I believe that we can and SHOULD take leadership here. The above paragraph misses quantum-safe (my preferred term). The document does not consistently use any one term.
  • MikeO: I think we have addressed this in a PR from MCR?
• BCP14 keywords declared, but none actually used. A few places where maybe
  they could be, but aren't.
• Also, the document sometimes says "traditional" and "legacy", and other times uses "classical".
  • MikeO: I believe we have addressed this in a PR?
• The section: "Traditional Cryptographic Primitives that Could Be Replaced by PQC" mentions key agreement, and then signatures, and a quibble might be that a number of our protocols (IKEv2 in particular), uses both an ephemeral key agreement (DH), with a signature to sign it. I don't know if it's worth adding that point; enough to make it clear to engineers that they might have to learn two things to properly replace that mechanism.
• "section 10.1, What is a KEM:" There seem to be three hands here: a) Key Agreements, b) Key Transport schemes, c) KEMs. I think that the ", on the other hand" is a mis-edit after the previous sentence was inserted?
• section "Authenticated Key Exchange (AKE)" -- This first sentence seems to belong elsewhere, if the point is to explain single-side KEM/non-interactive HPKE.
• NIKE belongs in a terminology section.
• "IETF specification authors should include all security concerns in the 'Security Considerations' section of the relevant RFC and should not assume that implementers are deep experts in cryptographic theory" -- Surely not every document that relies upon a security protocol needs to say this. Surely this is about specifications that specify How to use Algorithm XYZ in protocol ABC.
• As a general editorial point I think that there are many places where a new paragraph might help, and a few places where I think section headers would help people refer to things later.
• s a nit, I suggest when using markdown that every sentence start on a new line. This makes pull requests less disruptive. That is, "s/. /.^J/g"

[ounsworth]

Comments from Orie:

"Overall, I don't think this document is ready."

https://mailarchive.ietf.org/arch/msg/pqc/_Pv_5FKLnWlvXYKnDNfa-F51va0/

• The content and tone of the abstract, introduction and early sections feel
  different from the later sections.
• I'd be tempted to eliminate section 3 to section 6 altogether.
• "The document is a mix of history and descriptions, but makes very few clear
  recommendations (none using BCP14 ?).
  It would be nice if we could make at least a few RECOMMENDED / NOT
  RECOMMENDED comments to this effect." And maybe move the more explanatory text to an appendix?
• Abstract is long. Consider moving some of the text to the introduction.
• Lines 22 - 207: I don't like this framing. CRQCs are a threat to both symmetric and asymmetric cryptography. The threat is known to be greater to asymmetric schemes because of Shor's
  algorithm. There is still some threat to symmetric schemes and hash functions from Grover's algorithm.
• You should give PQC a definition in Section 2 similar to Wikipedia's:

Post-quantum cryptography (PQC), sometimes referred to as quantum-proof,
quantum-safe, or quantum-resistant, is the development of cryptographic
algorithms (usually public-key algorithms) that are currently thought to be
secure against a cryptanalytic attack by a quantum computer.

• Around line 262: I would change this section to summarize the impact on key establishment,
  content encryption and digital signatures. You might also consider noting that advanced cryptographic concepts such as zero knowledge proofs can be impacted similarly to how digital signature
  and key establishment algorithms are impacted.
• "295 5. Invariants of Post-Quantum Cryptography" -- I don't like the section title, and I am not sure what guidance is being recommended here. ... I would therefore delete section section 5 all together.
• "318 In 2016, the National Institute of Standards and Technology (NIST)" -- I would change this to describe the recent announcements, and direct readers to review them. Feels like this is just repeating NIST, and it would be better to just direct the reader there. I don't think the history adds anything here.
• "7. Threat of CRQCs on Cryptography" -- This feels like a better introduction. I would suggest restructuring to lead with this, after a shortened abstract.
• IETF Hybrid Policy -- the IETF as a whole does not have a hybrid policy, so we should instead mention specific drafts.
• "14.3. Additional Considerations" -- This section is long, and its title is vague... consider breaking it up to cover... primitive diversity, combining modes and composites, regional and regulatory compliance, ...
• "15.4. Caution: Ciphertext commitment in KEM vs DH" -- What should an engineer do with this information? Why does this consideration matter?
• Remove "Contributing to this document" section
• Section "NSA / BSI": Expand acronyms / handle country consistently. United States, National Security Agency/Central Security Service (NSA/CSS), National Institute of Standards and Technology (NIST), German, Federal Office for Information Security (BSI).

[ounsworth]

Comments from Thibaud Ecarot:

• Line 10: I suggest replacing: "Data encrypted today (2024) with an algorithm vulnerable to a quantum computer can be stored for decryption by a future attacker with a CRQC." With: "Data encrypted with an algorithm vulnerable to a quantum computer can be stored for decryption by a future attacker with a CRQC.". In the text, I will remove the date that fixes the standard in time. This could cause problems, especially since the terminology is supposed to be used for an extended period.
• Section 2: The terms traditional algorithm, conventional algorithm, or classical algorithm are not suitable for standardization due to their subjective nature. Introducing subjectivity into standards can lead to potential issues. Therefore, it is crucial to use more precise and less subjective terminology. For instance, a term like 'quantum-risk algorithm' or a newly coined term could be more appropriate for the standard.
• Overall, the term post-quantum algorithm could be better than the term the community has used far too much. The term post-quantum is bad because there is the term post. In 40 years, when there will be hybrid environments with quantum computers to do very specific calculations, and there will also be classical HPC, what does the term post mean? It is not very clear. Moreover, the document in its version 4 specifies: "There may be asymmetric cryptographic constructions that are neither post-quantum nor asymmetric traditional algorithms according to the definitions above, but these are out of scope of this document.". Who is the judge of whether an algorithm is quantum resistant or not? Only time will tell.
• What this may refer to in a single algorithm scheme needs to be clarified. Are there any examples? The text mentions that "A single-algorithm scheme could use either a traditional algorithm or a post-quantum algorithm.". We are at the level of generalization above. I would say "A single-algorithm scheme could use a unique cryptographic algorithm.". Wanting to associate traditional and post-quantum here does not make sense, neither from a taxonomic point of view nor even if we refer to ontological concepts (functions and relations).
• Section 3 of the document seems to lack coherence, with elements that do not seem to fit together or that use redundant terms to describe the same thing. This observation calls for a deeper analysis, which is where your expertise in the field of cryptography is crucial.
• In section 5, we must distinguish the teleological properties that set objectives to be achieved from the ontological properties of algorithms, which intrinsically characterize them.

[ounsworth]

Comments from Yaakov Stein:

"I think this document is really useful, but really really needs editorial work."

https://mailarchive.ietf.org/arch/msg/pqc/dSvnqCNqLJV3bV0I1aDUljR7qRE/

• Several examples are listed of sentences in need of editing polish.
• I found section 10 confusing since "hybrid" is used in 2 different ways, i.e., "hybrid PQ and conventional" and "hybrid asymmetric and symmetric". Yes, it is too late to change the terminology, but a sentence saying "please note that ..." would help.
• I also didn't see a sentence explaining that hybrid PQ-conventional schemes are used because of less time for checking that these newer algorithms are truly unbroken classically (although NIST doesn't recommend them).
• Please define "breaking" which is used 13 times. Do you mean reduced to polynomial complexity, or solvable in hours using current state-of-the-art?
• Please remove: "While there is ongoing discussion about whether to use the term 'Post-Quantum' or 'Quantum Ready/Resistant' to describe algorithms that resist CRQCs, a consensus has not yet been reached." -- This has been discussed elsewhere, and the title of this document already adopts "PQ".
• I realize that NIST uses ML-KEM but the original name "Kyber" is in such common use that it should be introduced.
• [ ]