| Re: [chrony-users] Chronyd does not use non-nts servers |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
- To: chrony-users@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-users] Chronyd does not use non-nts servers
- From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
- Date: Thu, 29 Oct 2020 17:21:08 +0100
- Authentication-results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@xxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603988479; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8B2rj246ma6yiYvVUe6/cfrOxU3n78SaHBYuYMuXvBQ=; b=Np3hfAqvUI6Pp9wAO9CBbOA2gHeBcNxNMk6PubEcMPJg0+Si6SDaSH9KYXDDhHKz9gkXPb vcCDodzf3t2nO8z6bQI620tamSiCaCFtDxJgjkirYXE0THCWvEEYjxQSrsC4Nsii/cU/Jj m+H+jR6zoRtxNjKZAU09xMIc+2tq1Bo=
On Thu, Oct 29, 2020 at 03:58:12PM +0100, Christian Ehrhardt wrote:
> I actually like to consider if "nts nocerttimecheck 1" would be a
> reasonable default config for what we ship in distros.
> People that can rely on their environment could further opt-in by dropping
> the nocerttimecheck.
> People with bad systems/clocks are not totally broken as the initial sync
> would be ok at least. And once the time is good after the first run it
> would be ok and use NTS.
>
> To me it seems that "nts" is more safe than "nts nocerttimecheck 1".
> But "nts nocerttimecheck 1" is much better than "".
I agree, but I'm no expert on TLS or certificates.
If you wanted to use nocerttimecheck by default, I'd suggest to
consider also adding the nosystemcert and ntstrustedcerts directives
to select only a minimal set of certificates needed to work with the
default servers to avoid attacks using an unrelated compromised key.
> The question to me is if there are general drawbacks that I'd overlook when
> we generally would enable this.
> E.g. much higher cpu consumptions which if you scale plenty of cloud guests
> would be a problem.
You mean additional load on NTP servers? NTS-KE is the problematic
part. It's difficult to estimate how much sessions per second might be
needed. In my tests a fast single CPU core can do about 1000 sessions
per second (using a ed25519 key). It scales well to multiple cores and
servers.
Most clients should be able to save and reload keys+cookies. They
won't generate much of NTS-KE load unless their packets are getting
lost in Internet (some major network operators are known to block/rate
limit long NTP packets). If this was a significant problem, we can add
an option to enable cookie reuse, losing some privacy benefits.
However, machines that are frequently created/reinstalled from
scratch wouldn't be able to reuse the keys/cookies and could generate
significant load if their number was large.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.