The key-manahement argument

[Richard Laager]

On 1/20/19 1:34 PM, Achim Gratz via devel wrote:
> Richard Laager via devel writes:
>>>> * Is NTPsec going to initiate NTS by default? 
>>
>>> Probably not.  That would break backward compatibility.
> 
> The draft RFC states that falling back to plain NTP from NTS is not
> allowed without explicit user interaction.

Nowhere have I proposed downgrading from NTS to plain NTP. In fact, I
said the exact opposite. If NTS is working, a downgrade is prohibited.

If the user has asked for NTS, obviously a downgrade should not be
allowed. But if the user has not asked for NTS, they're going to get
plain NTP anyway. There is no security harm in trying to upgrade it.
Other than potentially the fact that it's fragile, as Hal pointed out.

> the RFC is pretty clear in that the NTS-KE can give out associations
> for multiple NTS servers (4.1.7), which was likely introduced to support
> pool-like arrangements.

I see where I was wrong and how that would work now. So the pool could
speak NTS-KE on central servers and refer clients to NTP server using
NTS referrals.

Thanks to you and James for setting me straight.

James covered this too, so I'll respond to that here too:

On 1/19/19 6:24 PM, James Browning via devel wrote:
> pool 2.ntpsec.nts.pool.ntp.org +nts

I would think this would be "ntpsec.nts.pool.ntp.org +nts". There's no
need for a "2." on a pool directive.

> 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.

I'm not seeing the need for the CNAMEs. The pool could return multiple
A/AAAA entries directly.

> 3. NTPsec connects to each of NTS-ke servers

A key thing here being that these are servers operated by the pool, not
random volunteers, so they have a valid certificate for the pool
hostname (possibly by a wildcard certificate).

> 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

-- 
Richard