- From: Phil Karlton <karlton@netscape.com>
- Date: Tue, 03 Dec 1996 14:36:16 -0800
- To: David Brownell - JavaSoft <david.brownell@Eng.Sun.COM>
- CC: ietf-tls@w3.org, satishd@doppio.Eng.Sun.COM
David Brownell - JavaSoft wrote:
>
> One more protocol issue ... I've never seen an explanation about why
> the "change cipher spec" record is necessary. It seems like all that's
> needed is the ability to flush the handshake messages which have been
> queued, since I don't see any cases where the next legal handshake
> message isn't predictable from the current protocol state.
>
> 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.
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).
2) Future extensibility.
Handshake protocols have been proposed (and I strongly suspect will be
proposed in the future) where some of the handshake messages will have
to be encrypted for security reasons. Having an explicit marker makes
implementations and analysis easier.
PK
--
Philip L. Karlton karlton@netscape.com
Principal Curmudgeon http://www.netscape.com/people/karlton
Netscape Communications Corporation
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
Received on Tuesday, 3 December 1996 17:37:01 UTC