Yo Daniel! On Thu, 29 Sep 2016 20:30:49 -0400 Daniel Franke <[email protected]> wrote:
> On Sep 29, 2016 8:22 PM, "Eric S. Raymond" <[email protected]> wrote: > > > > Gary E. Miller <[email protected]>: > > > > 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 [email protected] Tel:+1 541 382 8588
pgpHKt7plbn6W.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
