3 ms·

It's an interesting thread. DNS security seems important, when the DNS cache poisoning vuln came out everyone was harping about how we need to secure the Intern

by pas 7y ago

It's an interesting thread. DNS security seems important, when the DNS cache poisoning vuln came out everyone was harping about how we need to secure the Internets! What happened? DoH or DoT is nice, at least you can pick your poison, if you will, by picking your resolver, but they are still just feeding you whatever they got from auth resolvers around the world via whatever packets they happen to have received. Sure, then use TLS as the next step. And that might work if browsers and the CA/B gets serious, but who knows, there are still nation state CAs everywhere by default. Wouldn't it be easier to set up DNSSEC and a lot of Cert Transp style notaries that can catch Uncle Sam and the 4 other eyes in the act?

tptacek 7y ago
When Kaminsky's vulnerability was published it was mitigated by randomized ports almost immediately, and Dan Bernstein's DNS server --- which always randomized --- wasn't susceptible. In fact, Kaminsky's vulnerability is derivative (not to take anything away from it; it's authentically clever) of a line of cache poisoning vulnerabilities from 1997 --- that is to say, we had a dry run for it in the 1990s. Bernstein's response to the 1997 vulnerabilities was to fix his server; Vixie's response was to say "DNSSEC will fix this" and do nothing. A decade later and we saw which approach was correct: in a sense, DNSSEC caused the Kaminsky vulnerability. You can't use DNSSEC to "catch Uncle Sam in the act", because "Uncle Sam" has de jure control over the domain names you care about. What's worse, Certificate Transparency actually has caught misissuing CAs, and the consequences for those CAs has been lethal: Chrome and Mozilla put the largest commercial CA on the Internet out of business over misissuance. When CA's misbehave, we can revoke them. We can't do that with DNSSEC: when .COM misbehaves --- and it will, we know, because it already has --- we remain stuck with it. The DNS is absolutely not trustworthy enough to store keys.
- pas 7y ago
  > because "Uncle Sam" has de jure control over the domain names you care about I know, and that's okay, if we knew what are those actual actions, and were there a log of those people could decide what to do. To me this sounds like an opportunity to decentralize DNSSEC, skip ICANN, let TLDs pick "trust root providers", make it tamper evident, and the resolvers will maintain the trusted set of roots. Or not, and just don't put keys into DNS and learn to live with the additional network round-trips required for the workarounds. :( (Like MTA-STS, which, on the other hand, is great. Relatively easy to deploy, opt-in, has a time-lock like HSTS, so sort of resilient. But still a workaround.)

by pas 7y ago

tptacek 7y ago

When Kaminsky's vulnerability was published it was mitigated by randomized ports almost immediately, and Dan Bernstein's DNS server --- which always randomized --- wasn't susceptible. In fact, Kaminsky's vulnerability is derivative (not to take anything away from it; it's authentically clever) of a line of cache poisoning vulnerabilities from 1997 --- that is to say, we had a dry run for it in the 1990s. Bernstein's response to the 1997 vulnerabilities was to fix his server; Vixie's response was to say "DNSSEC will fix this" and do nothing. A decade later and we saw which approach was correct: in a sense, DNSSEC caused the Kaminsky vulnerability. You can't use DNSSEC to "catch Uncle Sam in the act", because "Uncle Sam" has de jure control over the domain names you care about. What's worse, Certificate Transparency actually has caught misissuing CAs, and the consequences for those CAs has been lethal: Chrome and Mozilla put the largest commercial CA on the Internet out of business over misissuance. When CA's misbehave, we can revoke them. We can't do that with DNSSEC: when .COM misbehaves --- and it will, we know, because it already has --- we remain stuck with it. The DNS is absolutely not trustworthy enough to store keys.

pas 7y ago
> because "Uncle Sam" has de jure control over the domain names you care about I know, and that's okay, if we knew what are those actual actions, and were there a log of those people could decide what to do. To me this sounds like an opportunity to decentralize DNSSEC, skip ICANN, let TLDs pick "trust root providers", make it tamper evident, and the resolvers will maintain the trusted set of roots. Or not, and just don't put keys into DNS and learn to live with the additional network round-trips required for the workarounds. :( (Like MTA-STS, which, on the other hand, is great. Relatively easy to deploy, opt-in, has a time-lock like HSTS, so sort of resilient. But still a workaround.)