Re: [chrony-users] NTS fallback?

[kross@xxxxxxxxxxxxxxxxxxxx]

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
>
>
> kross@xxxxxxxxxxxxxxxxxxxx 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 <christoph.schittel@xxxxxxxxx>:
>  > > > 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- 
> request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
>  > > For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with 
> "help" in the subject.
>  > > Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.
>  >


--
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.