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

[Magnus Danielson <[e-mail]>]

Hi,

On 2021-01-19 10:42, Miroslav Lichvar wrote:
> On Mon, Jan 18, 2021 at 10:28:41PM +0100, Magnus Danielson wrote:
>> On 2021-01-18 22:15, Kurt Roeckx wrote:
>>> 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 DNSSEC records need to validate data-wise for the time-attack to do
>> any good. The design goal was just to enable the DNSSEC validation to
>> have good enough time for time-validation for bootstrap.
> I think the point is that you cannot bootstrap secure time out of
> nothing.
That's a conjecture, yet to be proven.
> You either do full validation using some trusted time source
> (e.g. RTC), or you don't.

RTC is not a trusted time source. I can be just as much a false-ticker
as any source you see. Do not trust the RTC to be near true time, it's
failed before and it will fail again. It's just another source of time,
it can be helpful to bootstrap things, but until validated you do not
trust it. This is really about doing a trust analysis.

We seem to accept that we can trust the authenticity of messages we get
through DNSSEC validation.

We seem to accept that we can trust the authenticity of messages we get
through X.509 and NTS validation.

Both these is data validity.

Now, to bootstrap things, we need time to achieve the DNSSEC validation,
but we say we do not trust the time until we achieved both DNSSEC and
NTS validation. So, if we acquire a time-stamp from what should be an
authentic time-source, without authentication being done, we can first
see if that checks out through the data validation part, which does not
require precise time. As we then have gone through both data validations
we then say that we trust the data of time, and using this we validate
the original time-stamp to see if that is consistent. If we can also
after the fact authenticate that time-stamp data-wise, so much better.

In this process we only assumed that the original timestamp was valid
durign the data-validation phase, and we already stated that we trust
the data validation part, and later test that assumption.

Now, regardless of which time-source led you astray, on the network or
local as the RTC, you must have a way to get away from that. If you have
local time source which pass the test of being valid, then it can be
used to speed things up, but whenever you put too high trust in
something that may lie to you, you end up in a dead-lock situation.
Treat the RTC as a read-cache. It may be valid and help you, but that's
about that.

The trick I used was that I did not trust any time, but I did trust the
data. If the initial time (really regardless where you get it) does not
make data validate, this could be because either the time or the data is
incorrect, or indeed both but not consistent. If we manage to get
through the trust loop of the data (potentially lying with the time to
make the DNSSEC validation check out even if it should be invalid), we
have yet not proved something. Now, then the independent data check of
the X.509 NTS path validate the data of the timing, again. Using DANE we
can provide a hand-off between DNSSEC and X.509 path that also needs to
be correct and valid, and again more data-trust that needs to be there.
Only as we built this data-trust and combine that we attain a time-stamp
we trust in data, and then we use that to check the validity of the
original time given. If consistent within some reasonable time (and here
we need to compensate for elapsed time naturally), and the process took
reasonable time, the trusted time we got helps in the end.

Now, this is jumping a bunch of loops in a strange way. Notice that the
time taken initial is not set as node time at all, it's just a timestamp
we use for the other processing as an assumed correct time to see if it
all checks out. If you want to be really careful you run the process
again but now with the trusted time, but since you already checked the
original first time was consistent with what came out validated, it ends
up being the same thing.

Then, you should do this to all your time-sources and do the normal
validation of trust in time that way too. But, if you do your tricks
properly, you can indeed pull your bunny out of an empty hat.

If someone compromise both the DNSSEC and X.509 path, it's game over. We
are not alone in that fight, but rather we use the same tools and their
development further to also acquire some confidence in the time we get.

Throughout the discussion, the ability to validate the root certificates
for DNSSEC and X.509 is assumed. Those public keys needs to be updated
regular enough. Failure to validate would indicate that those keys could
be out of date.

>  It doesn't matter if multiple systems are
> involved and their data seem consistent with each other.
>
> Even if we assume the attacker didn't manipulate the DNS(SEC) records,
> there is a possibility the name or address is no longer under the
> control of the original owner when those records were valid. In the
> pool that happens frequently.
>
This comes into how we disseminate the trust in particular boxes. That's
a separate issue, albeit we should also talk about that. There is those
I trust more over others. My choices there will not be the same as the
next guy. For NTP pool that much more an issue than specific known
servers. I aimed to solve the problem of how to bootstrap getting time
to a server we assume to be trusted in the first place, but we might not
trust that we get all the right pieces from what looks to be it. I think
the sub-problem is solved, the other pieces is outside of that scope.

Do not overly trust your RTC.

Cheers,
Magnus