- From: David P. Kemp <dpkemp@missi.ncsc.mil>
- Date: Thu, 5 Dec 1996 13:27:38 -0500
- To: ietf-tls@w3.org
> Date: Tue, 03 Dec 1996 11:28:25 -0800
> From: Tom Weinstein <tomw@netscape.com>
>
> It's there as an explicit indicator of the change. Yes, it would be
> possible to make it implicit, but for protocol purity reasons, we don't
> like implicit things, especially state changes. The fact that it's a
> different record type instead of a handshake message is just a way of
> making sure that someone can't send it in the middle of a handshake
> record.
Actually, from a protocol purity point of view, I believe it is
preferable go implicit (eliminate the ChangeCipherSpec message).
Any information that is both transmitted explicitly and known
from the protocol state can be treated 2 ways:
1. verify that the transmitted and inferred info agree, or
2. use the transmitted info only, without checking to see if it
is consistent with what is known.
(or 3. act on known state and ignore what is transmitted -
I haven't seen this proposed yet :-)
Keeping the ChangeCipherSpec message is only useful if it adds
information to the protocol exchange. If it doesn't, sending it
only forces extra checks (to see that it is received when expected
and not received when not expected), or opens up the potential
for bugs if implementors forget one of the consistency checks.
Implicit coding is already used in SSL for sequence numbers, which are
included in the MAC calculations but never transmitted. This is one of
the beautiful features of the protocol.
I agree with David Brownell that ChangeCipherSpec should be implicit.
dpk
Received on Thursday, 5 December 1996 13:28:13 UTC