Cert pinning

[Richard Laager]

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

-------------- 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/20190331/85cb7c6e/attachment-0001.bin>