The internet is actually controlled by 14 people who hold 7 secret keys | Hacker News Reader

The internet is actually controlled by 14 people who hold 7 secret keys

businessinsider.com

35 pointsalvil35 comments

Introducing 'the internet': https://www.youtube.com/watch?v=iDbyYGrswtg

This kind article comes out every year or two and it's always incredibly misleading. They always try to make it sound spooky and dystopic. What would it even mean for 14 people to "control" the internet in any newsworthy way?

"The group conducts the ritual, then each person files out of the room one by one, and then they all head to a restaurant and party."

Well, I now know where I would attack if I had any interest in a takeover of DNS.

Misleading title. More accurate title would be "the domain name system is actually controlled..."

Well, whoever gets to control what IPs get attached to domains, controls pretty much all of the internet...

It's a little grayer than that. If there was a breach of the root servers, then it would be trivial for most DNS administrators to change to a new set of DNS root hints once new root servers were put online. Since most consumers use the DNS servers of their ISP, there would likely be less impact than might be thought.

The domain name system functions fine regardless of who has the DNSSEC root keys or what they do with them. The private keys could be posted to Pastebin today and --- I mean this literally --- nothing important on the Internet would break.

"Ceremony" is a good word for what this stuff is.

It's sad that this is true.

It's fantastic that it's true. DNSSEC is a terrible idea that will harm the Internet.

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

This statement is not provably true. With a DNSSEC signed root anyone can host their own copy of the root zone, and we can all cryptographically verify that it is the same root. If someone were to sign a different root with the same key we would no longer be sure which was the right one. An attacker could redirect traffic away from TLD nameservers to their own nameservers.

I think you understand this. What I don't understand is why you think this scenario would not be a problem.

TLS works on the assumption that DNS is insecure. So, since everything that matters happens over TLS, it's not a problem if DNSSEC is compromised. It wouldn't matter if DNSSEC wasn't invented to begin with. It might be better that way, actually, given its problems.

Let's Encrypt, and pretty much any other CA, will issue me a TLS cert based on what they find in DNS. So how's that for circular reasoning :)

But seriously, wouldn't it be better if DNS wasn't so insecure? Or do you think that DNS being insecure provides a net good?

No, it wouldn't be better if DNS was less insecure: applying cryptography to address security problems adds cost (along several dimensions), and those costs outweigh the marginal benefit. It's like asking, "wouldn't the Internet be better if ARP were secure?"

I don't get the Internet ARP reference? That's just false equivalence.

I think we're just going to continue to disagree. We've argued over DNSSEC on HN many times and it's clear to me we don't see eye-to-eye. That's fine, and I respect your opinion. I just think you're wrong, and I doubt anything you say will convince me otherwise.

Practically 100% of all commercial DNS lookups --- that is, lookups done in the service of actual commerce --- are done without DNSSEC. Moreover, no modern browser implements DANE, and 3 (Safari, Firefox, and Chrome) have started and later retracted DANE support, so the TLS infrastructure also does not rely on DNSSEC in any way.

My earlier statement is surprising, and I understand why. But it's true.

DANE is relatively new, but already we have over 50,000 MX records with associated TLSA records. So DANE is actually being used regularly, and these numbers are growing. There's more to the Internet than just the web and browsers.

> Practically 100% of all commercial DNS lookups --- that is, lookups done in the service of actual commerce --- are done without DNSSEC.

Wait what? I'm not sure what you categorize as a 'commercial DNS lookup', and I'm not even sure it matters, because this statement is so completely false I don't even know where to begin. All of Comcast's subscriber base are using recursive resolvers that use DNSSEC, are none of them performing 'commercial DNS lookups'?

No, in fact, virtually nobody in the real world uses DANE, because no browser supports DANE. Chrome and Firefox briefly attempted DANE a few years ago, and both removed it. The Chromium team --- the single most important mover in SSL/TLS security --- has been pretty plain about the fact that DANE isn't on the agenda.

You might start with this Adam Langley post:

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

So after I bring up the fact that DANE is being used for SMTP you state that no one is using it because it's not being used for HTTPS?

BTW I'm not even arguing for DANE in this thread. I was arguing for DNSSEC specifically. You brought up DANE to make some point about DNSSEC. But we can have DNSSEC without DANE.

> With a DNSSEC signed root anyone can host their own copy of the root zone, and we can all cryptographically verify that it is the same root.

If that's the best counterpoint, then I'm sorry to say that this has already been possible for a long time. I remember it being available at least 10 or 15 years ago.

