Re: change_cipher_spec [was: draft agenda]

> > More like:  "I don't see any cases where you won't know that the
> > next handshake message from the peer must be 'Finished', even without
> > this 'change cipher spec' message."
> 
> On the client side when setting up a new session (rather than
> continuing an existing one) the handshake message before the Finished
> could be a ClientKeyExchange, or a CertificateVerify if the
> client was asked to authenticate itself.

The ClientKeyExchange is always sent.  CertVerify will only be seen if
there was a Certificate message.  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.


> However the changeCipherSpec message is there, and is an alert
> rather than a handshake message, in order to make better seperation
> between the record layer (which has to know about the change)
> and the handshake layer above it.

Actually it's a new record type.  I can't buy this argument; some
degree of linkage between the handshake and record modules needs
to exist in any case (to tell about the change), but I can see no
reason that implementation details of this linkage need to creep
into the protocol.


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

- Dave

Received on Tuesday, 3 December 1996 12:04:45 UTC