Hi Russ, Thank you for your reply. We have updated as requested.
The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9973.xml https://www.rfc-editor.org/authors/rfc9973.txt https://www.rfc-editor.org/authors/rfc9973.html https://www.rfc-editor.org/authors/rfc9973.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9973-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9973-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9973-auth48rfcdiff.html (AUTH48 changes side by side) Please review the document carefully and contact us with any further updates you may have. Note that we do not make changes once a document is published as an RFC. We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process. For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9973 Thank you, Alanna Paloma RFC Production Center > On Apr 6, 2026, at 12:50 PM, Russ Housley <[email protected]> wrote: > > Dear RFC Editor: > >> 1) <!--[rfced] FYI - We have updated the citation below from Section 2.1 to >> Section 3.1, as the document cited does not contain a Section 2.1. >> Please review. >> >> Original: >> While Grover's algorithm (described in >> Section 2.1 of [I-D.ietf-pquip-pqc-engineers]) allows a quantum >> computer to perform a brute force key search using quadratically >> fewer steps than would be required with classical computers... >> >> Current: >> While Grover's algorithm (described in >> Section 3.1 of [PQC]) allows a quantum computer to perform a brute >> force key search using quadratically fewer steps than would be >> required with classical computers... >> --> > > Nice catch. Thanks for fixing this. > >> 2) <!--[rfced] Per usage throughout the document, should the following >> instances of "confidentially" be updated to "confidentiality"? >> >> Original: >> The confidentially and authentication provided by the external PSK >> depend on whether the external PSK is used for more than one TLS 1.3 >> session and the parties that know the external PSK. >> ... >> * If the external PSK is used for a single TLS 1.3 session and it is >> known only by the client and server, then the usual TLS 1.3 >> confidentially and authentication is provided, including the >> cryptographic separation between TLS 1.3 sessions. >> ... >> * If the external PSK is used for more than one TLS 1.3 session and >> it is known only by the client and server, then the confidentially >> is limited to the client and server, but there is no cryptographic >> separation between TLS 1.3 sessions. >> ... >> * If the external PSK is used for more than one TLS 1.3 session and >> it is known by the client, server and others, then the >> confidentially is limited to the group that knows the external >> PSK, but there is no cryptographic separation between TLS 1.3 >> sessions. >> --> > > No. It should be "confidentiality". The use of "confidentially" was a typo, > and that got pasted in several places. I cannot belive no one cauth that in > the very long WG Last Call discussion. > >> 3) <!--[rfced] To improve readability, may we rephrase this sentence as >> follows? >> >> Original: >> Once an attacker has the external PSK, they can decrypt stored >> traffic if they ever gain access to a CRQC, in the same manner as a >> legitimate group member. >> >> Perhaps: >> Once an attacker has the external PSK, they can decrypt stored >> traffic in the same manner as a legitimate group member, if they ever >> gain access to a CRQC >> --> > > I prefer: > > Once an attacker has the external PSK, if they ever > gain access to a CRQC, they can decrypt stored > traffic in the same manner as a legitimate group > member. > >> 4) <!--[rfced] To reflect RFC 9849, should "Encrypted Client Hello >> extension" be updated to "'encrypted_client_hello' extension"? >> >> Original: >> The rotation of the external PSK identity or the use of >> the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate >> this risk. >> >> Perhaps: >> The rotation of the external PSK identity or the use of >> the "encrypted_client_hello" extension [I-D.ietf-tls-esni] can mitigate >> this risk. >> --> > > That draft is now RFC 9849. So, I suggest: > > The rotation of the external PSK identity or the use of the > "encrypted_client_hello" extension [RFC9849] can mitigate > this risk. > >> 5) <!--[rfced] Would you like the names listed in the second paragraph >> in the Acknowledgments section be listed in alphabetical order, like >> the first paragraph of the section? >> --> > > Yes, please. > >> 6) <!--[rfced] Both the expansion and the acronym for the following terms >> are used throughout the document. Would you like to update to using >> the expansion upon first usage and the acronym for the rest of the >> document for consistency? >> >> Cryptographically Relevant Quantum Computer (CRQC) >> pre-shared key (PSK) >> --> > > Yes, please. > >> 7) <!-- [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. >> >> In addition, please consider whether "traditional" or "traditionally" >> should be updated for clarity. This term is ambiguous, as "tradition" is >> subjective because it does not mean the same thing for everyone. >> --> > > I do not see any concerns. > > A "traditional adversary" is one that does not have access to a CRQC. So, > the use of "tradition" does not work here. Such an adversary might be > successful against traditional cryptography, but not post-quantum > cryptography (PQC). > > Thanks, > Russ > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
