The key-manahement argument

[James Browning]

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

pool 2.ntpsec.nts.pool.ntp.org +nts

is roughly what a simple entry would look like. on startup
1. NTPsec resolves  '2.ntpsec.nts.pool.ntp.org' to eight CNAME entries
such as '2g.nts.pool.ntp.org'
2. NTPsec resolves each of the CNAME to an A or AAAA record pointing
to a pool NTS-KE server.
3. NTPsec connects to each of NTS-ke servers and sends and negotiates.
probably mostly the way you'd expect except perhaps for a 'server
negotiation' record (4.1.7) probably set to
'2.ntpsec.nts.pool.ntp.org' or '2g.ntpsec.nts.pool.ntp.org'
4. the NTS-ke server breaks down the FQDN into search parameters for a database.
5. the NTS-ke server returns NTS records including a server
negotiation containing the IP address in the search result
6. NTPsec connects to the server address returned in the previous step

as an alternative to steps 2- the pool could return FQDNs of NTS
enabled NTP servers.