ntp.conf changes for NTS

[Richard Laager]

On 1/30/19 5:14 PM, Gary E. Miller via devel wrote:
> On Wed, 30 Jan 2019 16:59:28 -0600
> Richard Laager via devel <devel at ntpsec.org> wrote:
> 
>> There's another complication too. The server can send back a name or
>> an IP address. What happens if the client request contains a name and
>> the server's response contains an IP? That might be a match (e.g. if
>> the client performs an A/AAAA lookup for the name it requested, it
>> gets back that IP in the response) or it might not.
> 
> Yup.  As the proposed RFC says: OPTIONAL.

The RFC says "honoring the client's preference is OPTIONAL". I'm saying
something subtly different. What if the server honors the client's
preference, but does so by returning an IP address when the client sent
a name? I'm not sure that distinction changes the algorithm that ntpd
should implement, but I'm saying it's a case to keep in mind.

>> I think it would be useful to understand the use case(s) for the
>> client requesting a specific server vs the use case(s) for a user
>> configuring the client to request a specific server.
> 
> Isn't the client the also the user.  So both cases the same?

The user/admin is the person who configures ntpd. The client is ntpd.
The client may, for example, always (or sometimes) send a Server
Negotiation record, even if the user has not configured ntpd to request
a particular server, as discussed below.

>> Or, you can punt this all to the user by offering both choices:
>>
>> nts nts-ke.example.org
>> ^^ Accepts whatever is returned.
>>
>> nts nts-ke.example.org ask ntpd.example.org
>> ^^ Sends an explicit request. Accepts whatever is returned.
>>
>> nts nts-ke.example.org require ntpd.example.org
>> ^^ Sends an explicit request. If not mirrored back exactly, stop.
> 
> I like it.
> 
>> Here's another wrinkle. Does the first example, "nts
>> nts-ke.example.org", send a request for "nts-ke.example.org"? I think
>> it should.
> 
> Why?  In the first choice I just want any old chimer.

The client sending a Server Negotiation record is functionally very
similar to SNI, where a TLS client tells the TLS server the hostname it
is using: https://en.wikipedia.org/wiki/Server_Name_Indication

This is used with HTTPS to implement virtual hosting--having more than
one named site on the same IP address.

That same thing _may_ apply here. I'm not necessarily saying that it
does, but it's something to work through and consider.

The pool is the obvious example that comes to mind. Clients around the
world configure things like this (ignoring the questions about how you
designate "pool"):

nts us.nts.pool.ntp.org
nts ca.nts.pool.ntp.org
nts uk.nts.pool.ntp.org
nts fr.nts.pool.ntp.org
nts es.nts.pool.ntp.org
nts de.nts.pool.ntp.org

Perhaps all the NTS-KE servers are centrally located, so these all
resolve to the same IP(s). Or maybe the US and CA zones are together,
and all the European zones are together. By the client always sending a
name, the NTS-KE server can tell which subpool they are trying to access.

On the other hand, if this isn't required by the NTS spec, it'll be hard
for the pool to build their architecture this way. However, client
implementations, especially early ones, can shape the landscape or even
influence changes to the draft.

SNI itself is another dimension. Should clients use SNI on their NTS-KE
connection? I'd say probably. (The SSL library may even do that by
default.) If nothing else, like any TLS protocol, this can allow the
server to present the correct certificate, without needing a single
certificate valid for all its names.

-- 
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/20190130/1de7a81b/attachment-0001.bin>