- From: Eric Murray <ericm@lne.com>
- Date: Tue, 3 Dec 1996 09:48:05 -0800 (PST)
- To: david.brownell@Eng.Sun.COM (David Brownell - JavaSoft)
- Cc: ericm@lne.com, ietf-tls@w3.org, satishd@doppio.Eng.Sun.COM
David Brownell - JavaSoft writes: > The server knows if it's going to get a > CertVerify or a Finished handshake message next. When it expects a > Finished message next, it can enable the record-level behaviour which is > now triggered by receipt of change_cipher_spec ... triggering it by recipt > of the next handshake message instead. This works with the current set of handshake messages. But if the messages are changed so that the arrival of the Finished message is not predictable, or the Finished message isn't the first one to be encrypted under the newly-negotiated session, then it wouldn't work. It also requires a way to call into the record layer from the handshake layer to tell the record layer to switch to the new session. That's no problem in most current SSL implementations but might not be so easy in one that keeps the record layer and the handshake layer more seperate. > > Theoretically you could invent a new handshake protocol, and the > > underlying record layer wouldn't care (and the code wouldn't have to > > be changed) as long as your new handshake included changeCipherSpecs > > at the appropriate time. > > This is a more interesting kind of claim to make. But there was a > recent comment (Christopher Allen?) about the probably desirability > of making the handshake state machine fully specified, with which I > basically agree. I think it'd be reasonable to require such new > handshake protocols to be fully specified w.r.t. the point at which > cipher specs change, like the current handshake protocol. Yep, I agree. However I could see having a TLS implementation that can use either of two (or more) different handshake protocols, with the same record layer underneath (in fact at one point I was prepared to do this for PCT). The record layer would decide, based on the initial message, which handshake type was being used. I think that the changeCipherSpec makes this a bit easier, and we should keep it, especially if the handshake and record specs are split into two standards as has been proposed. I don't think it's that big a deal though. If changeCipherSpec went away, implementations would be a little uglier and it'd be a little more difficult to seperate the handshake and record layers, but it wouldn't be impossible. -- Eric Murray ericm@lne.com ericm@motorcycle.com http://www.lne.com/ericm PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03 92 E8 AC E6 7E 27 29 AF
Received on Tuesday, 3 December 1996 12:48:46 UTC