Cert pinning

[Gary E. Miller]

Yo Richard!

On Sun, 31 Mar 2019 18:33:54 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

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

Or to one of the public keys in the chain.  These are all DANE options.

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

Yes, suggested, and shown prior art, and code, to do so.

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

Which ignores all the other ways a cert can fail: before date, after
date, hostname mismatch, etc.  We need to be able to override all of
them at some pint.


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

I was deliberately vague there, so we can't be on the same page.

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

Sigh, we went over this before.  You can pin to the root CA, one
of the chain CAs, or the final cert.  Ditto you can pin to the public
key of any, or all, of these.  As Matt Salksy  mentioned in this thread
earlier, he pins the ntpsec.org DANE to the chain cert which only changes
every 5 years or so.

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

Yes, that is a good thing, to be encouraged, for the reasons stated
above.

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

Many other options.  So I'll not swing at that straw man.

> 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

Say what?  You just said pin to the intermediate cert, not to the any key.
How did the key get in here?

> and has a valid signature corresponding to the
> pinned intermediate CA's public key. That is how we know the pin has
> matched.

You just moved from pinning to a cert to pinning to a key.  Does not
compute.

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

Yes, that is how root certs work.  You also need to validate the not
before date, not after date and FQDN.  Stop trying to make this
simple.  DANE is a long RFC for good reasons.

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

Agreed.  Hal already said that was on his long term todo list, so that
is a distraction here...

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

For this one case, at one point in time.  I was using noval to connect
to this host long before I was told I could get a copy of the cert.

Other participants in the hackathin were on the private IETF LAN, and
thus could not get an FQDN, so they needed noval as well.


> 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

Maybe, maybe not.  Umtil we specify the defects being avoided this is
too simplistic.

> while this would fail (because the root still isn't trusted):
> server ... nts pin=THE_ROOT_PUBLIC_KEY_HASH

Maybe, maybe not, that is what we are debating.  If everything
else passes (dates, FQDN, etc.) then I would like the last to also
work.  With the noval option for the case where something else is
failing.

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

Well, that is a pretty important clarification to have at the end.

But somehow I read you as not liking that in your last example above.

I suspect before we are done we need to lay out the more than a dozen
cases and decide what we think they should all do.  I have been
avoiding doing so in order not to overload Hal.

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/20190331/a76c1e79/attachment.bin>