back
135 comments
From under my tinfoil hat, I have to wonder why we would listen to any recommendations from the NSA? Why would we not believe they are going to make recommendations of methods they know how to exploit?

Taking off my tinfoil hat, I understand that one of the purposes of the NSA is to keep US information safe. Following their recommendations should make your data safer.

However, Snowden showed us that the NSA doesn't always follow the rules it is supposed to operate within. Does that mean they are always be suspect? How do we decide when their recos are for the good fo all?

This is one of the arguments to separate USCYBERCOM and NSA.

IMO, the US should really strictly separate the offensive/SIGINT and defensive aspects of NSA into separate agencies, and move the defensive part out of the intelligence community. Make it part of NIST or something. It would restore at least a little credibility to documents like this.

The tricky bit is that offense and defense actually require the same knowledge. A 0-day is immediately applicable for offense and must be immediately patched for defense.
The NSA has a long history [0](PDF) of providing guidance for "best practices" for securing USA corporate networks. It's part of their job.

[0](PDF) https://apps.nsa.gov/iaarchive/customcf/openAttachment.cfm?F...

Yes, I stipulated that in my post. However, we have seen how the NSA wants data from US corporations. If they make a "recommendation" for corps to use, then how do we know it is solely for the corporation's best interests rather than the NSA's own interests in more easily accessing the corp's data while providing false sense of security?

We do know that the NSA pushed for a particular type of RSA encryption to become the default because they already knew how to break the encryption. Once something like that is known in the wild, credibility will from then on be suspect at best as to true motive.

Only if it doesn't make their own work any harder. NSA prefer weak security for everyone if securing US assets might risk others to be more secure too:

>NIST failed to exercise independent judgment but instead deferred extensively to NSA. After DUAL_EC was proposed, two major red flags emerged. Either one should have caused NIST to remove DUAL_EC from the standard, but in both cases NIST deferred to NSA requests to keep DUAL_EC"

https://www.nist.gov/system/files/documents/2017/05/09/VCAT-... [PDF warning]

I mean this question sincerely, as I'm a US Government employee currently and former Intelligence Officer:

What is it going to take to restore, or maybe even just establish, trust in US Government institutions by people in the US?

Prosecution of government employees and officeholders. You don't gain trust without a reason to trust you. There is no magic reset button. After COINTELPRO and Iran/Contra and Snowden, the USA Intel establishment has a solid record of attacking their own citizens and behaving as though laws don't apply to them and there is no oversight. Valerie Plame?

And then there's the last five years, starting with the Clinton email server. The Intel community can't prevent that, and then the FBI goes political at the end of election season?

There is no trust of intelligence agencies because they have proven they deserve none.

Your successes are secret, your failures are known. That's your industry's catch phrase.

Here's a list of things I can think of:

1. If you're the CIA/NSA, stop spying on American citizens.

2. See #1

3. Stop NSLs. If you want data, get a valid warrant visible to the public. Allow companies to inform their users/customers that their entire platform is vulnerable.

4. Subject yourself to non-govt over view.

5. Stop hoarding 0-days, and actively work with vendors to fix vulns.

Don't know how to fix it, but until you're no longer in the news for screwing up, this is where we are. Your internal documents show that all of that data slurping has not led to significant positive results. Why spend the money on it then? Why erode the trust that you want? You don't want to tip off the advesary, but your own citizen's rights are much more valuable than what little information you are getting.

In addition to what others have already said, actually preventing major breaches like the recent Solarwinds hack. Eg, besides the tinfoil hat stuff, just getting the basics right.

Personally I'd like to see the entire US govt IT infrastructure rebuilt around DARPA's HACMS project [1]. Get rid of Windows, base it all on SEL4 Linux or similar, rebuild the apps (everything in userspace), etc. That would significantly reduce the attack surface. Huge project obviously, but one can wish.

[1]:https://www.darpa.mil/program/high-assurance-cyber-military-...

