Hacker News Reader

Comment by tptacek | Hacker News Reader

I don't think the author of this article is really familiar with its subject. It's certainly not the case that "any security expert you ask will recognize the value of DNSSEC", or that we can all agree that it's a good thing. I'm far from the only security person saying DNSSEC is a very bad thing.

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

The roundup of implementation hurdles is gratifying to see (I missed the LWN article about it), since I think it's an under-appreciated cost of getting DNSSEC deployed.

As always, the biggest obstacle to DNSSEC is that it solves a problem nobody really cares about.

View on HN

> Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.

Um, he more or less did. Because he could have changes the A or CNAME records and gotten a DV certificate. And that certificate would have been legit, because bit.ly is genuinely subject to Libyan jurisdiction.

Sure, CT would have detected it. And any sane use of DANE (which might require an extension) would require CT plus DNSSEC. And, heck, DNSSEC would benefit greatly from a CT-like validation of domain signing keys.

None of this means that a failure to deploy DNSSEC is a good thing.

This is a little like saying that it would have been fine if Libya had simply been granted a root CA loaded in everyone's trust stores; after all, CT would detect the bad certificates.

The difference is, when a CA mis-issues, browsers can kill the CA, as they have done repeatedly in the last few years, to some of the biggest names in the business. You cannot do that do a TLD.

No, it’s a little bit like saying that Libya should be granted a root CA that is only accepted for .ly domains and only with appropriate CT records. Which actually seems quite reasonable to me.

Edit: Libya could create a bitly-like service and serve it up at bit.ly right now. What exactly would stop them?

> solves a problem nobody really cares about

DNSSEC was designed to protect from using forged or manipulated DNS data. Including all other records, like TXT, MX, CERT records, SSH fingerprints, IPSec public keys and TLS Trust Anchors.

I care that I can verify all this.

And being verifiable this means we don't need to care about how it gets transported to clients, which is a recurring theme in Internet design.

The TLS WG has a piece of work for how you shove the DNSSEC RRs into a TLS setup, so you can say "OK, I know DNSSEC but my resolver sucks, so, can you prove who you are with DNSSEC?" as an alternative to doing the Web PKI or some similar setup but with a private CA.

For example we saw this previously with OCSP in two ways: Firstly, any issuer working at scale does OCSP by pre-generating answers and shoving them into an ordinary CDN / reverse cache. The CA knows they issued cert X, and it was still good on Friday, they sign an OCSP response that says "I'm the issuer, cert X was still good as of today" dated Friday and they shove that into the cache. Now the CDN can deliver OCSP responses quickly and at scale without scattering OCSP signer keys all over the Internet. Clients can trust them because they're signed, even though the client talked to some CDN, not the issuer at all.

Secondly OCSP stapling. Instead of clients doing OCSP (and most often failing open since it's unreliable) let's have the server collect OCSP responses for its certificates periodically, and then "staple" the response to the certificate when delivering it. The OCSP signer and OCSP client never communicate at all, but since it's a signed message the client can trust that it's genuine.

You're one of the few. And I can't imagine why anyone would want to enroll their personal keys --- SSH, IPSEC, whatever --- into a global PKI. Your VPNs and SSH connections are more secure, objectively, outside of DNSSEC.

Only if you have an out-of-band way of verifying SSH keys. In my experience, 9 out of 10 times that doesn't happen and people just accept a changed SSH key.

So fuck it, let's let the United States Government cast the tiebreaking votes when we're not sure?

To add to that, new protocols are designed not to rely on DNSSEC: MTA-STS for MX records (uses HTTPS), Web Key Directory for OpenPGP keys (uses HTTPS).

Even old GnuPG deprecates DNS based key lookup: https://lists.gnupg.org/pipermail/gnupg-users/2018-October/0...

Putting user keys in DNS is an obvious mistake: deeply connected to DNS is the idea that the data in DNS is public. It requires heroic attempts like NSEC3 to keep data private and even NSEC3 is not enough. Trying to put list of users (mail addresses) in DNS is a mistake.

That said, the only reason for MTA-STS seems to be that some people don't like DNSSEC. From RFC 8461 "Related Technologies The DNS-Based Authentication of a Named Entities (DANE) TLSA record [RFC7672] is similar, in that DANE is also designed to upgrade unauthenticated encryption or plaintext transmission into authenticated, downgrade-resistant encrypted transmission. DANE requires DNSSEC [RFC4033] for authentication; the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades."

When you say "some people don't like DNSSEC", you're sort of dancing around the fact that the people who don't like it are some of the most important organizations on the Internet; to wit: all the major mail providers.

Which is fine. Do I really care about the security of Gmail? Yahoo? Hotmail?

For me the important thing is that all TLDs I care about support DNSSEC. So I can implement DNSSEC-based security locally. If other people want to play a different game, it is mostly fine with me.

The only annoying part is that browsers refuse to do DANE validation but firefox somehow is very quick to jump on the DoH bandwagon.

I don't know. Do you ever email people? If so: yes, you do.

It doesn't really matter that you can configure your own little island of DNSSEC since you'll inevitably depend on one of the resources in, like, the whole rest of the Internet, virtually none of which signs zones with DNSSEC. This really all is just security theater.

I assume that when you say 'virtually none', you are aware that more than 50% of the dot-nl domains (so around 3 million) are DNSSEC signed. Furthermore, more 60% of the DNS queries that reach the servers for the dot-nl zone are from validating resolvers.

I do not care about the thousands of European domains that are signed because domain hosting firms automatically enable it and sign zones for their customers, and neither should you, since that is obviously security theater.

In the unlikely event that anyone is reading the thread this deeply, you can go to https://dnssec-name-and-shame.com and try to find a big tech firm other than Cloudflare (which has a DNSSEC product) and (heh) Comcast that uses it.

It is important, because it is very important to have production traffic.

If you live in a centralised internet then what those big parties do is important.

I don't care what version of SSH any of those big parties are running.

Many services have a decentralised version. And when you really care about security, it is worth setting up local servers instead of hoping that those big parties really give you the service you need.

I flat-out don't understand what argument you're trying to make here. My response to your claim that DNSSEC is widespread because of signed .NL domains was simple: that's because registrars in .NL do that for zones automatically, holding the keys themselves. That's simply theater.

Not sure. Malicious ISP can forge DNS answers [0], the purpose of DNSSEC is to catch that.

[0] https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_...

False. DoH, DNS over TLS, and DNSCrypt/DNSCurve address that problem. DNSSEC does not.

One of the nice things about DNSSEC is that it is both optional and it actually works.

It being optional means that everybody who doesn't like DNSSEC can just ignore it. Just don't sign your zones, don't run a validating resolver. DNSSEC doesn't get in the way.

At the same time, because Google's public resolvers have been validating DNSSEC for quite a long time, it is safe to run a validating resolver. Anybody who signs a zone is forced to do it correctly, otherwise the zone will be unreachable for a significant fraction of the people on the the internet.

> Google's public resolvers have been validating DNSSEC for quite a long time

Quad9 also provides DNSSEC validation on our primary resolvers. Better for you privacy :)

