Will Price of PGP writes one of the best-organized arguments for open cryptography source code -- and I would extend that to digital commerce code as well -- that I've seen in a while. While I wonder if this may be written more for Will's new colleagues at Network Associates than anywhere else :-), I would reccommend that anyone who asks you "How can you sell open source?" get a copy of this. Excellent, Will. Cheers, Bob Hettinga --- begin forwarded text X-Sender: wprice@205.180.136.16 Mime-Version: 1.0 Date: Tue, 30 Dec 1997 20:01:03 -0800 To: ietf-tls@consensus.com, ietf-open-pgp@imc.org From: Will Price <wprice@pgp.com> Subject: Re: Proposed Extensions to TLS for OpenPGP Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Rather than quoting the messages on this topic, I'll just reference the other messages on the topic of export algorithms and issues which originated from my exclusion of export algorithms from the TLS/OpenPGP Spec. The debate over exactly what one can export legally usually proceeds under seriously false assumptions in my opinion. It generally starts with what bit level algorithm can be exported, proceeds to discussions about hooks whether general or crypto specific, usually has some mention of MS-CAPI until people realize that the modules have to be signed, those with legal knowledge try to jump in and help, and ends up with people being somewhat confused and feeling fairly helpless leading to less crypto software being written -- exactly the result the US government intended. Not directed at anyone in particular, but let's get back to basics people. There's no sense whatsoever in putting "export" algorithms into a product. It isn't encryption. The time is truly upon us when export algorithms are crackable in near real time by normal people. You might as well include a decoder ring with your product, it will take just as long or longer to decrypt for a casual attacker. At Pretty Good Privacy, we developed a reliable system which will be continued by Network Associates. The outline: write source code for product, print source code in book, distribute book using normal means. Now the process becomes somewhat foggier. In any case, printed source code for product gets exported -- note that this is of course legal. Individuals outside the US scan source code. A legally exported binary version of the product then becomes available internationally. Copyrights, trademarks, and licenses protect the original vendor and revenue can be made off the exported product. This is only one highly functional system for getting this done. One other alternative is to base all R&D outside the US which is infeasible for most US companies -- but Sun did it with SKIP. Finally, the crypto hooks mechanism does work and Commerce does in fact approve APIs that are intended for crypto but have been generalized for other uses, Qualcomm's EMSAPI used in Eudora is a perfect example of this. I can hear the first cry that some people will have now: are you crazy, we can't publish our source code! My response: well then what are you doing in the security business? This sector isn't about proprietary algorithms and code. It is not feasible to achieve secure software without public peer review by many cryptographers. We have seen time and time again how the smallest security bugs have turned into major international crises for some of the larger companies doing this. One can only imagine how many more such issues are left to be found were a quality cryptographic public peer review to take place on such products with access to source code. The majority of users reading the New York Times have no clue what a particular security flaw is about. They just know that the NYT says that product is insecure. Such stories reduce user faith in everybody's security products. The only solution is public code review. Now I can hear not only the cries about publishing source code, but the feathers of some readers getting ruffled believing that I have implied security flaws in their wonderful products. Not at all. I have the utmost respect for any company that makes an attempt to write crypto software in the US. We're all under these silly laws together. I use some of the products which have had reported security flaws in the past, but those products would be that much more valuable if one was able to trust their security from 3rd party review and if their protocol infrastructures had not been infected by 40 bit scrambling algorithms. Some companies will undoubtedly never bring themselves to implementing one of the above systems and will thus be relegated to snake oil security internationally until the laws in the US change. However, there *are* good and reliable ways for even the largest companies to solve this problem legally. Inclusion of "export" algorithms is, IMHO, security suicide. What has happened in many cases is that the installed base of, for instance, S/MIME and SSL users has been so infected by 40 bit clients that the vast majority really have no idea that the security they are using is completely useless. It forces those few with secure clients corresponding with those using 40 bit clients to also use 40 bit and so on -- generally without any warning to either user that their security has been eliminated. Some companies like Wells Fargo have tried to take a stand and require 128 bit crypto SSL and they get major flack from users who don't understand what is wrong with their 40 bit browser. Caving in and using 40 bit algorithms is *not* a solution to anything. We all know this, but the speed of business can make that choice less clear. The argument that "we have to sell it, so we have to include 40 bit" just doesn't wash given that there are all sorts of creative legal alternatives. The bigger the company, the more resources that company has to enable the alternatives -- which is why it is so odd that the smaller companies often produce the more secure software. Mass producing a source code book of
7000 pages for the PGP products isn't something a one person operation would be doing, but is trivial for a normal company.
Let's not infect our protocols with such politics. TLS 1.0 is a done deal as far as I'm concerned. SSL3 had export algorithms, so TLS1 does too, fine. There are now many better solutions to the export problem, let's not fall into the trap of using the easiest way out in new specifications. -Will Will Price, Architect Network Associates, Inc. Direct (650)596-1956 Main (650)572-0430 Fax (650)631-1033 Cell/VM (650)533-0399 <pgpfone://clotho.pgp.com> PGPkey: <http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0xCF73EC4C> --- end forwarded text ----------------- Robert Hettinga (rah@shipwright.com), Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/ Ask me about FC98 in Anguilla!: <http://www.fc98.ai/>