- From: Phil Karlton <karlton@netscape.com>
- Date: Wed, 04 Dec 1996 14:45:44 -0800
- 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? Yes. > 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, Precisely. > 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. 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 Wednesday, 4 December 1996 17:46:42 UTC