Cert pinning

[Gary E. Miller]

Yo Richard!

On Thu, 28 Mar 2019 17:54:04 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> On 3/28/19 5:35 PM, Gary E. Miller via devel wrote:
> > Yo Richard!
> > 
> > On Thu, 28 Mar 2019 17:00:51 -0500
> > Richard Laager via devel <devel at ntpsec.org> wrote:
> >   
> >> On 3/28/19 3:01 PM, Gary E. Miller via devel wrote:  
> >>> server nts3-e.ostfalia.de:443 nts noval pin
> >>> 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18    
> >>
> >> I think the "pin" option should take (as an argument or in its
> >> name), the hash algorithm being used (presumably SHA-256 here, but
> >> it could change in the future). For example, HPKP uses pin-sha256
> >> as the name.  
> > 
> > If we are going to design the option, then it needs to algorithm,
> > and what it is pinned to.  You can pin to the provided cert, the
> > cert that signed the cert, the full chain of the cert, the root
> > that signed the cert, or just the public key of the cert.  
> 
> I think public key (as opposed to certificate) pinning is the common
> approach these days. The application simply requires that one of the
> public keys in the chain match the pinned public key. The user can
> decide if they want to pin the server public key, the intermediate CA,
> or the root CA.

Tell that to Matt Selsky.  He changed the ntpsec.org pinning to
be that if the signing cert.  Updating the pins every 90 days
was a PITA.

> That said, we need to think carefully about the intended interactions
> between pinning and validation (or lack thereof with noval).

Not need to think about it.  Lot's of prior art.  Just use that.
The DANE is well thought out.

> I think that you in particular are using pinning to avoid adding the
> server operator's private root certificate that you don't trust.

Today, yes.  And no way I'll ever add a provate root cert I don't
have enourmous trust in.

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

Uh, no.  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.

? I think you're intending for the latter.

Uh, no.  Many combination are possible, they all have a use case.

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

And, please note, I have not brought up cert times.  That is yet
another lengthy discussion.  Let us do that later and not confuse
this discussion.

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

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

smtp, https, XMPP, etc. have all gone down this road before, let us not
try to reinvent a wheel that already works very well.

And, let's do the cert time discussion later...

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/20190328/4c83bf6a/attachment.bin>