But you don't care at all about confidentiality?

If you're going to argue that implementation difficulties make DNSSEC too much trouble I can respect the argument. To say that it doesn't solve a problem worth solving is strange.

Interrogate the thought more carefully. I understand why your default assumption is that securing DNS records is a good thing. But why is that, really? All sorts of things aren't secured cryptographically --- ARP! IP options! --- and we don't care. The modern Internet was designed with the assumption that the DNS is insecure.

Like SPF? Or DKIM?

ARP, and more generally any single-segment Ethernet network, is insecure, and it’s a problem. It’s just a very ingrained problem that’s unlikely to get fixed any time soon.

What about SPF and DKIM? Virtually none of the world's SPF and DKIM records are signed with DNSSEC.

You said:

> The modern Internet was designed with the assumption that the DNS is insecure.

SPF and such may well be designed under the assumption that DNS is insecure but, under that assumption, they too are insecure.

I don't understand your argument. Again, we have SPF and DKIM now, and neither rely on DNSSEC, which is good, because virtually nobody uses DNSSEC. You absolutely do need SPF and DKIM configured to be a mail sender; the Internet does rely on those. But you do not need DNSSEC to do that, and nobody cares if you do or don't.

And the security is weaker than it should be because the SPF, etc records are unauthenticated.

That's not how security works. In the real world, security is in part a resource allocation problem. We spend resources to raise the cost of an attack over the threshold a model attacker would pay. There is a reason nobody gives enough of a shit to sign SPF records, and you can start to see it by taking the time to track down all the incident reports where someone exploited cache poisoning to override SPF.

Interrogate the thought more carefully.

I kind of wish there was a version of 'Against DNSSEC' that was just about that. The 'Unnecessary' and 'Architecturally Unsound' parts of that argument are so strong, the other bits end up feeling like springboards for DNSSECtarians to launch into debate.

What are my options if I don't want my ISP (and thus the government, which in my case can easily get that information) to easily know which sites I'm visiting and thwart their attempts to block sites using trivial methods — assuming I don't use my ISPs DNS service and use something else? I know that my ISP would have the IP addresses I'm connecting to and also the encrypted traffic (for TLS) to the addresses along with timestamps, my IP address/location, etc., which would/may allow for various inferences to be made.

I'm not looking for perfect security or perfect anonymity. Is there nothing better that's available today than the status quo of plain old DNS?

P.S.: I read the related FAQ on sockpuppet.org.

Tor is probably the appropriate technology for this purpose.

Even with full deployment of eSNI, DNSSEC and DPRIVE it remains practical for an ISP on behalf of your government to track and block IP-level stuff.

It's more expensive than the DNS-level attacks such ISPs mostly use today, but it's entirely practical, governments might choose not to do it (or ISPs might insist on being paid, which forces a government to write a budget line item) because it costs so much, but that'd be the only reason.

What is your opinion on handshake.org? I am excited about it’s potential even though it has a massive uphill battle to gain adoption. The main reason why I’m excited about it is because it could also be used as a cryptographic identity that’s compatible with the old system.

At least it's an ethos.

Reply on news.ycombinator.com