Cert pinning

[Richard Laager]

On 3/28/19 6:06 PM, Gary E. Miller via devel wrote:
> On Thu, 28 Mar 2019 17:54:04 -0500
> Richard Laager via devel <devel at ntpsec.org> wrote:

> Updating the pins every 90 days
> was a PITA.
Yes, pinning the end certificate or end public key is going to be
annoying if those rotate frequently. That's why you probably want to pin
the intermediate or root CA public key.

>> So
>> either pinning needs to override validation, or you'll still need to
>> continue to specify "noval".
> 
> Uh, no.

I'm not sure what you're disagreeing with. In your case, validation is
currently failing for one NTS association, and you have suggested
pinning as a possible solution.

The quoted text from me above is only claiming that one of the following
must be true:
A) Pinning overrides validation. This allows you to remove "noval" from
   this association when you add the pin.
B) Pinning does not override validation. You would still need "noval"
   even with the pin.

> Pinning does not necessarily override validation, it is another
> type of validation.  Just as the pinning in the ntpsec.org records add
> to, but does not replace, other validation.

Right, that's the latter option, so we're on the same page. In that
case, normal validation is still going to fail for you, so you'd have to
keep using "noval". Or, you'd need to add that root for that
association, as discussed below.

>> That's all fine. The only tricky thing is that if you pin something
>> other than the end public key (i.e. you pin the intermediate or root
>> CA), then we _do_ need to validate the chain up to that point (albeit
>> maybe still ignoring the NotBefore/NotAfter times).
> 
> Uh, no.  Just as easy to pin to the end cert.  No need to go up.

But then you need to adjust your pin every 60-90 days when the
certificate changes. As you noted above, this is a pain. Still, you're
welcome to do that.

But unless ntpd's pinning implementation _only_ allows pinning the end
certificate or public key, then it is possible that someone could pin an
intermediate. And if someone does that, we either need to disallow the
combination of pinning and "noval" or, if they specify "noval", we need
to do enough validation to verify the pin. In other words, imagine that
you pin the intermediate CA public key and specify "noval".  We need to
verify that the end certificate corresponds to the server's key and has
a valid signature corresponding to the pinned intermediate CA's public
key. That is how we know the pin has matched.

If someone pins the root CA's public key and uses "noval", we would need
to validate the chain another step further, up to the root.

>> An alternative approach to meet this particular demand would be to
>> allow specifying a root certificate per NTS association.
> 
> Gee, I think that is called pinning.  DANE type 1.

I proposed specifying a root certificate for the association, which is
_not_ the same as pinning.

Specifying a root certificate for this particular association would make
normal validation pass, which is currently failing (for lack of that
root certificate being in your trusted root certificate list). This
would allow you to remove noval.

In other words, these would all pass:
server ... nts noval
server ... nts noval pin=THE_ROOT_PUBLIC_KEY_HASH
server ... nts root=/path/to/this/root.pem
while this would fail (because the root still isn't trusted):
server ... nts pin=THE_ROOT_PUBLIC_KEY_HASH

>> The
>> advantage of this approach would be that you can remove "noval" and
>> thus get the usual validation, including checking certificate
>> NotBefore/NotAfter times.
> 
> Ugh, please no.  Pinning is an alternative to noval, not a replacement.

I was saying you would "remove noval from the configuration line for
that NTS server", not "remove the noval option from ntpd entirely".

-- 
Richard