Andrei Popov writes: > I support this change, willing to implement it in the Windows TLS > stack. We have thousands of customers concerned about increased > latencies due to the enablement of TLS 1.3. The services they connect > to require NIST curves and HRR is required to get TLS clients to send > appropriate key shares.
To clarify, when you say "require NIST curves", do you mean "require conformance with NIST SP 800-56A"? In other words, will another curve be allowed once it's added to NIST SP 800-56A? Maybe faster: would the short-term problem be addressed if we can convince NIST to announce that it will consider X25519 and X448 for a revision of SP 800-56A, and doesn't intend to enforce conformance of cryptographic modules with SP 800-56A until the revisions are done? Or are you saying that, independently of NIST's decisions, the services in question are for some reason specifically requiring what's typically called the "NIST curves", namely the fifteen NSA curves that NIST standardized? Or the subset of those that NIST hasn't deprecated yet? Thanks in advance for the clarification. ---D. J. Bernstein _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
