The key-manahement argument

[Achim Gratz]

Richard Laager via devel writes:
> 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.

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.

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

They might still do that for redundancy or load balancing.  But yes, not
strictly needed with a proper NTS-KE DNS setup.  The way the pool works
such an NTS-KE would also either want to keep some state around for each
client in order to not give out the same server twice or (more likely)
the NTS client code would need to take the possibility into account and
drop the association and ask again if it gets a duplicate server.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables