Re: [Ntp] [EXT] Pool and DNS

[Neta R S <[e-mail]>]

Hi David,


Just to make sure we are on the page, in Khronos standard we will refer to
NTS as a possible authentication for NTP that improves security.

If the current discussion regarding efficiency of cookie management comes
to the conclusion that this is not trivial then we should have another
draft describing Khorons with NTS.


Thanks,

Neta

On Sat, Oct 22, 2022 at 10:45 AM David Venhoek <[e-mail]> wrote:

> Although Marcus is right that there isn't a strict lifetime specified
> for NTS cookies, I think we shouldn't disregard the potential impact
> this could have in terms of load when combined with NTS. RFC8915 does
> suggest on cookies the following (although non-normatively):
>
> Servers should periodically (e.g., once daily) generate a new pair
> '(I,K)' and immediately switch to using these values for all
> newly-generated cookies. Following each such key rotation, servers
> should securely erase any previously generated keys that should now be
> expired. Servers should continue to accept any cookie generated using
> keys that they have not yet erased, even if those keys are no longer
> current. Erasing old keys provides for forward secrecy, limiting the
> scope of what old information can be stolen if a master key is somehow
> compromised. Holding on to a limited number of old keys allows clients
> to seamlessly transition from one generation to the next without
> having to perform a new NTS-KE handshake.
>
> With multi-day polling intervals, which could easily occur with
> Khronos, it is not inconceivable that the cookies will be expired each
> and every time an NTS server is queried, which would mean a NTS-KE
> exchange each and every time that server is used. Given the cost of
> those, I think we should at least discuss why this is a reasonable
> cost to incur.
>
> Kind regards,
> David
>
> On Fri, Oct 21, 2022 at 11:08 PM Neta R S <[e-mail]> wrote:
> >
> > Hi,
> >
> > Perhaps, in order to avoid the uncertainty regarding when NTPs needs to
> query the DNS, we can just say that assuming the calibration period is one
> month,
> > 250 DNS queries means an average of  about 10 DNS queries per day, which
> is usually several order of magnitude lower than the total daily number of
> DNS queries per machine.
> >
> > Regarding NTS, I will add a reference to it in the draft, where we say
> that “adding an authentication layer to Khronos will enhance its security
> guarantees and enable the detection of various spoofing and modification
> attacks.”
> >
> > Thanks,
> > Neta
> >
> > On Wed, Oct 19, 2022 at 12:58 PM Ulrich Windl <
> [e-mail]> wrote:
> >>
> >> >>> Hal Murray <[e-mail]> schrieb am 19.10.2022 um 06:42 in
> >> Nachricht
> >> <
> [e-mail]
> >:
> >>
> >> >> Around 250 DNS queries are required by Khronos to obtain a pool of
> 1000
> >> NTP
> >> >> servers, which is equal to the number of queries performed by NTPv4
> in a
> >> >> duration of 10 days (assuming a query per hour).
> >> >
> >> > Where did that "a query per hour" come from?
> >>
> >> Good question: maxpoll default is still 10, and on typical servers a
> higher
> >> number like 12 makes little sense.
> >>
> >> >
> >> > It's not wildly wrong and I don't have a better number.  But I worry
> that
> >> > somebody will assume it is a solid data point and use it in some
> future line
> >>
> >> >
> >> > of reasoning.
> >> >
> >> > ‑‑‑‑‑‑‑‑
> >> >
> >> > My reading is that pool traffic is bimodal.  ntpd makes a few DNS
> requests
> >> > on
> >> > startup then uses those servers for a long time.  sntp makes a DNS
> request
> >> > every time it is run.
> >> >
> >> > You can see that by watching the traffic on a server in the pool when
> you
> >> > disable it by setting the traffic rate to monitor‑only.  The traffic
> drops
> >>
> >> By "disabling" you mean removing it from the DNS pool, but keep it
> running?
> >>
> >> > abruptly by X%, then slowly decays.  "Slowly" is ballpark of 10% per
> day.  X
> >>
> >> >
> >> > is ballpark of 60%.  (I didn't get decent data because I only figured
> out
> >> > what
> >> > was going on after I had already messed things up.  Next time...)
> >> >
> >> > ‑‑‑‑‑‑‑‑‑‑
> >> >
> >> > The main problem with DNS and the pool is that there is currently no
> clean
> >> > way to remove a server from the pool.  If you remove it from the
> pool, the
> >> > sntp traffic will vanish since it will get removed from future DNS
> answers.
> >>
> >> > But the ntpd traffic will continue to use existing servers as long as
> ntpd
> >> > keeps running and the servers keep responding.
> >>
> >> Not quite: If the server performs worse than the rest, ntpd wil request
> >> another one, dropping the bad one.
> >> We are runníng most servers using manycast here, but the mechanism
> should be
> >> similar.
> >>
> >>
> >> >
> >> > There is no way to ask if a server is still in the pool.  If there
> was, ntpd
> >>
> >> > should check every day or week or ...  That would add more DNS
> traffic from
> >>
> >> > the long running ntpd servers.  Khronos would add much more.
> >> >
> >> > ‑‑‑‑‑‑‑‑‑‑
> >> >
> >> > The more interesting question is NTS.  The NTS‑KE step is fairly
> >> heavyweight,
> >> > much more work than a DNS lookup.
> >> >
> >> > The current parameters are 8 cookies with a lifetime of a day.  A day
> is
> >> > 86400 seconds.  That means we need to poll each server every 10800
> seconds.
> >>
> >> > With 1000 servers and M=15 (from the draft) that will take a Khronos
> poll
> >> > every (10800/1000)*15 => 162 seconds.  If Khronos runs at 10x the
> poll time
> >> of
> >> > ntpd, that's not going to work.
> >> >
> >> > We could gain a factor of 2 or 3 by dropping cookies older than a
> day.  (and
> >>
> >> > asking for several more to fill up again when we do poll a server)
> >> >
> >> > Of course, NTS doesn't work with the pool and I don't see how to fix
> that,
> >> > so this is all a wild goose chase.
> >> >
> >> >
> >> > Maybe we should be comparing Khronos with 1 or 2 trusted servers
> using NTS.
> >> >
> >> >
> >> > ‑‑
> >> > These are my opinions.  I hate spam.
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > ntp mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/ntp
> >>
> >>
> >>
> > _______________________________________________
> > ntp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ntp
>