Hacker News Reader

With DNSSEC combined with HTTPS it is very reasonable to say that both you're connecting to the party you're expecting to connect to and in addition, no third party listening on the line either knows what host name or page you're visiting (only the IP address of the box).

No, because clients don't validate DNSSEC responses. You'd need to be running a full resolver in your machine, which OSs usually don't.

Also, with SNI¹ they'll know the hostname anyway.

¹ http://en.wikipedia.org/wiki/Server_Name_Indication

> I haven't heard many alternatives (in general).

These problems don't call for a general solution. We should respect the fundamental truth behind the end-to-end principle and solve these problems as close to the application as possible. The likely threats, appropriate default choices and trust model are all best understood by each application developer and building these solutions into Layer-3/4 is bound to cause short-term pain and reduce our long-term flexibility to meet new risks.

For example, EFF's STARTTLS Everywhere project takes into account the fact that a huge percentage of the world's mail moves between a small enough number of providers that human verification of announcements is possible. It also recognizes that the MX configuration for these providers is reasonably static, meaning that changes that propagate in minutes do not need to be accommodated. Small specific solutions like this can be rolled out and provide a real, tangible benefit to users much faster than we can upgrade the entire DNS system to provide a more general solution.

I agree that we need a DNS privacy solution, one that hopefully doesn't eliminate the existence of caching infrastructure.

> I agree that we need a DNS privacy solution, one that hopefully doesn't eliminate the existence of caching infrastructure.

Please do take a look at what the folks are doing within the DPRIVE working group of the IETF:

https://datatracker.ietf.org/wg/dprive/charter/

They are working on mechanisms to bring privacy / confidentiality to the "last mile" of DNS connections. Any input you have would be useful. (There's a link there to a mailing list to which you can subscribe.)

> I haven't heard many alternatives (in general).

From tptacek's FAQ ( http://sockpuppet.org/stuff/dnssec-qa.html ):

> What’s the alternative to DNSSEC?

> Do nothing. The DNS does not urgently need to be secured. > All effective security on the Internet assumes that DNS lookups are unsafe. If this bothers people from a design perspective, they should consider all the other protocol interactions in TCP/IP that aren’t secure: BGP4 advertisements, IP source addresses, ARP lookups. Clearly there is some point in the TCP/IP stack where we must draw a line and say “security and privacy are built above this layer”. The argument against DNSSEC simply says the line should be drawn somewhere higher than the DNS.

Right.... which is where I disagree with Thomas. I believe we should secure the integrity of answers from DNS.

I want a DNS we can trust.

I see DNSSEC as one of the many layers in any defense-in-depth security plan.

Yes, I acknowledge that there are some challenges with DNSSEC deployment... but those are what a good number of us are working on fixing.

I don't see "Do nothing" as a viable alternative.

Doing nothing is self-evidently viable. Virtually no business transactions in the world are protected by DNSSEC today. None ever have been. The onus is on you to demonstrate that DNSSEC is viable, because "no DNS security at all" clearly does work.

You keep walking face-first into this rhetorical brick wall. If you're going to say "doing nothing isn't viable", you need to have a ready response to the extremely obvious observation that the Internet seems to function pretty OK without DNS security. It's not 1994 anymore. You can't wave your hands and suggest that the Internet is going to get more serious in 10 years and need better security. It already needs the best security it can possibly get. It's just that DNSSEC isn't part of that mix.

I think it is unfortunate that you leave DNSCurve at the end. I think securing the DNS is a good thing regardless.

I found many of your criticisms of DNSSEC reasonable and well-informed, but the "do nothing" part puzzled me. The information security status quo isn't exactly excellent or ideal. DNS attacks (including monitoring of DNS queries) often form a part of other attacks. Many of those attacks are perhaps best mitigated at other layers, but not all have been, and at least something like query privacy can't be.

(Yes, I know DNSSEC doesn't try to address query privacy, so that problem isn't an argument for DNSSEC itself.)

Thomas, as you are well aware, the Internet of 1994 was an extremely different and much smaller world. I completely agree with this:

> It already needs the best security it can possibly get.

It's just that I believe that DNSSEC should be part of the mix.

For instance here's an example of some research out of CERT-CC back in September 2014 where hijacking of MX records is redirecting email to someone:

http://www.internetsociety.org/deploy360/blog/2014/09/email-...

As far as I can see, deploying DNSSEC validation on the networks of the affected mail servers - and receiving DNSSEC-signed MX records - would prevent them from delivering mail to servers in the middle.

It's things like this that I want to prevent.

I want a more secure Internet - and in my view DNSSEC helps.

I'm sorry, but I'm going to have to point out that your comment doesn't respond to mine in any way.

Once again: the 2015 Internet functions with no DNS security whatsoever. BGP announcements, themselves unencrypted, aren't protected with DNSSEC. Browsers don't use DNSSEC in any way and are in fact blind to it. Email will remain insecure with or without it. Credit card transactions are protected at a layer higher than DNS, one designed to assume that the DNS would always be insecure.

Why, specifically, is doing nothing to secure the DNS "not viable"?

> BGP announcements, themselves unencrypted, aren't protected with DNSSEC.

This is true, but only because BGP announcements don't involve DNS, and so all the DNS security in the world won't help. Agreed that there is a lot of scope for doing better on BGP security, though - and indeed DNS security.

The fact that "all the DNS security in the world won't help" is part of my point. There aren't really any places where "all the DNS security in the world" will help.

> Agreed that there is a lot of scope for doing better on BGP security, though

Yes... and there we go down the path toward BPGSEC, RPKI and other tools that people are developing to help secure the routing infrastructure.

> I'm sorry, but I'm going to have to point out that your comment doesn't respond to mine in any way.

Hmmm... you said " you need to have a ready response to the extremely obvious observation that the Internet seems to function pretty OK without DNS security "

I gave you one example. Here are some more:

- There are now over 800 XMPP servers with DNSSEC-signed SRV records that can be used to ensure they are talking to the correct servers. https://xmpp.net/reports.php#dnssecsrv

- On a related note, there are over 300 XMPP servers using DANE to provide a higher level of trust to TLS certs: https://xmpp.net/reports.php#dnssecdane

- There are now over 1,000 email servers using TLSA records (DANE) to provide a higher level of security to the TLS connections between email servers. (Viktor Dukhovni of exim)

These are very real cases where adding DNSSEC is, to me, increasing the security of DNS.

Because I'm around examples like these, I see value in securing the DNS. So to me, "doing nothing" is not an option.

Wait. The one place you suggest DNSSEC is adding security value is small servers for an unencrypted insecure messaging service: that is to say, the one place where NSA's almost total ability to manipulate the DNS would (a) most likely go completely undetected and (b) transparently cough up chat transcripts from private message sessions.

And one of the ways you suggest it could help is to allow clients to override TLS certificates and instead trust the government-controlled DNS.

That is an amazing concession.

Cert scanning projects and Certificate Transparency (edit: and pinning) may reverse this calculus or may already have reversed it, but of course the TLS certificates are commonly being issued on the strength of what unauthenticated DNS records said at the time of issuance. Adversaries that could tamper with a CA's view of a zone (or a route) at some point could cause cert misissuance, whether or not they could modify the underlying zone contents. The DNS is the underlying evidentiary basis for a substantial number of DV cert issuance events.

The second paragraph of "Against DNSSEC" addresses this.

Not conceding anything... just pointing out some of the use cases today that are interesting.

Another one is most of the email service providers in Germany, where DNSSEC / DANE are being seen as ways to have a more secure email environment.

The list can go on...

> And one of the ways you suggest it could help is to allow clients to override TLS certificates and instead trust the government-controlled DNS.

:-) Where did I say override, Thomas? You can, if you wish, use a different trust anchor than the current (broken) CA system, but the beauty of DANE is that it gives you a way to add another layer of trust to existing systems. So you can use a CA-issued TLS cert and put a fingerprint in a TLSA record as an added check during a SMTP transaction. You could also check certs with CT... and if it were HTTP you could do pinning as well.

