<div dir="ltr"><div dir="ltr">On Sun, Aug 18, 2019 at 5:27 PM Hal Murray via devel <<a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<a href="mailto:esr@thyrsus.com" target="_blank">esr@thyrsus.com</a> said:<br>
> That's covered. In the page on NTPsec changes:<br>
> * Broadcast- and multicast modes, which are impossible to<br>
>   secure, have been removed. <br>
<br>
I was looking for more information.  Why can't we secure it?<br>
<br>
What's wrong with using a public/private key to sign each broadcast packet?<br>
<br>
(It's hard to prove a negative like "impossible to secure", but maybe security <br>
geeks know things that I don't.)<br>
<br>
-----------<br>
<br>
I'm not sad to see broadcast modes gone.  It was tangled up with a state machine which I never really understood.<br>
<br>
In general, broadcasting is evil.  That's another reason to drop it.<br>
<br>
But there might be good reasons to use it.  Maybe simplifying the config file for some deployment applications?<br></blockquote><div><br></div><div>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.</div></div></div>