Hacker News Reader

Comment by axaxs | Hacker News Reader

DNSSEC adoption is growing each year. Constantly dismissing it does not make that fact nor DNSSEC itself magically disappear. You mention that the queries themselves are not encrypted, but know (I hope as a security guy) that it is not the goal of DNSSEC, so why bring this up? In a perfect world, perhaps every query will be done over TLS. But until every piece of the chain guarantees this, DNSSEC is necessary to ensure the answer wasn't spoofed. You can think of a million better alternatives, but it's extremely hard to get the whole world to change...

View on HN

Actually, on a percentage of zones signed basis, or queries issued, DNSSEC penetration shrinks each day.

He mentions encryption since the vast majority of people believe DNSSEC provides some level of privacy, encryption, or security. Most of us in the industry who aren't financially aligned to support DNSSEC recognize it does little to nothing in this area; while simultaneously adding complexity and brittleness.

The only benefit DNSSEC offers (imho) right now is DANE-like services. And guess what? There are much easier ways to accomplish that.

Percentage based statistics are just as misleading. To me this data only says that personal/adspam/squatter zones are growing at a faster rate than those with integrity considerations. In raw numbers, adoption is growing. The consensus is that DANE requires 2048 zsk, which none of the big players are using to my knowledge. In that regard, I think DANE is easier to replace at this point.

The number of DNS resolutions that occur in the US and Europe that use DNSSEC is, as a fraction of all DNS resolutions, below the noise floor. That's the correct metric, by the way: DNSSEC in use.

DNSSEC realists are curmudgeonly about this stuff in part because DNSSEC advocates have been saying things like "DNSSEC is growing" since nineteen ninety-nine.

DANE is even worse than plain-old DNSSEC. For those of you who don't know what it is: DANE allows the DNS to vouch for your certificates. In other words: whoever controls the DNS roots effectively controls your certificates.

You can in some sense sum up the cryptographic competence of DNSSEC by observing, as you have, that many of its largest deployers still use RSA-1024. If you have any actual interest in cryptography, here's a fun little research project: go find out the padding format those deployments use. :)

> DANE is even worse than plain-old DNSSEC. For those of you who don't know what it is: DANE allows the DNS to vouch for your certificates. In other words: whoever controls the DNS roots effectively controls your certificates.

Please explain to me HOW the person who controls the DNS roots controls my certicate? I take my TLS certificate (either a CA-signed cert or a self-signed cert) and I load either a fingerprint of the cert or the complete cert into a TLSA record in my DNS zone. I then sign that with my DNSSEC key (create an RRSIG record) and publish it in the zone. It's all under my control.

