[3500] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: Netscape Wants MS to Weaken IE's SSL/RSA Handshake for Export

daemon@ATHENA.MIT.EDU (EKR)
Fri Oct 16 14:54:16 1998

To: Vin McLellan <vin@shore.net>
Cc: cryptography@c2.net
From: EKR <ekr@rtfm.com>
Date: 16 Oct 1998 11:35:33 -0700
In-Reply-To: Vin McLellan's message of "Fri, 16 Oct 1998 11:56:53 -0400"

A bedtime story...
This takes place in the time when the State department still
controlled export and getting approval to generally distribute was
called CJ (Commodities jurisdiction) [1]. The way things used to work was
that there was something called 7 and 14 day fast track approval. If
you met certain criteria (512 bit RSA keys and 40 bit symmetric
crypto) you could get fast track. It was widely understood (though
never stated) that these key lengths were pretty much fixed limits and
that you would never get approval for anything better. That is to say,
you didn't have to do fast track but if you didn't come pretty close
to meeting the fast track requirements, you wouldn't get approval at
all.

Back in those days there was SSLv2 (SSLv1 doesn't even merit
discussion.) SSLv2 did it's key exchange in a very simple fashion. It
encrypted a master key under the server's key (as found in the
certificate).  SSL was carefully designed to allow exportable
cryptography (40 bit RC4). However, Netscape got export approval (and
shipped) a version that accepted 1024 bit RSA keys for handshakes. The
way I heard this, NSA just goofed, but I heard that nth hand.
Naturally, it's possible that NSA made a policy decision to let this
through. I just don't know. Maybe someone else an fill
in this detail.

But this put everyone else in an unacceptable position. Netscape was
the gold standard for SSL compliance, but exportable Netscape would
take keys that it wasn't supposed to take. This meant that everyone
else had to try to export 1024 bit RSA as well, because explaining to
people why your code didn't work and Netscape's did was just too
hard. I don't know who else got export approval, but apparently at
least Microsoft did. Probably some people just exported the damn thing
anyway.

When I worked for Terisa, we told our customers how to configure their
systems both for certain compliance and for what might be called
"Netscape export mode". I don't know what they typically actually got
export for.

Now along comes SSLv3. SSLv3 includes an ephemeral RSA key feature,
which means that you can use a 1024 permanent key for authentication
but a 512 bit key for key exchange. IIRC Kocher added this feature
because he wanted it to be easy to get CJ but he didn't think 512 was
good enough. No (export) SSLv3 implementation that I know of will
accept a 1024 bit key for key exchange.

In any case, it's hard for me to believe that Netscape hasn't known
about this problem in v2 for quite some time. It's certainly been
widely discussed in SSL circles. So it seems fairly disingenous to me
for them to suddenly get religion and complain that MS is in
violation, since MS was just trapped into doing things this way in
order to match Netscape.

Now, I don't know exactly the politics that lead to Netscape's
changing their code were. Perhaps someone from Netscape can comment.

In any case, it seems to me that if MS got approval for something
(whatever it is) and they didn't misrepresent it to NSA, then
they're in compliance. 

Hope this helps,
-Ekr

[1] Yes, I know that CJ ACTUALLY meant that Commerce could decide
on export, but it was also understood that Commerce would pretty
much approve once you got CJ.
-- 
[Eric Rescorla        Independent Security Consultant         ekr@rtfm.com]


home help back first fref pref prev next nref lref last post