From: "Jeff Weinstein" <jsw@netscape.com>
Date: Thu, 21 Sep 95 01:07:51 PDT
To: "Erik E. Fair"  (Time Keeper) <fair@clock.org>
Subject: Re: Please send me SSL problems...
In-Reply-To: <v02110104ac85a804545b@[204.179.132.1]>
Message-ID: <9509210104.ZM154@tofuhut>
MIME-Version: 1.0
Content-Type: text/plain


On Sep 20,  4:35am, "Erik E. Fair"  (Time Keeper) wrote:
> Subject: Re: Please send me SSL problems...

> Jeff, the SSL specification has a severe *architectural* problem - it
> assumes that Internet Protocols are APIs - interface standards, and that
> you can just slide a "layer" underneath without anyone noticing. Such is
> not the case - all the Internet Protocols are real protocol standards, in
> that they specify the syntax, order, and semantics of the actual bits on
> the wire. The IETF quite explicitly doesn't care about APIs - that's a host
> software issue, and it doesn't matter what the host software looks like (or
> even what the machine looks like), so long as it gets the bits on the wire
> right, according to the protocol spec. This is how the Internet can make
> very strong guarantees about interoperability.
>
> You can't fiddle with a communication protocol without getting agreement
> from everyone about the change, or extend it in a way that is compatible
> with the protocol you're modifying, on a per-protocol basis (e.g. adding a
> TELNET negotiation option to TELNET for encryption, an FTP command to FTP,
> etc). Otherwise, all you've done is made a private, non-interoperable
> change to an existing protocol that guarantees interoperability *failures*
> between systems that implement the existing specification, versus your own
> version of HTTP, or TELNET, or whatever. In short, the SSL specification,
> as written, proposes to change all Internet application protocols, globally
> - "slide in a layer." That's not how it's done, and it's not the right
> place to do it, even if it appears to work in an enclave of systems.

  My view of SSL is that it should not generally be considered a transparent
layer that can be plugged in below any application.  I don't consider
HTTP on top of SSL to be the same as HTTP, or something that can totally
replace HTTP.  Thats why we use a different port and call it https: and not
http. I think using TELNET and FTP as examples of protocols that can be
transparently layered on top of SSL was unfortunate.  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.

  It seems that the thing you are objecting to is the wording in the
spec, in the "motivation" section, that appears to suggest that the
entire internet could run on top of SSL.  I think that section of the
spec could just be chopped out, and SSL would still be useful today
without pretentions of world domination.

  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).

  This was sort of off the top of my head.  I've not spent long hours
contemplating these questions...

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.