https://www.internic.net/domain/

At the above link you can download, over HTTPS, the root zone including PGP signatures.

With everything taken into account, DNSSEC causes far more problems than it solves.

The root zone has always been publicly available.

But isn't it nice that you can cryptographically verify that this is the root-zone with DNSSEC? I'm not sure how you're verifying it using PGP, but I think you mean public key encryption, which is what DNSSEC is using.

DNSSEC does not in fact use public-key encryption; it uses public-key signatures, with an outmoded RSA construction that would have been rejected for new protocols 5 years ago. In fact: TLS 1.3 just jettisoned RSA.

This is only for DNSSEC signing for the root zone, right? If you don’t use DNSSEC, those 14 people don’t affect you in any way.

8.8.8.8 DNSSEC validates. So that's a lot of people right there. I think Comcast also validates. There are others but I think you get the point.

You might be relying on DNSSEC validation without knowing it.

Where by "relying on" you mean "impacted by outages and little else", since we systemically do not validate DNSSEC and any attack that DNSSEC "prevents" can simply be aimed at a different part of the communications infrastructure.

Also, obviously, people who "rely on" 8.8.8.8 doing DNSSEC lookups are in fact relying on a single bit in an unencrypted DNS response packet that vouches for the validation that the server did. Nothing 8.8.8.8 can do will protect the link between the user's stub resolver and Google's DNS server.

> Where by "relying on" you mean "impacted by outages and little else", since we systemically do not validate DNSSEC and any attack that DNSSEC "prevents" can simply be aimed at a different part of the communications infrastructure.

You could make that statement about nearly any security mechanism. It still doesn't explain why you think unsigned DNS responses are better than signed ones.

> Also, obviously, people who "rely on" 8.8.8.8 doing DNSSEC lookups are in fact relying on a single bit in an unencrypted DNS response packet that vouches for the validation that the server did. Nothing 8.8.8.8 can do will protect the link between the user's stub resolver and Google's DNS server.

Yes, which is why the kind folks at the IETF are working on DNSoTLS. But that's orthogonal to DNSSEC.

No, you don't understand what I'm saying. I'm saying that by using Google DNS to "verify" DNSSEC, you're playing pretend, because DNSSEC doesn't do anything to protect the last mile between your stub resolver and Google's servers; instead, it sets a single bit in the header to reassure your resolver that "yes, Google verified this DNSSEC request". But any coffee shop MITM can simply flip that bit back!

Google DNS's DNSSEC support is pure security theater.

Which is why I brought up DNSoTLS which you conveniently ignored. That 'last mile' problem you speak of is being worked on at the IETF. It's not an easy problem to solve. But I suspect this argument of yours, which is valid BTW, will be less of problem in 5 years. We're already starting to see DNSoTLS testing happening.

You could also run a DNSSEC validating stub resolver on your laptop. Or you can run DNSMasq on my home router with DNSSEC validation enabled. Both of these effectively prevent the MITM you bring up.

"the Elders of the Internet"

I got this article a day before from a friend and he brought up the question which I have no answer for: > what if all 14 are assassinated? > 14 is not that many, especially when they meet occasionally

Then I was just reading the https://github.com/orisi/wiki/wiki/Orisi-White-Paper which has a "contract amendments" section saying: "... if over 50% of oracles notice that one of them fell, they can transfer the contract funds to another multisig address, with the dead oracle replaced by another one, allowing for safe and long-term contract management."

which sounds like they don't have plan for 100% death rate either.

I guess in case of such an horrible event, we would finally setup a different process which wouldn't require the collocation of several people...

Someone has got to write Lord of the Keys.

http://www.azlyrics.com/lyrics/helloween/keeperofthesevenkey...

Now may we please have Namecoin .bit domains? Thanks.

You can have whatever you want when it comes to DNS. I mean it doesn't mean the rest of the world will support it or join in but fill yer boots lad.

No one is stopping you from making alternate root servers. AlterNIC [1] offered them for years.

[1] https://en.m.wikipedia.org/wiki/AlterNIC

I'm surprised at the violently negative voting reaction to this common-sensical wish. What am I missing? Sure, nobody is stopping me from making alternate root servers. But I'm not competent to run alternate root servers. Don't we all need a decentralized DNS? I suppose some people interpreted my remarks to be trolling, but I wouldn't know enough to do a good troll on this topic. I'm just a dumb user, who suspects peer DNS would eliminate the value in DDOS against centralized DNS.

Reply on news.ycombinator.com