February 18, 2012

The Convergence of PKI

Last week's post on the jaws of Trust sparked a bit of interest, and Chris asks what I think about Convergence in comments. I listened to this talk by Moxie Marlinspike, and it is entertaining.

The 'new idea' is not difficult. The idea of Convergence is for independent operators (like CAcert or FSFE or FSF) to run servers that cache certificates from sites. Then, when a user browser comes across a new certificate, instead of accepting the fiat declaration from the CA, it gets a "second opinion" from one of these caching sites.

Convergence is best seen as conceptually extending or varying the SSH or TOFU model that has already been tried in browsers through CertPatrol, Trustbar, Petnames and the like.

In the Trust-on-first-use model, we can make a pretty good judgement call that the first time a user comes to a site, she is at low risk. It is only later on when her relationship establishes (think online banking) that her risk rises.

This risk works because likelihood of an event is inversely aligned with the cost of doing that attack. One single MITM might be cost X, two might be X+delta, so as it goes on it gets more costly. In two ways: firstly, in maintaining the MITM over time against Alice costs go up more dramatically than linear additions of a small delta. In this sense, MITMs are like DOSs, they are easier to mount for brief periods. Secondly, because we don't know of Alice's relationship before hand, we have to cast a very broad net, so a lot of MITMs are needed to find the minnow that becomes the whale.

First-use-caching or TOFU works then because it forces the attacker into an uneconomic position - the easy attacks are worthless.

Convergence then extends that model by using someone else's cache, thus further boxing the attacker in. With a fully developed Convergence network in place, we can see that the attacker has to conduct what amounts to being a perfect MITM closer to the site than any caching server (at least at the threat modelling level).

Which in effect means he owns the site at least at the router level, and if that is true, then he's probably already inside and prefers more sophisticated breaches than mucking around with MITMs.

Thus, the very model of a successful mitigation -- this is a great risk for users to accept if only they were given the chance! It's pretty much ideal on paper.

Now move from paper threat modelling to *the business*. We can ask several questions. Is this better than the fiat or authority model of CAs which is in place now? Well, maybe. Assuming a fully developed network, Convergance is probably in the ballpark. A serious attacker can mount several false nodes, something that was seen in peer2peer networks. But a serious attacker can take over a CA, something we saw in 2011.

Another question is, is it cheaper? Yes, definately. It means that the entire middle ground of "white label" HTTPS certs as Mozilla now shows them can use Convergence and get approximately the same protection. No need to muck around with CAs. High end merchants will still go for EV because of the branding effect sold to them by vendors.

A final question is whether it will work in the economics sense - is this going to take off? Well, I wish Moxie luck, and I wish it work, but I have my reservations.

Like so many other developments - and I wish I could take the time to lay out all the tall pioneers who provided the high view for each succeeding innovation - where they fall short is they do not mesh well with the current economic structure of the market.

In particular, one facet of the new market strikes me as overtaking events: the über-CA. In this concept, we re-model the world such that the vendors are the CAs, and the current crop are pushed down (or up) to become sub-CAs. E.g., imagine that Mozilla now creates a root cert and signs individually each root in their root list, and thus turns it into a sub-root list. That's easy enough, although highly offensive to some.

Without thinking of the other ramifications too much, now add Convergance to the über-CA model. If the über-CA has taken on the responsibility, and manages the process end to end, it can also do the Convergence thing in-house. That is, it can maintain its set of servers, do the crawling, do the responding. Indeed, we already know how to do the crawling part, most vendors have had a go at it, just for in-house research.

Why do I think this is relevant? One word - google. If the Convergence idea is good (and I do think it is) then google will have already looked at it, and will have already decided how to do it more efficiently. Google have already taken more steps towards ueber-CA with their decision to rewire the certificate flow. Time for a bad haiku.

Google sites are pinned now / All your 'vokes are b'long to us / Cache your certs too, soon.

And who is the world's expert at rhyming data?

Which all goes to say that Convergence may be a good idea, a great one even, but it is being overtaken by other developments. To put it pithily the market is converging on another direction. 1-2 years ago maybe, yes, as google was still working on the browser at the standards level. Now google are changing the way things are done, and this idea will fall out easily in their development.

(For what it is worth, google are just as likely to make their servers available for other browsers to use anyway, so they could just "run" the Convergance network. Who knows. The google talks to no-one, until it is done, and often not even then.)

Posted by iang at February 18, 2012 07:21 PM | TrackBack
Comments

we were brought in to consult with small client/server startup that wanted to do payment transactions on their server, they had also invented this technology called "SSL" they wanted to use, the result is now frequently called "electronic commerce"

the trust model is the user trusts the URL ... the user is suppose to understand the relationship between the webserver they think they are talking to and the URL. Then SSL provides the trust between the URL and the webserver they are actually talking to. The original deployment for security/trust was that user types in the trusted URL and goes to that website and the whole session is https. That was almost immediately broken when merchants discovered https cut their throughput by 85-95% and they dropped back to just using https for check-out/paying. This involved the user clicking on a button (from an unvalidated/untrusted website) which provided a (/an untrusted) URL. Now rather than the user is talking to the website they think they are talking to ... it just becomes the website that the website claims to be.

I've pontificated that the CA industry has somewhat backed some aspects of DNSSEC where somebody registers a public key along with registering a domain. This is countermeasure to domain name take-over ... all subsequent communication with the domain name infrastructure is digitally signed and verified with the on-file public key. The scenario is somebody that has taken over domain can go to CA for certificate ... since the CA validates the true ownership of domain certificate with the authoritative agency for domain ownership ... the domain name infrastructure (root trust for domain certificates is the integrity of the agency that keeps track of who owns a domain).

This creates something of catch-22 for CA industry since could imagine that response to domain->ip-address request could also piggy-back the on-file public key (eliminating need for domain certificates).

There was recent item claiming that Google is now the highest used DNS server.
http://code.google.com/speed/public-dns/docs/using.html

Google now the largest public DNS provider in the world
http://www.fiercecio.com/techwatch/story/google-now-largest-public-dns-provider-world/2012-02-16

misc. past posts mentioning catch-22 for the CA industry
http://www.garlic.com/~lynn/subpubkey.html#catch22

Posted by: Lynn Wheeler at February 18, 2012 09:51 AM

I feel like the whole PKI system is a complete joke. All it does is make me suspicious about my browser.

IMO we are moving towards a combination of Namecoin and Ricardian contracts.

Your contract will contain your Namecoin address, and your Namecoin address will resolve to a censorship-proof record of your contract hash.

dot p2p baby!

Posted by: Fellow Traveler at February 25, 2012 06:56 AM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.