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.