The key-manahement argument

[Richard Laager]

On 1/19/19 5:28 PM, James Browning via devel wrote:
> On Sat, Jan 19, 2019, 2:50 PM Richard Laager via devel <devel at ntpsec.org 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