Does broadcast *server* mode still exist?

[James Browning]

On Sun, Aug 18, 2019 at 5:27 PM Hal Murray via devel <devel at ntpsec.org>
wrote:

>
> esr at thyrsus.com said:
> > That's covered. In the page on NTPsec changes:
> > * Broadcast- and multicast modes, which are impossible to
> >   secure, have been removed.
>
> I was looking for more information.  Why can't we secure it?
>
> What's wrong with using a public/private key to sign each broadcast packet?
>
> (It's hard to prove a negative like "impossible to secure", but maybe
> security
> geeks know things that I don't.)
>
> -----------
>
> I'm not sad to see broadcast modes gone.  It was tangled up with a state
> machine which I never really understood.
>
> In general, broadcasting is evil.  That's another reason to drop it.
>
> But there might be good reasons to use it.  Maybe simplifying the config
> file for some deployment applications?
>

Assuming a can opener, If the packets were signed with a private key it
might reasonably be possible to verify that signature with the *known*
associated public key. However, there is not reasonable protection against
delayed or replayed packets. OTOH broadcast NTP service solicitations
should reasonably be securable via NTS if the FQDN is returned in addition
to the network address. However, in such an instance it might be
easier/better to use the pool directive with a multicast DNS SRV resolver.
All of this is shallow thinking and I am sure I missed much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190818/25bc32e8/attachment.htm>