Cert pinning

[Gary E. Miller]

Yo Richard!

On Sun, 31 Mar 2019 21:57:22 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> 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.

Sad.  Seems we've been around this May Pole way too many times already...
You have nothing new to say below, and my answers are also not new.

So anyone following along can just quit reading right now.

> 1) I agree that "noval" is useful for _debugging_. For now, and
> probably indefinitely, it should stay.

Agreed.

> 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.

Agreed, sort of.  This assumes fixes that do not exist.  So "assuming
a canopener".  It also assumes that less than perfect security is no
security.  Part of the rationale for NTS is that since the cookies
change every request, then the user can not be tracked. "noval" does not
remove that feature, or some other goodness.


> 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.

Agreed, sort of.  The "ca", which is an "assumed can opener", does
not solve many very similar cases.

> 4) Implementing certificate pinning would be a "nice to have" feature
> that can increase security above and beyond normal certificate
> validation.

"nice to have", or "must have", depending on other "assumed can openers".

Personally, I'd rather have DANE type pinning before "ca".  And once
"ca" is implemented would like to do both.

> 4A) The pins could come from manual configuration and/or DANE,
> depending on what someone is willing to implement in ntpd.

Yes, this all comes down to Hal for now.

> 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).

And now your talking about features we might get in 2025.  Pretty
premature.  Way beyond Hal's current horizon.

> 4B) If ntpd implements pinning, it should be in addition to the usual
> certificate validation, not instead of.

Of course.  But completly missing the point.  Once again, DANE goes
over all of this.  The problem at hand is where "The usual certificate
validation" fails.


> This may be controversial with others. Let me explain my thoughts, so
> we can determine if/where the disagreement lies:

Not controversial, just missing key corner cases, and sometimes wrong.

> - If validation is succeeding, there is no problem.

No.  Rememeber when Comodo issued the cert "*.google.com" to bad guys?

That was partly the reson for HPKP, DANE, etc.

> - If validation is failing due to a private root, add it system wide
> or use the "ca" option to fix the validation.

Or, pinning, or just "assume a can opener".

> - If validation is failing because the hostname doesn't match,
> something is configured wrong on either the server or client. Fix
> that.

Ah, a new type of "assumed can opener'!

> - If validation is failing because the chain is broken, fix that on
> the server.

Except I'm the client, thus not possible.

> - 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).

Except I'm the client, I can't fix a bad server cert.

> - 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.

Yup, a whole 'nother rat hole.

> 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.

Says someone with a static public IP.  Not an option for private
networks, test networks, roaming servers, etc.

Not controversy, just facts.

> Am I missing other scenarios where validation fails? If so, please be
> specific.

Yes, see above.  There are more, but just getting this far (potential
features for 2025) is exhausting.  I'd rather be coding....

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190401/fc24625a/attachment.bin>