The key-manahement argument

[Richard Laager]

On 1/21/19 11:14 AM, Achim Gratz via devel wrote:
>> 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.
>
> But an opportunistic NTS startup does allow an attacker to force a
> downgrade to plain NTP by blocking the TCP connection and allowing UDP
> through.  I'll grant you it only works if NTS-KE and NTS server reside
> at the same address and at startup, but the user can't really tell if
> the server just doesn't support NTS or if the connection gets hijacked.
> So I'd rule out an opportunistic scheme for that reason.

Opportunistic NTS is only applicable when the administrator has not
specified NTS. In that scenario, if ntpd doesn't do opportunistic NTS,
then it's going to do plain NTP. How is the risk that a MITM could
downgrade you only at startup worse than always being "downgraded"
because you didn't even try to upgrade to NTS?

I'm not sure how large the NTPsec install base is, but pretend for a
second that there was no fork (or that NTP Classic implements NTS and
matches NTPsec's behavior on opportunistic NTS). There is a huge install
base. If ntpd does opportunistic NTS, then as both sides of an
association upgrade, NTS will Just Work. That's going to result in quite
a bit of NTS happening.

Granted, a _lot_ of that install base is using the pool.

-- 
Richard