From: "Erik E. Fair"  (Time Keeper) <fair@clock.org>
Date: Wed, 20 Sep 95 04:36:04 PDT
To: Jeff Weinstein <jsw@netscape.com>
Subject: Re: Please send me SSL problems...
Message-ID: <v02110104ac85a804545b@[204.179.132.1]>
MIME-Version: 1.0
Content-Type: text/plain


>  I'd just like to let all cypherpunks know that I'm really interested in
>getting any feedback you might have about security problems with Netscape
>products.  I'm particularly interested in bugs in the our implementation
>of SSL, and problems in the protocol that are not addressed in SSL 3.0.
>
>  We have been collecting comments on SSL 3.0, and have started incorporating
>that feedback into our spec.  Please don't assume that our lack of response
>means that we are ignoring your comments.  Between Navigator 2.0 and
>things like the SSL challenge and the RNG fire drill, we just have not had
>the time to get a new rev of the spec out.  Hopefully soon...

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.

About the SSL protocol, encryption algorithms, or the SQA that went into
'em, I think other people have expounded on those issues eloquently, and so
I have nothing to add to that.

Erik Fair