Alanna: I realize that PSK is spelled out in the Abstract, but I would also like to spell it out the first time it appears in the Introduction.
OLD: PSK NEW: pre-shared key (PSK) With that minor change, I approve publication. Russ > On Apr 7, 2026, at 1:14 PM, Alanna Paloma <[email protected]> > wrote: > > 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]
