Incompatible changes, security, and good practice
Gary E. Miller
gem at rellim.com
Thu Oct 6 23:52:59 UTC 2016
On Thu, 6 Oct 2016 19:31:45 -0400
Daniel Franke <dfoxfranke at gmail.com> wrote:
> On 10/6/16, Gary E. Miller <gem at rellim.com> wrote:
> > This is NOT an all or nothing decision. There are other ways to
> > mitigate this problem that do not involve major silent breakage.
> You've argued this a few times, but you still haven't specified what
> you have in mind.
Well, actually, I have, many times, I just got tired of no active
> I think you mentioned that you'd be happy with just changing "peer" to
> be a synonym for "server", which basically amounts to desupporting
> symmetric active mode and changing those systems to behave as ordinary
Ah, so you were listening. This change painlessly upgrades less
secure configuration to more secure configuration. It breaks nothing.
Maybe it should be coupled with an INFO log for anyone paying
> I could make a similar change to the way symmetric passive mode works:
> when a host gets a symmetric active mode request, immediately reply
> with a symmetric passive response, but *don't* set up a new
> association. Basically, respond in the same way it would respond to a
> client-mode packet, just with the mode field in the response changed
> from 4 to 2.
I don't understand the protocol, but easy enough to test.
My goal would be to not break old clients, and if NTPsec can improve
their security then great.
> So, if you update the passive side, symmetric active peers keep
> working. The passive side will no longer sync to the active side, but
> the active side will keep syncing to the passive side. If you update
> the active side, it switches to just being a client of the passive
> side, and therefore continues syncing to it.
I can't say I understand all that, but I'd love to test it.
> This still ends up being a silent behavior change, because passive
> peers silently stop syncing to the active peers. But it achieves
> security, and breaks fewer things.
Easy to make it less silent, just add some logging. Just like an EULA,
98% will ignore it, but the few clueful get the message and work
for positive change.
I expect too soon to know what it might break, but I'm game to try
anything less intrusive than the current solution.
I suspect there may be some fun issues with how this works with crypto,
but that way out of my knowledge space. let's try it and see what
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem at rellim.com Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 473 bytes
Desc: OpenPGP digital signature
More information about the devel