(Non-conformance) Wrapping of Record Sequence Number

[bathooman]

Description

• Type: Non-conformance Bug
• Priority: Minor

---

Non-conformance Bug

Version: development branch

Expected behavior
The DTLS 1.2 RFC specifies the following requirement regarding the wrapping of record sequence number :

As in TLS, implementations MUST either abandon an association or rehandshake prior to allowing the sequence number to wrap.

Actual behavior
When TinyDTLS receives a CH2 with the record sequence set to the highest possible value (i.e. FF FF FF FF FF FF), it repeats the record sequence number in the SH and then it increments the record sequence for SHD which results in wrapping the sequence number (i.e. SHD.sequence_number = 0).

I have attached the handshake trace for the mentioned non-conformance.

rseq_wrapping.zip

[boaks]

FMPOV for an IoT low-power use-cases that's not relevant. No such device will be able to send 2^48 messages ;-).

Assuming 1 message per hour, that will result in 32131846656 years.
Assuming 1 message per second, that will still result in 8925512 years.

The recommendation for fresh handshakes is not to wait that long. In the most cases a device restart will be required more or less frequent. And it depends a lot on the use-case and application.

E.g. for the CCM8 cipher suites, you may consider less records than for CCM.
For moving cellular devices it may be recommended to do that fresh handshake only when the radio signal is above a specific level.
And so on.

But 2^48 outside of video streaming isn't relevant.