Hacker News Reader

Comment by tptacek | Hacker News Reader

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"?

View on HN

> 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!

> 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.

Reply on news.ycombinator.com