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