Wandering Thoughts archives

The (or an) attraction of Twitter

As I was reading Sun documentation yesterday, I had a belated realization about one of the attractions of Twitter: it is a public place to put snarky comments and quick reactions that are neither serious enough nor long enough for a blog entry, even a very short one.

Now, as it happens I already have social venues for these reactions, but they suffer from two problems. First, they're not public, and second, they take more involvement than merely throwing something at Twitter, because they actually are social venues; I can't just show up, throw out a one-liner, and disappear again.

(Since I am almost entirely ignorant of how people use Twitter, it is possible that Twitter itself is turning into a social venue where people expect you to pay attention and reply to their replies to you. In my view, this would be kind of unfortunate.)

Of course, you don't need to use Twitter itself for this; there are lots of ways to do this sort of thing in your own web presence. But apart from network effects, I think that there are at least two attractions of doing this with Twitter itself: first, someone else has already created all of the software necessary for you (including clients), and second, Twitter's success has created the broad social expectations of what you get from someone's Twitter updates, so you don't have to train people that this sidebar on your website is not so serious and deep.

(I don't mind creating my own software; it's even fun. But right now I have lots of other things that are taking up my time, so I'm just as happy to not reinvent reasonably round wheels.)

The problems I see with multi-signed SSL in practice

Given both the need for certificate authorities and the practical weaknesses that they have, it would be nice if it was easy to drop a CA without causing massive havoc. The most straightforward way to implement this is to allow SSL certificates to be signed by more than one authority, and to be considered valid if any of authorities is trusted.

The problem with this is economic. Each CA is going to have to charge you their own payment in order to sign your certificate, which means that most people will never buy this 'insurance'. Because that's what it is; it enables no extra functionality, it just keeps your website going if your original CA screws up or goes bad. Worse, this is an unlikely event that could be fixed fairly fast if it happened at all, so why pay in advance? Thus, the likely result is that most certificates will still only have a single CA's signature, and you have not made it any easier or less disruptive to pull a CA's root certificate.

(If having signatures from multiple CAs becomes part of some 'extended validation' scheme, it will be correctly seen as yet another attempt by CAs to extract even more money from certificate users.)

Why do CAs have to charge you?

Given the issues with the web of trust model and that you cannot ask users to manage their own security, the trust roots basically need two properties: they have to be sufficiently trustworthy that they can be included in browsers by default, and they must be basically 'flat', more or less directly signing website certificates. Since the trust root needs to be flat, the CA has to deal with all of the signature volume itself, with enough care and validation to be trusted; it cannot push parts of the load off on to third party volunteers. And as we've seen over and over, free volunteer work does not scale above a certain volume level, where it exhausts all of the free time and free resources.

(Web of trust based systems can operate for free because they distribute the volume; any given node in the web only signs a relatively low volume of things, and nodes can just decline to sign at all if they're overloaded because the 'customers' can just go find another node.)

Why SSL needs certificate authorities, or at least trust roots

Despite what I wrote yesterday and my general views on authenticating SSL, I think that in real life SSL still needs certificate authorities, or at least some sort of trust roots. The problem is that normal people are simply not interested in assessing trust issues and probably are not capable of doing so. In fact I'm not sure that I'm capable of doing it.

(As I wrote once before, in practice I make no attempt to actually verify the SSH host keys that I get prompted to approve, so the odds that I would hand-validate SSL certificates is low. And I am far more technical and aware of these issues than ordinary people are. Remember, security is a pain.)

If SSL is going to mean anything more than very casual opportunistic encryption in practice, we need to delegate trust issues to someone; in other words, we need some sort of trust roots. The traditional alternative answer to this is a 'web of trust' model, but this is just a cop-out, and a dangerous one at that. You're still leaving it to people to pick their own trust roots, with the predictable result that many people are going to do a bad job of it. Plus, in practice I believe that the whole model has flaws that weaken its security.

(Yes, yes, at this point it is popular to blame the people for not doing their 'job' correctly. Wrong. If you design a system that you know is going to be used incorrectly by people, you have failed because you haven't solved the important problem.)

(On a side note, I'd expect a web of trust system to have even more problems with revocation than SSL currently does, since it would involve more signatures that are more widely distributed.)

This doesn't mean that you need certificate authorities as they currently are (that would be truly depressing), but it does mean that you need trust roots and networks of trust that are trustworthy enough that they can be configured into browsers and shipped off to people who don't want to care about all of this. My feeling is that each trust root will have to have a pretty flat trust hierarchy in order to stay trustworthy overall; we've already seen the practical problem with doing otherwise.

I haven't thought very much about how many trust roots there should be. On the one hand, more trust roots should mean that less depends on any given trust root, which would make it easier (in practice) to revoke one when things go wrong. On the other hand, the more trust roots you have the less you can inspect and monitor each individual one's operations, so they can be sloppier before getting caught.

(The cynic would say that there is no real monitoring of CAs now; all you have to do is pass an initial inspection and then you're pretty much set.)