Sovereign Keys, EFF's proposal to replace the certificate authority model | Hacker News Reader

Sovereign Keys, EFF's proposal to replace the certificate authority model

eff.org

127 pointsxyzzyrz10 comments

This is clever, and I think it relates in a neat way to the current TLS trust imbalance between browsers and native clients.

When I write a native client app against my own server, I don't need to rely on traditional appeals to CA trust because I know exactly what certificate the server should be presenting to me.

TLS is weaker in browsers because arbitrary web clients don't know my server ahead of time, so they trust me if one of the Super Trustworthy Oracles trusts me. But the list of those CAs is large enough, and updated slow enough, that the list is not particularly trustworthy in aggregate even when any individual CA may be considered trustworthy at a particular point in time. So there's an issue there, even with a savvy user class who would reject access in response to a certificate warning.

The Sovereign Keys proposal strikes me as a way to let browsers 'phone a friend' who, in essence, knows exactly what certificate the server should be presenting. It makes an arbitrary client more like my native client.

But I think there's a scalability concern about Sovereign Keys that's related to the problems we see with CAs today: When they become a popular commodity, how will the system deal with millions of websites asking for Sovereign Keys? Will it really take the time to verify that the requestors are valid, or will it try to 'meet the demand' and sacrifice security in the process? And when the system is fooled, as it occasionally will be, how quickly will revocations or replacements be operational?

I don't think the scalability is as much of an issue as you think. The current system allows a trusted CA (or untrusted if you are OK with warnings) to issue a cert to a malicious party for, say, facebook.com. This means that in aggregate it is difficult to trust the reliability of a cert that a browser receives.

The strength of the Sovereign Key is that once facebook.com issues a Sovereign Key, no one can possibly produce a key that is valid for facebook.com unless facebook.com revokes its key, which is a cryptographically secure process that only facebook.com can perform using its private key.

This largely alleviates the problem you describe. One can be relatively lax in distributing new sovereign keys, because there is no way to attack an existing one by granting another. One still has to be a little careful in granting them because a site without a sovereign key might be attacked by creating one in its name controlled by a malicious third party, but it's not as dangerous as the current system where granting an overly broad certificate to Joe Schmo can compromise google.com's SSL.

What would happen if a sovereign key for facebook.com was granted to a malicious party before Facebook gets the chance to request one? Can such an error ever be corrected?

This is exactly my concern, only less for facebook and more for the multitudes of less-famous sites that nevertheless transact a lot of business.

There is already quite a bit of work done regarding using DNSSEC as a PKI for distributing keys(any kind). One relevant paper is http://www.acsac.org/2005/papers/49.pdf.

The nice part about storing public keys in DNS and authenticate them using the trust chain starting from the DNS root servers, is that you have a solid foundation that can be used for all kinds of interesting applications, much more than just encrypting traffic between the webserver and the client. As an example, we had a project where we stored a public key in the txt field of a domain name(signed), and we would sign all HTTP responses with that key. The client could then get the public key via DNSSEC and verify the signature of the HTTP response. The advantage over SSL is that you get authenticity and integrity for each HTTP response. http://tnc2010.terena.org/schedule/posters/pdf/100511170332n...

The proposal from EFF also leverages DNSSEC as a trust source, which I think is better than the current PKI that we are using, but its not without its flaws. The biggest problem is that you are still dependent of a 3rd party(registrar) to give you that trust, and usually these kind of entities are very prone to being influenced by governments. We can see what kind of legislation some governments are trying to promote, so I'm not sure if a centralized solution is the best way we can go :)

  > usually these kind of entities are very prone to
  > being influenced by governments

A lot of registrars are down-right shady without getting governments involved...

In related news, Google has said they do not plan to implement Convergence, a similar SSL alternative:

http://www.theregister.co.uk/2011/09/08/google_chrome_reject...

"The main requirement for being able to [create a Sovereign Key] is that the requesting party controls a CA-signed certificate for the relevant domain, or uses a DNSSEC-signed key to show that they control that domain".

I don't quite understand this. If our problem is that CA-signed certificates are not very trustworthy, why use them as the basis for the new system?

Can someone explain the DNSSEC alternative?

My first thought when I saw the word "sovereign" was that this was a plan advocating making nation-states the ultimate certificate authority or something.

Now that I see this is just the opposite, the terror of that moment has passed.

How does that compare to bitcoin? The distributed append-only data structure sounds like it is similar to the bitcoin block chain.

But the article says this structure is "semi-centralized". Is there a good reason why the sovereign key system isn't fully distributed like bitcon is?

Reply on news.ycombinator.com