DTLS 1.2 (RFC 6347) Compliance Observations in tinydtls

Hi, while reviewing tinydtls's DTLS 1.2 implementation against RFC 6347, we noticed several
places where the current behavior appears to differ from the specification. Each item below
cites the relevant RFC text alongside the corresponding source code for your reference.
We hope this is helpful for improving RFC conformance.

---

1. Epoch Wrap Protection Not Currently Enforced

RFC Reference: RFC 6347 Section 4.1

"Similarly, implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association as described in Section 4.2.8."

Analysis:
The epoch counter is declared as uint16_t epoch in crypto.h (line 120), giving it a maximum value of 65535. Each time a ChangeCipherSpec message is sent, the epoch is incremented. The record-sending path in dtls_prepare_record (dtls.c, line 1690) writes security->epoch directly into the outgoing record header via dtls_set_record_header without checking whether the counter is approaching or has reached its maximum value. No code path in the codebase triggers a new-association teardown or otherwise prevents a theoretical wrap from 65535 back to 0. While 65536 consecutive cipher state changes are highly improbable in practice, the absence of any overflow guard means the behavior is not consistent with the unconditional MUST NOT in the RFC.

Source Code Evidence (dtls.c):

// dtls.c:1685-1691
  if (!peer || !security) {
    dtls_alert("peer or security parameter missing\n");
    return dtls_alert_fatal_create(DTLS_ALERT_INTERNAL_ERROR);
  }

  p = dtls_set_record_header(type, security->epoch, &(security->rseq), sendbuf);

---

2. Old-Epoch Records Dropped During Active Handshake

RFC Reference: RFC 6347 Section 4.1

"Until the handshake has completed, implementations MUST accept packets from the old epoch."

Analysis:
During an in-progress handshake the helper dtls_security_params_read_epoch in peer.h (lines 87–97) returns a security context only when the incoming record's epoch exactly matches hs_state.read_epoch. Records carrying the previous epoch value find no matching context and cause the function to return NULL. Back in the main record-processing loop in dtls.c (lines 4660–4667), a NULL return immediately sets data_length = -1, which subsequently causes the record to be discarded rather than accepted or buffered. The RFC explicitly requires that old-epoch records be accepted until the handshake completes, so the current strict epoch-match logic does not appear to satisfy that requirement.

Source Code Evidence (peer.h and dtls.c):

// peer.h:87-97
static inline dtls_security_parameters_t *
dtls_security_params_read_epoch(dtls_peer_t *peer, uint16_t epoch)
{
  if (peer->handshake_params) {
    if (peer->handshake_params->hs_state.read_epoch == epoch) {
      return dtls_security_params_epoch(peer, epoch);
    }
  } else if (peer->security_params[0] &&
             peer->security_params[0]->epoch == epoch) {
    return peer->security_params[0];
  }
  return NULL;
}

// dtls.c:4660-4667
    dtls_security_parameters_t *security =
        dtls_security_params_read_epoch(peer, epoch);
    if (!security) {
      if (content_type_name) {
        dtls_warn("No security context for epoch: %i (%s)\n", epoch, content_type_name);
      } else {
        dtls_warn("No security context for epoch: %i (%u)\n", epoch, content_type);
      }
      data_length = -1;

---

3. Reactive Retransmission of Last Flight Not Implemented

RFC Reference: RFC 6347 Section 4.2.4

"when in the FINISHED state, the node that transmits the last flight (the server in an ordinary handshake or the client in a resumed handshake) MUST respond to a retransmit of the peer's last flight with a retransmit of the last flight."

Analysis:
After a successful handshake, peer->handshake_params is set to NULL (dtls.c, line 4077–4078). When a subsequent handshake-layer message arrives for the now-CONNECTED peer, handle_handshake checks peer->handshake_params at line 4357 and, finding it NULL, logs a warning and returns 0 without taking any action. The retransmission function dtls_retransmit (dtls.c, line 4957) is driven exclusively by a timer and operates on entries in the send queue; there is no code path that triggers it reactively upon receiving a duplicate peer flight. Additionally, after handshake completion, dtls_stop_retransmission clears the send queue, leaving nothing to re-send even if reactive retransmission were attempted. The RFC requires that receiving a retransmitted peer flight unconditionally triggers a retransmit of the local last flight for at least twice the MSL.

Source Code Evidence (dtls.c):

// dtls.c:4357-4361
  if (!peer->handshake_params) {

    dtls_warn("ignore unexpected handshake message\n");
    return 0;
  }

---