Does DTLS Change_Cipher re-transmission use same epoch as original one or the new one?

Question

DTLS endpoints are required to re-transmit the entire flight of handshake messages in case there is a timeout. Before timeout event, the transmit epoch can change at record protocol. Which epoch is used for re-transmission of messages? The old one of the new one?

E.g., during initial handshake, client sends a flight comprising of key_exchange, ChangeCipher & FINISHED messages. The key_exchange, CCS are sent with epoch=0 and FINISHED is sent with epoch=1.

Say ChangeCipher gets lost.

Does the retransmission of full flight happen in epoch-1 (which is latest one)? If this is the case, the peer has no way of decoding the flight.

Or

Does the retransmission of records happen in same epoch as original but new record protocol sequence numbers are used? In this case, handshake protocol needs to pass epoch information to record protocol. Also record protocol is required to maintain multiple transmit epochs.

Answer 1

The handshake protocol retransmits its messages using the same epoch as it used in the first original transmission.

DTLS1.2 RFC6347 section 4.1 hints about it. However the text to reuse the same epoch is not explicit.

... some care needs to be taken during the handshake to ensure that retransmitted messages use the right epoch and keying material...

For the situation where ChangeCipherSpec gets lost, it cannot be retransmitted in the new epoch. Doing so will lead the ChangeCipherSpec recipient to a situation where it does not have anyway to decrypt it because its own receive side record layer cipher state has not been updated yet with the keys of new epoch.