W3C home > Mailing lists > Public > ietf-tls@w3.org > October to December 1996

Re: change_cipher_spec [was: draft agenda]

From: David Brownell - JavaSoft <david.brownell@Eng.Sun.COM>
Date: Tue, 3 Dec 1996 09:04:45 -0800
Message-Id: <199612031704.JAA07149@argon.eng.sun.com>
To: ericm@lne.com
Cc: ietf-tls@w3.org, satishd@doppio.Eng.Sun.COM
> > 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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:55 EDT