There is a typo in Sarah's message. AUTH48 status can be found here: https://www.rfc-editor.org/auth48/rfc9941
(Every author has to approve for publication) Deb On Thu, Apr 2, 2026 at 3:51 PM Deb Cooley <[email protected]> wrote: > I approve (Appendix A is much better w/out the ASCII) > > Deb Cooley > > On Thu, Apr 2, 2026 at 11:37 AM Sarah Tarrant < > [email protected]> wrote: > >> Hello Jan, Markus, Simon, and *Deb, >> >> *Deb - Could you take a look at the updated sourcecode in Appendix A? In >> order to conform to the line character length, the authors elected to >> remove the ASCII representation on the right. See: >> https://www.rfc-editor.org/authors/rfc9941-auth48diff.html >> >> Authors - Thank you for your replies! I have updated accordingly and have >> no further questions. >> >> Please review the document carefully to ensure satisfaction as we do not >> make changes once it has been published as an RFC. Contact us with any >> further updates or with your approval of the document in its current form. >> We will await approvals from each author prior to moving forward in the >> publication process. >> >> The updated files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9941.txt >> https://www.rfc-editor.org/authors/rfc9941.pdf >> https://www.rfc-editor.org/authors/rfc9941.html >> https://www.rfc-editor.org/authors/rfc9941.xml >> >> The relevant diff files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9941-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc9941-auth48diff.html (AUTH48 >> changes only) >> >> Note that it may be necessary for you to refresh your browser to view the >> most recent version. >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfcXXXX >> >> Thank you, >> Sarah Tarrant >> RFC Production Center >> >> > On Apr 2, 2026, at 10:03 AM, Simon Josefsson <[email protected]> >> wrote: >> > >> > +1 on changes below. >> > >> > The citation style change was discussed in WG/IESG LC comments, IIRC, >> > so while I also prefer style B, maybe someone want to review the >> > earlier feedback to see if there is anything more than editorial here. >> > >> > I'm still behind schedule to print and re-read the entire document from >> > start to finish, but maybe if the changes below can be applied, I have >> > an excuse for a couple of more days. >> > >> > /Simon >> > >> > >> > tor 2026-04-02 klockan 12:54 +0200 skrev Jan Mojzis: >> >> Hi, >> >> >> >> (5b) >> >> I agree with Markus, >> >> it looks much better in this form, without the ASCII representation. >> >> >> >> Jan >> >> >> >> >> >> >> >>> On 1. 4. 2026, at 18:12, Markus Friedl <[email protected]> wrote: >> >>> >> >>> Hi, sorry for the delay: >> >>> >> >>> 1) OK for the updated title. >> >>> 2) Keywords: "(hybrid) key exchange" >> >>> 3) I prefer citations as in B >> >>> 4) I like and prefer the new wording >> >>> 5a) "test-vectors" is the correct choice >> >>> 5b) See below >> >>> 6) OK for the text, no findings. >> >>> >> >>> As to (5b), I think it's better to drop the last column (ASCII) >> >>> and keep the hexadecimal values. The ASCII representation >> >>> does not add any value. >> >>> >> >>> OLD: >> >>> >> >>> client public key sntrup761: >> >>> 0000: 5d b3 a9 d3 93 30 31 76 0e 8a f5 87 f7 b2 8c 4f >> >>> ]....01v.......O >> >>> 0016: 97 a1 74 0e 6b 6f cf 1a d9 d9 99 8a 32 a5 61 e5 >> >>> ..t.ko......2.a. >> >>> >> >>> NEW: >> >>> >> >>> client public key sntrup761: >> >>> 0000: 5d b3 a9 d3 93 30 31 76 0e 8a f5 87 f7 b2 8c 4f >> >>> 0016: 97 a1 74 0e 6b 6f cf 1a d9 d9 99 8a 32 a5 61 e5 >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> -m >> >>> >> >>>> Am 30.03.2026 um 17:52 schrieb Sarah Tarrant >> >>>> <[email protected]>: >> >>>> >> >>>> All - We are awaiting answers to the questions that were sent out >> >>>> at the beginning of AUTH48: >> >>>> >> >>>>> 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_languag >> >>>>> e> >> >>>>> 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. >> >>>>> --> >> >>>> >> >>>> >> >>>> Sincerely, >> >>>> Sarah Tarrant >> >>>> RFC Production Center >> >>>> >> >>>>> On Mar 30, 2026, at 10:37 AM, Markus Friedl <[email protected]> >> >>>>> wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>>> Am 09.03.2026 um 16:00 schrieb Sarah Tarrant >> >>>>>> <[email protected]>: >> >>>>>> >> >>>>>> 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", DOI 10.5281/zenodo.13983972, October >> >>>>>> 2020, >> >>>>>> <https://doi.org/10.5281/zenodo.13983972>. >> >>>>>> >> >>>>>> <https://ntruprime.cr.yp.to/nist/ntruprime-20201007.pdf>. >> >>>>>> >> >>>>>> Please let us know if this is acceptable. >> >>>>> >> >>>>> Thanks, I think the there should be no full-stop after the >> >>>>> first URL, and the >> >>>>> ordering should be like in the earlier email: >> >>>>> >> >>>>> 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>. >> >>>>> >> >>>> >> >>> >> >>
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
