Re: Parler
sro...@ronan-online.com :
> While Amazon is absolutely within their rights to suspend anyone they want
> for violation of their TOS, it does create an interesting problem. Amazon is
> now in the content moderation business, which could potentially open them up
> to liability if they fail to suspend any other customer who hosts
> objectionable content.
>
> When I actively hosted USENET servers, I was repeatedly warned by in-house
> and external counsel, not to moderate which groups I hosted based on content,
> less I become responsible for moderating all groups, shouldn’t that same
> principal apply to platforms like AWS and Twitter?
Yes, it would. This was an astonnishingly stupid move on AWS's part;
I'm prett sure their counsel was not conmsulted.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Re: Time and Timing Servers
Ethan O'Toole :
> > I'm looking for a device that can receive GPS inside a building without
> > the assistance of an external antenna (Frontier says they no longer
> > allow external antenna), will provide traditional NTP services, and will
> > provide a timing signal that my Metaswitch can work with.
>
> GPS inside a building probably isn't going to work unless you have the
> antenna up against a window.
Concur. But if you have that, my microserver build on a Raspberry Pi
will do nicely.
https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/
No need for expensive proprietary hardware.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Re: Crowdfunding critical infrastructure
Jon Lewis :
> This may have been an anomaly made possible by early .com $, but I'm pretty
> sure at one point, companies like VA Research / VA Linux employed developers
> who in various cases worked part or full time on the Linux kernel and other
> Open Source projects "as their job".
I was on the Board of Directors of VA Linux at the time. I know we did.
That kind of generosity can exist, yes. But the economic headwinds
are against it. If you're one of the lucky developers patronized
*inside* a corporation, you are never more than one bad quarter from
being defunded.
For some projects, like Apache or the Linux kernel, the business case
for cross-corporate collaboration on shared infrastructure is so clear
that even a succession of non-technical bosses can grasp it. And when
that happens, you can thank me, because I wrote up that business case
where it could become part of C-level thinking.
That just means that people like me get to worry about the next level of the
problem. Shared infrastructure where the connection to profits is *not*
one that a non-technical executive can easily grasp. Good luck keeping
*that* sort of work funded inside a for-profit organizatiion.
> That you've developed/maintained software that's in every Android device,
> but haven't been paid by anyone for that may be the biggest flaw with Open
> Source / Free Software. Presumably, if you chose to stop doing that work
> and nobody volunteered to step into your place, Google (and others) would be
> forced to fork the code and pay developers to maintain their own versions.
They would. More efficient for me to keep doing it, but that's not an
efficiency
that shows up in a manager's quarterlies.
> Free software was meant to give users control of / access to the code...not
> create a parasitic ecosystem where some people code because they enjoy doing
> it and others profit from their work by packaging and selling it or things
> based on it.
My eyes were open. Open source was, and is, a solution - oe ary least
a good hard whack - at one set of systemic problems. Now we get to
deal with the problems that come from the solution.
That's what I'm trying to do.
You know how to help. Take the Loadsharers pleadge and spread the word.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Re: OFFTRACK - Re: 1st Linux Distro [was:Re: Crowdfunding critical infrastructure]
Eric S. Raymond :
> Miles Fidelman :
> > Now, if you mean, the oldest EXTANT distribution, that WOULD be Slackware.
>
> I will revise appropriately. And ask my informants some pointed questions.
>
> This is, by tge why, an exemplar of why LBIP evaluation should be
> crowdsourced. I can't know eveything relevant. No other single
> person or smal;l panel of expes could either.
"by the way"
Ugh.
Excuse my typos. I'm still in recovery from surgery and not at 100%
--
http://www.catb.org/~esr/;>Eric S. Raymond
Re: Crowdfunding critical infrastructure
Jan Schaumann : > Perhaps an opportunity to collaborate with > https://www.coreinfrastructure.org/ ? I am unfortunately constrained in what I can say about CII. The temptation to rant is extreme, but I would be revealing confidences that are not mine if I did so. I'll just suggest that if you think CII is the solution to this problem, you should take a hard look at what they're actually funding. And *not* funding. I have a paragraph in the Loadsharers FAQ about the failure modes of centralized fundings for LBIPs. I did *not* write that paragraph from theory. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: OFFTRACK - Re: 1st Linux Distro [was:Re: Crowdfunding critical infrastructure]
Miles Fidelman : > Now, if you mean, the oldest EXTANT distribution, that WOULD be Slackware. I will revise appropriately. And ask my informants some pointed questions. This is, by tge why, an exemplar of why LBIP evaluation should be crowdsourced. I can't know eveything relevant. No other single person or smal;l panel of expes could either. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: Crowdfunding critical infrastructure
Chris Adams : > Once upon a time, Eric S. Raymond said: > > Tell it to Patrick Volkerding, who sweated to created the first Linux > > distribution > > No, he didn't. Can you be more specific? Are we possibly having some definitional issue about what constitutes a Linux distribution? It is certainly possible you are right and all my other informants are wrong, but... facts, please? Off-list, preferably. This isn't a nanog concern. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: Crowdfunding critical infrastructure
Jeff Shultz :
> As is, one thing that grates a bit personally is that the two advisor
> pages do not share a common structure - If I'm doing a comparison,
> even unconsciously, I'm going to want to be looking at like objects.
> Instead, I have your page, which matches the rest of the formatting of
> the Loadsharer's website, and then I go to Dave Täht's page which is a
> Patreon blog post, with a very different appearance.
>
> I suggest that you provide Advisors with Loadsharer pages like your
> own, to increase the commonality between list appearances.
>
> My background is military - some uniformity counts in my worldview.
> Maybe the lack of it will assist in splitting the loadsharers between
> Advisors, which could be considered a feature.
No, I think you are right and had already identified this as a problem.
I just hadn't gotten around to nudging Dave about it yet. I'm
forwarding this to him.
I'm going to take your feedback as actionable advice that I need to do
something formal about making adviser pages comparable *now*, rather
than when I get a round tuit.
What I can do about this within the Loadsharers organizational design
is put up a "Best practices for Advisers" page strongly recommending
that new advisers should clone an existing Adviser page when creating
theirs. I'll put that up today.
I can also offer advisers the ability to host their pages through the
Gitlab repository I use for the main loadsharers page and FAQ, with the
same toolchain for making the HTML.
Which is, in case anyone didn't recognize it, asciidoc. With a Gitlab
CI job rendering to GitLab pages and a custom domain.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Re: Crowdfunding critical infrastructure
Miles Fidelman : > I think it would be a grand thing if someone put together a visible list of > critical Internet infrastructure, who maintains it, and perhaps "click to > support" buttons for those that need support. Then again, such a list might > present a wonderful target list for those who might want to do ill. Which is why Loadsharers is designed not to have one big list at all. As Internet engineers, we've learned a lot about avoiding single points of failure in our communications networks. Loadsharers applies that hard-won wisdom to the funding problem. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: Crowdfunding critical infrastructure
Mehmet Akcin :
> On Thu, Jun 27, 2019 at 08:41 Eric S. Raymond wrote:
>
> > The members of this list are, I think, much more aware tham most that
> > a lot of critical Internet software is maintained by unfunded
> > volunteers, and of the systemic risks that result from this.
>
> Please explain. This is not true.
Tell it to Dave Taht, who broke his health solving the bufferbloat problem.
Tell it to Patrick Volkerding, who sweated to created the first Linux
distribution - inventing a whole tier of infrastructure we now take
for granted - only to end up in deep financial trouble because other
people make all the money selling the CDs.
Tell it to me, leading GIFLIB and GPSD and NTPsec and 48 other
projects and looking at having my life savings possibly wiped out by a
relatively low-grade medical problem because I'm not on anyone's
payroll.
Tell it to Harlan Stenn, who worked on NTP for over a decade and could
barely get anyone to kick in enough money to buy coffee.
If you do not understand the scope of this problem, you are *astoundingly*
ignorant. And probably alone on this list.
> This needs governance and transparency around it. Just launching a page
> isn’t going to get you anywhere “sustsinable”
Every loadsharer keeps control of their money at all times. Nobody is
makng decisions for them; the most the advisers can do is suggest
priorities. Everyting happens in public. How does it get more
transparent than that?
--
http://www.catb.org/~esr/;>Eric S. Raymond
Re: Crowdfunding critical infrastructure
Jeff Shultz : > It will be interesting to see, should this get off the ground to any > significant amount, if it turns into a bit of a popularity contest - > where a few get the lions share of the donations and the rest a > pittance. I'm aware of that possible failure mode. It's why I designed in a three-way fanout. The Loadsharer pledge strongly encourages its takers to to find and sponsore *three* LBIPs. > It might be a good idea to provide the list in a random (and > frequently re-randomized) fashion to avoid the same names always being > at the top of it. I see that Matt Harris had the same thought. There is no one list, by design. That would be a single point of failure. Each adviser keeps his or her own list. Loadsharers choose which advisers to pay attention to. Didn't anyone actually read the webpage? -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: Crowdfunding critical infrastructure
Tom Beecher
> > Adding an organization in front of that whose sole reason for existence is
> > to decide who gets what % of the money doesn't make a lot of sense, mostly
> > because it is just creating another layer of people who are then going to
> > feel entitled to be compensated for taking the time to decide who should be
> > compensated.
> I don't think anyone needs to be compensated for that. I think that you can
> certainly run a volunteer organization. The time required would be minimal
> enough that normally-employed folks could participate without issue in
> managing it.
I have founded and run three 501(c)3s. Two of them are still on mission 17
and 26 years, respectively, after they were founded and with me no longer
running them. I have seen success, I have seen failure, I have the battle
scars.
You are, sadly, wrong. When your nonprofit scales up past a certain level
part time problems turn into full-time ones. You may get lucky and not be
required to scale up that far, but it is not wise to count on this.
Usually you *will* hit that transition point. If you don't adapt to it,
your organization will fail. Above that point, when you fail to
compensate your people adequately, you lose them. They bail out or
they burn out. Altrustic drive can postpone that reckoning, but not
prevent it.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Re: Crowdfunding critical infrastructure
Matt Harris : > Interesting concept, and seems like a good idea. What's the end goal look > like? Depends on timescale. What I want is for a growing number of skilled engineers to be able to both (a) work shared-infrastructure problems full time, and (b) be able to feed themselves and pay rent and live normal lives while doing it. If this *really* scales up well, shared infrastructure might become something like a career path. Work on things of widely perceived value, get lots of patrons, prosper. We need to do something like this because currently LBIPs are caught between two problems: (1) No way to monetize critical services (2) Altruism doesn't scale well. >Encouraging folks to contribute to specific individuals directly may > be a little more difficult though, compared to, say, getting a legitimate > organization going that provides (likely objectively-determined > merit-based) payouts to the sort of folks you're talking about. I designed loadsharers out of experience that the centralized model has been tried and failed. As the FAQ notes: It turns out that recruiting people who are both competent to run an organization like that and able to sustain the effort is really hard. Also, organizations that handle money have high complexity, overhead, and management costs. Remittance systems offer us a way to route around most of those costs. Loadsharers is designed to be the thinnest possible coordination layer over the remittance systems. Last but not least, centralization creates single points of failure. A loose network like Loadsharers should be less vulnerable to individual incompetence, political capture, corruption, etc. I have specific instances in mind for all the organizational failure modes I describe. Also, I have yet to see any evidence that small central panels of experts are better at judging merit than a swarm attack on the evaluation problem in which people choose to fund what they like and know about. That's called a "market". It works. > I think many of us assume that doing the sort of work you're referring to > will definitely result in the regular receipt of many prestigious, > high-paying job offers. When that happens, it's actually a problem. Let's suppose that someone were to judge I've been doing high-quality work on security-hardened NTP. I get a job offer as a result. Is it going to be to work on NTP? Nope, you can't monetize NTP, so my employer will want me to work on something else that generates a profit. Boom. We lose. >If that's not the case, maybe something else we can > do is to help find full-time employment/funding for folks who contribute > and need it. What "something else" could be more efficient that putting money into Loadsharers? Corporate overhead for an employee is typically 100% of gross salary or up due to plant costs. When you fund an LBIP through a remittance service, the service takes a cut that's usually about 5%. You could buy a lot more infrastructure support with the 95% difference. Part of what the Loadsharers design is surfing on is the fact that software developers don't actually need the kind of capital concentration that the modern corporation is adapted to manage. We used to, back when computers and communications were expensive, but that was decades ago now. So, if your corporation wants to do infrastructure support efficiently, the most effective thing it can do is earmark some number of K$ per month for the job, then choose experts from among their employees to put it into Loadsharers, possibly acting as advisers to attract more money to the things they can make a case are important. > Hope your ankle's feeling better soon! Thank you, it seems to be healing nicely. -- http://www.catb.org/~esr/;>Eric S. Raymond
Crowdfunding critical infrastructure
The members of this list are, I think, much more aware tham most that a lot of critical Internet software is maintained by unfunded volunteers, and of the systemic risks that result from this. I'm attacking the problem at the root, applying what the Internet has taught us about decentralization and avoidiing single poimts of failure. In part because I'm currently struggling with medical bills (nothing life-threatening, just ankle surgery) but I've been worrying about the larger problem for a decade. Please read http://loadsharers.net Of course I would like everyone on here to take the pledge and spread the word in technical communities where they have influence. But beyond that, there are several members of this list who are clearly qualified to join as advisers. We're going to need that as the Loadsharers network scales up. -- http://www.catb.org/~esr/;>Eric S. Raymond .. a government and its agents are under no general duty to provide public services, such as police protection, to any particular individual citizen... -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181)
Re: Cost effective time servers
Patrick :
> On 2019-06-20 20:18, Jay Hennigan wrote:
> > If you want to go really cheap and don't value your time, but do value
> > knowing the correct time, a GPS receiver with a USB interface and a
> > Raspberry Pi would do the trick.
>
> https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/
>
> RPi + GPS Hat because time across USB has much jitter.
I wrote that white paper, and a good big chunk of the software in the recipe is
mine.
The rest is about 25% percent of Dave Mills's reference implementation of NTP.
USB jitter isn't too bad, actually. Unacceptable if you're doing pgysics
experiments but
an order of magitude below the expected accuracy of WAN time synchronization.
That said, my recipe *is* better. And a fun, simple, dirt-cheap build.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Re: NTP for ASBRs?
Royce Williams : > > Anybody know of anything fitting that description that you might want > > to deploy in a data center as a Stratum 1? If such a creature exists I > > shall contrive to get my lunch hooks on one and write a driver for it. > > That would be fantastic. I mentioned it on Freenode when it first came out > - but it may have escaped your attention. :) > > An eBay search for "EverSet ES100 WWVB BPSK Phase Modulation Receiver Kit" > should prove fruitful. I have one - but I haven't had time to tinker with > it yet. > > The kit comes with the double-antenna setup that appears to be key to the > improved reception. In the clocks, the antennas are at 90 degrees relative > to each other. Alas. In concept, that is extremely interesting. But a bit too bare-metal for me; first I'd have to recruit help to design and build it into something one of my computers can talk to. OTOH, I have written successful I2C code; if something like this hardware were a Raspberry Pi HAT I'd have bought one before I finished typing this reply and probably have a test system up in 24 hours. So it's close. Real close. Relevant link: https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/ It would be delightful to add a WWVB radio version of the build to that document. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: NTP for ASBRs?
Chris Adams :
> Once upon a time, Royce Williams said:
> > The La Crosse 404-1235UA-SS UltrAtomic (not affiliated, just a fan) tracks
> > DST - and even leap seconds. They have much better reach than previous
> > similar clocks.
>
> Looks like somebody finally brought a clock to market that uses the
> new-format phase-modulated signal. Hopefully there'll be more, but with
> the WWVB funding threats, I wouldn't be surprised if companies don't
> want to invest in any new products that use it.
Interesting - first device I've heard of that uses the new-format
fine modulation, and as NTPsec's tech lead I keep as close an eye on such
developments as anybody.
Before this I had thought that a combination of clock vendors feeling burned by
the modulation change and cheap GPSes entirely killed the market for devices
that
can get high-precision time from WWBV.
Anybody know of anything fitting that description that you might want
to deploy in a data center as a Stratum 1? If such a creature exists I shall
contrive to get my lunch hooks on one and write a driver for it.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Re: NTP question
Mel Beckman : > It’s hard to consider messing with signal converters and pricey > remotely-powered active antennas when you can solve the problem for $300. :) The recipe I posted a link to upthread is cheaper. https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/ -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: NTP question
Alejandro Acosta : > "The built in high sensitivity GPS receiver is able to lock multiple > satellites from within multiple buildings or from a window location*, > eliminating the requirement that an outdoor antenna be installed*." Even relatively low-end GPS hardware can do this now. https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/ That's my recipe for a GPS-based Stratum 1 server built from a RasPi and any one of several generally-available GPS daughterboards. Cost less than $100. A window location works just fine. I have six of these on the windowsill above my desk - they're my test fleet for NTPsec. The trees near the outside of that window aren't a problem, and while it isn't *guaraneed* that you have a 4-satellite lock at any ven time periods of no tracking tend to be short. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: NTP question
Brielle Bruns : > I've got a WWVB clock as well that I'd love to get hooked into my main NTP > server, but I worry they're going to finally kill that off in the next year > or so. Alas, your WWVB clock is probably already almost useless except as a wall decoration. The modulation of the subsecond part of the WWVB signal changed in 2012. If your clock is older than that, the best it can still do is pick up the low-precision per-second tick. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: GPS rollover
Matthew Petach : > On Sun, Mar 10, 2019 at 8:04 PM Stephen Satchell wrote: > > > So far as I can tell with NTP, there was no issue with time sources > > becoming false-tickers, including my local GPS appliance. FWIW. > > > > > I believe the rollover is *next* month, in April. :) > https://ics-cert.us-cert.gov/sites/default/files/documents/Memorandum_on_GPS_2019.pdf > > "This paper is intended to provide an understanding of the possible effects > of the April 6, 2019 GPS Week Number Rollover on Coordinated Universal Time > derived from GPS devices." I'm a domain expert in this area - lead of NTPsec and GPSD. Everything said in that memo is correct. I would add only that it is more normal now than not for GPSes to have a hidden pivot date. "For example, a particular GPS device may interpret the WN parameter relative to a firmware creation date and would experience a similar rollover event 1024 weeks after that firmware creation date." Yes, exactly. It is therefore unlikely that your GPSes will become falsetickers on 6 April. That's the good news. The bad news is that they *will* go poof some unpredictable number of weeks later. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: NTP problems/time.windows.com?
Majdi S. Abbas <m...@latt.net>: > Haven't seen it, but if people are reporting sudden hour > offsets, on the first Monday in April, I'd bet on a DST implementation > bug that hijacked the system clock on their servers. > > This doesn't look like the sort of error you'd get with a free > running clock. I concur, about the one-hour shift anyway. The random garbage times aren't really likely either - jumps that large would tend to get the source rejected as a falseticker. It's a weird set of symptoms that rather looks as if they hit two different failure modes at once. Dunno. One of our NTPsec devs posted the link on one of our project channels and suggested maybe we ought to call M$ with an offer of help... -- http://www.catb.org/~esr/;>Eric S. Raymond Please consider contributing to my Patreon page at https://www.patreon.com/esr so I can keep the invisible wheels of the Internet turning. Give generously - the civilization you save might be your own.
Re: Spitballing IoT Security
Ronald F. Guilmette <r...@tristatelogic.com>: > > In message <20161030044342.ga18...@thyrsus.com>, > "Eric S. Raymond" <e...@thyrsus.com> wrote: > > >Ronald F. Guilmette <r...@tristatelogic.com>: > >> Two kids with a modest amount of knowledge > >> and a lot of time on their hands can do it from their mom's basement. > > > >I in turn have to call BS on this. If it were really that easy, we'd > >be inundated by Mirais -- we'd have several attacks a *day*. > > > You need to get out more. > > http://www.nab.org/cybersecurity/Verisign-report-ddos-trends-Q22016.pdf > > It *is* happening every day. You just don't hear about it on CNN because > a "little" 80Mbps DDoS isn't even worthy of a headline anymore, even > though such an attack could CRUSH a local bank, and even many regional > banks into utter oblivion. > > Now, where did I put those bitcoins... It's ransom time! Don't change the subject. An effective DDoS against any single site is, though concerning, not a Mirai-class event. The difference matters, and you shouldn't be pretending it does to score rhetorical points. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: Spitballing IoT Security
Ronald F. Guilmette <r...@tristatelogic.com>: > Two kids with a modest amount of knowledge > and a lot of time on their hands can do it from their mom's basement. I in turn have to call BS on this. If it were really that easy, we'd be inundated by Mirais -- we'd have several attacks a *day*. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: Spitballing IoT Security
b...@theworld.com <b...@theworld.com>:
>
> On October 28, 2016 at 22:27 l...@satchell.net (Stephen Satchell) wrote:
> > On 10/28/2016 10:14 PM, b...@theworld.com wrote:
> > > Thus far the goal just seems to be mayhem.
> >
> > Thus far, the goal on the part of the botnet opearators is to make
> > money. The goal of the CUSTOMERS of the botnet operators? Who knows?
>
> You're speaking in general terms, right? We don't know much anything
> about the perpetrators of these recent Krebs and Dyn attacks such as
> whether there was any DDoS for hire involved.
We can deduce a lot from what didn't happen.
You don't build or hire a botnet on Mirai's scale with pocket change.
And the M.O. doesn't fit a criminal organization - no ransom demand,
no attempt to steal data.
That means the motive was prep for terrorism or cyberwar by a
state-level actor. Bruce Schneier is right and is only saying what
everybody else on the InfoSec side I've spoken with is thinking - the
People's Liberation Army is the top suspect, with the Russian FSB
operating through proxies in Bulgaria or Romania as a fairly distant
second.
Me, I think this fits the profile of a PLA probing attack perfectly.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Re: Yet another NTP security bug we fixed before the CVE issued
Harlan Stenn <st...@ntp.org>:
> Interleave is the best way to get the next major step in accurate time
> using the NTP Protocol. Yes, it needs work. A reference implementation
> is where this work happens.
Daniel Franke judges the interleave concept doesn't actually work well
enough to be worth its code weight, and that Mills believed otherwise
because of an error he failed to notice in the timestamp handling. I
have not looked myself, but I have found Daniel very reliable when he
says such things.
> Yes, we have another release about to happen. Mostly "security" bugs
> that folks will not see, if they're being at all responsible.
They certainly won't see those bugs in NTPsec -- Daniel briefed me about
90 minutes ago, and even if we hadn't I knew we were pre-armored
against 3/4ths of the CVEs that hit you guys this year. Might just have
something to do with having removed 153KLOC of useless code and winding
up with less than a third of the attack surface you guys have exposed.
> Eric, you are loved and appreciated, and respected and admired.
That's nice. It's a damn shame you didn't "admire" me (and my team
members) enough to join forces with us when we were trying to avoid a
fork, rather than fighting us and forcing one to happen. Your choice,
your consequences.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Yet another NTP security bug we fixed before the CVE issued
http://forums.theregister.co.uk/forum/1/2016/10/28/researchers_tag_new_brace_of_bugs_in_ntp_but_theyre_fixable/ That'd be another CVE that NTPsec dodges before it's issued. We removed interleaved mode months ago because the code smelled bad and turned out to have an implementation error in the timestamp handling. On past performance, there'll be about a 75% chance each that we've pre-fixed the other new security bugs. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: Spitballing IoT Security
Mel Beckman <m...@beckman.org>:
> I also really like the idea of offering open source options to vendors, many
> of whom seem to illegally take that privilege anyway. A key fast-path
> component, though, is in my opinion a new RFC for IoT security best
> practices, and probably some revisions to UPNP.
>
> The IoT RFC would spell out basic rules for safe devices: no back doors, no
> default passwords, no gratuitous inbound connections, etc. It would also make
> encryption a requirement, and limit how existing UPNP is deployed to prevent
> unnecessarily exposing vulnerable TCP/UDP ports to the wild. With this RFC in
> hand, and an appropriate splashy icon for vendor packaging (“RFC
> ThingSafe!”), vendors will have a competitive reason for compliance as a
> market differentiator, whether they deploy with open-source or proprietary
> code.
That is a good idea and I am officially adopting it as part of the Evil
Master Plan for World Domination. :-)
I may recruit you to help draft the RFC.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Re: Spitballing IoT Security
Rich Kulawiec <r...@gsp.org>: > I think our working assumption should be that there will be zero cooperation > from the IoT vendors. (Yeah, once in a while one might actually step up, > but that will merely be a happy anomaly.) I agree. There is, however, a chokepoint we have more hope of getting decent software deployed to. I refer to home and small-business routers. OpenWRT and kin are already minor but significant players here. And there's an NRE-minimization aregument we can make for router manufacturers to use rebranded versions rather than rolling their own crappy firmware. I think the anti-IoT-flood strategy that makes the most sense is: 1. Push open-source firmware that doesn't suck to the vendors with a cost- and risk-minimization pitch. 2. Ship it with egress filters. (And telnet blocked.) It wouldn't be technically very difficult to make the firmware rate-limit outbound connections. Cute trick: if we unlimit any local IP address that is a port-forwarding target, most users will never notice because their browser sessions won't be effected. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: Death of the Internet, Film at 11
Aaron C. de Bruyn via NANOG <nanog@nanog.org>:
> On Sun, Oct 23, 2016 at 12:41 PM, <b...@theworld.com> wrote:
> >
> > Assuming these manufacturers who are culpable carry product liability
> > insurance go to their insurance companies and explain the situation.
>
> Cheaper solution: Start a company, build crappy firmware, carry
> product liability insurance, release the product, immediately sell
> millions of units to various vendors that 'rebrand' your product.
> Close your business / go out of business. Wait for lawsuits to roll
> in after the business has been shut down.
>
> -A
For anyone who thinks this is a hypothetical, the market for
consumer-grade GPSes already works this way -- though, not for liability
reasons in quite the same sense. The issue in GPS-land is blocking patents
and other IP. Fly-by-night GPS vendors with 60-to-90-day life cycles
keep a lot of Shenzhen shops busy.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Re: Leap Second planned for 2016
Chris Adams <c...@cmadams.net>:
> Leap seconds are inserted to keep the atomic clocks synced with an
> arbitrary time base (that is guaranteed to vary forever). There's
> nothing magic about having noon UTC meaning the Sun is directly over 0°
> longitude; if we didn't insert leap seconds, it would have drifted
> slightly, but so what?
Here is "so what". From my blog, earlier this year: "In defense of
calendrical irregularity"
I’ve been getting deeper into timekeeping and calendar-related
software the last few years. Besides my work on GPSD, I’m now the tech
lead of NTPsec. Accordingly, I have learned a great deal about time
mensuration and the many odd problems that beset calendricists. I
could tell you more about the flakiness of timezones, leap seconds,
and the error budget of UTC than you probably want to know.
Paradoxically, I find that studying the glitches in the system (some
of which are quite maddening from a software engineer’s point of view)
has left me more opposed to efforts to simplify them out of
existence. I am against, as a major example, the efforts to abolish
leap seconds.
My reason is that studying this mess has made me more aware than I
used to be of the actual function of civil timekeeping. It is to allow
humans to have consistent and useful intuitions about how clock time
relates to the solar day, and in particular to how human circadian
rhythms are entrained by the solar day. Secondarily to maintain
knowledge of how human biological rhythms connect to the seasonal
round (a weaker effect but not a trivial one).
Yes, in theory we could abolish calendars and timestamp everything by
atomic-clock kiloseconds since an epoch. And if there ever comes a day
when we all live in completely controlled environments like space habs
or dome colonies that might actually work for us.
Until then, the trouble with that sort of computer-optimized timestamp
is that while it tells us what time it is, it doesn’t tell us what
*kind* of time it is – how the time relates to human living. Day? Night?
Season?
Those sideband meanings are an important component of how humans use
and interpret time references. Yes, I know January in Australia
doesn’t mean the same thing as January in the U.S. – the point is that
people in both places have stable intuitions about what the weather
will be like then, what sorts of holidays will be celebrated, what
kind of mood is prevalent.
I judge that all the crap I go though reconciling scientific absolute
time to human-centered solar time is worth it. Because when all is
said and done, clocks and calendars are human instruments to serve
human needs. We should be glad when they add texture and meaning to
human life, and beware lest in our attempts to make software easier to
write we inadvertently bulldoze away entire structures of delicate
meaning.
UPDATE: There is one context, however, in which I would cheerfully
junk timezones. I think timestamps on things like file modifications
and version-control commits should always be kept, and represented, in
UTC, and I’m a big fan of RFC3339 format as the way to do that.
The reason I say this is that these times almost never have a
human-body-clock meaning, while on the other hand it is often useful
to be able to compare them unambiguously across timezones. Their usage
pattern is more like scientific than civil time.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Re: Cost-effectivenesss of highly-accurate clocks for NTP
Mel Beckman <m...@beckman.org>: > The upshot is that there are many real-world situations where > expensive clock discipline is needed. But IT isn't, I don't think, > one of them, with the exception of private SONET networks (fast > disappearing in the face of metro Ethernet). Thank you, that was very interesting information. I'm not used to thinking of IT as a relatively low-challenge environment! You're implicitly suggesting there might be a technical case for replacing these T1/T3 trunks with some kind of VOIP provisioning less dependent on accurate time synch. Do you think that's true? -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: Cost-effectivenesss of highly-accurate clocks for NTP
Bruce Simpson <b...@fastmail.net>: > On 13/05/16 20:39, Eric S. Raymond wrote: > >In 2012, nearly three years before being recruited for NTPsec, I > >solved this problem as part of my work on GPSD. The key to this > >solution is an obscure feature of USB, and a one-wire > >patch to the bog-standard design for generic USB that exploits > >it. Technical details on request, but what it comes down to is > >that with this one weird trick(!) you can mass-produce primary time > >sources with a jitter bounded by the USB polling interval for > >about $20 a pop. > > > >The USB 1 polling interval is 1ms. > > What about USB 3.1 (assuming the device is not intended to be backwards > compatible with the polling model) ? I should point out Intel intend to > retire EHCI/UHCI and implement only xHCI. Nobody makes GPSes with even USB 2 or 3 yet, and it is unlikely to happen for a long time. Cost reasons - USB GPSes are cheap consumer-grade hardware and the manufacturers care about fractions of a cent on the BOM. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: Cost-effectivenesss of highly-accurate clocks for NTP
Baldur Norddahl <baldur.nordd...@gmail.com>:
> Ok how many hours or days of holdover can you expect from quartz,
> temperature compensated quartz or Rubidium?
Sorry, I don't have those drift figures handy. I'm a programmer, not
a large-site sysadmin - I've never had purchase authority with a
budget large enough to buy a rubidium-oscillator GPSDO or any other
device with holdover. Better to ask Mel Beckman or someone else
with field experience.
> Should we calculate holdover as
> time until drift is more than 1 millisecond, 10 ms or more for NTP
> applications?
If you want to go super-accurate, 1ms. If you want to go cheap, on
sampling-theory grounds I'd say you want to vary your drift threshold
from 1 to 5ms (half the expected precision of WAN time, think of it as
the Nyquist rate) and look for a knee in the cost curve.
> I am thinking that many available datacenter locations will have poor GPS
> signal so we can expect signal loss to be common. Some weather patterns
> might even cause extended GPS signal loss.
Weather won't do it, usually. Rain and fog and clouds are transparent
to GPS frequencies. Standing water directly on an antenna can cause
some attenuation, but with any serious GPS engine made more recently
than 5 years ago I would be extremely surprised if that lost it
lock. The newer ones handle down to 30 feet in ocean water on robot
submarines.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Cost-effectivenesss of highly-accurate clocks for NTP
quency drift that you get from the
cheap, non-temperature-compensated quartz crystals in your PC.
There is room for debate about how much holdover you should pay for,
but you'll at least be thinking more clearly about the problem if
you recognize that you *should not* buy expensive hardware for
accuracy. For WAN time service, in that price range, you're wither
buying holdover and knowing you're doing so or wasting your money.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Everything you know is wrong. But some of it is a useful first approximation.
Re: A briefing on NTPsec
Mel Beckman <m...@beckman.org>: > Does your project have anything like a portable regression test > suite that the rest of us could use for NTP product evaluations? We do not, yet. Testing NTP at above the level of unit tests for individual functions is *quite* difficult - I say that as the person who successfully implemented a very rigorous regression-test suite in GPSD. The NTP version of this problem is, unfortunately, much less tractable. We have some ideas and a partial implementation, but this is the technical area in which we have had the least success so far. We will persevere. We're going to need good end-to-end testing to maintain provable functional stability through some of the large changes I have in mind. I cannot, however, promise that our test framework will be applicable to other implementations. >And what I be correct in guessing that all of your work is foss? Yes. NTP and 2-clause BSD licenses. > When you say that nothing has been done to add security mechanisms > to NTP, are you saying that all the work so far has been code > hardening exclusively? Yes. There remains a considerable amount of this to be done. We have our eyes on several risky and only marginally useful features that should probably be excised. The recently-acquired ability of Windows to run many Linux binaries probably means all the Windows port shims can be thrown out. And so forth. The official motto of our project, front and center on www.ntpsec.org, is the Saint-Exupery quote: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." I must say that the effectiveness of ruthlessly cutting away bloat as a security-hardening strategy has actually exceeded our initial expectations. We were hoping for "successful" and seem to have achieved "wildly successful" - I think dodging 8 of 11 CVEs in the last batch counts as that. > Finally, do you want to weigh in on the necessity for highly > accurate local RT clocks in NTP servers? That seems to be the big > bugaboo in cost limiting right now. I'll reply to this starting a separate thread. -- http://www.catb.org/~esr/;>Eric S. Raymond
A briefing on NTPsec
Jay Ashworth informs me that NTP security and risks has recently been
a hot topic on NANOG, and that NTPsec was mentioned. Therefore I've
written a bit of a background briefing on the project, which follows.
The NTPsec project was initially funded in late 2014 by NSF when
authorities there became concerned about frequent incidents of DDoS
amplification involving ntpd. I was hired in as tech lead early on (in
part because of my work on GPSD, a technically similar project) and
retained that position when the Linux Foundation picked up funding
the project. It's now managed by Mark Atwood, who some of you may know
from HPE and OpenStack.
I'm going to pass over the politics around the fork from what our team
now calls "NTP Classic" because it wasn't my decision or desire, merely
observing that I reluctantly acknowledged the necessity and wish
things could have been otherwise.
The goal of NTPsec is to achieve high security and high assurance
through systematic application of modern best practices. Though not
yet at release 1.0, our progress can be judged by the fact that when
the last batch of 11 CVEs against NTP was released, we were not
vulnerable to 8 of them because we had previously removed or successfully
hardened the code they exploited.
This was no fluke. Over the last 11 months, we have compiled a
significantly - I think it's fair to say "dramatically" - better
security record than Classic. We've earned some trust in the infosec
research community, working effectively with (among others) Sharon
Goldberg's group at BU. We were the first to develop a verified fix
for the now infamous off-path KOD bug (CVE-2015-7979).
You can read more about our code-hardening practices here:
http://esr.ibiblio.org/?p=6881
In brief, we've thrown out a lot of cruft and archaisms. The code has
been lifted to C99/POSIX-2001 conformance; other than a few warts near
Mac OS X and some unused Windows code probably destined for removal
itself, the port shims that used to infest the codebase are nearly
gone. Mode 7 has been removed, as has Autokey; these were nests of
bugs too risky to leave in.
We've also done a lot of code auditing using tools like Coverity and
cppcheck, and worked hard on improving our test coverage (that part has
been more difficult than any of the code changes, actually, and is
still very much a work in progress).
Here's a figure that should tell you a lot: we removed 57% of the
original codebase in the process of cleaning it up. No, that's not
a typo; the NTPsec codebase is *less than half* the size of NTP
Classic. And much, much easier to read. That's even without
counting the huge simplification win from ditching autotools.
Nevertheless, sysdamins will find it very familiar. The largest
speedbump you will encounter in normal operation is that we've
changed the names of some auxiliary tools so everything has an "ntp"
prefix. The only thing I expect to actually surprise you is the
documentation, which has been greatly improved, specifically by
removing duplications and inconsistencies and distracting references
to equipment that has been dead since the Late Cretaceous.
So far this is a deliberately conservative fork. We haven't yet tried
to add protocol features for security because there is plenty of
useful work to be done before tackling that very hard problem. We're
actively cooperating with the IETF NTP WG (we've committed to
supplying second interop for some upcoming draft RFCs) and we're
watching the work on NTS closely. It is likely, though not yet
certain, that we'll be second interop on that.
Finally, I note some criticism that NTPsec is short on people who
understand all the subtleties of time service in the field. This is
partly justified. The tech lead admits to being something of a newbie;
though I know a lot about some adjacent technical areas from ten years
of leading GPSD, I was not a time-service expert before being engaged
for this project and am still coming up to speed.
The team does already include one time-service old hand and a really
good crypto/infosec specialist. NANOG listmember Gary E. Miller was
an early team member who remains a friend of the project. We would
certainly welcome more engagement and advice fom time-service experts,
and the sort of experienced sysadmins who frequent NANOG.
In a future post I may have a bit to say about Stratum 1s based on the
RPi and other hackerboards. I've been working in that area as well.
I'll be happy to answer technical and procedural questions about NTPsec.
Any questions about politics and policy should go to Mark Atwood.
See www.ntpsec.org for more information.
--
http://www.catb.org/~esr/;>Eric S. Raymond
A briefing on NTPsec
Jay Ashworth informs me that NTP security and risks has recently been
a hot topic on NANOG, and that NTPsec was mentioned. Therefore I've
written a bit of a background briefing on the project, which follows.
The NTPsec project was initially funded in late 2014 by NSF when
authorities there became concerned about frequent incidents of DDoS
amplification involving ntpd. I was hired in as tech lead early on (in
part because of my work on GPSD, a technically similar project) and
retained that position when the Linux Foundation picked up funding
the project. It's now managed by Mark Atwood, who some of you may know
from HPE and OpenStack.
I'm going to pass over the politics around the fork from what our team
now calls "NTP Classic" because it wasn't my decision or desire, merely
observing that I reluctantly acknowledged the necessity and wish
things could have been otherwise.
The goal of NTPsec is to achieve high security and high assurance
through systematic application of modern best practices. Though not
yet at release 1.0, our progress can be judged by the fact that when
the last batch of 11 CVEs against NTP was released, we were not
vulnerable to 8 of them because we had previously removed or successfully
hardened the code they exploited.
This was no fluke. Over the last 11 months, we have compiled a
significantly - I think it's fair to say "dramatically" - better
security record than Classic. We've earned some trust in the infosec
research community, working effectively with (among others) Sharon
Goldberg's group at BU. We were the first to develop a verified fix
for the now infamous off-path KOD bug (CVE-2015-7979).
You can read more about our code-hardening practices here:
http://esr.ibiblio.org/?p=6881
In brief, we've thrown out a lot of cruft and archaisms. The code has
been lifted to C99/POSIX-2001 conformance; other than a few warts near
Mac OS X and some unused Windows code probably destined for removal
itself, the port shims that used to infest the codebase are nearly
gone. Mode 7 has been removed, as has Autokey; these were nests of
bugs too risky to leave in.
We've also done a lot of code auditing using tools like Coverity and
cppcheck, and worked hard on improving our test coverage (that part has
been more difficult than any of the code changes, actually, and is
still very much a work in progress).
Here's a figure that should tell you a lot: we removed 57% of the
original codebase in the process of cleaning it up. No, that's not
a typo; the NTPsec codebase is *less than half* the size of NTP
Classic. And much, much easier to read. That's even without
counting the huge simplification win from ditching autotools.
Nevertheless, sysdamins will find it very familiar. The largest
speedbump you will encounter in normal operation is that we've
changed the names of some auxiliary tools so everything has an "ntp"
prefix. The only thing I expect to actually surprise you is the
documentation, which has been greatly improved, specifically by
removing duplications and inconsistencies and distracting references
to equipment that has been dead since the Late Cretaceous.
So far this is a deliberately conservative fork. We haven't yet tried
to add protocol features for security because there is plenty of
useful work to be done before tackling that very hard problem. We're
actively cooperating with the IETF NTP WG (we've committed to
supplying second interop for some upcoming draft RFCs) and we're
watching the work on NTS closely. It is likely, though not yet
certain, that we'll be second interop on that.
Finally, I note some criticism that NTPsec is short on people who
understand all the subtleties of time service in the field. This is
partly justified. The tech lead admits to being something of a newbie;
though I know a lot about some adjacent technical areas from ten years
of leading GPSD, I was not a time-service expert before being engaged
for this project and am still coming up to speed.
The team does already include one time-service old hand and a really
good crypto/infosec specialist. NANOG listmember Gary E. Miller was
an early team member who remains a friend of the project. We would
certainly welcome more engagement and advice fom time-service experts,
and the sort of experienced sysadmins who frequent NANOG.
In a future post I may have a bit to say about Stratum 1s based on the
RPi and other hackerboards. I've been working in that area as well.
I'll be happy to answer technical and procedural questions about NTPsec.
Any questions about politics and policy should go to Mark Atwood.
See www.ntpsec.org for more information.
--
http://www.catb.org/~esr/;>Eric S. Raymond
This would be the best of all possible worlds, if there were
no religion in it. -- John Adams, in a letter to Thomas Jefferson.