NSA recommendations for the securing of government infrastructure should be listened to by corps with the normal grain of salt of understanding when and where it is appropriate to apply such measures.

NSA recommendations for the securing of enterprises and corporations should be ignored or avoided. If it was actually secure, they would also recommend it for government use

That's the frustrating thing. The NSA actually used to be good, and generally useful towards securing our digital borders. SELinux, for example, was a contribution to the linux kernel that is generally highly regarded and well vetted, and it was freely given to us plebs that don't have nuclear arsenals to secure.

But now, everything is different. They've been telling us to use flawed crypto algorithms simply because they know how to break them and they can have access to whatever they want. With our current-day NSA, our least risky choice is to consider the NSA an adversary, just like North Korea, Russia, or China. Nothing they say should be taken at face value.

Pretty shitty that we have to treat our own government security agencies like that.

Let us not forget the elliptic curve backdoor they gave themselves a few years ago. https://www.wired.com/2013/09/nsa-backdoor/
> I have to wonder why we would listen to any recommendations from the NSA?

Because the NSA is a defensive as well as offensive institution, they defend the home front as well as they attack adversaries

Under what threat model would you be threatened by a domestic spy agency having a backdoor? Ignoring the red herring that "backdoors don't stay hidden".
My instinct would be to say to verify what they are saying, but it seems like we should just take advice from the people who we would verify with it in the first place
>NSA recommends that an enterprise network’s DNS traffic, encrypted or not, be sent only to the designated enterprise DNS resolver.

its either a slow day at the NSA or federal agencies have become so intellectually bankrupted by the cloud that they consider proclamations of the fundamentals of DNS and networking to be some sort of sage wisdom.

They are responding to the very recent emergence of applications (like Firefox) that (optionally) use their own encrypted DNS, thus bypassing the enterprise's ability to apply security policy based on DNS. (Visibility on DNS is also useful to help detect some malware.) I'll allow it.
I read that to mean: Do not allow doh to tunnel all your dns traffic out to cloudflare regardless of the promise of encryption. Send it only to the designated enterprise DNS resolver, ie the one under control by the enterprise.

All other DNS resolvers should be disabled and blocked, ie all those public dns resolvers.

