Thanks for the review. I will address these comments promptly, but it might not be until next week.
Russ > On Mar 25, 2019, at 5:08 PM, Yoav Nir <[email protected]> wrote: > > 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 > <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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
