From: Robert Hettinga <rah@shipwright.com>
Date: Wed, 31 Dec 1997 08:49:11 -0800 (PST)
To: Recipient List Suppressed:;
Subject: Why use open crypto/commerce source?
Message-ID: <v04002704b0d01d4bd237@[139.167.130.249]>
MIME-Version: 1.0
Content-Type: text/plain


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/>