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

Re: change_cipher_spec [was: draft agenda]

From: Phil Karlton <karlton@netscape.com>
Date: Wed, 04 Dec 1996 14:45:44 -0800
Message-ID: <32A5FF17.6495@netscape.com>
To: David Brownell - JavaSoft <david.brownell@Eng.Sun.COM>
CC: ietf-tls@w3.org
David Brownell - JavaSoft wrote:

> Are there really
> hardware implementations under way?


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

I've seen proposals where (nearly) everything except an outcall or two
to check policy conditions (such as "Do we trust this CA, I don't have
it in my tables") is done in hardware/firmware.

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

... and the record layer remains stalled until that happens. The
presentation of cipher and keys needs to block (or timeout with error)
until the change cipher spec comes along.

In my opinion, it's better to have this synchronization point be
explicit in the protocol as opposed to implicit in the state of the
handshake (for either hardware or software). It also helps to keep the
record and handshake layers less interdependent.

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 Wednesday, 4 December 1996 17:46:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:12 UTC