[wtallis]

DNSSEC only seems unnecessary under the assumption that you're already making full use of existing security measures everywhere else in the stack. If you live in a world where unencrypted HTTP still exists then it's nice to have some defense against ISPs who like to lie in DNS responses. And even if I am connecting over HTTPS through a shady ISP, I'd prefer not to send any packets at all to the wrong IP rather than wait until it presents the wrong certificate.

[chimeracoder]

> If you live in a world where unencrypted HTTP still exists then it's nice to have some defense against ISPs who like to lie in DNS responses.

As tptacek and others have pointed out numerous times elsewhere on HN (and in the article linked above):

1. DNSSEC doesn't protect against ISPs hijacking DNS responses

2. TLS is easier to deploy than DNSSEC

3. TLS provides more security for the end user than DNSSEC does

3a. If TLS us used, DNSSEC provides essentially no additional security benefits to the end user.

So really, it makes sense to be advocating the use of TLS, which is what projects like Let's Encrypt are all about. DNSSEC is at best a waste of resources that could be better spent on actually securing the Internet through TLS, and at worst actively harmful (because the strongest criticism of TLS is that it centralizes trust in CAs, and DNSSEC centralizes trust even further - in a single entity!)

> I'd prefer not to send any packets at all to the wrong IP rather than wait until it presents the wrong certificate.

I'm not sure what difference it makes to be sending packets to the wrong IP. The whole point of TLS is that it doesn't really matter, because they can't read what you're sending anyway.

Also, the way the Internet works, you're always sending packets through the "wrong" IP addresses, so you should make the assumption that your raw traffic is visible to to any eavesdropper (and therefore encrypt your traffic so that this is not an issue).

[wtallis]

> 1. DNSSEC doesn't protect against ISPs hijacking DNS responses

DNSSEC protects signed zones by allowing clients to notice a suspicious lack of a valid signature on responses that should have been signed. DNSSEC doesn't protect unsigned zones, but that shouldn't surprise anyone and isn't really an indictment of DNSSEC's capabilities.

> I'm not sure what difference it makes to be sending packets to the wrong IP.

That malicious IP gets to record what kind of connection my computer was trying to make to that domain, even if the connection attempt is aborted relatively early. That's more information being leaked than if my computer had been able to determine that it got a probably-spoofed DNS response and aborted there.

Playing shenanigans with the DNS server is a lot easier than full-scale snooping and tampering on all traffic, which is why ISPs commonly do the former but the latter is usually only done with NSA involvement.

It needs to be hard for ISPs to direct all mistyped domain names to their own advertising (and in the process, implicitly pretending that the Web is the only use for the Internet) or to claim that sites they don't like don't exist. DNSSEC helps with that.

[icebraining]

But the clients' stub resolvers don't validate the answers, so how can they notice the lack of a valid signature?

[wtallis]

Some clients don't validate. Some do. Everything on my home network is protected because my router's instance of dnsmasq validates. When I'm away from home, there's dnssec-trigger and a Firefox extension.

I really don't understand why the existence of software that doesn't try to take advantage of DNSSEC is being used as evidence that DNSSEC is incapable of doing something.

[chimeracoder]

> I really don't understand why the existence of software that doesn't try to take advantage of DNSSEC is being used as evidence that DNSSEC is incapable of doing something.

It's not that DNSSEC is fundamentally "incapable" of doing this, but that it's literally not what the protocol is designed to do. As noted in the other HN thread on this announcement, the DNSSEC protocol is explicitly not designed for end-user verification, and end-users are discouraged from running their own valdiators. There's a reason that browsers don't support this out-of-the-box and (more importantly) don't ever plan on it.

If you're concerned about people snooping on your TCP packets, DNSSEC doesn't solve that. If you're concerned about people spoofing DNS responses, DNSSEC doesn't solve that[0]. TLS + HSTS does solve that, by making it impossible to load a forged page, regardless of what DNS records were returned[1].

Again, TLS solves all the problems you describe (including the problem of ISPs redirecting mistyped pages to their own advertising pages). TLS is also supported by every browser, out-of-the-box. It's more secure, easier to deploy, and already widely used.

[0] Again, as explained in the post, DNSSEC is not designed to protect end-users against malicious ISPs. This is literally a matter of what problems DNSSEC is even aimed at solving.

[1] Notice how http://google.com (not even https://) will never redirect to a captive portal. That's not DNSSEC. That's TLS + HSTS. DNSSEC is redundant in this situation.

[wtallis]

> [...] but that it's literally not what the protocol is designed to do.

> the DNSSEC protocol is explicitly not designed for end-user verification

> This is literally a matter of what problems DNSSEC is even aimed at solving.

Repetition doesn't make that argument any more valid. If DNSSEC wasn't intended to have this capability, it's for the same reasons that it wasn't intended to be used for on-the-fly signing: it was designed in the mid-'90s when that was impractical. Nowadays it is practical and it does in fact work just fine for this purpose, and it provides an extra layer of defense in depth and stops some attacks sooner than TLS can and provides some added security to things that aren't using TLS (because remember, there's more to the Internet than just the WWW, and many of those things don't have the aggressive upgrade cycle that Chrome uses).