Re: change_cipher_spec [was: draft agenda]

Note that one purpose of the change cypher spec command was to allow the
cypher used for the SSL session to change depending upon content.  For
example,the administrator could choose to protect one directory with one
grade of security and another with some other form of security.  The
value of such a feature can certainly be debated, but I just wanted to
point out that I think this was one objective.

David Brownell - JavaSoft wrote:
> > > This is a more interesting kind of claim to make.  But there was a
> > > recent comment (Christopher Allen?) about the probably desirability
> > > of making the handshake state machine fully specified, with which I
> > > basically agree.  I think it'd be reasonable to require such new
> > > handshake protocols to be fully specified w.r.t. the point at which
> > > cipher specs change, like the current handshake protocol.
> >
> > Yep, I agree.  However I could see having a TLS implementation
> > that can use either of two (or more) different handshake protocols, with
> > the same record layer underneath (in fact at one point I was prepared to do
> > this for PCT).  The record layer would decide, based on the initial
> > message, which handshake type was being used.  I think that the
> > changeCipherSpec makes this a bit easier, and we should keep
> > it, especially if the handshake and record specs are split into
> > two standards as has been proposed.
> If those handshake protocols are well specified in the way I suggested,
> then having multiple such protocols would never be a problem.
> > I don't think it's that big a deal though.  If changeCipherSpec went
> > away, implementations would be a little uglier and it'd be a little
> > more difficult to seperate the handshake and record layers, but it
> > wouldn't be impossible.
> They're already closely related; I can't see new ugliness coming in.
> Code related to change_cipher_spec gets removed, and the existing
> hook in the record layer (triggered by receipt of change_cipher_spec,
> when conditions are right) gets triggered by receipt of a different
> message (again, if conditions are right).
> - Dave

Eric Greenberg, Security Product Management
Netscape Communications Corp.  
-- "speakin for just me and no one else" --

Received on Tuesday, 3 December 1996 15:22:46 UTC