4 ms·
I need a house and a car and food, can I rely on NTP developers for those? Just because someone needs an NTP implementation doesn't mean that the NTP developers
by Oxitendwe 10y ago
I need a house and a car and food, can I rely on NTP developers for those? Just because someone needs an NTP implementation doesn't mean that the NTP developers need to provide it, especially if providing it is to the detriment of everyone else's security. What do any of us who don't have to run 80's mainframes get out of tethering ourselves to the past?
- eridius 10y agoWhy does retaining compatibility with systems that you've always had compatibility with mean reduced security? That seems like a pretty big assumption without any supporting evidence. Normally retaining compatibility with old systems is a pain just because it's extra work, rather than actually hurting the security of the software.
- PeterisP 10y agoIf that compatibility is implemented by large quantities of otherwise unnecessary code, then having that code be there increases the potential attack surface and reduces security. Just as obscure, rarely used features - removing them would facilitate security. I don't know much about NTP, but if I would take their claims at face value - "reduction in code of over 2/3 (from 227kLOC to 74kLOC)" is a valuable gain even if means removing compatibility with some less used systems; and "NTPsec was immune to over 50% of NTP Classic vulns BEFORE discovery in the last year" is a realistic consequence of a large reduction in code size/attack surface.
- eridius 10y agoIf NTPsec is immune to a bunch of vulnerabilities because they literally deleted all of the relevant code, that's disingenuous. It's not that they're immune, it's that they chose to literally throw away support for a whole bunch of functionality that NTP retained. You could argue that maybe people shouldn't be using that functionality anymore (though I don't know if that's a good argument, since I don't know what the actual functionality is or why NTPsec threw it away), but since people are using it, and since NTP Classic is the reference implementation for NTP (and therefore must implement all of NTP), I reject the notion that NTP Classic is automatically in the wrong for retaining this functionality.
- PeterisP 10y agoIf product A implements a small subset of the functionality of product B, but that small subset is enough for your needs, then from a security perspective (other things being roughly equal) you should never ever use product B. It brings in additional risks for no good reason. By default, extra functionality is a cost and a drawback - if it's useful it may justify that cost, but otherwise removing that functionality is a very useful thing to do. If half of people need the 'deleted' functionality (and it seems that the proportion is much smaller, but let's assume half) then obviously they should use NTP Classic, but the other half definitely should not.
- eridius 10y agoDepending on what the deleted functionality is, vulnerabilities in that functionality may not affect you anyway even if you're using NTP Classic. If you're not using that functionality to begin with, then it's hard to be affected by vulnerabilities in it. I say "depending on what it is" because of course you can have functionality that, even though you don't care about it, you still can't actually turn off (e.g. a protocol server that implements commands you don't care about, but can't disable). It's not clear to me offhand whether the NTP Classic functionality that NTPsec deleted is the type that doesn't affect you if you don't use it, or if it's the type that can't be disabled.