On 2/2/19 1:59 AM, Eric S. Raymond via devel wrote: > What I *am* clear on is that we have a job to do to convince Cisco to > keep funding us. I want to impress them with quality and *speed* and that > means I am not going to go on any yak-shaving expeditions and you > shouldn't either.
Avoiding yak-shaving is one thing. Ignoring the experience of people with actual operational experience in TLS protocols is another. > Are you seriously telling me that, for example, the TLS RFCs require me to > have a switch in configuration that says "Don't accept TLS 1.3 connections?" > If that is true, I want to see a chapter and verse cite. The TLS RFCs obviously do not require this, but various other standards do (including some that are very much binding). For example, PCI DSS requires me to disable all TLS before version X, where X increases over time. In practice, at least how the auditing is implemented, this is for all daemons on the system, not just ones (e.g. Apache) involved in processing credit cards. I realize that NTS currently requires TLS 1.2 as the minimum, so we're fine at the moment. But if NTS had been spec'ed some years ago and we were having this conversation then, and you choose not to implement a TLS versioning option in ntpd, them I (the system admin) am in a world of hurt once the minimum TLS version in the PCI DSS standard is updated. Worst case, I may be forced into the perverse choice of having to disable NTS to pass the audit. (Yes, this is dumb. Welcome to audit checkbox compliance.) > I want to know why it's not fully conformant to always accept 1.2 *and* > 1.3 connections and ditch the restrictive options. In short, because at some point in the future, some binding standard will require me to disable TLS 1.2 on my existing production systems and I will not be willing (or depending on timing able) to wait for a new version of ntpd to ship from upstream and then through my distro. On 2/2/19 2:06 AM, Eric S. Raymond via devel wrote: > Can we toss out these cipher config options in favor of a mechanism > that *discovers* what the available cipher are and does the right > thing? Treat the ciphers list (and for TLS 1.3, the ciphersuites list) as an opaque string and hand it to OpenSSL. Full stop. Do not attempt to do any interpretation of it for any reason. For ntpciphers, things are a bit more complicated. I'm not sure if all the AEAD algorithms (including specifically the required AEAD_AES_SIV_CMAC_256) have OpenSSL cipher/ciphersuite names. AEAD_AES_SIV_CMAC_256 is not intended for use in TLS, so it probably doesn't. And even if they do, I'm not sure if there will be an API where you can pass them to OpenSSL. You could punt on ntpciphers for now, if you only support AEAD_AES_SIV_CMAC_256. -- Richard
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
