Deciding what modes to keep.

[Gary E. Miller]

Yo Eric!

On Thu, 29 Sep 2016 19:39:28 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Gary E. Miller <gem at rellim.com>:
> > On Thu, 29 Sep 2016 19:19:28 -0400
> > "Eric S. Raymond" <esr at thyrsus.com> wrote:
> >   
> > > So, the question for our domain experts is, are there any serious
> > > use cases for broadcast modes?  They cost a lot in configuration
> > > and code complexity; it would be nice to just drop them. How much
> > > screaming might that cause from actual users?  
> > 
> > I don't care if there is a valid 'serious' use case or not.  When 
> > someone tries to sell his boss on moving from NTP Classic to NTPsec
> > he does not want to have to do a large use case analysis.  There
> > is a strong case for 'drop-in replacement' possible.  Like the
> > 'notrap' option.  
> 
> But we have one mission imperative that trumps drop-in replacement:
> security.  And what makes these modes targets for removal is that,
> according to Daniel, there are fundamentally impossible to secure.

I would split that hair.  Maybe ntpd could still send broadcast, there
are a lot of legacy clients that can not be updated.  But not
accept broadcast in.

I not exactly sure what modes you are dropping, but dropping 'peer'
mode would be a serious PITA for the isntalled base.  Trying to
update an old router, without a support contract, is pretty much
impossible.  At least not without some license or legal violation.
 
> I did in fact restore a dummy 'notrap' keyword so old configs
> won't break.  But that's because it had no security implications.

Yes, which is why I brought it up, back compatibility matters.  And
you bought into there.

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/20160929/56a58895/attachment.bin>