Incompatible changes, security, and good practice

[Gary E. Miller]

Yo Daniel!

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
engagement...

> 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
> clients.

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
attention.

> 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
breaks.

RGDS
GARY
---------------------------------------------------------------------------
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
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20161006/74ba2369/attachment.bin>