Re: [Ntp] NTS pool support

["Patrik Fältström " <[e-mail]>]

On 22 Jul 2019, at 8:25, Ask Bjørn Hansen wrote:

>> On Jul 21, 2019, at 3:15 PM, Hal Murray <[e-mail]> wrote:
>>
>>> Here's my naive suggestion on how to handle NTS pools.
>>
>> I think you have to be very careful about what you mean by "pool".  In most
>> NTP discussions, "the pool" usually means pool.ntp.org, a large collection of
>> NTP servers run by volunteers.  Trust and secure don't make sense with that
>> type of operation.  There is no point in using NTS.
>
> I don’t think that’s true. Implemented right a client could know for sure who it’s talking to.

I must think quite a bit on this proposal, and I completely trust you guys doing NTS right, BUT, my view is:

1. Keep the pool-mechanisms as separate from "NTS-server" mechanisms -- i.e. I am always nervous of feature creep in protocols.

2. We must trust the DNS anyways, and whether one sign and/or validate DNS is a question orthogonal to this discussion. The use of DNSSEC is today *strongly* encouraged, and if you choose to still not do it, you are to some degree toast. But that is a choice.

3. We can not design NTS to be robust if people have chosen other insecure things regarding their environment. There must be a known context within which we design the NTS (and NTS-pool) related issues. We can for example not solve routing problems, and we can not solve DNS security issues, or issues with fake SSIDs (evil hot spots), fake bootp or neighbor discovery messages, or other things.

4. What we *can* do is to make a robust protocol that to some degree for example withstand MITM attacks, but, to get complete protection one must do validation of DNSSEC signed responses, one must have RPKI "strict" for the IP addresses, one must... etc, and that list which is "basic" for todays Internet start to be quite long :-) NTS should fit in that echo system so that other people say "you should use NTS (+roughtime for bootstrap) or else..." i.e. I do not want DNS or HTTP or BGP people start to expand their protocols "just because people might only use NTP and not NTS because NTS is so hard". ;-)

Given that context, on a quick read, I sort of like the below, but think we can do slightly better IF we rely on DNS a bit more. I.e. we can do something that is easy for everyone, and get a good pool structure, and then we say "if the zone is signed, and validation takes place, THEN the whole thing is...".

But I must think a bit more.

   Patrik

> With short lived certificates, the client could know that the pool system had validated the monitoring data within X hours/days. It could be a solution to having a client know if the server had been removed from the pool system.
>
> One suggestion for this that’d work, I think, with Christer’s SRV suggestion would be (as I suggested a few days ago) to configure the client with a certificate authority that’s managed by the pool system and only trust this CA for servers returned by that specific pool DNS name.  (Basically Christer’s TLSA suggestion, but for clients not doing DNSSEC they could configure the CA in their configuration).
>
> The servers participating in the pool would (automatically) request/get an updated certificate every so many days.
>
> This would be an improvement over the current system in that the client will know for sure who it’s talking to and that the server it’s talking to is part of the pool.
>
> (DNSSEC would still be an improvement in that the client would know the particular DNS response was generated by the pool system and not “improvised”, but it wouldn’t be required for NTS to work).
>
> (Another version, as per what Ragner Sundblad suggested last year in https://tools.ietf.org/html/draft-dansarie-nts-00#section-8 <https://tools.ietf.org/html/draft-dansarie-nts-00#section-8> would be to require the pool system to run the NTSKE servers and have another key exchange method with the servers. I think that proposal underestimated the number of distinct clients using the big public pool-like systems (NTP Pool Project and NIST, as two of them).  Christer’s proposal would support “load balancing” the NTPKE work better).
>
>
>
> Ask
>
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp