- From: David P. Kemp <dpkemp@missi.ncsc.mil>
- Date: Fri, 24 May 1996 12:07:24 -0400
- To: ietf-tls@w3.org
> From bsy@work.ucsd.edu Wed May 22 20:07:31 1996 > > > I believe the issue is not whether the platform / OS (it's not just > > an OS question) will be replaced with something "secure", it is whether > > an IETF-standardized protocol should be designed in such a manner as > > to facilitate the development of secure systems, as opposed to relying > > on each separate application to design and incorporate it's own security. > > Perhaps I'm being dense, but I don't see how having -any- security > protocol standardized by IETF would mean relying on every separate app > to design and incorporate its own security. I guess I was trying (poorly) to make the distinction between having a single protocol that does both key management and encryption, and having two independent protocols. The "each separate app" business refers to the relative ease with which applications could be written to include Record-Layer-only code, vs. the difficulty of each app having to also include key and certificate management functions. > As long as (minimally) version numbers exist to provide an on-wire > upgrade path and with reasonable API design, we'd have to at most > relink the apps. Unless, of course, the standardized protocol > actually fails to provide any security properties whatsoever. Yes, you can accomplish anything with version numbers :-). I believe that one of the requirements of the TLS working group should be to specify a Record-Layer protocol that defines the on-the-wire data, along with an (extremely simple) API to allow session keys to be fed into the implementation of the protocol, whether the implementation resides in user space (the browser) or kernel space (the network stack). A completely independent requirement should be to define the handshake protocol by which the session keys are established. That is where all the session/connection state is maintained, where the debate over CipherSuite bundling will occur, where implementations will have to do certificate passing, parsing, validation, and caching, etc. These are the hard problems, and it makes sense to divorce them from the easy problem of defining a record layer. > > Modifying the network stack on Unix hosts only requires kernel > > modifications (and source) if you're using an obsolete Unix. If > > the kernel uses Streams networking (Solaris, for example) the > > application can just push another Streams module onto the stack. > > Installing a streams module require root access. Certainly heretofore > browser installation had not required such, so "just" pushing another > Streams module isn't necessarily something that we can mandate. > Furthermore, last I heard Netscape provided a Linux version of > Navigator, and while users of these systems are more likely to have > root access, Linux/*BSD does not have Streams. That paragraph was just a gratuitous dig at the people who are still using SunOS 4.x. I should have included a smiley, or omitted it altogether. Regardless, compliance with the proposed independent record/handshake TLS protocols does not mandate any particular implementation, app or stack-based. It just happens that separating out the key management protocol enables network stack implementations; it doesn't mandate their use.
Received on Friday, 24 May 1996 12:07:20 UTC