Why CISA Issued Our First Emergency Directive

Hmm, interesting. The high profile ones seem to go through without any more than a ceremonial objection so those less prominent ones are surprising.

Thanks for checking this!

Not accurate at all. The senate has all the party line votes it needs. Theres no 'slow walking' around that. The reason the appointees aren't there is becuase the Trump admin hasnt appointed them.

Do you guys just blame the Democrats for everything? It seems dishonest.

Sorry, but from the earliest point in Obama's presidency, the Republican side of Congress stated that it was their goal to make him a one term president.

There has never in US history been more stonewalling than there was during 6 years of the Obama presidency.

Yeah I read it; I was highlighting this for parent.

For sure, you can totally make something like this happen, but again that means writing and securing a bespoke system. If you’re a team managing your AWS infrastructure with Terraform, it sucks to have to write a totally different system (and all the secrets management that goes along with it).

Additionally, for a government agency you could have dozens of contractor teams, and you need a method of securing access for all of them. It’d be much easier to just use Route53 and delegated subdomains, as all teams are largely deployed and managing infra (with MFA) there.

But it’s not allowed, because DNSSEC.

One of the problems with DNSSEC is that it causes the size of DNS responses to increase substantially, which becomes a DDoS vector. The response to this is nominally to use response rate limiting, but the more people who use DNSSEC the less effective that is because it means more DNS servers the attacker can use to reflect their attack through without reaching the rate limit for any one. (RRL is also not ideal because a large DNS cache can hit the rate limit by just making a large number of legitimate queries.) And the more servers that use DNSSEC the harder to block a DDoS attack because it comes from a larger number of unique addresses.

And now TXT records used for domain validation are becoming quite large as well. You add a ~hundred byte TXT record for each service you want to validate your domain against, but they all want the entry to go in the same place (at the root), so you do the DNS TXT query for the root and you get a big response. Adding DNSSEC on top of that might even blow the practical limit for UDP EDNS0 responses sometimes, never mind the DDoS potential.

There may be a solution for that one -- specify a location for each TXT record instead of everyone using the root, so Facebook uses _facebook-domain-verification.[example.com], Google uses _google-site-verification.[example.com], etc. Then you wouldn't get a dozen large TXT records in response to a single query because they're each at a different name. But that's not currently what companies are doing, and a purist wouldn't like it because in principle controlling _google-site-verification.example.com doesn't mean you control all of example.com.

Route53 was very slow to even enable CAA itself. They are not exactly at the bleeding edge of DNS features.

CA/B Baseline Requirement 3.2.2.8 says to do RFC 6844, and that CAs need to implement at least enough DNSSEC so that they can determine whether "the domain's zone does not have a DNSSEC validation chain to the ICANN root" because if there is no DNSSEC validation chain you can treat DNS failure as permission.

In practice most larger CAs just do DNSSEC entirely here, Let's Encrypt uses it everywhere. Deployability to ordinary end user clients remains poor due to middle boxes and local DNS implementations that are garbage, but if you actually control your network (as a competent CA should) then it isn't a problem.

The sort of CAs and CA-customer relationships where DNSSEC was argued to be problematic aren't going to be doing ACME CAA, or probably ACME at all.

[Edited to delete me confusing one ID for another]

> The article/directive specifically called out DNS account passwords on DNS hosting providers. If they were using support tickets and manually implemented changes by hand then there would not be an account.

I don't think it's difficult to imagine that, somewhere within the massive federal bureaucracy, there is a team that works on DNS record tickets filed by other parts of the bureaucracy, and logs into a web console with a DNS hosting provider in order to fulfill those tickets.

“If they were using support tickets and manually implemented changes by hand then there would not be an account.”

Your contracting team may not have a DNS account, but the contractor that deals with DNS changes certainly does.

The point is that all infrastructure really should be managed with code. If you managed DNS from Terraform you’d notice that your production DNS system was in conflict from what your code said it should be the next time a terraform plan/apply was run (which is happening all the time from dev or maybe CI). Without it you could go months or years without noticing a changed entry on a little used, but critical system. From what I remember this attack was ongoing for a couple years before it was noticed.

No. The assertion is that it does fail to provide a benefit in practical, real-world cases, but defends against a fairly niche attack.

There's a reason that 'tptacek called it "security theater". Its implementors could better spend that time on actual security measures for things that are much more likely to happen...like defense in depth for credential leaking.

It protects against targeted DNS poisoning, but that is already covered by TLS.