NTS client configuration support has landed

[Richard Laager]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190202/3c2f8040/attachment.bin>