Hi. I’ve read this draft. For the most part it seems fine, but I have a few editorial nits:
Abstract: I realize that all of section 3 is dedicated to motivation, but there really needs to be something in the abstract. Otherwise, I’m reading “authenticate with a combination of a certificate and an external pre-shared key” and wondering why you would want to use a certificate at all if you’ve managed to get a PSK between the client and the server. It needs at least something like “... in order to facilitate post-quantum forward secrecy.” at the end. Section 1 (Introduction): The Introduction contains the following text: "The TLS 1.3 ... provides two mutually exclusive forms of server authentication... Second, the server can be authenticated by demonstrating that it possesses a pre-shared key (PSK) that was established by a previous handshake.” This flatly says that all PSKs in TLS 1.3 are established by a previous handshake, and that is not true. The very next sentence calls these “resumption PSKs” and describes other PSKs called “external PSKs”. So these external PSKs are part of TLS 1.3, so the above sentence is incorrect. Section 3 (Motivation and Design Rationale): The section describes the threat to forward secrecy of a future large-scale quantum computer. Then the third paragraph says this: "In the near-term, this document describes [a] TLS 1.3 extension to protect today's communications from the future invention of a large-scale quantum computer by providing a strong external PSK as an input to the TLS 1.3 key schedule while preserving the authentication provided by the existing certificate and digital signature mechanisms.” It is not obvious to me that adding an external PSK to the TLS 1.3 key schedule protects against a large-scale quantum computer. The IPsecME draft specifying the same thing ( https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2 ) has such rationale in the Introduction, in the Security Considerations section, and in Appendix A. I think this document needs some similar text as well. Section 5 (Certificate with External PSK Extension): There’s a lot of stuff repeated here from RFC 8446: The extensions structure, including its fields The rules for a server responding with an extension (only if the ClientHello contained it) The rules for a repeated ClientHello following a HelloRetryRequest The PreSharedKeyExtension from RFC 8446. The rules for handling an extension that appears in the wrong message. I don’t believe repeating this information adds clarity. Section 7 (Security Considerations): The fifth paragraph says the following: Implementations must choose external PSKs with a secure key management technique, such as pseudo-random generation of the key or derivation of the key from one or more other secure keys. The use of inadequate pseudo-random number generators (PRNGs) to generate external PSKs can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the external PSKs and searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. [RFC4086] offers important guidance in this area. That’s fine, but I’m missing the required length of such a PSK. I believe the text should say “at least 256 randomly-generated bits” Yoav
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
