The Journey to Hijacking a Country’s TLD – The Hidden Risks of Domain Extensions | Hacker News Reader

The Journey to Hijacking a Country’s TLD – The Hidden Risks of Domain Extensions

thehackerblog.com

55 points0x07 comments

And that, ladies and gentlemen, is why DNSSEC is a really terrible idea... That's what tptacek would've said, I guess.

But seriously, having such a weak security for something so fundamental as name server scares me out.

No, what I'd say is that DNSSEC adoption is incredibly low because it provides practically no value over what the TLS X.509 CA system does --- and yes, I agree the CA system is terrible, which is what makes it amazing that the IETF couldn't do better.

Most of the drive to get DNSSEC deployed comes from governments, which is no surprise: DNSSEC is a key escrow system for the web PKI, controlled by governments.

I'm not sure this is an indictment for DNSSEC; if DNSSEC were widely deployed, it would actually address one aspect of this: you wouldn't be able to takeover a latent glue record, because you couldn't provide properly signed answers.

If you takeover email domains, and ask IANA to change the signing keys, or take over the servers and recover the signing secrets; DNSSEC wouldn't help, and might provide some air of legitimacy though. And, of course, then you could provide false keys for whatever subdomains you hijacked. On the other hand, if you control DNS, it's not hard to get a domain validated certificate, although some CAs will run your domain through a list of high value names before they will issue a fully automated cert.

In a world with domain validated certificates being very common, it doesn't seem like we gain much by declaring that TLD operators are untrustworthy, so we can't explicitly trust them to provide DNSSEC signatures and enable DANE, when we are implicitly trusting them to provide correct information when CAs do domain validation.

There's certainly an argument that we don't gain very much by knowing an untrustworthy entity has certified something, though.

Yep, this discussion about DNSSEC happens here from time to time usually with the same arguments.

Once Chrome even supported DANE certs for domains but deprecated it for I think performance reasons:

> Some years ago now, Chrome did an experiment where we would lookup a TXT record that we knew existed when we knew the Internet connection was working. At the time, some 4–5% of users couldn't lookup that record; we assume because the network wasn't transparent to non-standard DNS resource types. DANE records are going to be even more non-standard, are going to be larger and browsers would have to fetch lots of them because they'll need the DNSKEY/RRSIG chain up from the root. Even if DNSSEC record lookup worked flawlessly for everyone, we probably still wouldn't implement this aspect of DANE because each extra lookup is more latency and another chance for packet loss to cause an expensive timeout and retransmit.

Source: https://www.imperialviolet.org/2015/01/17/notdane.html

Is DANE currently used for anything? XMPP certs?

I don't think DANE is really in use; although there's some hints it may be usable with SMTP (postfix has support).

I'm not sure DANE is realistically usable anyway -- unless it was for a protocol which specified DANE only, you'd need to have a CA signed cert for interoperability with clients that didn't support it; in which case, you may as well just use that. I guess it makes sense for SMTP -- generally certificates are not validated when delivering mail, under the theory that encryption with an invalid cert is better than plaintext, and there's not a usable UI to let the sender pick what to do. In that case, DANE can work, but I kind of doubt there's much adoption still.

One huge question is: why are entire countries' TLDs being hosted on free DNS services?

Budget cuts? :)

Reply on news.ycombinator.com