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@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
