At 11:15 PM -0800 12/30/97, Eric Rescorla wrote:
Will, I'm not particularly interested in debating protocol
level crypto policy here. However, the crypto export laws
are reality for most people here, and I find your attempt to
imply that they're easily worked around fairly disingenuous.
Easily? If you got the impression from my message that it was easy, I
suggest you read it again. What you imply here is that you need an easy
solution. If you were willing to do something slightly less than easy, you
might find another solution as other companies have. This issue is at the
very core of secure software. If it isn't done right, nothing is. Use of
40 bit scrambling is exactly the kind of issue on which companies making
security products cannot use the easy solution.
Will Price <wprice(_at_)pgp(_dot_)com> writes:
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.
It's hard to believe that this is really going to work for many
real programs. Have you seen the size of Netscape lately. Have
you noticed how often Netscape ships new versions? (I'm not
trying to pick on Netscape here. IE has similar characteristics.
There are plenty of other big programs but web browsers hae
particularly fast release cycles.)
Have you seen the size of PGP 5.5.3 on 10 different platforms lately with
all the GUI code? It's not exactly small. As for dot releases, use a diff
printed release. Publish the diffs since the last source release. We've
done it. It works. Big is not an issue. Binaries, pictures, and all the
other things that go into a product are not an issue. Very simple, solved
problems.
insecure. Such stories reduce user faith in everybody's security products.
The only solution is public code review.
It's not obvious this makes much of a difference. Note that Sendmail
source code has been widely available since the beginning.
Nobody trusts sendmail. Nobody needs to trust sendmail if they use secure
mail. Secure systems are built to be simple enough to comprehend fully so
that reviewers can analyze it fully. Sendmail clearly doesn't fall into
this category. Everyone knows sendmail is buggy, so nobody wastes their
time trying to document every bug.
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.
I think it's unreasonable to say that 40 bit crypto is "snake oil".
It's exactly as strong as advertised. There's no secret about the
situation.
There is no "advertising" of it. The users are simply unaware --
effectively making it a secret. When was the last time you saw a big
company putting a very visible warning about 40 bit security inside its 40
bit product? I know I've never seen something like that. Further, even
the strong crypto products are infected by the weak crypto products in
protocols like S/MIME and SSL which require both sides to use the same
algorithms. No warning is given in those cases either in any of the
products I've examined. It leads to a cascade effect wherein the vast
majority of users end up having no security when they think they do have
security. The deceit here is that even when users learn about 40 bit
security, they think it is still encryption. Realistically, it just isn't.
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,
Perhaps, but you haven't suggested any.
I suggested three each of which is completely workable and in use by real
companies as big as Sun. It isn't clear how you say that I have not
suggested any when there are very clearly three alternatives suggested. If
these don't work for you, I suggest seeking legal advice. There are many
other roads that haven't yet been travelled. Don't look for the easy
solution, look for the right solution.
-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>