I will confirm that the working group asked for a reference that was perceived to be 'more stable'. Using both would be ideal, even if that isn't really typical.
I guess the reference could be split into two entries, but I think that would affect the text of the specification itself. Deb On Sat, Mar 7, 2026 at 7:07 AM Simon Josefsson <[email protected]> wrote: > Hi > > I'm reviewing the changes, and noticed that you removed the DOI URL in > the [NTRUPrimePQCS] reference. > > Adding that URL was requested as part of the WGLC process, IIRC. > > Was there any strong reason to make this change? > > I think including both URLs would be better. Suggestion: > > OLD: > [NTRUPrimePQCS] > Bernstein, D.J., Brumley, B. B., Chen,, M., Chuengsatiansup, C., > Lange, T., Marotzke, A., Peng, B., Tuveri, N., Vredendaal, C. V., and > B. Yang, "NTRU Prime: round 3", DOI 10.5281/zenodo.13983972, October > 2020, <https://ntruprime.cr.yp.to/nist/ntruprime-20201007.pdf>. > > NEW: > [NTRUPrimePQCS] > Bernstein, D.J., Brumley, B. B., Chen,, M., Chuengsatiansup, C., > Lange, T., Marotzke, A., Peng, B., Tuveri, N., Vredendaal, C. V., and > B. Yang, "NTRU Prime: round 3", October 2020, > <https://ntruprime.cr.yp.to/nist/ntruprime-20201007.pdf>, DOI > 10.5281/zenodo.13983972, <https://doi.org/10.5281/zenodo.13983972>. > > Compare how it looks in the last I-D (a bit buggy hyperlink though, so > fixing that would be nice): > > https://datatracker.ietf.org/doc/html/draft-ietf-sshm-ntruprime-ssh-06#name-normative-references > > /Simon > > > fre 2026-03-06 klockan 19:15 -0800 skrev [email protected]: > > Authors, > > > > While reviewing this document during AUTH48, please resolve (as > > necessary) the following questions, which are also in the source > > file. > > > > > > 1) <!-- [rfced] FYI - We updated the abbreviated title as follows. > > The > > abbreviated title appears in the center of the running header at the > > top > > of each page in the PDF output. > > > > Original: > > NTRUPrime+X25519 for SSH > > > > Updated: > > NTRUPrime and X25519 for SSH > > --> > > > > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear > > in > > the title) for use on https://www.rfc-editor.org/search. --> > > > > > > 3) <!-- [rfced] In the text below, may we either update to use > > complete titles of > > the RFCs or use just the citation? Note that other instances in the > > document use just the citation, as does similar text in RFC 8731. > > > > a) From Introduction > > > > Original: > > Secure Shell (SSH) [RFC4251] is a secure remote login protocol. > > The > > key exchange protocol described in SSH transport layer [RFC4253] > > supports an extensible set of methods. Elliptic Curve Algorithms > > in > > SSH [RFC5656] defines how elliptic curves are integrated into the > > extensible SSH framework, and SSH KEX Using Curve25519 and > > Curve448 > > [RFC8731] adds curve25519-sha256 to support the pre-quantum > > elliptic- > > curve Diffie-Hellman X25519 function [RFC7748]. > > ... > > This document was derived from SSH KEX Using Curve25519 and > > Curve448 > > [RFC8731]. > > > > Perhaps A (full titles): > > "The Secure Shell (SSH) Protocol Architecture" [RFC4251] is a > > secure > > remote login protocol. The key exchange protocol described in > > "The > > Secure Shell (SSH) Transport Layer Protocol" [RFC4253] supports an > > extensible set of methods. The "Elliptic Curve Algorithm > > Integration > > in the Secure Shell Transport Layer" [RFC5656] defines how > > elliptic > > curves are integrated into the extensible SSH framework, and the > > "Secure Shell (SSH) Key Exchange Method Using Curve25519 and > > Curve448" > > [RFC8731] adds curve25519-sha256 to support the pre-quantum > > Elliptic > > Curve Diffie-Hellman (ECDH) X25519 function [RFC7748]. > > ... > > This document was derived from "Secure Shell (SSH) Key Exchange > > Method > > Using Curve25519 and Curve448" [RFC8731]. > > > > Perhaps B (just citations): > > Secure Shell (SSH) [RFC4251] is a secure remote login protocol. > > The > > key exchange protocol described in [RFC4253] > > supports an extensible set of methods. > > [RFC5656] defines how elliptic curves are integrated into the > > extensible SSH framework, and > > [RFC8731] adds curve25519-sha256 to support the pre-quantum > > Elliptic > > Curve Diffie-Hellman (ECDH) X25519 function [RFC7748]. > > ... > > This document was derived from [RFC8731]. > > > > > > b) From Section 3 > > > > Original: > > For consistency with ECC in SSH [RFC5656], which define the packet > > syntax, we use those names in the rest of this document. > > > > Perhaps A (full titles): > > For consistency with "Elliptic Curve Algorithm Integration in the > > Secure Shell Transport Layer" [RFC5656], which defines the packet > > syntax, we use those names in the rest of this document. > > > > Perhaps B (just citations): > > For consistency with [RFC5656], which defines the packet > > syntax, we use those names in the rest of this document. > > > > > > c) From Security Considerations > > > > Original: > > The security considerations of the SSH Protocol [RFC4251], ECC for > > SSH [RFC5656], Elliptic Curves for Security [RFC7748], and SSH KEX > > Using Curve25519 and Curve448 [RFC8731] are inherited. > > > > Perhaps A (full titles): > > The security considerations of the following are inherited: > > > > * "The Secure Shell (SSH) Protocol Architecture" [RFC4251] > > > > * "Elliptic Curve Algorithm Integration in the Secure Shell > > Transport Layer" [RFC5656] > > > > * "Elliptic Curves for Security" [RFC7748] > > > > * "Secure Shell (SSH) Key Exchange Method Using Curve25519 and > > Curve448" [RFC8731] > > > > Perhaps B (just citations): > > The security considerations in [RFC4251], [RFC5656], [RFC7748], > > and > > [RFC8731] are inherited. > > --> > > > > > > 4) <!-- [rfced] Please review the following phrases in the sentence > > below and > > consider how to update for clarity. > > > > - "security considerations of Curve25519-sha256 [RFC8731]" > > - "is used bignum-encoded" > > - "hash-processing time side-channel" > > > > Original: > > As discussed in the security considerations of Curve25519-sha256 > > [RFC8731], the X25519 shared secret K is used bignum-encoded in > > that > > document, and this raise a potential for a hash-processing time > > side- > > channel that could leak one bit of the secret due to different > > length > > of the bignum sign pad. > > > > Perhaps: > > As discussed in the security considerations of > > [RFC8731], the X25519 shared secret K is bignum-encoded in that > > document, and this raises the potential for a side- > > channel attack that could leak one bit of the secret due to the > > different length > > of the bignum sign pad. > > --> > > > > > > 5) <!-- [rfced] Artwork/sourcecode > > > > a) We updated the <artwork> in Appendix A to <sourcecode > > type="test-vectors">. Please confirm that the value "test-vectors" is > > correct. The current list of preferred values for "type" 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. > > > > b) The lines in the figure in Appendix A are too long for the TXT > > output. For > > sourcecode, the maximum line length is 69 characters (the current is > > 71 > > characters). Please let us know how to update to fit this > > requirement. > > --> > > > > > > 6) <!-- [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 Mar 6, 2026, at 7:12 PM, [email protected] wrote: > > > > *****IMPORTANT***** > > > > Updated 2026/03/06 > > > > 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/rfc9941.xml > > https://www.rfc-editor.org/authors/rfc9941.html > > https://www.rfc-editor.org/authors/rfc9941.pdf > > https://www.rfc-editor.org/authors/rfc9941.txt > > > > Diff file of the text: > > https://www.rfc-editor.org/authors/rfc9941-diff.html > > https://www.rfc-editor.org/authors/rfc9941-rfcdiff.html (side by > > side) > > > > For your convenience, we have also created an alt-diff file that will > > allow you to more easily view changes where text has been deleted or > > moved: > > https://www.rfc-editor.org/authors/rfc9941-alt-diff.html > > > > Diff of the XML: > > https://www.rfc-editor.org/authors/rfc9941-xmldiff1.html > > > > > > Tracking progress > > ----------------- > > > > The details of the AUTH48 status of your document are here: > > https://www.rfc-editor.org/auth48/rfc9941 > > > > Please let us know if you have any questions. > > > > Thank you for your cooperation, > > > > RFC Editor > > > > -------------------------------------- > > RFC9941 (draft-ietf-sshm-ntruprime-ssh-06) > > > > Title : Secure Shell (SSH) Key Exchange Method Using > > Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: > > sntrup761x25519-sha512 > > Author(s) : M. Friedl, J. Mojzis, S. Josefsson > > WG Chair(s) : Stephen Farrell, Job Snijders > > > > Area Director(s) : Deb Cooley, Paul Wouters >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
