Subject: [TLS] make ChangeCipherSpec a handshake message

From: Hauke Mehrtens <[email-masked]>
Date: Sun, 28 Dec 2014 18:06:39 +0100

Why is ChangeCipherSpec a special type and not just a handshake message?
It is only send in the handshake and preceded and followed by handshake
messages.

DTLS has some functionality for reordering of handshake messages. All
the handshake messages have a message_seq field which is used to bring
the messages into the right order again and detect duplicates. The
messages can get into the wrong order if they are send independently and
not the hole flight in one turn. This gets even messier when the
packages are getting retransmitted. When packages are getting
retransmitted all packages from a flight are getting retransmitted even
if just one of these packages were not received. With the message_seq
field one can detect if this package was already received and what is
the next package to handle.

The ChangeCipherSpec package does not have a message_seq field, but it
also has to get reordered and retransmitted like the handshake packages.

RFC 6347 already says there is a problem in DTLS:
https://tools.ietf.org/html/rfc6347#section-4.2.5

I worked on a DTLS 1.2 implementation some time ago and there I had to
do some magic to support reordering of the ChangeCipherSpec message.

My proposal for TLS 1.3 is to make ChangeCipherSpec a normal handshake
message. This should make DTLS implementations based on TLS 1.3 easier
and TLS 1.3 gets rid of one special case. When this gets changed the
enum in the ChangeCipherSpec message can get removed as it only contains
one static value. The ChangeCipherSpec message would be similar to the
ServerHelloDone message.

Hauke

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 28 Dec 2014 19:20:56 +0200

> the next package to handle.

I think the plan is to rip out CCS entierely, that is, rely on handshake
state machine to initate the key transitions (which should make it more
difficult to get wrong).

-Ilari

---

From: Hauke Mehrtens <[email-masked]>
Date: Sun, 28 Dec 2014 18:48:50 +0100

> state machine to initate the key transitions (which should make it more

Removing CCS entirely is the best solution. I haven't seen any
discussions about this plan. I just looked into the TLS 1.3 handshake in
more detail and it should be pretty easy to detect where a CCS should
be. As long as all handshakes are using ECDHE, DHE or something with a
similar handshake I do not see a problem with just removing the CCS
message, but when something like static PSK Cipher are getting added and
the handshake is very different there it could cause some problem. (I
haven't thought in detail about this)

Actually in the DTLS implementation I worked on, I placed the CCS
message more or less by guessing form the context.

Hauke