A crypto standards manifesto, version 0.1
Feb. 18th, 2007 06:52 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ciphergothUpdate: Anonymous comments must be signed! I've made a couple of exceptions to this policy, but I may stop unscreening comments that don't have any kind of name at the bottom.
My current plan to change the world involves writing a manifesto for a proposed mailing list to work out crypto standards that actually work and stand a chance of getting widely adopted in the open source world. This is essentially version 0.1.5 of that rant, and may contain some inaccuracies or overstatements; I look forward to your comments and corrections.
Currently there are four crypto standards that see any real use in open source land; in order of deployment, they are:
It's worth noting one other infuriating consequence of the PKI problems these applications display: none of them really talk to each other. You can buy an X.509 certificate that will do for both your SSL and IPSec applications, if you're really rich; these certificates will cost you far more than a normal SSL certificate, and for no better reason than that they are more useful and so Verisign and their friends are going to ream you harder for them. Apart from that, each application is an island that will not help you get the others set up at all.
I've left out WEP/WPA basically because it's barely even trying. It should never have existed, and wouldn't have if IPSec had been any good.
I'm now in the position of wanting to make crypto recommendations for the next generation of the Monotone revision control system. I wish I had a better idea what to tell them. They need transport-level crypto for server-to-server connections, but I hesitate to recommend SSL because the poison that is X.509 is hard to remove and it makes all the libraries for using SSL ugly and hard to use. They need to sign things, but I don't want to recommend OpenPGP: it's hard to talk to and the Web of Trust is a truly terrible fit for their problem; on top of which, OpenPGP has no systematic way to assert the type of what you're signing. They need a way for one key to make assertions about another, and we're going to invent all that from scratch because nothing out there is even remotely suitable.
Monotone has re-invented all the crypto for everything it does, and may be about to again. And in doing so, it's repeating what many, many open source applications have done before, in incompatible and (always) broken ways, because the existing standards demand too much of them and give back too little in return. As a result, crypto goes unused in practically all the circumstances where it would be useful, and in the rare case that it is used it is at best inconvenient and unnecessarily insecure.
I don't believe that things are better in the closed source world either; in fact they are probably worse. I just care more about what happens in the open source world.
We can do better than this. Let's use what we've learned in the thirty-odd years there's been a public crypto community to do something better. Let's leave the vendors out, with their gratuitous complexity and incompatibility as commercial interests screw up the standards process, and write our own standards that we'll actually feel like working with. We can make useful software without their support, and it seems in this instance that their support is worse than useless.
A good starting point is SPKI. SPKI has a very nice, clean syntax that's easy to work with in any programming language, very straightforward semantics, and supports constructions that anticipate the central ideas behind petnames and Zooko's Triangle. Unfortunately SPKI seems to be abandoned today; the feeling when I last looked at it was that despite their inadequacies, the victory of PKIX and X.509 was now inevitable and resistance was futile.
Well, it turns out that X.509 was so bad that no amount of industry support could turn it into the universal standard for key management applications. There are places that it will simply never be able to go, and in fact these are the vast majority of real crypto applications. On top of which, there is a limit to how far a standard that hardly anyone will ever understand the application of can go.
It's time we brought back SPKI. But more than that, it's time we adapted it for the times it finds itself in; take out the parts that complicate it unnecessarily or slow its adoption, extend it to do more than just PKI, and specify how it can talk to the existing broken cryptographic applications in as useful a way as possible. Once we've built a working petnames system to serve as a workable PKI, my current feeling is that we should start with no lesser a goal than replacing all of the standards listed above.
Does anyone else think this sounds like a good idea? What other way forward is there?
My current plan to change the world involves writing a manifesto for a proposed mailing list to work out crypto standards that actually work and stand a chance of getting widely adopted in the open source world. This is essentially version 0.1.5 of that rant, and may contain some inaccuracies or overstatements; I look forward to your comments and corrections.
Currently there are four crypto standards that see any real use in open source land; in order of deployment, they are:
- SSL/TLS
- SSH
- OpenPGP/GnuPG
- IPSec
- They are all designed long ago, in three cases initially by people who were not cryptographers, and are difficult to adapt to new knowledge in the crypto world about how to build good secure software. As a result, deprecated constructions for which there are no good security reductions are common. They are also generally far less efficient than they need to be, which would be a very minor problem if it didn't put people off using them.
- In every case protocols and file formats introduce far more complexity than is needed to get the job done, and often this shows up as complexity for the users and administrators trying to make them work, as well as unnecessary opportunities to make them insecure through misconfiguration.
- But by far the worst of all is the parlous state of PKI. This of course is something I've ranted about before:
- SSL's dependence on the disaster that is X.509 makes it insecure, painful for clients, and imposes the ridiculous Verisign Tax on servers, as well as making it very unattractive as a platform for new software development.
- SSH occasionally shows you a dialog saying "you haven't connected to this server before, are you sure?" I'm sure someone's going to tell me they actually check the fingerprints before connecting, but let me assure you, you are practically alone in this. I can't even share this information across all the machines I log in from, even if I use ssh-agent. The situation for authenticating clients to servers is slightly better, but still involves copying private keys about by hand if you want the most convenience out of it. It makes you copy whole public keys rather than something shorter and more convenient like OpenPGP fingerprints. It certainly doesn't make use of the basic fact that keys can sign assertions about other keys to make life more convenient.
- OpenPGP's authentication is based on the PGP Web of Trust, which is all about binding keys to real names using things like passports. As I've argued before, this is a poor match for what people actually want keys to do; it's a very poor match for authenticating anything other than a person.
- IPSec is also tied to the X.509 disaster. It is also so complex and hard to set up that AFAICT most IPSec installations don't use public key cryptography at all.
It's worth noting one other infuriating consequence of the PKI problems these applications display: none of them really talk to each other. You can buy an X.509 certificate that will do for both your SSL and IPSec applications, if you're really rich; these certificates will cost you far more than a normal SSL certificate, and for no better reason than that they are more useful and so Verisign and their friends are going to ream you harder for them. Apart from that, each application is an island that will not help you get the others set up at all.
I've left out WEP/WPA basically because it's barely even trying. It should never have existed, and wouldn't have if IPSec had been any good.
I'm now in the position of wanting to make crypto recommendations for the next generation of the Monotone revision control system. I wish I had a better idea what to tell them. They need transport-level crypto for server-to-server connections, but I hesitate to recommend SSL because the poison that is X.509 is hard to remove and it makes all the libraries for using SSL ugly and hard to use. They need to sign things, but I don't want to recommend OpenPGP: it's hard to talk to and the Web of Trust is a truly terrible fit for their problem; on top of which, OpenPGP has no systematic way to assert the type of what you're signing. They need a way for one key to make assertions about another, and we're going to invent all that from scratch because nothing out there is even remotely suitable.
Monotone has re-invented all the crypto for everything it does, and may be about to again. And in doing so, it's repeating what many, many open source applications have done before, in incompatible and (always) broken ways, because the existing standards demand too much of them and give back too little in return. As a result, crypto goes unused in practically all the circumstances where it would be useful, and in the rare case that it is used it is at best inconvenient and unnecessarily insecure.
I don't believe that things are better in the closed source world either; in fact they are probably worse. I just care more about what happens in the open source world.
We can do better than this. Let's use what we've learned in the thirty-odd years there's been a public crypto community to do something better. Let's leave the vendors out, with their gratuitous complexity and incompatibility as commercial interests screw up the standards process, and write our own standards that we'll actually feel like working with. We can make useful software without their support, and it seems in this instance that their support is worse than useless.
A good starting point is SPKI. SPKI has a very nice, clean syntax that's easy to work with in any programming language, very straightforward semantics, and supports constructions that anticipate the central ideas behind petnames and Zooko's Triangle. Unfortunately SPKI seems to be abandoned today; the feeling when I last looked at it was that despite their inadequacies, the victory of PKIX and X.509 was now inevitable and resistance was futile.
Well, it turns out that X.509 was so bad that no amount of industry support could turn it into the universal standard for key management applications. There are places that it will simply never be able to go, and in fact these are the vast majority of real crypto applications. On top of which, there is a limit to how far a standard that hardly anyone will ever understand the application of can go.
It's time we brought back SPKI. But more than that, it's time we adapted it for the times it finds itself in; take out the parts that complicate it unnecessarily or slow its adoption, extend it to do more than just PKI, and specify how it can talk to the existing broken cryptographic applications in as useful a way as possible. Once we've built a working petnames system to serve as a workable PKI, my current feeling is that we should start with no lesser a goal than replacing all of the standards listed above.
Does anyone else think this sounds like a good idea? What other way forward is there?
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2007-02-19 12:03 am (UTC)I don't understand why the current mechanism, whereby you could check with the administrator of a remote system that the fingerprint you saw when you tried to connect to what purported to be her machine matched the one she saw on her system would be improved by putting into the DNS?
How does that help?
no subject
Date: 2007-02-19 05:49 am (UTC)no subject
Date: 2007-02-19 10:35 am (UTC)no subject
Date: 2007-02-19 11:23 am (UTC)However:
(*) DNSSEC would only ever work if everyone who got a domain got a DNSSEC delegation as a matter of course. That's directly against the commercial interests of Verisign, who sell SSL certificates and now seem to control the domain system.
(*) The DNSSEC designers made some bad choices: they wanted all subdomains to be securely enumerable from the root domain, so that you could get secure assurance of a negative answer. People really, really don't like that. They should have allowed negative answer signing to be delegated to an ephemeral key that lived on the DNS server itself and wasn't empowered to sign much else.
(*) It only covers one edge of Zooko's triangle in any case; I want to leave the world where we all try and live on that one edge.
no subject
Date: 2007-03-26 05:13 pm (UTC)no subject
Date: 2007-03-26 05:43 pm (UTC)no subject
Date: 2007-02-20 10:06 pm (UTC)In the most common case everything is OK.
The really serious times these are useful is when a host key has changed without you expecting it - I figure that because people are conditioned to accept these prompts on new connections that a significant number of people will just "OK" a changed host key.
If, additionally, key fingerprints are stored in DNS then the typical case would be:
a) User connects to new host.
b) DNS says everything is OK
c) User is not prompted.
The only times the user would be prompted would be a) if the key changes, or b) if the DNS data is incorrect - but hopefully at this point most people would be unused to these kind of prompts and things would be simpler.
Its not a huge win if you don't control DNS - and in that case you might be at the kind of company where databases of server fingerprints are automatically distributed (with cfengine/etc) .. but it is a simple check to make..
no subject
Date: 2007-02-20 10:39 pm (UTC)no subject
Date: 2007-02-20 10:43 pm (UTC)