Re: NTS fallback?

Hello Christoph,

The question to me is why you'd want to use NTS in the first place for=20
the use cases you hint at?

NTS gives certain security guarantees (as far as that can be done).=20
Saying one wants to have a silent fallback to just ignore NTS when it=20
doesn't work suggests to me that the point isn't about actual security=20
at all, in the sense of what NTS is intended to provide. Rather, it=20
sounds like NTS is being used just for the sake of it, because it's=20
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=20
locks and security mechanisms as your front door, and then hanging the=20
keys and security codes on the door knob. Or leaving the porch door=20
right next to the locked front door wide open.

Other protocols such as HTTPS are going to great lengths to avoid just=20
this kind of scenario, and to reduce the options to bypass security=20
mechanisms.

In my view, the existing and appropriate fallback is to let the NTP=20
client operator _explicitly_ decide not to use NTS for servers that=20
don't support it, or where its operation is unreliable due to a number=20
of potential factors. Otherwise, it gives a false sense of security,=20
when there actually isn't any security at all.

Or the already existing configuration options, which you cite as well,=20
of combining unprotected and NTS-protected sources in various way. E.g.,=
=20
get time from a high-quality/accurate, but possibly unprotected source,=20
and use NTS-protected sources for sanity-checking. The existing=20
configuration options should cover a wide range of scenarios.

Kind regards,

Joachim

On 08.08.25 10:28, Christoph Schittel wrote:
>=20
> Thank you Joachim,
>=20
> I see, this makes perfect sense!
>=20
> Nonetheless I think there are setups where it would be helpful to have=
=20
> this fallback. With "authselectmode" it can be decided if=20
> unauthenticated servers will be used and how.
>=20
> There could be a timeout option "authfallback" with an integer parameter=
=20
> giving the number of tries after which chrony should use unauthenticated=
=20
> queries when authentications fails. Authentication request should=20
> nevertheless be tried in parallel. An parameter of zero would be the=20
> default behavior - no fallback.
>=20
> regards,
> Christoph
>=20
>=20
> kross-WHuJl200arIRAJMLapdhQVaTQe2KTcn/@public.gmane.org schrieb am Donnerstag, 7. August 2025=20
> 23:20:42 (+02:00):
>=20
>  > Hello Christoph,
>  > > The idea is to prevent so-called "bidding down" attacks. I.e.,=20
> instead of trying to attack the protection mechanisms, the idea of such=
=20
> stracks is to get the client to simply not use them. Not falling back to=
=20
> NTP without NTS when NTS fails is a way to avoid that, i.e., is fully=20
> intended.
>  > > Kind regards
>  > > Joachim
>  > > 07.08.2025 22:22:03 Christoph Schittel <[email protected]=
m>:
>  > > > Hello!
>  > > > > When a server directive is specified with "nts" this server is=
=20
> only queried when nts service is working on this server.
>  > > Is there no fallback to unauthenicated time transfer for servers=20
> with nts option given? Like when nts services are failing or temporarily=
=20
> disabled on the server.
>  > > > > I know about "authselectmode", but this is only working between=
=20
> different queried servers, authenticated and not authenticated.
>  > > > > regards
>  > > Christoph
>  > > > > -- > > To unsubscribe email chrony-users-=20
> [email protected] with "unsubscribe" in the subject.
>  > > For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with=20
> "help" in the subject.
>  > > Trouble?=C2=A0 Email [email protected]
>  >


-- 
To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "help" in the subject.
Trouble?  Email [email protected]