Cert pinning

[Richard Laager]

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.

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

I think that you in particular are using pinning to avoid adding the
server operator's private root certificate that you don't trust. So
either pinning needs to override validation, or you'll still need to
continue to specify "noval". I think you're intending for the latter.
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).

An alternative approach to meet this particular demand would be to allow
specifying a root certificate per NTS association. Then you could
specify the private root CA for this particular association, without
needing to trust it system-wide, or even ntpd-wide. The advantage of
this approach would be that you can remove "noval" and thus get the
usual validation, including checking certificate NotBefore/NotAfter times.

-- 
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/20190328/32dbd8ce/attachment.bin>