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]
