> Knowing the (rough) broadcast delay from sender to receiver is sufficient.
You're citing things without understanding them.
First, you've mangled that summarisation, knowing an upper bound on delay is not the same as knowing delay.
Second, that's true for using TESLA for data streams. Not for when the timing of the stream itself is the information content. That bound on delay translates into a spatial zone of spoofability. The RFC refers to the content being timely (not stale) and authenticated, but timely is not the same as using the timing itself as data.
If you wish to know how well Galileo+TESLA work, see perhaps:
> Global Navigation Satellite Systems (GNSS) are critical for infrastructure like energy, telecommunications, and transportation, making their accuracy vital. To enhance security especially against location spoofing, in 2024, the Galileo GNSS system adopted the Timed Efficient Stream Loss-Tolerant Authentication (TESLA) protocol, for Navigation Message Authentication (NMA). However, past and present TESLA versions have lacked formal verification due to challenges in modelling their streaming and timing mechanisms. Given the importance of formal verification in uncovering protocol flaws, this work addresses that gap by formally modelling and verifying the latest TESLA protocol used in Galileo; we verify Galileo’s TESLA protocol in the well-known Tamarin prover. We discuss our findings and, since this is work-in-progress, we contextualise them in terms of next steps for us, as well as for future Navigation Message Authentication protocols inside GNSS systems.
> Then, security-wise, via 8 lemmas, we show: […] timeliness of the messages: the receiver will reject messages (even when they have cryptographic integrity) if they were received outside of their validity time-interval; […] replay-related security: i.e., replay attacks are possible, but only if the acceptability time interval is not violated (i.e., messages replayed too late will be rejected). […]
* https://www.ndss-symposium.org/ndss-paper/auto-draft-620/
* https://dx.doi.org/10.14722/spacesec.2025.23009