On 1/19/19 5:28 PM, James Browning via devel wrote: > On Sat, Jan 19, 2019, 2:50 PM Richard Laager via devel <[email protected] > wrote: >> >> neither is set: >> >> For a pool, behave as "nonts" (because the common pool case is a public >> pool with volunteer servers that will not be able to present a valid >> certificate for the pool). > > Actually, I think I came up with a way to NTS enable the pool. Ask > would have to create an nts subdomain with a wildcard certificate. > FQDNs beginning with a number (ie 2.) return a quartet (or octet in > the case of 2.) of CNAMEs for number-letter beginning FQDNs (ie 2g.). > The number-letter host(s) are NTS-KE server(s) that negotiate for > criteria matching a pseudo-random host in a database as > *.nts.pool.ntp.org.
I'm not fully understanding this proposal. Could you expand on the examples a bit more. What would the config entry/entries look like, exactly what would those resolve to, and if CNAMEs, what would those resolve to? My thought about how to enable NTS for the pool would involve requiring a SRV record lookup for NTS-KE. Then *.pool.ntp.org (or *.nts.pool.ntp.org as you suggested) could send NTS-KE to a different set of NTS-KE servers than the A/AAAA records on the same names used for NTP. The NTS-KE servers would have to share NTS master keys (and cookie formats!) with volunteer NTP servers. Also, this would put a lot of load on the NTS-KE servers. All of this makes my idea seem unlikely. -- Richard _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
