Comment by oleganza | Hacker News Reader

Comment by oleganza | Hacker News Reader

Parent Full thread

Remember that CAs were invented as a way to solve two UX and security issues:

1. When I go to google.com, I want to be sure it's the same google.com everyone else connects to.

2. When I go to google.com many more times, I want to get to the same google.com as I was visiting before.

It's relatively easy to do #2 (SSH was doing it for years), but it's very hard task to do #1 correctly. The first problem is essentially a problem of global consensus. It can only be solved using Bitcoin blockchain, poorly simulated with Certificate Authorities, or left alone as SSH did (which is fine for hackers connecting to their own machines, but not fine for global name system).

If anyone is interested in improving SSL/TLS, the way forward is to use blockchain to associate names and public keys so that users could know for sure that they connect to the same name as anyone else without trusting any CAs. Of course, that'd require development not only of a new DNS-meets-SSL protocol, but also robust lightweight Bitcoin nodes and correct UX conventions. That's hard, time consuming, but the only way forward out of the current mess.

Relevant quote from Nick Szabo ("leaving small holes unplugged"): http://blog.oleganza.com/post/69174500046/leaving-small-hole...

Practically nothing you said is correct.

* CAs were implemented to issue and verify digital certificates, not verify a connection. No part of TLS PKI is intended to verify that you are connecting to the same service everyone else is.

PKI (and CAs) are intended to assure identity, as well as providing a secure connection over a public network. When you buy a Papa Johns pizza, we know we're not all buying our pizza from the exact same Papa Johns store. But we do know it's a Papa Johns.

* SSH does do your second example, but TLS PKI does not.

As the above example points out, there is more than one Papa Johns store, just as there is more than one web server or service around the globe providing the same organization's data. SSH assumes there is only one Papa Johns store that serves all Papa Johns pizzas; one host is tied to one host key signature. PKI does not make this assumption.

* Blockchains are a stupid idea because they require access to a global public network. Depending on DNS to issue and verify digital certificates is like using SMTP/POP3 to 'simplify' the authentication of users when distributing web downloads.

TLS PKI does not require access to a network, nor receiving any updates from it, and its software is designed to be secure by default, unlike DNS, which in many operating systems cannot be secure by design (because they don't provide a verifying stub resolver, besides the inherent security problems in the protocol's design).

Honestly, most of the suggestions people have to replace PKI just reduces reliability without providing particularly improved security. The biggest problem with PKI is the uncertainty of ensuring the security of such a high number of CAs. That's easy enough to solve... have less CAs and make them more transparent.

>It can only be solved using Bitcoin blockchain

Could you please elaborate?

Proving that you see the same data as everyone else is Byzantine General's Problem which cannot be solved in information theory. However, it can be solved practically if there's a single hugely powerful chain of proofs-of-work referencing that data. Today it is Bitcoin's blockchain.

What you want to prove to yourself is that if "google.com" is associated with public key "04cafebabe", that association is also visible to everyone else (provided other people follow the same protocol).

The distributed DNS+SSL protocol could look like this (simplified):

1) To register a name "google.com", check that it's not registered yet (see below). If not, create a special Bitcoin transaction ("registration tx") that encodes both the name and the public key of the SSL certificate used by that server.

2) To check who owns the name "google.com", find the earliest "registration tx" on the blockchain (other people could add more, but only the first one is considered valid). If the name is 100 blocks deep, trust the public key associated with it.

The protocol can (and should be) extended to allow transferring the name to new public keys, you may check how Namecoin does it.

What you get in result is that every single user can be sure that they see the same up-to-date public key identifying "google.com" without any trusted Certificate Authorities who have failed at this promise multiple times already.

As a nice side effect, name allocation and trade is also decentralized. If you own name "google.com" and users respect the protocol, no one can take this name from you or censor your sale of that name to someone else. Also, you are free to register your own name without asking for anyone's permission and paying fees.

The fundamental problem is the first come first name nature.

It is not correct.

If I monitor DNS changes, and when new host names pop up. If I have the resources I can make a block-chain transaction automatically.

How will my transactions (provided I also create a new walletID) for each transaction be framed as fraudulent? Without community or authoritative over-site?

How to "fairly" distribute names is orthogonal problem to the one "how to stay on the same page" for already registered names. There are essentially two ways: 1) first come, first grab. Or 2) have a central bootstrapping party that will sign off "valid" registrations. You cannot register whatever you want, but after you got your name, you can trade it freely without anyone censoring you.

I was not saying that new system must necessarily map current DNS owners to new DNS 2.0 owners. These could exist in parallel. My point is to have secure "TLS with names" you must have something like what I describe, otherwise it's a waste of time. Social issues of fairness etc are secondary to the security of addressing names and servers. (Although, they could be real obstacles to adoption, I don't deny that.)

We use a commitment scheme in Namecoin. There is a NAME_NEW transaction that is done first that secretly reserves the name. This transaction is then spent, a minimum of 12 blocks later with a NAME_FIRSTUPDATE which reveals the name and sets the initial data for it. It would be quite difficult to do what you suggest unless you can pull off a 51% attack on Namecoin for at least several hours, and if you can do that you probably do it to Bitcoin as well.

I don't understand this - domain names are first come first serve anyways. Why would it be bad to have the security part of the domain handled at the same time, in the same transaction as the registration part?

Namecoin works great in a vacuum. It would be amazing if DNS already didn't exist.

But using namecoin with DNS allows for duplicate and erroneous entries in one or the other. (DNS record != Namecoin record).

Currently most namecoin advocates pretend the former is the case. And it isn't, because have DNS currently. Namecoin is a complete re-invention of the system. Not a iterative improvement.

My issue is that in its current state one can make a namecoin entry that is correct as far as namecoin is concerned, and incorrect as far as DNSSEC or standard DNS is concerned. Thus rendering the system in a weird state.

It would be great to see namecoin become more popular. It would mean we could just use self signed certificates and store the fingerprint in the namecoin record.

Checkout Namecoin: http://namecoin.info/ - which seems like a really interesting mapping of the benefits of a blockchain ecosystem against the issues of DNS+SSL.

Reply on news.ycombinator.com