Hi Scott, Regarding: > 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?
I'm not sure what you mean by "basing our changes on". draft-fluhrer-lms-more-parm-sets-19 has now entered AUTH48 as RFC-to-be 9858. And we await answers to the questions below. Here are those links again: 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 Please let me know if I can be of further assistance. Sincerely, Sarah Tarrant RFC Production Center > On Sep 17, 2025, at 7:28 AM, Scott Fluhrer (sfluhrer) > <[email protected]> wrote: > > 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: [email protected] <[email protected]> > Sent: Monday, September 15, 2025 10:05 PM > To: Scott Fluhrer (sfluhrer) <[email protected]>; [email protected] > <[email protected]> > Cc: [email protected] <[email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]> > 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, [email protected] 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 > > * [email protected] (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). > > * [email protected], 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, > [email protected] 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 -- [email protected] To unsubscribe send an email to [email protected]
