Paul Crowley rants in anguish over the status of current day cryptoplumbing, and attacks the usual suspects (SSL, SSH, *pgp*, IPSec). They are easy targets so I'll let you read them there. (Where Paul goes further is that he actually attacks SSH, which takes it beyond the norm. I like.)
Leaving aside that, what is it that Paul really interested in? He needs a protocol.
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.
After long hard thought ... Paul says he has problems with what is offered. Here's what I think, and in my scratch pad of Hypotheses, I call this
Hypothesis #6: It's your job. Do it.
(It's your job to click. Click on ... thanks to Zooko for the pointer! Oh, and the editor reminds that Hypothesis #3 was introduced earlier.)
Posted by iang at February 26, 2007 07:17 PM | TrackBackIf a matrix of risk and the cost associated with it can be applied to a particular application operating within certain enviroments then the cost attributed to crypto might be determined.. The cost of purchasing a bank account for the purpose of phishing has been established at $400.USD. The rate of return for the phisher must be significant, considering the reward versus risk. So is there an accounting feature that can be assigned to the value of investing more or the right amount in security and crypto? So the cost of the attacks that seem to avoid the service provider in leui of some smart attorney making their liability stick, might be accounted for and quantified in the balance sheet. Are we facing a backlash of accountability on the part of users being aggregated into a super class of those phished and those defrauded? The networking of users will eventually find the right attorney who will find the right venue to assert the liability. When this happens discussions on the value of the particulars will take on new significance beyond the implementing few.
Posted by: jimn at February 27, 2007 12:12 AMThanks for propogating - and for commenting!
I can't work out if I detect a point of disagreement. Your "hypothesis 6" makes it sound pretty much inevitable that you're going to end up hand-crafting because any standard will be a poor fit for your needs, whereas I think that we can (and must) design standards that will be a better fit to the needs of a great many people.
Posted by: Paul Crowley at February 27, 2007 04:05 PMI think, PGP/MIME is the way to go. It has a well-defined and quite interoperable way of signing metadata together with the document and OpenPGP trumps everything else in terms of flexibility when it comes to keys making assertions about other keys.
Yes, it's a heavy standard, but partial implementations work quite well. My suggestion would be to adopt OpenPGP for signatures and design something simpler for transport-level crypto. You are free to leave the Web of Trust out, too.
That's what I'd do, anyway.
Posted by: Daniel A. Nagy at February 28, 2007 08:29 AMHey Paul,
I just posted on your blog about this...
Yes, I think you have it right: if you pick a standard, you are picking someone else's security model. Your assertation that "we can (and must) design standards that will be a better fit to the needs of a great many people" can be analysed at the economic level:
Are people so bad at security, or is security so hard, or is security so unimportant that people will accept a standard fit for it?
Does a standard fit cover most needs?
Does the nature of the problem lend itself to a static approach of a standard?
Obviously, if there were a standard then that would be fantastic. But the fact that most of the standards don't do a great job can be read two ways: we haven't found the ideal standard yet, or security isn't a problem amenable to standards!
Posted by: Iang at March 3, 2007 11:50 AMhttp://mail.jabber.org/pipermail/security/2007-March/000009.html has a good example of #6.1 as requirements. Is that a roadmap or is that a continental constructional plan or what?
Posted by: JabberSpy at April 1, 2007 05:51 PM