4 ms·
Seriously? I'll give you two differences right off the bat: 1. DNSSEC only protects the name lookup for a host, and TLS/HTTPS protects the entire session. 2.
by tptacek 8mo ago
Seriously? I'll give you two differences right off the bat:
1. DNSSEC only protects the name lookup for a host, and TLS/HTTPS protects the entire session.
2. People actually rely on TLS/HTTPS, and nobody relies on DNSSEC, to the point where the root keys for DNSSEC could be posted on Pastebin tonight and almost nobody would have to be paged. If the private key for a CA in any mainstream browser root program got published that way, it would be all hands on deck across the whole industry.
- indolering 8mo ago> DNSSEC only protects the name lookup for a host, and TLS/HTTPS protects the entire session. It only provides privacy, it doesn't verify that the resolver didn't tamper with the record. >to the point where the root keys for DNSSEC could be posted on Pastebin tonight and almost nobody would have to be paged. This would very much be a major issue and lots of people would immediately scramble to address it. The root servers are very highly audited and there is an absurd amount of protocol and oversight of the process.
- tptacek 8mo agoWho? Outside of DNS providers, which organizations would need an emergency response to the collapse of DNSSEC security? Be specific; name one. If TLS security collapsed, I could pick a company from the Fortune 1000 at random, and they'd have an emergency response going.
- indolering 8mo agoIf DNS PKI is compromised, so is HTTPS. So yes, they would be scrambling too.
- tptacek 8mo agoThis is obviously not true.
- indolering 8mo agoDNS is where domain name authority is delegated. Anything you build on top of that is also going to be a world of hurt if it gets compromised.
- akerl_ 8mo agoSo why are we not constantly seeing real world compromises of major sites that don't use DNSSEC?
- gzread 8mo agoHere's one: https://notes.valdikss.org.ru/jabber.ru-mitm/ https://notes.valdikss.org.ru/jabber.ru-mitm/
- akerl_ 8mo agoI don't see any indication that DNSSEC would have been relevant there? Their assessment was that that interception (and certificate issuance) were completed by redirecting traffic for the legitimate IPs to another destination. The DNS records continued to work as expected.
- gzread 8mo agoYou requested: > real world compromises of major sites that don't use DNSSEC? Without any other changes to this infrastructure DNSSEC by itself wouldn't have prevented this, but it could have been combined with something else like a CAA record.
- akerl_ 8mo agoSure. I guess by that logic this attack also could have been prevented by flossing, as long as you combined flossing with setting a CAA record.
- cyberax 8mo agoDNSSEC can be trivially used with DANE to protect the entire session. The browser vendors quite consciously decided to NOT do that. > 2. People actually rely on TLS/HTTPS, and nobody relies on DNSSEC Sure. But I treat it as a failing of the overall ecosystem rather than just the technical failure of DNSSEC. It's not the _best_ technology, but it's also no worse than many others. This is the outcome of browser vendors not caring at all about privacy and security. Step back and look at the current TLS infrastructure from the viewpoint of somebody in the 90-s: You're saying that to provide service for anything over the Web, you have to publish all your DNS names in a globally distributed immutable log that will be preserved for all eternity? And that you can't even have a purely static website anymore because you need to update the TLS cert every 7 days? This is just some crazy talk! (yes, you technically can get a wildcard cert, but it requires ...drumroll... messing with the DNS) The amount of just plain brokenness and centralization in TLS is mind-boggling, but we somehow just deal with it without even noticing it anymore. Because browser vendors were able to apply sufficient thrust to that pig.
- ekr____ 8mo ago> DNSSEC can be trivially used with DANE to protect the entire session. The browser vendors quite consciously decided to NOT do that. 100%. The reasons why are explained in some detail here: https://educatedguesswork.org/posts/dns-security-dane/ https://educatedguesswork.org/posts/dns-security-dane/. The TL;DR is that by the time DANE was created the WebPKI already existed and was universal and so adding DANE didn't buy you anything because you still were going to have to have a WebPKI certificate more or less in perpetuity. > This is the outcome of browser vendors not caring at all about privacy and security. This is false. The browser vendors care a great deal about privacy and security. Source: it was my job at Mozilla to care about this, amongst other things. It may be the case that they have different priorities than you. > You're saying that to provide service for anything over the Web, you have to publish all your DNS names in a globally distributed immutable log that will be preserved for all eternity? Well, back when people were taking DNSSEC and DANE more seriously, there was a lot of talk of doing DNSSEC Transparency. > And that you can't even have a purely static website anymore because you need to update the TLS cert every 7 days? This is just some crazy talk! This is hyperbole, because nobody is forcing you to update the TLS cert every 7 days. It's true that the lifetimes are going to go down to 45 days eventually and LE offers 6 day certificates, but those are both optional and non-default. Moreover, the same basic situation applies to DNSSEC, because your zone also needs to be signed frequently, for the same underlying reason: disabling compromised or mississued credentials.