Re: Missing requirements

> 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