Re: [Ntp] NTP Security (was NTPv5: big picture)

[FUSTE Emmanuel <[e-mail]>]

Le 18/01/2021 à 22:15, Kurt Roeckx a écrit :
> On Mon, Jan 18, 2021 at 09:17:49PM +0100, Magnus Danielson wrote:
>> Hi,
>>
>> On 2021-01-18 17:25, Miroslav Lichvar wrote:
>>> On Mon, Jan 18, 2021 at 04:46:22PM +0100, Magnus Danielson wrote:
>>>> 6) If verified time matches that of the initial handshake request (as
>>>> updated using local time progess), then unauthenticated time in step 2
>>>> and 3 was valid, and thus the verification was valid and progress, else
>>>> fail.
>>>>
>>>> So, we see how unauthenticated time can be used to bootstrap the
>>>> handshake. Notice that this is not used to initiate node time, but only
>>>> for that handshake. Only after things is secured, you accept time as
>>>> being secured.
>>> I don't quite follow. If A was compromised at some point, how do you
>>> know you are not talking to the attacker intercepting your requests
>>> and giving you old signatures? Isn't the whole point of the validity
>>> period to prevent such attacks? If you don't know the current time,
>>> how can you validate anything that's not supposed to be trusted
>>> forever?
>>>
>> You actually do not trust the time you get initially. You validate it.
>> If your DNSSEC is invalid because of time, then the DNSSEC does not
>> validate. If your DNSSEC is invalid because false data, the DNSSEC does
>> not validate. Then, if and only if DNSSEC validate, only then you get
>> time but using the data-validated path, and only then you validate if
>> the original time and the validated time match up. If they don't, then
>> you do not trust either. If you can spoof the DNSSEC to validate, you
>> are toast anyway, if you have put your trust there.
> In case keys are compromised, an attacker can send you an invalid
> initial time. That same attacker can create DNSSEC records, which
> you're happy to validate with the wrong time. So now you think DNS
> is working properly and ask for the time again, and still get the
> wrong time.
The lying  time windows will not be very huge to continue to be valid 
for all the chain.
It will so be valid for the other configured servers and you want to 
configure multiple ones and eject bad ones the standard way.

Validating reverse DNS records is a good thing too, as the two are 
managed generally by different organization and definitively use another 
trust chain and key.
For the pool, with what I have in mind with DANE and DNSSEC, you will 
have the trust dispatched between the DNS hierarchy of the pool, the  
DNS hierarchy of each participant and a simple x509 authority operated 
by the pool and published in a DANE record.
Why not a "classic" public authority ? Mainly for the bootstrapping 
problem as you don't have to distribute the authority certificate chain 
to the clients, and on a very personal point of view because I consider 
this external "moral" authority trust model broken.

Anyway compromised machine will still be compromised and dealt as usual.

This and all  the local possible trusting possibilities options/policies 
(RTC, trusted sources like GPS/GNSS, human validation etc...) permit a 
very robust time trust model.

Emmanuel.