From: "Joe Tardo" <joe_tardo@genmagic.com>
Date: Thu, 21 Sep 95 11:59:48 PDT
To: "Jeff Weinstein" <jsw@netscape.com>
Subject: Re: Please send me SSL prob
Message-ID: <n1400438055.58002@qm.genmagic.com>
MIME-Version: 1.0
Content-Type: text/plain


        Reply to:   RE>>Please send me SSL problems...

Jeff:

The name chosen for SSL was, perhaps, unfortunate and misleading, but should
not get in the way of the kind of service it provides.  I keep combing the
spec looking for socket-like api's, and so far have not found any  :-).

> I've looked at
>what it takes to make some existing protocols work with SSL, and I'm not
>convinced that its always appropriate.  For example FTP and RCMD use
>multiple connections, which is a royal pain.

Doesn't HTTP use a new connection for every GET?

> If a secure IP standard emerges that is widely deployed and provides
>similar services, I don't see why SSL couldn't just go away (this is my
>opinion, not an official position of netscape).

The ipsec people are currently debating what it means to do replay detection
on an unreliable datagram service, what it means to authenticate 
individual users in a layer that only knows how to name host endpoints, how
a protocol specification deals with how policy would be set for mixed 
encryption service requirements, etc.  This is not the first time these 
points have been debated in the history of the universe, nor the first 
attempt at a 'one size fits all' security protocol.

I, personally, would not be too quick to expect IP security to solve all of 
your problems, but it will do a better job on, say, host-to-host disclosure 
protection.  It will, however, require new kernel code or low-level 
driver or hardware hacks,  which simultaneously provide the better 
protection and a barrier to security deployment for a product like 
Netscape's.

Now, how about fixing SSL's keying so it has perfect forward secrecy?

-Joe