Somebody has to recommend the basic stuff, otherwise it's just rumor. This is a topical addition to a list of DNS recommendations.
Now you can point to that and say “We use the best DNS practices as recommended by the NSA.”
Specifically, they are saying that in a home/personal environment, it makes sense to use DoH with a public resolver like cloudflare, but in enterprise, you will not be able to maintain tight control over internal use as browsers role out with DoH by default unless you block those public resolvers and enforce policy to use the enterprise resolver. It doesn't matter unless you care about these tight controls though even in enterprise.
Security recommendations aren't supposed to be brilliant insights. They're just best practices.
unless i am reading this wrong, they are not saying don't send your requests to Cloudfare, Apple, etc. i am not entirely privy to all this, but aren't they entreprise grade DNS resolvers?
I wonder when smart TV manufacturers will begin using DNS-over-HTTPS to make it harder for PiHole et al to block their ads.
I wonder why they haven't done this along time ago. They don't even need a full DoH endpoint, just an auto-updating hosts file downloaded from a non-blockable domain (one used for other TV features) would do it.
The already hard code dns to do this, need to do an address translation to fix
There's no reason any of these products need to use on-prem DNS of any sort, except maybe for the DNS lookup to the central server that they require to operate at all. I know a lot of people base DoH concerns on the idea that it allows their set-top box to evade their local DNS policy, but that's not a coherent argument; these boxes can tunnel all their traffic out, if they want to (you can block that, but it's all-or-none, which is the thing the DNS boffins claim they can work around).
I kinda doubt they're concerned about the tiny percentage of users who would do such a thing.
I already use an Nvidia Shield instead of my smart TV, even though both are Android TV. It is such a better experience. If any device started taking over it's DNS in a way I couldn't override, and I had reason to care, I would stop using it. PiHole is already a meh solution.

My two primary apps on my Shield are SmartTubeTV and Kodi. I won't pay for YouTube when they force bundle it with other services I don't want. The alternative of ads has gotten to ridiculous levels, and then the ads in the video from them on top. SponsorBlock is another game changer. Sadly it isn't in an AndroidTV app yet.

On my phone it is Vanced all the way for YouTube, and it does have SponsorBlock.

And that's when you start adopting reverse dns + mac address filtering
I don't understand why people can't see the dangers of moving everything to DoH. For example if you have a 3000 user network and 2900 of them are using a local resolver. You have almost no chance of finding those 100 nodes doing DoH without MITM everything over 443.

Someone will probably respond with something like: "Just block the IP address ranges of public DoH resolvers" and that would work for the resolvers we know about.

I don't understand why people can't see the dangers of moving everything to DoH

Because "more security" is hard to argue against. The huge corporations who ultimately want to take control of the population have realised that, and are using that excuse to get in bit by bit.

If you’ve got 3000 nodes on your network without inventory, logging and configuration control on each of those devices you’ve already lost. You don’t have a secure network, at best you’ve got a guest network at a cafe.
They are just saying within enterprises it is of the enterprises best interest to control all aspects of dns so all traffic can be monitored. Which you seriously need to do if you aren't doing it already.

Dns needs to be monitored holistically it is a great place to catch IOCs.

I think I found the one Hacker News in this thread that actually works in security ops.
There's good money to be made selling a solution that detects and blocks rogue DoH requests.

Anyways, it's possible: https://dl.acm.org/doi/abs/10.1145/3407023.3409192

^^^THIS^^^

Especially given that malicious JavaScript can now make DoH toward their distributed command and control centers.

Why they advised DoH and not DoT? DoT is simpler, no http cookies ambiguity. Easier to block counter argument does not really apply to businesses...
For non-malicious apps, generally speaking DoT is something you need to specifically enable, whereas certain major applications are working towards using DoH by default (or they already do [0]). DoH is also mixed with regular HTTPS traffic, so it is much harder to detect and act upon - so businesses need to spend more effort to counter it. As a bonus, most of the mitigations in use here also apply to DoT, so you are also getting it in the bargain...

[0] https://blog.mozilla.org/blog/2020/02/25/firefox-continues-p...

There has certainly been evidence of censorship amongst the thousands of third party open resolvers. Are there any examples of known "malicious" third party DoH or DoT resolvers. Has anyone been studying this.
Nice try NSA
Could someone create a replacement for DNS entirely please?

DNS does WAY more than what the typical user needs it for and services that present it are resultantly much more complex than what is needed for the 99% use case.

The 99% use case: resolve x.y.z to some IP address.

What I think should happen:

1. At each level, a public/private keypair is used to authenticate valid records for the name. Eg: .com has public/private keypair(s) to represent who can sign x.com records. .com owner only needs to publish these. Reliable sources ( ISPs etc ) can then share these.

2. The x.com records themselves would be: Mapping from x.com to IP address(s) / public key.

3. The x.com owners could then publish out their x.y.com records freely and they could be mirrored by everyone.

Unlike the current methodology, there would be far less need to trust where you get the records from. The public/private keypairs should change WAY less frequently.

Agreeably in such a widely distributed system you wouldn't have nice TTL, but that is for the better. DNS records should not be changing that frequently.

Such a new system also should be done in a fully distributed way and NOT controlled by a bunch of money grubbing bastards who make way too much money from records.

It should NOT cost $20/yr to own a record pointing x.y to a number. It's absurd and really needs to stop.

Did you just reinvent DNSSEC...?
Bunch of garbage, NSA and FBI hate ESNI.

Firefox silently pulled all production ESNI code as of v83 without a word of warning to anyone. As in, the Firefox development team simply killed encrypted SNI and told nobody that may have been using ESNI in despot regimes, in exchange for future ECH support which is not implemented anywhere yet.

Nor will ECH be endpoint supported any time soon.