Deciding what modes to keep.

[Gary E. Miller]

Yo Daniel!

On Thu, 29 Sep 2016 20:30:49 -0400
Daniel Franke <dfoxfranke at gmail.com> wrote:

> On Sep 29, 2016 8:22 PM, "Eric S. Raymond" <esr at thyrsus.com> wrote:
> >
> > Gary E. Miller <gem at rellim.com>:  
> > > > 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.  
> >
> > That is an interesting idea!
> >  
> > > 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.  
> >
> > Ordinary peer mode is unicast, yes?  No way we'd ever drop that.  
> 
> Peer mode is a synonym for symmetric mode which we discussed on the
> phone earlier today.

Are we talking about the same 'peer' mode?  This thing in my ntp.conf:

    peer 204.17.205.17 maxpoll 5 # pi2

> It has some security problems

yeah, like all of NTP.

> and no good
> justification for existing, and when we discussed it at IETF 96
> nobody knew of any users. My NTS proposal will be able to solve the
> security issues. In contrast, I don't currently have any solution for
> securing broadcast clients.

I use that all the time.  Why would someone not?  it allows some 
optimizations in the protocol and in the relationship between servers.

You are not improving my marginal opinion of the IETF standards
process...

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/448cb58c/attachment.bin>