Re: change_cipher_spec [was: draft agenda]

Phil,

Thanks for the first answer that really makes sense!  :-)


> > Is "change cipher spec" as a record type an artifact of some early SSL
> > implementation, which might be removed in a "new protocol based on the
> > SSL 3.0 specification"?
> 
> It's there for 2 reasons.
> 
> 1) Hardware implementations.

This seems to me like it's the most solid argument.  Are there really
hardware implementations under way?  Intriguing.


> Imagine a pipelined implementation of a TLS protocol engine (record
> gathering, decompression, decryption). At the point that a cipher spec
> changes, the pipeline must be stalled/flushed so that the new ciphers
> and keys can be loaded (potentially in parallel) into that engine.
> 
> It is very convenient for there to be a simple test for the hardware to
> make to know to do that stall (as opposed to having to understand the
> semantics of the protocol).

To restate this point ... you're saying that the hardware needs to have
a simply specified synchronization point where it can stall until ciphers,
keys, and compression algorithms are specified by the handshake engine.
(Which I'll assume is implemented in software.)

The approach I'd suggested relied on the fact that software isn't often
going to operate concurrently at that fine a granularity, so one could
rely on an "implicit stall" ... the event/message which arrived to
signal "time to change ciphers/keys" wouldn't be detected until the
preceding message was fully processed.


> > A particular behaviour
> > is triggered when several conditions (knowable only to the
> > handshake layer, until it tells another layer) are satisfied,
> > and a particular meessage comes in. 
> 
> The point is to be able to have the condition be knowable outside the
> handshake layer.

I was talking about the "READY to change cipher state" condition,
which won't be known outside the handshake layer unless some other
layer (record?) understands the handshake protocol. The hardware
wouldn't itself be ready until it knew the keys and algorithms to
use on the next set of records -- it'd stall until they were known.
Then the record layer can decrypt the next message ("Finished") etc.


> It is incumbent upon the handshake layer implementation to verify that
> the underlying engine went through the transition at the point that the
> handshake layer expected it to. That still does not make it a handshake
> layer condition.

But the underlying engine can't go through that transition without
access to the crypto keys, so it can't do the transition until it's
told by the handshake layer "here are the cipher and keys".

- Dave

Received on Wednesday, 4 December 1996 00:22:21 UTC