------------------------------------------------------------Date: Thu, 22 Feb 1996 16:55:29 -0800 (PST) From: Raph Levien Message-Id: <199602230055.QAA15846@infinity.c2.org> Subect: Conference report - resolving security workshop To: cypherpunks@toad.com, coderpunks@toad.com, resolving-security@imc.org Sender: owner-best-of-security@suburbia.net Errors-to: nobody@mail.uu.net Precedence: bulk Reply-To: nobody@mail.uu.net Here follow one cypherpunk's impressions of the Internet Mail Consortium's Security Workshop (http://www.imc.org/security-workshop.html) on Wednedsday 21 Feb 1996. Since there will be official notes of the proceedings, I felt I had a little more scope to convey mood and feelings rather than dry technical facts. After all, I think the buzz will do more to determine what gets deployed than the technical merits. This document is available on the Web at: http://www.c2.org/~raph/report.html The setting ----------- Paul Hoffmann and Dave Crocker recently started the Internet Mail Consortium (http://www.imc.org). This workshop was its first major activity. Dave Crocker moderated the event, skillfully herding almost 70 secure email proponents and representatives from user communities through a very tough subject. The title of the workshop was "Resolving email security," but there was no real expectation that the issues would be resolved that day. What was expected (and what happened) is that people would get a better understanding of why secure email hasn't happened yet, what kinds of things could be done to make it happen. More impressively, there was "room consensus" for a few _very_ positive steps, about which more later. One of the goals of the IMC is to involve users, not just developers. I was ready to "officially" represent the "cypherpunk user community," but fortunately, I didn't need to. In fact, the strongest advocacy of strong crypto came from an employee of a "large service provider in America." Overall, I felt that the user communities were pretty well represented, and all important technical points got made. MOSS is dead, long live MOSS ---------------------------- There were five contenders on the field going into the day, and two and a half at the end. MOSS was one of the casualties. A lot of us were sorry to see it go, but eliminating candidates has got to happen if we're going to have interoperation. It's hard to say exactly what went wrong. MOSS had many advantages, and was a nice, clean, pretty standard. I think what doomed it was the lack of a good implementation. Even though MOSS is no longer considered a serious contender, one piece of it is still very much alive: the multipart/signed message format. At the end of the day, there was strong, nearly unanimous consensus that multipart/signed should be recommended as the signed message format for _all_ of the email encryption protocols. S/MIME: you can dance to it --------------------------- There was a lot of energy around S/MIME. People are implementing it. Internally, it's pretty kludgely, but it does provide pretty good cryptographic services. (as an aside, my favorite kludge anecdote is the fact that X.509 certificates use an IA5 character set rather than ASCII, so that the @ in email addresses has to be represented as (a) instead). The main thing people didn't like about the existing S/MIME spec is the signed message format. In the existing spec, you've got a choice between a message unreadable to non-S/MIME-aware clients, or duplicating the data. Neither alternative is very palatable. Apparently, though, a new version of the S/MIME spec _will_ incorporate the multipart/signed format of RFC 1847. This made almost everybody happy, although I'm sure all those S/MIME developers are a bit unhappy with the spec changing, and having to reimplement stuff. The biggest problem with S/MIME is that the signed and encrypted format reveals who made the signatures. Obviously, this has severe consequences for anonymous mail. Believe it or not, a lot of people care. For example, the car manufacturers do not wish to broadcast the email addresses of their employees over the net. One technical workaround is to do it the MOSS way - first, sign the message, resulting in an intermediate S/MIME message, then encrypt that into a second S/MIME message. I'd recommend that implementors make provisions for such recursive formats; I think it's likely that we'll see a lot of these on the Net. PGP: troubled, but still alive ------------------------------ The consensus was that S/MIME and PGP/MIME are the two viable email encryption protocols. Thus, PGP is still very much alive and kicking. PGP's fabulous strength is that it won't let you down cryptographically. That simply cannot be said for the other contenders. That said, much about the PGP effort troubles me. Perhaps the biggest problem is that there just aren't enough people working on it. >From what I understand, it's pretty much just Derek and Colin, and there's a _lot_ of work to do. I said before that I didn't think the public PGP/MIME release will happen until this fall, and I see no reason to change my estimate. By that time, a lot of S/MIME implementations will already be deployed. One strength of PGP has traditionally been its unity. PGP means one message format (the PGP one), one suite of crypto algorithms (the PGP one), one key format (the PGP one), one application (PGP itself). Most of the other proposals are modular in some way, especially with respect to algorithms. PGP is moving in that direction. The most visible evidence of that is the way PGP/MIME is being done. The prevailing philosophy of the PGP people is that the PGP application itself should not decode MIME formats - that should be the job of a separate application. It seems to me that this is going against the tradition, though. In the past, if you got a PGP message, you just ran it through PGP. Now you won't be able to do that. Also, the existing data formats (while pretty good) are going to get changed. The algorithms are going to "go modular" (although I don't think we'll be seeing a Fortezza implementation any time soon). This is going to cause a lot of pain for the installed base. Will it be worth it? We'll just have to see. MSP: not as bad as you think ---------------------------- Earlier, I mentioned that two and a half protocols survived the day. The remaining one is MSP. It's actually not a bad protocol. It has two features that none of the others have: the ability to label classified messages, and a cryptographically strong signed receipt. Both of these functions are highly important for government users. It looks like government suppliers are going to go ahead and implement it, and the government is going to use it. MSP has been around a while, but the effort to turn it into a serious alternative for general Internet use is quite new. Two specs got published this month: a MIME integration spec (sharing the same problems as the old S/MIME), and a spec for plugging in the RSA algorithm suite. With these specs in place, MSP would not be fundamentally that different than, say, S/MIME. My feeling is that the main differences are cultural. MSP still has a very ASN.1, OSI, governmental flavor. Its proponents are making the effort to be responsive to users, but I think there's still a bit of skepticism about that, perhaps misguided, perhaps not. It was announced that there will be a free reference implementation of MSP, available to US citizens. My kingdom for 40 bits ---------------------- I've been thinking about the 40 bit thing a lot. It makes me very uncomfortable. From the cypherpunk perspective, this should be nothing new or remarkable, but keep in mind that there's a _lot_ of pressure on companies to be able to make money in overseas markets. In one of the "modular algorithms" designs, it's not easy to figure out which algorithms your recipient can understand. Guess wrong, and your message goes out with 40-bit encryption. In my opinion, this is worse than no encryption at all, because it gives the false sense of security. Building such a failure mode into an email encryption protocol strikes me as a bad idea. This is my subjective impression, but I sensed that there was a collective delusion that US software developers would actually be able to sell a 40-bit product overseas. Certainly, Netscape has proved that it is possible, but then again, encryption is peripheral to the value of their product. You'd still be using Netscape even if it had no encryption at all, wouldn't you? How many https: URL's are even in your history.db file? For a "secure email" product, it's a different story. There were a few other things that led me to the conclusion of a 40-bit delusion. First, people still seemed to thing that the cypherpunk 40-bit cracks were a concerted effort by highly expert people, rather than the weekend hacks that could be duplicated by any competent sysadmin or grad student. I don't think the message really got through. If 40-bit email gets deployed, we need to make a few more high-profile cracks just to hammer it in. Finally, there's an almost religious belief that making the choice of algorithms indepenent of the encryption protocol will somehow solve the problem. From the point of view of the user, this is just not true. What the user selects is an encryption protocol, an algorithm suite, and whatever other parts of the spec were left open. What the user selects doesn't have any modularity in it at all. It's either a good protocol or a bad one. Maybe customers today think that 40-bit encryption offers some value, but I think they'll soon be disillusioned. This is something that cypherpunks can have a role in. In the medium to long term, it will become clear that 40-bit encryption offers no benefits, and in fact is dangerous. My advice to US developers: don't even try to export a 40-bit version of your product. Just leave crypto out of the export version. Your product will have better performance and many fewer configuration problems. Include 40-bit in the US product if you have to, but don't allow it to be used silently. For example, put up a little dialog that says, "are you _sure_ you want to use 40-bit encryption? It's not secure, you know." If care about offering crypto in the non-US market, form a partnership with overseas developers to add the crypto. Non-US developers, now is a fabulous opportunity. Get those implementations underway, the sooner the better. Coexistence ----------- Since there is no one single standard that everyone feels comfortable with, we will somehow have to deal with the coexistence of multiple conflicting protocols. Fortunately, this is something the Net is good at. Most serious email vendors plan to "implement everything that's real." That means S/MIME for sure, PGP/MIME assuming they can get their hands on a decent implementation, and MSP if they sell a lot of stuff to the government. If everyone follows this path, then we really will have interoperable secure email. Perhaps over the long term, one of the standards would come to dominate, perhaps not. I know that the deployment of secure email has been a year away for the past decade or so, but now I think it really is poised to happen. The implementation effort is very much real. Over the next few months, we will see some very high profile, mass market implementations. Before that happens, though, the protocols must actually become stable. It's a characteristic of _all_ of the viable protocols that they're still in flux, still in the process of being defined. But at least the direction is clear, largely as a result of feedback from this workshop. Consensus --------- At the end of the meeting, Dave asked the room for consensus on several points. First, there was strong consensus that the encryption protocols converge on multipart/security for their signed message format. Second, it was agreed that the proponents of the surviving schemes get together to list their differences, justify these difference, and commonalize things that don't _need_ to be different, also agreeing on a timetable concluding at the Montreal IETF meeting. I'd say that's quite a remarkable achievement for a such a difficult area. Raph Levien