Netscape & Fortessa

All-
	I remember there was some talk about Netscape adding Fortessa support
on here a couple of days ago, so I thought I'd share this.  Marc Andreessen
(president of technology for Netscape Communications) made a presentation
today at the 18th National Information Systems Security Conference about
Fortessa support within Netscape 2.0 to be shipping Beta Q2 '96 and final
the second half of '96 (I haven't seen an official press release, but he more
or less said they were announcing it today).  From his description, it looks
like they are going to place the Fortessa drivers right in the SSL layer
bypassing the software subsystem that currently exists in favor of the
hardware (the software subsystem would still be utilized for non-Fortessa
sessions).  He also commented that this was possibly a lead-in to other
hardware subsystems in the future.  General reaction (at least in my
immediate vicinity in the lecture hall) was quite positive -- looks like
Fortessa is gaining even more momentum (Oracle had a talk about Fortessa
support immediately after Netscape).  I wonder when Microsoft & company will
jump on the bandwagon? :-)

-Michael

 (The above statements are my opinions and do not necessarily represent the
  opinions of the Department of Defense, the US Navy, or the Naval Research
  Laboratory.)

Michael G. Reed <reed@itd.nrl.navy.mil> writes:

>All-
>	I remember there was some talk about Netscape adding Fortessa support
>on here a couple of days ago, so I thought I'd share this.  Marc Andreessen
>(president of technology for Netscape Communications) made a presentation
>today at the 18th National Information Systems Security Conference about
>Fortessa support within Netscape 2.0 to be shipping Beta Q2 '96 and final
>the second half of '96 (I haven't seen an official press release, but he more
>or less said they were announcing it today).  From his description, it looks
>like they are going to place the Fortessa drivers right in the SSL layer
>bypassing the software subsystem that currently exists in favor of the
>hardware (the software subsystem would still be utilized for non-Fortessa
>sessions).  He also commented that this was possibly a lead-in to other
>hardware subsystems in the future.  General reaction (at least in my
>immediate vicinity in the lecture hall) was quite positive -- looks like
>Fortessa is gaining even more momentum (Oracle had a talk about Fortessa
>support immediately after Netscape).  I wonder when Microsoft & company will
>jump on the bandwagon? :-)

There seems to be a convergence on this approach to a hardware
solution.  HP has been pushing for a model in which software with hooks
for hardware encryption will be allowed to get exported.  Then you can
plug in whatever level of encryption you are able to have in the
form of a card token.  Traditionally NSA has opposed export of software
with hooks but there are some indications that this method could be
accepted eventually.

Conceivably we could get to a situation where most encryption is done in
hardware, with the big, ubiquitous software packages like Netscape and
Word and their descendants just having hooks.  This would have some
advantages but overall I think it would be detrimental to cypherpunk
goals.  One of the biggest problems faced by those who want to restrict
access to encryption is how easy it is to do.  PGP and other programs are
virtually impossible to control.  They are easy to write and people can
spread them around trivially.

But hardware is not so simple.  If the only effective way to get
convenient communications with your net access software became to use a
hardware token, then it would be a lot easier to put on restrictions.  An
underground effort to manufacture and distribute tokens would be much
less practical than one to do the same thing for secure software.

I would like to see companies which add hooks for hardware also begin
adding hooks for software packages as well, at least in their domestic
versions.  In the case of Windows, for example, a DLL interface to
provide encryption functions should not be hard to add using a similar
API as for the hardware crypto card.  Similar interfaces should be
possible on other OS's.  Companies which do this will demonstrate their
commitment to making good quality cryptography available to their
customers.  A system which is "open" only to the extent that a hardware
card can be added is not sufficient.  A truly open system will allow
software add-ons as well.  Let's keep an eye on how this develops and let
the companies know how we feel.

Hal

-----BEGIN PGP SIGNED MESSAGE-----

In article <199510110025.RAA10439@jobe.shell.portal.com>,
hfinney@shell.portal.com (Hal) wrote:

> There seems to be a convergence on this approach to a hardware
> solution.  HP has been pushing for a model in which software with hooks
> for hardware encryption will be allowed to get exported.  Then you can
> plug in whatever level of encryption you are able to have in the
> form of a card token.  Traditionally NSA has opposed export of software
> with hooks but there are some indications that this method could be
> accepted eventually.

Yes, it might, because of the strong support by vendors for voluntary GAK
or no crypto at all. Let me explain. There are a number of indicators that
show that strong crypto is losing in the global marketplace. Example: the
charter of the new IETF Internet Payment Systems working group requires
that the use of crypto be limited. In the discussion about the charter,
the near unanimous consent (with myself as the sole dissenter) was that
crypto may only be used for authentication, not confidentiality.

It is true that the prospect of loosening the rules for crypto
software/hardware implementations is a major motivator in the marketplace.
The whole development of National Semi's iPower PCMCIA card was driven by
a promise made by the NSA of high lot numbers due to (future?) relaxed
export rules. I suppose that trapdoors in hardware are much harder to find
than trapdoors in software.
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBMHtHmCoZzwIn1bdtAQFm6AGAje0x07V6Ak/nnBLIQyAv9XDZToUw0vju
2GmRq/F1eSeiiOGfXwVGP+irPFd1W/tg
=nix8
-----END PGP SIGNATURE-----

Lucky Green writes:
> Yes, it might, because of the strong support by vendors for voluntary GAK
> or no crypto at all. Let me explain. There are a number of indicators that
> show that strong crypto is losing in the global marketplace. Example: the
> charter of the new IETF Internet Payment Systems working group requires
> that the use of crypto be limited. In the discussion about the charter,
> the near unanimous consent (with myself as the sole dissenter) was that
> crypto may only be used for authentication, not confidentiality.

I wasn't aware of that -- I believe that this may have happened
because those of us who cared didn't attend the zoo in Stockholm. The
meeting was a complete joke, with the Microsoft people and others
making it clear that they didn't intend to follow the process. Many of
us who cared decided to do better things with our time instead of
showing up in the aptly named Weapons room for the second session.

.pm