If the operative word is "sent" and "all" the likelihood is zero, as I can assert I've never sent a private key to NSA, and I've made quite a few over the past few years.
That said, carlosdp makes a great point as to how one should behave. Even though not all private keys get shipped to NSA (can't make claims about other teams), the government is very public about other data sharing programs (see https://www.dhs.gov/sites/default/files/publications/privacy... for example).
Even though all government agencies must disclose these types of programs, they are so numerous and often so difficult to decipher, the only rational response is to assume everyone has everything or could have access in the future.
The only way to avoid this is to build zero-knowledge systems on the server side, something I hope you'll see more of in 2017.
Ultimately, it comes down to how you construct the root origin of the problem facing government right now. For me personally (hence why this post is on Medium and not on a *.gov) is the lack of both faith and trust (two very different things) in public structures of all kinds, not just the federal government.
We've lost that faith and trust for very good reasons, to be sure. We may forgive, but not forget those indiscretions to put it mildly, and they go back to the founding of the republic.
The problem as I see it though is that faith and trust have fallen into such disrepair, it's become a self-replicating negative cycle. So few people believe govt can do anything well (in terms inclusive of ethics/effectiveness/efficiency) which leads to apathy, which leads to skilled people leaving govt or not joining, which leads to further degradation, which leads to a further undermining both in perception and in actual funding or authorities from Congress, and on and on it goes.
That cycle is not just observed at the federal level of course. Even more pernicious to me is the apathy it creates at the state/city (or even community) level, even if one person or one small group's potential for positive impact is exceedingly more likely at the level!
I certainly still have my ethical red lines, and I recite them to myself on a near daily basis so I don't normalize the "might" of the feds with "right". But I still see the one of the core origins that got us to this point being the cycle above, so trying to break the cycle is still my #1 priority for now.
OP here. Yep - the record keeping is out of this world. Due to the spending clauses of the Constitution, even a penny spent in excess of budget or even without all the proper authorities in place can result in a Constitutional violation, and you need to write a fulsome report to your agency head, Congress, the White House, auditors, etc. I've seen it done for what are effectively rounding errors for the US Govt (a few hundred dollars in the wrong spending 'bucket').
Echoing comments above, the laws/regs are strong, the problem continues to be implementation. Govt fiscal IT systems are some of our worst / most tricky legacy systems to modernize.
OP here. I totally grok your feeling on that, but we've adopted the opposite strategy from Day 1. Extreme transparency to the degree we're allowed, so the public can see the value of the work and defend it if necessary. At the moment, I'm still cautiously optimistic.
OP here. "In theory" - most of the stories don't realize we're funded by a fund with billions in revenue, and was net positive in 2016. https://www.gsa.gov/portal/content/152462#ASF
Congress designed the revolving fund with the purpose of spending any funds in excess of costs to help the rest of government be more efficient and effective, as those funds don't naturally return to the US Treasury as they would in other parts of government.
In terms of 18F's performance in both regards, the capital start up funding we've received from the fund has been extremely well spent IMHO, but of course I'm totally biased. I'd look at what we've produced with that $ and let the work speak for itself, especially given how much govt would normally spend on this much information technology: https://github.com/18f
That also only captures things which have an impact in software - we're still working on the best way to represent the fiscal or performance impact of our consulting work.
All that said, of course we can always be more efficient ourselves, and I think the next few years of fiscal reports will show that.
As someone who worked on an open data toolkit here in New Zealand, you also wouldn't have any clarity on "shadow users" either when it comes to non-economic returns.
For our initial prototype, we originally forked your docs repo and heavily modified it which got us up and running quicker than if we had started from scratch!
That said, we ended up switching to another setup later on but still, it would've been painful without your open sourced works!
I’m Noah Kunin, the Infrastructure Director at 18F/GSA.
While the Department of Homeland Security (DHS) owns the Trusted Internet Connections (TIC) policy and controls (https://www.dhs.gov/trusted-internet-connections) we’ve been working hard with DHS teams to clarify and improve implementation guidance.
We hear you - loud and clear - and understand there’s a lot of frustration.
Check out our updates with one of our pilot partners, Amazon Web Services:
18Fer here. The main issue here is how the Gov actually gets $ to that entity. There are lots of laws and rules that we need to obey about who we pay $ to - Gov doesn't have a ton of flexibility here. There was a reason why bidders had to be pre-registered.
That said, many of us want to continue to expand our engagement with the community. When it comes to bounty/reward style programs, the one I'm personally focused on figuring out first is a bug bounty program. Once we've figured out solutions for a bounty type program, you'll absolutely hear from us.
I'm sure you've thought of this, but is it impossible to subcontract this out to a non-profit to increase flexibility in the details of how the work is done? I.e. same requirements, same constraints, but the non-profit is formally registered with GSA and handles payments to subcontractors rather than the sub getting it straight from the government?
The bounty program as a whole. Like when I worked at NREL they were government funded but on paper I think it looked like a subcontract to run the lab which was fully managed by another entity. NREL I'm sure can hire contractors, although I suppose they might have to be in GSA as well?
18Fer here. Before I answer in greater detail, why do you think FIPS requires RHEL with mod_nss only? I don't see why an OpenSSL in FIPS mode wouldn't fit the bill too.
Regardless of your detailed answer, FIPS crypto requirements are a topic of some amusement in professional cryptographic and security circles, and anything you do to push back on them will be a help basically to humanity.
"So at this moment we cannot say whether mod_ssl is going to be a valid crypto module in FIPS mode under RHEL-6 although this is the intent."
That may have changed, and contradict other sources on redhat.com. There are a lot more KB articles on FIPS since the last time I really dug into it over a year ago.
Edit, yes, it looks like it was mod_nss only until the release of RHEL 5.9 last Jan. RHEL-6 was ongoing, but it looks like they claim mod_ssl will work now in other places in the knowledge-base.
FIPS is just one area where it seems like there's a lot of contradictory information for federal IT. After doing the FedRAMP dance, and reading things to the letter, we stopped working towards it and partnered with one of the vendors that got it first. Their remote access was plain text VNC, 8 character password max. I would say I was surprised the paperwork matters more than real security, but I wasn't.
So your post makes no sense. OpenSSL provides the FIPS portion directly. You can just download and compile it according to the instructions and you are now FIPS compliant just awaiting a certification. You can do this yourself, you don't need RedHat or Debian to do it for you.
This is one of the problems with Government and hopefully something that will change. All that is done is piece together bits of what outside vendors have put together and the piecing together is normally done by contractors.
So you think recompiling OpenSSL from scratch, in doing so, deviating from the upstream vendor's supported binaries, and the dependency problems with updates it will cause, just to support a mostly smoke and mirrors standard is a good idea? I'd don't really think that's a best practice in commercial or government IT.
Exactly what the American people have come to expect from the government. Unless its been gift wrapped by a contractor they lack any ability to do anything technical.
You make a RPM and you deploy it like you would any other package. Yes it is a best practice, in fact the people at Red Hat do the _exact_ same thing, the difference is they have the technical capability to make those kinds of changes, as do most people in the commercial IT sector. The government is the one place where they call it IT when its really just glorified procurement.
However thats not even the problem as you stated its supported just fine. It has been for almost 9 years. The bigger issue is there was a perception is wasn't and instead of working to see what reality was people just did nothing.
> Exactly what the American people have come to expect from the government. Unless its been gift wrapped by a contractor they lack any ability to do anything technical.
Exactly the expectations that 18F would like to change.
If the operative word is "sent" and "all" the likelihood is zero, as I can assert I've never sent a private key to NSA, and I've made quite a few over the past few years.
That said, carlosdp makes a great point as to how one should behave. Even though not all private keys get shipped to NSA (can't make claims about other teams), the government is very public about other data sharing programs (see https://www.dhs.gov/sites/default/files/publications/privacy... for example).
Even though all government agencies must disclose these types of programs, they are so numerous and often so difficult to decipher, the only rational response is to assume everyone has everything or could have access in the future.
The only way to avoid this is to build zero-knowledge systems on the server side, something I hope you'll see more of in 2017.