NTS client configuration support has landed

[Gary E. Miller]

Yo Richard!

On Fri, 1 Feb 2019 18:35:49 -0600
Richard Laager via devel <devel at ntpsec.org> wrote:

> FWIW, I think you've sold me on why we need "nts" separate from
> "server". There are a LOT of extra options for NTS.

13, and counting.

> On 2/1/19 4:51 PM, Gary E. Miller via devel wrote:
> > *require [address]* Require a particular NTPD server, fail if it is
> > not the NTPD sevver address returned.  Otherwise same as *ask*.  
> 
> If I specify "require 1.2.3.4" and get back 1.2.3.4:1123, does that
> fail because the port doesn't match (because the port, if not
> specified, is 123)? I'd say yes.

Works for me.  I wonder how to say that in the doc...  Then I worry
someone will want the reverse.

> You probably also need a parameter to specify a root certificate list.
> This might be for all of ntpd, rather than per association.

I prolly added that after you looked.  I came up with:

    *ca [location]* Use the file, or directory, specified by *location*
    to validate the NTS-KE server certificate.  Do not use any other CA.

I made it per NTS-KE to allow for easier testing.

> > *tls1.2* Allow TLS1.2 connection.
> > 
> > *tls1.3* Allow TLS1.3 connection.  
> 
> This does not feel scalable as new versions of TLS get created.

Yeah.  You prolly guessed I stole of lot of the options from elsewhere.
This one also bugged me.

> I'd
> suggest something like tlsminver, which specifies the minimum version
> of TLS to accept. The default is 1.2 per the draft.

Ah, where does it say 1.2 is default?

> The allowed
> values are currently 1.2 and 1.3. For an example of this, see Dovecot
> 2.3 which introduced ssl_min_protocol.

The problem is that tlsminver makes it hard to force TLS1.2 for testing.
It turns out the OpenSSL code paths for TLS1.2 and TLS1.3 are not the
same.  So testing each is important.

Maybe:

"tlsver [1.2 1.3]*

> > *tls1.2ciphers [list]*  List of TLS 1.2 ciphers to negotiate, in
> > prefered order.  
> 
> Please call this "ciphers" to match OpenSSL and other applications.

So, which of these should be just 'ciphers': tls1.2ciphers, tls1.3ciphers,
or ntpciphers?  And it has to be rediculously obvious which of the
three applies where.  All at the same time!

The OpenSSL doc makes it real hard to see which ciphers go where...

> > *tls1.3ciphers [list]*  List of TLS 1.3 ciphers to negotiate, in
> > prefered order.  TLS 1.2 and 1.3 ciphers are different and must be
> > specified separately as OpenSSL needs them separately.  
> 
> Please call this "ciphersuites" to match OpenSSL and other
> applications.

I can not find that in the OpenSSL doc:

https://www.openssl.org/docs/man1.1.1/man3/SSL_CIPHER_description.html

I'm happy to change it to something OpenSSL prefers.  I just took that
from another project to start things off.

> Also, if a future TLS 1.4 uses the same list, it will
> be weird if this has TLS 1.3 embedded in the name forever.

Like the name SSL living long past the protocol.  Yeah, needs work.

> > *ntpciphers [list]*  List of ciphers to negotiate, in prefered
> > order for the NTPD connection.  
> 
> All three of these take a "list", which is really a single string
> which happens to be colon-separated.

Good point.  Will add.

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/20190201/7eae74dd/attachment.bin>