Hi Russ, We have added the expansion for “PSK” back into the Introduction.
Current: Second, the server can be authenticated by demonstrating that it possesses a pre-shared key (PSK) that was established by a previous handshake. 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) Additionally, your approval has been noted. We have now received all necessary approvals and consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9973 As this document is part of Cluster C430, you may track the progress of all documents in this cluster through AUTH48 at: https://www.rfc-editor.org/auth48/C430 Note: This document normatively references RFC-to-be 9846, so it will be published at the same time as or after that document. Please let us know if you have any questions. Thank you, Alanna Paloma RFC Production Center > On Apr 7, 2026, at 10:38 AM, Russ Housley <[email protected]> wrote: > > 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]
