Hi Scott and Stanislav, Scott - I believe this would be a question for the Document Shepherd.
Stanislav - Could you better direct Scott on this? Thank you, Sarah Tarrant RFC Production Center > On Sep 17, 2025, at 4:35 PM, Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> > wrote: > > Quick question: RFC 5743 asks: > > The breadth of review the document has received must also be > noted. For example, was this document read by all the active > research group members, only three people, or folks who are not > "in" the RG but are expert in the area? > > > Actually, I'm not sure of the breadth. I do know some people reviewed it > (and we did get a few comments), but I would be quite surprised if the > majority of the research group did. How do I note that? > From: Sarah Tarrant <starr...@staff.rfc-editor.org> > Sent: Wednesday, September 17, 2025 8:59 AM > To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> > Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>; > quynh.d...@nist.gov <quynh.d...@nist.gov>; 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 > > 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) > > <sfluhrer=40cisco....@dmarc.ietf.org> 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: 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
