Let me try this again, as one standalone post, updated with the latest information, including that we already have a documented "ca" option which just needs implementation.
1) I agree that "noval" is useful for _debugging_. For now, and probably indefinitely, it should stay. 2) Since "noval" disables the security, using "noval" means one is essentially falling back to non-NTS. Therefore, "noval" doesn't make any sense for long-term production use. A user contemplating using "noval" indefinitely in production should either fix the validation so NTS is actually providing some security benefit, or just use plain NTP if they don't care about the security benefits of NTS. 3) Right now, you (Gary) are trying to connect to some server, which is failing because it uses a private root CA, which you are (quite reasonably) unwilling to trust system-wide. Once the "ca" option is implemented, you can use that option for that particular association, and you will no longer need "noval" for that particular association. 4) Implementing certificate pinning would be a "nice to have" feature that can increase security above and beyond normal certificate validation. 4A) The pins could come from manual configuration and/or DANE, depending on what someone is willing to implement in ntpd. Those somewhat cover different use cases. Manual configuration allows the administrator of the client to manually tighten the requirements. DANE allows the server operator to request (via DNS records) that clients automatically tighten the requirements. There is overlap where the client and server administrators are the same person, in which case either option may meet their needs (if DNSSEC is available so DANE works securely). 4B) If ntpd implements pinning, it should be in addition to the usual certificate validation, not instead of. This may be controversial with others. Let me explain my thoughts, so we can determine if/where the disagreement lies: - If validation is succeeding, there is no problem. - If validation is failing due to a private root, add it system wide or use the "ca" option to fix the validation. - If validation is failing because the hostname doesn't match, something is configured wrong on either the server or client. Fix that. - If validation is failing because the chain is broken, fix that on the server. - If validation is failing due to legitimate time issues, fix that on the server or with the CA (which is presumably private, because a public CA certainly should have their clocks set correctly). - If validation is failing due to bootstrapping time issues, that's a separate discussion we've already covered, expanding on the guidance from the NTS draft. That affects servers with certificates from public CAs, too. This is probably the most controversial one: - If the server has a self-signed certificate, they should switch to either a certificate from a public CA (e.g. Let's Encrypt) or setup a private CA. In a world where "real" certificates are readily and freely available, I see no reason that security-minded folks (who are doing extra work to opt-in to NTS!) can't use a real certificate or setup a private CA. Am I missing other scenarios where validation fails? If so, please be specific. -- Richard
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
