Incompatible changes, security, and good practice

[Eric S. Raymond]

Gary E. Miller <gem at rellim.com>:
> 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.

You've changed the subject.  Your objections here jump ahead to point
3, the policy question about compatibility/security tradeoffs.  The
sole issue under point 1 is whether Daniel's assessment of high threat
level with no real benefits is correct.

I expect and want you to be in the policy argument, but to do it
right.  Confusing these different kinds of issues is not doing it
right.

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

Evidently it wasn't, because you mis-identified the breaking commit.
You thought it was my TESTFRAME removal, or one of the two immediately
following.  That's what you told me, and havoc (including the head reset)
ensued.

Let me emphasize that point, not because I want to beat up on you but
because we need to be clear about what went wrong in order to improve.
If you had correctly identified the merge commit as the place where
symmetric-peer behavior changed, I would not have concluded that we
were in shit so deep that the head reset was required.  Several days
of scrambling to put the pieces back together in a sane order would
have been avoided.

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

Generally agreed, but there comes a point where the big merge has to
happen.  The team didn't handle that well.  Daniel screwed up, you
screwed up, I screwed up.  We need to do better next time.

> > 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'm listening, when you're ready to produce them.

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

What "this problem" are you referring to? If it's what to do about
symmetric peer mode, maybe you're right.  But now, under point 3,
that's over-focusing on the point problem.

What I want to hear from you is what criteria you want us to use
for making security vs. compatibility tradeoffs in general.  You
don't like my criterion; that's OK, but if we're going to reach
a theory we can all live with, you need to put yours on the table.

You can use a proposed disposition of peer mode to illustrate
your more general criteria, but the discussion won't advance
much if you stop there.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20161006/cb3e57d3/attachment.bin>