Incompatible changes, security, and good practice

[Gary E. Miller]

Yo Eric!

On Thu,  6 Oct 2016 17:06:29 -0400 (EDT)
esr at thyrsus.com (Eric S. Raymond) wrote:

> 1. Technical justification

> The narrow technical case for disabling unauthenticated symmetric-peer
> mode is clear.

No, for many reasons.  

a) Silently breaking existing working configurations is always bad.

b) When NTPsec can not interoperate with existingg systems (that can not 
be updated), then people will just not use NTPsec.  Only when NTPsec
has dominant market share can we just tell users to suck it.

c) There were other changes that can be done to improve the situation
that do not have the problems a) and b).  Things might be different if
there were no other options, but that is not the case.  Stop hijacking
the discussion like this is the only way to solve the problem.

> 2. Proper communication
> 
> All kinds of havoc and tsuris ensued because dfranke did not realize
> he needed to broadcast a much louder alert about this change.  As he
> later said:

No.  The commit was all the communication I needed to know something
had gone horribley wrong.

Big and grossly intrusive changes need to be made a small step at a
time.  And quickly reverted when fixable issues come tom light.
Possibly only in testing branches.


> 3. Compatibility vs. security tradeoffs.
> 
> This is one of those cases - like the proposed change in access
> defaults I posted about recently - where there are serious questions
> about how we trade off backward compatibility versus improved
> security.

Actually, I agree with the comparision of this change to the defaults
change.  I just come to totally different conclusions than you do.

The defaults change has been widely touted for years as the proper
thing to do.  Now that years have passed, and any system that could be
fixed has been fixed, it is appropriate to shoot the last straglers.

This change is exactly the opposite.  No years long consensus that
this is the right thing.  No internet wide consensus that this is
the right thing.  No years of testing to be sure the fixs works as 
intended.

> I think *everything* other than pure client mode with an ntp.conf full
> of dumb defaults is a sufficiently rarely used feature to be sacrified
> for any significant security gain.


Many facts not in evidence.  And ignoring facts in evidence.

>  I understand that some of us think
> differently because we're in the tiny minority of those who operate
> servers and tinker with ntp.conf. It is perfectly natural that we have
> a perspective exaggerating our own concerns, but the truth is that
> J. Random Linux or BSD user will never even notice any of the things
> we argue about.

ASadly, in this case, the major breakage this caused show your statement
to be incorrect.  And you continue to ignore other good options.

> If any of you have a principled position different from that, I want
> to hear about it.  If you *agree* with that position, let me hear
> that, too.  What I want is for us to arrive at a rough consensus
> so the arguments stay civilized.

This is NOT an all or nothing decision.  There are other ways to 
mitigate this problem that do not involve major silent breakage.

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/34806e43/attachment.bin>