(NOTE: For those not familiar with the DANE protocol please see RFC 6698 or resources here: https://www.internetsociety.org/deploy360/resources/dane/ )

The DNS root can alter your records to be whatever they want.

Sure, they can already change your MX now and get a CA to sign a new cert by intercepting the email. But a replacement protocol should have much better design goals.

Yes. Just change the word "should" to "MUST".

How can the DNS root alter my records?

Say my domain is "example.com" and I serve the zone out of my own authoritative DNS server running on my own host. I create a "www" record that I serve out pointing to my site's IP address. Leaving DNSSEC out for a moment, how can the DNS root alter my records?

All the DNS root does is provide pointers to the .com authoritative name servers. The .com name servers provide pointers to my example.com name server. My example.com name server serves out the zone data.

I mean the TLD root. Aka the .com registrar.

Ah, gotcha. Sure, the .COM registry could return NS records for example.com pointing to a controlled name server that could then return an A record pointing to a controlled web server that wasn't mine.

And those false NS records could be modified by the registry (unlikely in the case of .COM but could conceivably be for a ccTLD) or more likely the registrar (after a compromise there).

I think you're playing a semantic game with the word "alter". The roots can't "alter" your records. They can prevent other people from seeing those records, though, and replace them with an entirely different set of records.

I was not playing a game. I was honestly trying to understand because it didn't make any sense to me.

I don't see the actual root of DNS being able to do much at all. If the root tried to give altered NS records for one of the TLDs I believe that would be noticed by many out there.

The TLD registries could give altered NS records pointing to a controlled authoritative name server for a domain, and then THAT controlled name server could provide an entirely different set of records. (And they could all be DNSSEC-signed.)

But to me this is kind of DNS security 101 - you have to trust your parent zones and you have to trust your registrar. If you think that a TLD registry or registrar could do this kind of change... don't use them.

> You can in some sense sum up the cryptographic competence of DNSSEC by observing, as you have, that many of its largest deployers still use RSA-1024. If you have any actual interest in cryptography

... you could also help improve the DANE protocol. The DANE Working Group within the IETF is open to all. The mailing list is at:

https://www.ietf.org/mailman/listinfo/dane

FYI, the working group will be meeting Tuesday afternoon (July 22) here at IETF 90 in Toronto, Canada, from 16:40-18:40 EDT. Agenda is:

https://datatracker.ietf.org/meeting/90/agenda/dane/

Streaming audio is at:

http://ietf90streaming.dnsalias.net/ietf/ietf902.m3u

Jabber chat room at: dane@jabber.ietf.org

You're certainly welcome to show up and ask questions about the crypto involved. :-)

No, RSA-1024 does not sum up the cryptographic problems of DNSSEC. If it did, I would have just said that.

"Actual" interest in cryptography?

You managed to successfully refute and argue with...yourself I think.

>"Actual" interest in cryptography?

I was replying to your reply and quoted part of your message and just snipped it off without really indicating that I had just ended it. The way it came out on the HN page it is hard to see that it was your message versus mine. :-(

RSA-1024 is an easy problem to fix; it's not baked into the protocol. Other crypto problems in DNSSEC, not so much, sorry.

> whoever controls the DNS roots effectively controls your certificates

This is misleading at best.

He who controls the DNS root servers controls absolutely nothing.

He who controls the DNS root zone could, in theory, re-delegate a whole top domain to a malicious third party and thereby control your domain via this new top domain, thereby get control of your DANE certs.

Don't you think the Internet at large would notice, and immediately route around the problem?

When was the last time you saw an illegitimate top domain transfer? Never, that's when.

Even if it was true that targeted changes were impossible this would still be a bogus argument. But it isn't true; attacks can be carried out surgically against small targets.

How? Please explain how an attack can be carried out surgically against small targets from the root?

Please elaborate further. You've been alluding to that is a series of comments here. If it's too much for a reply do it in a blog post somewhere. You will find that people take reasonable arguments a lot more seriously.

Who in the industry, whether they are "financially aligned" or not, claims that DNSSEC provides you with privacy or encryption? The DNS data is sent in the clear.

No-one who uses DNSSEC is arguing it keeps your DNS records private. It is a straw man argument to suggest otherwise.

DNSSEC is designed to provide tamper-evidence, not privacy.

It's not a straw man to point out that the protocol that ostensibly "secures the DNS" does not in fact encrypt DNS queries or responses. I wasn't merely saying that DNSSEC records are plaintext (though they are). I was pointing out that the last mile from server to resolver has no cryptography whatsoever. Resolvers don't speak DNSSEC to servers --- it's a server-to-server protocol.

This is a common tactic among DNSSEC advocates. Observation oft he inexplicable lack of last-mile security --- the one place where the Internet could actually benefit from DNS security --- is dismissed as a "straw man". Yes, it's very inconvenient to arguments for DNSSEC adoption. No, that doesn't make it out-of-bounds.

> This is a common tactic among DNSSEC advocates.

Hmm... as a "DNSSEC advocate", I can say that I've never dismissed the lack of last-mile security as a "straw man". It's a real issue - but NOT one that DNSSEC seeks to solve. Because of this issue, many of us who advocate DNSSEC also advocate that the DNSSEC validation happens as close as possible to the end user, including even within the applications used by the user. If not in the apps then in the operating system. And if not there then on the local network... but then you start expanding the zone of risk. For the DNSSEC integrity validation to be useful it needs to happen as close as possible to the user - OR have a secured connection between the user and their DNS resolver.

From a DNSSEC advocacy point of view, I'm always glad when a provider of DNS resolvers turns on DNSSEC validation... but public DNS servers are farther away from the end user than I would personally like to see. It's a good first step... but we really need the integrity validation happening close to the user.

A protocol already exists that does a significantly better job both of providing query integrity and confidentiality on the "last mile" for DNS: it's DNSCurve. DNSSEC on the other hand is almost perfectly unsuited for last mile security, requiring as it does every enabled resolver to act as it's own fully recursive cache. DNSSEC almost petulantly fails to provide confidentiality, too.

2014 advocacy for DNSSEC seems to me like distilled sunk-cost fallacy. It sucks that people spent 2 entire decades working on this protocol (most of the design is still traceable to TIS!), but they did, and it didn't work out, and now they should move on.

The manifold weaknesses of DNSSEC are completely unnecessary. The protocol has no meaningful deployment. Inflicting it on the internet in 2014 would be a grave and unforced error. Do better.

Thomas, DNSSEC has nothing to do with last-mile security, nor does it have anything to do with confidentiality. You know that. Neither of those is the problem DNSSEC solves.

> 2014 advocacy for DNSSEC seems to me like distilled sunk-cost fallacy.

2014 advocacy for DNSSEC is merely a continuation of advocacy that has been going on for years now. The root zone of DNS was only signed 4 years ago. It's taken those 4 years to get almost all the gTLDs signed and 2/3rds of the ccTLDs signed. It's taken those years to get the DNSSEC-related tools to the point where the configuration and deployment is as simple as it is now. It's taken those 4 years to get the pieces in place where it can work well... and there's still more work to do.

> The manifold weaknesses of DNSSEC are completely unnecessary. The protocol has no meaningful deployment.

I've quoted many deployment statistics in other parts of this thread. You dismiss them. That is your right. But to say it has "no meaningful deployment" is to dismiss the great amount of work that has happened all over the world by developers and network operators who DO see DNSSEC as something useful. To go back to one I've quoted here - there are 18 million Comcast customers in the USA that have all of their DNS queries validated by DNSSEC. To me that is a meaningful deployment.

> Inflicting it on the internet in 2014 would be a grave and unforced error. Do better.

We are doing better. In the view of myself and many others, DNSSEC makes the Internet more secure. We're implementing it. We're deploying it.

If you've got a better idea bring it to the IETF and lets have the debate in the standards mailing lists.

I agree that DNSSEC has nothing to do with last-mile DNS security! Where we differ is that you don't seem to care that it doesn't, whereas I am completely bewildered by the idea that anybody could advocate investing tens of millions of dollars into a forklift upgrade of DNS infrastructure that would solidify government control of Internet privacy without doing anything to solve the most urgent problem with the DNS --- if there is an urgent problem with the DNS at all, which is debatable.

The root zone of DNS was signed 4 years ago, but the DNSSEC protocol has been under development since the early nineties, back when the forum for discussing it was dns-security@tis.com. That's approximately how long I've been following DNS security. The record names changed during the typecode roll in 2003, but if you blur your eyes, DNSKEY, RRSIG, and NSEC are just KEY, SIG, and NXT, and the core DNSSEC protocol --- authenticated denial, offline signing, no confidentiality --- is the same as the one TIS worked on under US federal government contract back in 1994.

I'm not simply "dismissing" the statistics you're providing. I'm challenging them. One US provider runs a DNSSEC-compatible resolver system. So what? Google DNS enabled DNSSEC years ago. You're talking about decisions that perhaps tens of people at those companies made and executed. So a cabal of hobbyists enabled DNSSEC at Comcast. What percentage of DNS queries at Comcast return DNSSEC-authenticated names? I don't know, but I'll put money on my guess: an infinitesimal fraction, because DNSSEC isn't deployed across the Internet.

DNSSEC makes the Internet less secure. It's a government contract that morphed into a standards committee boondoggle --- don't take my word for that, just read any of the mid-2000s Vixie mails to namedroppers begging the group to just please standardize something --- that has been beset for two decades by grievous technical flaws, ranging from the delegation signer debacle through the Unix-password-file-cracking NSEC3 scheme. It hands control over a critical piece of security infrastructure to world governments. It does all this without solving the most important DNS security flaws. Meanwhile, those of us who work in security can't help but notice that despite the lack of any DNS security over and above randomized source ports and query IDs, the Internet is not falling apart... because it's been designed and built over the last 15 years not to rely on the DNS for security.

It's taken two decades to get to this point because signing individual DNS records and treating zones as the fount of all truth on the Internet is the wrong design. There is too much data in the DNS to boil the ocean and sign every record individually, and even if you could, if the last 10 years have taught us anything at all, it's that Internet trust doesn't work like a tree with a single root. Global hierarchical PKI is dead. Let it rest in peace.

Thanks for writing that response. I certainly agree DNSSEC could be improved (which is a large part of why I'm at IETF90 in Toronto this week).

On whether DNSSEC makes the Internet more or less secure, I think you and I will just have to continue to disagree.

Thanks, though, for the discussion. I enjoy having my views challenged and this has been very helpful. I have to sign off now for the night, though, but thanks.

Reply on news.ycombinator.com