Comment by peterwwillis | Hacker News Reader

Comment by peterwwillis | Hacker News Reader

Parent Full thread

Putting it another way:

"Why isn’t DNSSEC good enough?

DNSSEC attempts to guarantee that domain names are resolved to correct IP addresses. However, DNS resolution is just one aspect of securely communicating on the internet. DNSSEC does not fully secure a domain:

- Once DNS resolution is complete, DNSSEC does not ensure the confidentiality or integrity of communication between a client and the destination IP.

- No major web browsers inform the user when DNSSEC validation fails, limiting its strength and enforceability.

HTTPS guarantees the confidentiality and integrity of communication between client and server, and web browsers have rigorous and evolving HTTPS enforcement policies."

> https://https.cio.gov/faq/

And:

"Registrars can still theoretically abuse their position because they're responsible for communicating your intentions to the root servers. This includes information about your DNSSec keys. This relationship will never change; if you can't trust your registrar, then get a new registrar.

DNSSec doesn't prevent MITM attacks. It absolutely prevents DNS spoofing. But there are other ways of inserting yourself into a traffic flow than just DNS spoofing."

> https://security.stackexchange.com/questions/11566/how-does-...

^"No major web browsers inform the user when DNSSEC validation fails, limiting its strength and enforceability"

-- when DNSSEC validation fails, the domain is unreachable: www.dnssec-failed.org. The browser doesn't have to warn the user, the resolver will fail to return the DNS answer altogether.

With a non-validating stub resolver you'll have no idea if DNSSEC is being used at all, much less if DNSSEC fails and it falls back to plain DNS. And most OSes up to this point use non-validating stub resolvers.

From a user's perspective, DNSSEC is merely the potential to be more secure; until they personally verify it is working for them, they have no idea if they are actually more secure or not. And you have to do this per device, per OS.

I just pulled up http://www.dnssec-failed.org/ on both my laptop and my Android phone, it loaded just fine. So DNSSEC failed to prevent either of these devices from loading an invalid domain. But I had no notification that DNSSEC failed; the page just worked!

If the browser actually informed me that DNSSEC isn't being enforced at all, I would at least know i'm not as secure as I could be.

On a [EDIT:] 2.5yo chromebook and on a moto e (total value, new, unsubsidized, of both devices: $250) that site doesn't load, with "ERR_NAME_NOT_RESOLVED". You can't hold dnssec responsible for your choice of broke-ass old-n-busted clients. What other security system would be held to that standard?

I'm using Android 5.0 and Windows 7. If those are broke-ass old-n-busted clients, screw modern technology.

Even if they were old-n-busted, your network must also use a DNS resolving server that supports DNSSEC. So even if your client has the right stub resolver, the network you connect to determines whether your client can make a secure connection or not.

Assuming both the client and network were correct, you still have no idea if it worked or not! If you are a really smart user who thinks a site should be using DNSSEC and you try to go to that site, and your dns resolver supports DNSSEC properly, all you get back from trying a bad site is the domain wasn't resolved.

Is DNSSEC broken? Was the domain name wrong? Do I not have an IP on the network? Did something else happen? Who the fuck knows? Not the user, who gets back a generic error message if DNSSEC is working, and gets no error message if DNSSEC is not working.

So it only works reliably when it's broken. What a fantastic security system.

None of that happens with HTTPS, of course. With HTTPS the only thing that determines the security of the connection is whether the client validates its certs (and all browsers do). If it fails, you get an error and a big scary warning page.

Even if they were old-n-busted, your network must also use a DNS resolving server that supports DNSSEC. So even if your client has the right stub resolver, the network you connect to determines whether your client can make a secure connection or not.

Good point! I didn't know that. Perhaps that's what you're running into, since Android 5.0 seems to be working fine for me? For a long time we all just used whatever DNS server we got from DHCP, but I think the time for that has passed. At this point we should choose our own recursive DNS provider, and reconsider using networks that don't allow that.

> At this point we should choose our own recursive DNS provider

Assuming you control your device (non-corporate non-government users) and know how to configure your DNS server (elite users only) and wanted to do this extra step (privacy-conscious people?), this will break for hotels, airports, cafes/restaurants, corporate/government networks, anyone with an ISP that intercepts public DNS requests, and various home routers. Not to mention making surfing the web much slower and less reliable, since we distribute name servers specifically to rely on caching to lower latency and increase availability in case of various network failures.

But otherwise, sure, that works.

Assuming you control your device...

If this isn't the case, then I know that the device operates not in my interest, but in that of whoever controls it. So, I probably won't be entering any sensitive information into it.

Like your work e-mail?

Email is rarely a good place for sensitive information. DNSSEC is not a panacea, but it does make Eve's job harder. https://insights.sei.cmu.edu/cert/2014/09/-probable-cache-po...

This is a bigger problem than I think people think it is.

Reply on news.ycombinator.com