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.


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.

  • $\begingroup$ I looked at openssl code. It retains epoch IDs for every handshake message fragment and uses it while retransmission. $\endgroup$
    – Vakul Garg
    May 26 '17 at 11:43

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.