Hello Christoph,
The question to me is why you'd want to use NTS in the first place for
the use cases you hint at?
NTS gives certain security guarantees (as far as that can be done).
Saying one wants to have a silent fallback to just ignore NTS when it
doesn't work suggests to me that the point isn't about actual security
at all, in the sense of what NTS is intended to provide. Rather, it
sounds like NTS is being used just for the sake of it, because it's
there, because it sounds nice, because it gives a warm, fuzzy feeling, ...
It's like having a highly secure, reinforced door with all kinds of
locks and security mechanisms as your front door, and then hanging the
keys and security codes on the door knob. Or leaving the porch door
right next to the locked front door wide open.
Other protocols such as HTTPS are going to great lengths to avoid just
this kind of scenario, and to reduce the options to bypass security
mechanisms.
In my view, the existing and appropriate fallback is to let the NTP
client operator _explicitly_ decide not to use NTS for servers that
don't support it, or where its operation is unreliable due to a number
of potential factors. Otherwise, it gives a false sense of security,
when there actually isn't any security at all.
Or the already existing configuration options, which you cite as well,
of combining unprotected and NTS-protected sources in various way. E.g.,
get time from a high-quality/accurate, but possibly unprotected source,
and use NTS-protected sources for sanity-checking. The existing
configuration options should cover a wide range of scenarios.
Kind regards,
Joachim
On 08.08.25 10:28, Christoph Schittel wrote:
Thank you Joachim,
I see, this makes perfect sense!
Nonetheless I think there are setups where it would be helpful to have
this fallback. With "authselectmode" it can be decided if
unauthenticated servers will be used and how.
There could be a timeout option "authfallback" with an integer parameter
giving the number of tries after which chrony should use unauthenticated
queries when authentications fails. Authentication request should
nevertheless be tried in parallel. An parameter of zero would be the
default behavior - no fallback.
regards,
Christoph
[email protected] schrieb am Donnerstag, 7. August 2025
23:20:42 (+02:00):
> Hello Christoph,
> > The idea is to prevent so-called "bidding down" attacks. I.e.,
instead of trying to attack the protection mechanisms, the idea of such
stracks is to get the client to simply not use them. Not falling back to
NTP without NTS when NTS fails is a way to avoid that, i.e., is fully
intended.
> > Kind regards
> > Joachim
> > 07.08.2025 22:22:03 Christoph Schittel <[email protected]>:
> > > Hello!
> > > > When a server directive is specified with "nts" this server is
only queried when nts service is working on this server.
> > Is there no fallback to unauthenicated time transfer for servers
with nts option given? Like when nts services are failing or temporarily
disabled on the server.
> > > > I know about "authselectmode", but this is only working between
different queried servers, authenticated and not authenticated.
> > > > regards
> > Christoph
> > > > -- > > To unsubscribe email chrony-users-
[email protected] with "unsubscribe" in the subject.
> > For help email [email protected] with
"help" in the subject.
> > Trouble? Email [email protected].
>
--
To unsubscribe email [email protected]
with "unsubscribe" in the subject.
For help email [email protected]
with "help" in the subject.
Trouble? Email [email protected].
