What version of the draft should we be basing our changes on? Is it the -19 version in data tracker? Or, is it some version that the RFC editor has modified?
________________________________ From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> Sent: Monday, September 15, 2025 10:05 PM To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com>; quynh.d...@nist.gov <quynh.d...@nist.gov> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>; i...@irtf.org <i...@irtf.org>; smys...@gmail.com <smys...@gmail.com>; auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> Subject: Re: AUTH48: RFC-to-be 9858 <draft-fluhrer-lms-more-parm-sets-19> for your review Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file. 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!-- [rfced] Please ensure that the guidelines listed in Section 2.1 of RFC 5743 have been adhered to in this document. See https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1. --> 3) <!-- [rfced] Please clarify "by defining parameter sets by including additional hash functions" in the first sentence below. Also, would it be helpful to update "These include hash functions that result" in the second sentence in one of the following ways? Or is the current correct? Original: This note extends HSS/LMS (RFC 8554) by defining parameter sets by including additional hash functions. These include hash functions that result in signatures with significantly smaller size than the signatures using the current parameter sets, and should have sufficient security. Perhaps: This document extends HSS/LMS (RFC 8554) by defining additional parameter sets and hash functions. The hash functions result in signatures with significantly smaller sizes than the signatures using the current parameter sets, and they should have sufficient security. Or: This document extends HSS/LMS (RFC 8554) by defining additional parameter sets and hash functions that result in signatures with significantly smaller sizes than the signatures using the current parameter sets and they should have sufficient security. --> 4) <!-- [rfced] Please clarify "a set of parameter sets to". Original: What this draft explores is a set of parameter sets to the HSS/LMS (RFC8554) stateful hash based signature method that reduce the size of the signature significantly or rely on a hash function other than SHA-256 (to increase cryptodiversity). Perhaps: This document explores parameter sets for the HSS/LMS stateful hash-based signature method [RFC8554] that reduce the size of the signature significantly or rely on a hash function other than SHA-256 (to increase cryptodiversity). --> 5) <!-- [rfced] May we update "that will be used in Section 3 and Section 4" as follows? Original: This section defines three hash functions that will be used in Section 3 and Section 4. Perhaps: This section defines three hash functions that are used with the parameter sets defined in Sections 3 and 4. --> 6) <!-- [rfced] We recommend updating these sentences as follows. Please review and let us know your thoughts. Original: Here is a table with the Leighton-Micali One-Time Signature (LM-OTS) parameters defined that use the above hashes: ... Here is a table with the Leighton-Micali (LM) parameters defined that use SHA-256/192, SHAKE256/256 and SHAKE256/192 hash functions: ... Here is a table that gives the space used by both the 256 bit parameter sets and the 192 bit parameter sets, for a range of plausible Winternitz parameters and tree heights: Perhaps: The table below defines the Leighton-Micali One-Time Signature (LM- OTS) parameters that use the hashes defined in Section 2: ... The table below defines the Leighton-Micali (LM) parameters that use the SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions: ... The table below gives the space used by both the 256-bit and 192-bit parameter sets for a range of plausible Winternitz parameters and tree heights: --> 7) <!-- [rfced] How may we revise the parenthetical here to improve clarity? Current: For signature length, both effects are relevant (because the signature consists of a series of hashes and each hash is shorter, and because we need fewer Winternitz chains, we need fewer hashes in each LM-OTS signature). Perhaps: For signature length, both effects are relevant. The first is relevant because the signature consists of a series of hashes and each hash is shorter. The second is relevant because when we need fewer Winternitz chains, we need fewer hashes in each LM-OTS signature. Or: For signature length, both effects are relevant (i.e., because the signature consists of a series of hashes and each hash is shorter and because we need fewer Winternitz chains and thus fewer hashes in each LM-OTS signature). --> 8) <!-- [rfced] Will readers understand what "reason 2 above" refers to? Original: For SHA-256/192, there is a smaller (circa 20%) reduction in the amount of computation required for a signature operation with a 192 bit hash (for reason 2 listed above). Perhaps: For SHA-256/192, there is a smaller (circa 20%) reduction in the amount of computation required for a signature operation with a 192-bit hash (for effect 2 listed above). Or: For SHA-256/192, there is a smaller (circa 20%) reduction in the amount of computation required for a signature operation with a 192-bit hash (for reason 2 listed in Section 6). --> 9) <!-- [rfced] Would updating "will need to be performed, performing the computations on" to "will need to be performed on" make this sentence easier to follow? Original: For example, if the adversary is willing to wait for 2**64 times the time taken by a hash computation (which is over 50 years if a Quantum Computer can compute a hash in 0.1 nsec), this implies that a total of 2**(192-64) = 2**128 hash computations will need to be performed, performing the computations on 2**64 (18 quintillion) separate Quantum Computers, each of which computes 2**64 hash evaluations. Perhaps: For example, if the adversary is willing to wait for 2**64 times the time taken by a hash computation (which is over 50 years if a quantum computer can compute a hash in 0.1 nanoseconds), this implies that a total of 2**(192-64) = 2**128 hash computations will need to be performed on 2**64 (18 quintillion) separate quantum computers, each of which computes 2**64 hash evaluations. --> 10) <!-- [rfced] Should "standard SHA256" here include a hyphen (i.e., "standard SHA-256")? Original: In addition, to perform a length extension attack on SHA-256/192, the attacker has to guess the 64 omitted bits (because the attack requires all 256 bits of the hash value); hence that is even less of a concern than it is for the standard SHA256. --> 11) <!-- [rfced] The text after the semicolon is a fragment. How may we update to connect this text to the rest of the sentence? Original: However, if the application needs to assume that it is infeasible for the signer to generate such a signature, then the security strength assumptions are reduced; 128 bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192. Perhaps: However, if the application needs to assume that it is infeasible for the signer to generate such a signature, then the security strength assumptions are reduced to 128 bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192. Or: However, if the application needs to assume that it is infeasible for the signer to generate such a signature, then the security strength assumptions are reduced (128 bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192). --> 12) <!-- [rfced] Questions about IANA values a) Should the values in the "id" column in Tables 1 and 2 be updated to exactly match the values in the "Numeric Identifier" column of the "LM-OTS Signatures" and "Leighton-Micali Signatures (LMS)" registries in regard to capitalization and leading zeroes? We understand that these hex values are the same. Examples: "id" column of Table 1: 0x0005 0x000a "Numeric Identifier" column of "LM-OTS Signatures" registry: 0x00000005 0x0000000A Links to registries: https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-signatures.xhtml#leighton-micali-signatures-1 https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-signatures.xhtml#lm-ots-signatures b) Some of these values also appear in Appendix A but without the "0x" prefix. Please confirm that this is correct. Example: Appendix A: 0000000a "Numeric Identifier" column of "LM-OTS Signatures" registry: 0x0000000A c) In Appendix A, we believe the names below should be updated as follows to align with the parameter set names in Tables 1 and 2 (and in the IANA registries). Please confirm. Note that there are two instances of of each in Appendix A. Original: LMS type 00000014 # LMS_SHAKE256_N24_H5 LMOTS type 00000010 # LMOTS_SHAKE256_N24_W8 LMS type 0000000f # LMS_SHAKE256_N32_H5 LMOTS type 0000000c # LMOTS_SHAKE256_N32_W8 Perhaps: LMS type 00000014 # LMS_SHAKE_M24_H5 LMOTS type 00000010 # LMOTS_SHAKE_N24_W8 LMS type 0000000f # LMS_SHAKE_M32_H5 LMOTS type 0000000c # LMOTS_SHAKE_N32_W8 --> 13) <!-- [rfced] The following reference entries appeared in the Normative References section but were not cited in the text. We have removed them; however, if they should be cited in the text, please let us know where to include them. [RFC2119] [RFC3979] [RFC4879] [RFC5226] [RFC8174] --> 14) <!-- [rfced] FYI - For [Grover96], we found the following URL from the ACM Digital Library: https://dl.acm.org/doi/10.1145/237814.237866 We have updated this reference to match the information provided at this URL. Please let us know if you have any objections. Current: [Grover96] Grover, L., "A fast quantum mechanical algorithm for database search", Proceedings of the twenty-eighth annual ACM symposium on Theory of Computing (STOC '96), pp. 212-219, DOI 10.1145/237814.237866, July 1996, <https://doi.org/10.1145/237814.237866>. --> 15) <!-- [rfced] Appendix A a) Appendix A includes four test cases, not three as indicated in the sentence below. We updated as follows for accuracy. Please let us know any objections. Original: This section provides three test cases that can be used to verify or debug an implementation, one for each hash function. Updated: This appendix provides four test cases that can be used to verify or debug an implementation. b) FYI - Note that we used figure titles to label the test cases for clarity, even though we see that figure titles were not used in a similar appendix in RFC 8554. Let us know any concerns. c) For the ease of the reader, we suggest adding subsections to Appendix A for each test case. Let us know your thoughts. Current: Appendix A. Test Cases Perhaps: Appendix A. Test Cases A.1. Test Case 1 A.2. Test Case 2 A.3. Test Case 3 A.4. Test Case 4 If we update like this, we could also remove "Test Case 1", "Test Case 2", etc. from the figure titles if you wish. --> 16) <!-- [rfced] In Section 2.1, we updated <artwork> to <sourcecode type="test-vectors">. Please let us know any concerns. Also, please review each artwork element in Appendix A. Should these be tagged as sourcecode or another element? If these are updated to sourcecode, please let us know how/if to set the type attribute. The current list of preferred values for the "type" attribute for <sourcecode> is available here: https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types If this list does not contain an applicable type, then feel free to suggest a new one. Also, it is acceptable to leave the "type" attribute not set. --> 17) <!-- [rfced] Does "**" indicate superscript? Some examples: 2**192 2**96 2**t 2**(192-t) 2**(192/2) If so, would you like to make use of <sup> for superscript in this document? As an example, we updated "2**192" in the fourth paragraph of Section 8 to use <sup>. If this is acceptable, we will update the other instances; if you choose not to use <sup>, we will revert this change. Note: In the HTML and PDF, it appears as superscript. In the text output, <sup> generates a^b instead of a**b, which was used in the original document. --> 18) <!-- [rfced] We updated "1k - 4kbytes" and "0.1 nsec" as follows for clarity. Let us know any concerns. Original: One disadvantage is that the signatures they produce tend to be somewhat large (possibly 1k - 4kbytes). ... (which is over 50 years if a Quantum Computer can compute a hash in 0.1 nsec) Updated: One disadvantage is that the signatures they produce tend to be somewhat large (possibly 1-4 kilobytes). ... (which is over 50 years, if a quantum computer can compute a hash in 0.1 nanoseconds) --> 19) <!-- [rfced] Terminology a) The first two sentences below use "LM-OTS" and "LM", while the third sentence uses "LMOTS" and "LMS" when discussing Tables 1 and 2. Please review and let us know if updates are needed for consistency. Original: Here is a table with the Leighton-Micali One-Time Signature (LM-OTS) parameters defined that use the above hashes: ... Here is a table with the Leighton-Micali (LM) parameters defined that use SHA-256/192, SHAKE256/256 SHAKE256/256, and SHAKE256/192 hash functions: ... To use the additional hash functions within HSS, one would use the appropriate LMOTS id from Table 1 and the appropriate LMS id from Table 2, ... b) Please also review the following (which appear in Appendix A) and let us know if any updates are needed to align with the choice for the question above. LMS type LMOTS type LMOTS signature c) Please review the the following and let us know if any updates are needed. These are used in RFC 8445, but we note that there is redundancy with "signature" when expanded (i.e., "Leighton-Micali Signature signature" and "Hierarchical Signature System signature"). LMS signature HSS signature --> 20) <!-- [rfced] Abbreviations: a) FYI - We have added expansions for the following abbreviation(s) per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. extendable-output function (XOF) b) How may we expand "IV" in the following? As "Initialization Vector (IV)"? This the only instance of IV in the document. Original: We use the same IV as the untruncated SHA-256, rather than defining a distinct one, so that we can use a standard SHA-256 hash implementation without modification. Perhaps: We use the same initialization vector as the untruncated SHA-256, rather than defining a distinct one, so that we can use a standard SHA-256 hash implementation without modification. --> 21) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. Sarah Tarrant and Rebecca VanRheenen RFC Production Center On Sep 15, 2025, at 6:59 PM, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/09/15 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9858.xml https://www.rfc-editor.org/authors/rfc9858.html https://www.rfc-editor.org/authors/rfc9858.pdf https://www.rfc-editor.org/authors/rfc9858.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9858-diff.html https://www.rfc-editor.org/authors/rfc9858-rfcdiff.html (side by side) Alt-diff of the text (allows you to more easily view changes where text has been deleted or moved): https://www.rfc-editor.org/authors/rfc9858-alt-diff.html Diff of the XML: https://www.rfc-editor.org/authors/rfc9858-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9858 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9858 (draft-fluhrer-lms-more-parm-sets-19) Title : Additional Parameter sets for HSS/LMS Hash-Based Signatures Author(s) : S. Fluhrer, Q. Dang WG Chair(s) : Area Director(s) :
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
