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]
