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_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. >> --> > > > 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]