As many layers as you want!

> because "no DNS security at all" clearly does work.

No it does not work. I have been the victim of DNS poisoning with a flood of requests that almost took my server down.

If DNS poisoning is so easy then DNS is not working correcting. If you want to get rid of DNSSEC then you need to say how you would fix it instead.

DNSSEC makes it easier to take servers down, not harder: a tiny UDP DNSSEC request generates a massive DNSSEC response loaded up with RSA key material.

So what is your alternative for solving DNS poisoning?

Exactly the same thing we do today! Assume the DNS is poisoned, and delegate security to higher layers so that there's not much point in bothering to poison it. Literally, my answer is DO NOTHING NEW.

> delegate security to higher layers so that there's not much point in bothering to poison it. Literally, my answer is DO NOTHING NEW.

That would not help my server - the DNS poisoning is acting like a DDOS. Sure the random victims know they are on the wrong page, but it doesn't help my server for them to know that.

Wonder if DNSCurve would solve that.

Isn't exactly the same form of DDOS --- not even reaching how many simpler ways there are to DDOS you --- available in DNSSEC, by injecting non-validating records?

Not exactly, as you don't cache non validating records (for very long).

> Plus with NSA mass surveillance, DNS makes seeing what domains you're visiting and building a "picture" of you as an individual absolutely trivial. The IP addresses still may help them do that to some extent, but it certainly becomes very easy if they can see your DNS packets.

FYI, there is a working group within the IETF working on the issue of providing confidentiality to DNS transactions. It's called DPRIVE and more info can be found here:

https://datatracker.ietf.org/wg/dprive/charter/

DNSSEC does nothing to prevent information leakage, the opposite in fact.

People compare it to SSL but it's not like SSL. It does NO encryption of the commuications. It's only validation (argubaly the most broken part of SSL).

A better ananlog to SSL would be DNSCrypt, which we've been using now for years, is slowly gaining traction and adoption by others, and provides real privacy from DNS messages from being intercepted or manipulated.