Re: change_cipher_spec [was: draft agenda]

> > 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

Received on Tuesday, 3 December 1996 13:24:31 UTC