- 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