Trusting people on the internet.

sdfsdfsdfsdf By evan on May 29, 2016

An issue;

Who do you trust on the internet? It’s a simple question, with a horrendously complex answer.

Some of the key underpinnings of the internet like DNS and Certificate Authorities are trust based. You believe that https://google.com isn’t impersonating the real google because GeoTrust vouched for them. They believe Google because someone submitted a request from webmaster@google.com (yes that’s a bit of an oversimplification but accurate in most cases)

You can’t really trust DNS, at least, without something like DNSSEC. It also leaks a lot of information, like a list of every single website you’ve ever visited. Worst case scenario someone could man-in-the-middle a Certificate Authorities DNS provider and get certs for anything by ‘proving’ that they’re really webmaster@yoursitehere.com. In short, yes, the CA’s that you trust to vouch for people themselves trust DNS, something with no encryption or validation or verification in any way shape or form.

Cool.

This would be fine if all the big players were trustworthy. You can trust the CA because a vendor vouched for them (or their friends); And of course, vendors are always trustworthy. Yes, that is sarcasm.

Faith might be a better word than trust.

After the BlueCoat news, I started thinking about how the internet would look without faith. That is, instead of the implicit belief that any given agent/actor/person is trustworthy, simply have them prove whatever it is you want to know. There’s also the pesky issue of expiry dates being abused for revenue generation, but I digress.

A good place to start thinking about this is Tor hidden services. It’s an entire encrypted network, without any external DNS provider, without any external CA, but it still allows you to prove you’re talking to someone and that you’re talking to the same someone every time. The problem is that Tor is anonymous by design which is awesome if you want to buy drugs on the internet (that’s a fair statement, if incomplete), but for any tangible transactions I need to *prove* who the other person is and hidden services explicitly prevent that (unless you’re at https://facebookcorewwwi.onion which is a whole other issue.) Tor also has root servers, though very resilient, are still root servers.

The end goal is really having verifiable evidence, or proof that abc.xyz is at 172.217.4.78, and proof that abc.xyz is actually ‘Alphabet, Inc.’ In the current faith-based model, DNSSEC provides the former, and Certificate Authorities provide the latter. 

A solution.

The question becomes, how do we do that? The answer is blockchains, and it’s very simple. Every block is a DNS record at a point in time, contains a public key for https (this would be akin to HPKP), and is signed by the organization with the same keypair. When you look up a DNS record (a block), you search from most recent to oldest and stop when you get a hit. Every DNS record contains a hash of the one before it, making it infeasible to falsify any records.

In short, the bastard lovechild of DANE and namecoin.

The only real downside of this is losing vanity domains. I’m not sure that’s a real problem, given the recent explosion of tld’s and the massive abuse of domain resellers. Browsers are starting to remove the URL from the address bar anyways. The obvious loss is writing domains down on business cards, but that’s a solved problem with QR codes. It has no bearing at all on links or bookmarks. There’s always the potential for adding an alias, but that becomes subject to cybersquatting. But then, that’s no worse than what we have now.

In addition to the privacy afforded by local DNS lookups, we also effectively have local X.509 Certificates.  A client doesn’t need to ask for a cert in the clear, it already has one. That is actually a thing and it has been used to track down hidden service operators on the public internet, when they share a keypair. We can skip the first two parts of the SSL handshake, and go right to key exchange.

This becomes figuratively impossible to spoof. There are simply no records over the wire to MITM,  every record is verifiable, and the client simply can’t connect to the server without the right record. Zooko’s triangle aside, this is nearly a holy grail.

This is also impossible to tamper with, at least, without the right keypair. Politically driven domain seizures would be a thing of the past.

The only element of trust left, is on a site by site basis, that is, do you trust the operator? That’s simply not a technical issue.

Skipping the SSL handshake breaks SNI, so we need to address that as well. SNI does have other issues, like the unintended side effect of allowing a third party to see what website you’re requesting. Since this system values authenticity AND privacy, that needs dealt with. The best method I’ve come up with (and this could also be applied to the internet as it exists now) is to store an SNI public key in the DNS record. The client then encrypts the domain it’s requesting with that key, and a salt. The salt is important otherwise there’s still a 1:1 relationship between the raw domain and it’s encrypted equivalent. This solves the privacy issues with SNI while also ensuring compatibility with alternative DNS schemes.

Open to comments or thoughts, this would be a fairly radical change to the basic underpinnings of the internet, but a necessary one in my opinion.