On 2/2/19 5:16 AM, Eric S. Raymond via devel wrote: > NEVER CONFIGURE WHAT YOU CAN DISCOVER > > These are from nts.adoc: > > *tls1.2* Allow TLS1.2 connection. > > *tls1.3* Allow TLS1.3 connection. > > We don't need these because in this 'graph > > Implementations MUST NOT negotiate TLS versions earlier than 1.2, > SHOULD negotiate TLS 1.3 [RFC8446] or later when possible, and MAY > refuse to negotiate any TLS version which has been superseded by a > later supported version. > > the last normative is a MAY, not a MUST. Thus, you never need to do > anything but allow some connection at 1.2 or up even once 1.2 is > superseded. Correct[racticr is to use the highest version you have. > > We also don't need these. > > *tls1.2ciphers [list]* List of TLS 1.2 ciphers to negotiate, in prefered > order. The list is one or more cipher names, separated by colons. > > *tls1.3ciphers [list]* List of TLS 1.3 ciphers to negotiate, in prefered > order. TLS 1.2 and 1.3 ciphers are different and must be specified > separately as OpenSSL needs them separately. > > *ntpciphers [list]* List of ciphers to negotiate, in prefered order for > the NTPD connection. The server must support AEAD_AES_SIV_CMAC_256. > > The correct, conformant policy is to negitiate your best possible TLS > version, then ask your TLS implementation what its list of ciphers > for that level is, then ship that.
Your TLS library will negotiate the best TLS version. That's literally the entire point of TLS negotiation. HOWEVER, various (non-binding and) binding security standards require that you disable old TLS versions. At one time, this unquestionably made security sense, as it protected against downgrade attacks. Imagine: Alice --> Bob Alice announces, "I support SSLv3, TLS 1.0, 1.1, 1.2, and 1.3." Bob supports TLS 1.0, 1.1, and 1.2. Bob will use 1.2. That's how negotiation works. Now add Eve as a MITM (WITM?): Alice --> Eve --> Bob Alice announces, "I support SSLv3, TLS 1.0, 1.1, 1.2, and 1.3." Eve (maybe having probed Bob) changes that to "I support TLS 1.0.". Bob will use TLS 1.0. This is a downgrade attack. If your security standards require you to set a minimum TLS version (as either client or server), then you fail hard (good!) rather than having your security broken (bad!). Now, is this still necessary after RFC 7507? That's potentially debatable. If everyone implemented RFC 7507, maybe not. I'm not enough of a crypto and TLS expert to say for sure. But given that probably not everyone does implement it, and more importantly, that it is only a solution for clients not servers, I think you're still going to see security standards requiring minimum TLS versions. And most importantly, it does not matter if you or I think the binding security standard is incorrect. If a binding standard, backed by auditing and financial penalties, says that I need to configure a minimum TLS version, I need to do that. The only time I'd consider violating a binding standard is if they recommendation makes my security _worse_, or completely breaks critical communications where I have no other choice, not if it merely introduces an unnecessary config change. -- Richard _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
