Re: change_cipher_spec [was: draft agenda]

David Brownell - JavaSoft writes:
>  The server knows if it's going to get a
> CertVerify or a Finished handshake message next.  When it expects a
> Finished message next, it can enable the record-level behaviour which is
> now triggered by receipt of change_cipher_spec ... triggering it by recipt
> of the next handshake message instead.

This works with the current set of handshake messages.  But if
the messages are changed so that the arrival of the Finished
message is not predictable, or the Finished message isn't the
first one to be encrypted under the newly-negotiated session, then
it wouldn't work.

It also requires a way to call into the record layer from the
handshake layer to tell the record layer to switch to the new
session.  That's no problem in most current SSL implementations but
might not be so easy in one that keeps the record layer and the
handshake layer more seperate.

> > Theoretically you could invent a new handshake protocol, and the
> > underlying record layer wouldn't care (and the code wouldn't have to
> > be changed) as long as your new handshake included changeCipherSpecs
> > at the appropriate time.
> 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.

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.

Eric Murray
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF

Received on Tuesday, 3 December 1996 12:48:46 UTC