Ballot for draft-ietf-lamps-rfc8708bis
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Why is SHAKE256 picked over SHA3-256? Doesn't this cut the preimage resistance in half? Is the increased speed of 2x compared to SHA2-256 really that important? What considerations were made for this? Why not define both SHA3-256 and SHAKE256 and let people pick their preferred option? Should the reasoning for these choices perhaps be added to the document so others can be informed about the choices made?
Recent advances in cryptanalysis [BH2013] and progress in the development
of quantum computers [NAS2019] pose a threat
If cryptographically relevant quantum computers (CRQCs) are ever
built, these computers will be able to
I find the first sentence contradicting the rest of the section. Maybe say
"future threat" or "possible threat"?
The HSS/LMS signatures [HASHSIG] are currently defined to use
SHA-256 [SHS] and SHAKE256 [SHA3].
I guess I am seeing a start of confusion about SHA3 vs SHAKE256. But I think it is
too late to try and fix that terminology now :/
An implementation MUST ensure that an LM-OTS private key is used
to generate a signature only one time and ensure that it cannot
be used for any other purpose.
How can an implementer "ensure that it cannot be used for any other purpose" ?
You mean with EKU flags or something else?
I am yet to see a response to the SECDIR review done by Donald Eastlake. Hope the authors are planning to address the comments. Section 1.4, paragraph 4 > Provide more detail in Section 4 regarding allowed values in the > X.509 certificate key usage extension for an HSS/LMS public key. Is this a TODO for the author? ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. These URLs in the document did not return content: * http://www.springer.com/cda/content/document/cda_downloaddocument/9783540887010-c1.pdf Section 1, paragraph 1 > ystem to efficiently scale for a larger numbers of signatures. The HSS/LMS al > ^^^^^^^^^^^^^^^^ The plural noun "numbers" cannot be used with the article "a". Did you mean "a larger number" or "larger numbers"?
Thank you to Linda Dunbar for the GENART review.
Thank you for the work done in this document. Some non-blocking comments though ;-) The shepherd's write-up is slight inconsistent as it says that this I-D "updates" RFC 8708 while it actually obsoletes it. Also, I am unsure whether this I-D is fixing an erratum (Q1 of the template) or at least the erratum reference would be welcome. ## Section 1.3 I find weird to have a 2013 reference in the same sentence as "recent advances", see `Recent advances in cryptanalysis [BH2013]` ;-) ## Section 1.4 Is there some hand waving in this section with terms like `there are plans` and `yet-to-be-published` ? I am not very familiar in the PKIX/CMS parts of the Internet, so this may well be clear for more knowledgeable people.