(Non-conformance) Stateless Cookie Exchange

[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 stateless cookie exchange :

The DTLS server SHOULD generate cookies in such a way that they can be verified without retaining any per-client state on the server.

Actual behavior

TinyDTLS stores the record sequence number of the initial ClientHello and discards any subsequent records that duplicate this sequence number. However, in a truly stateless exchange, no information from the initial ClientHello should be retained. In the attached handshake trace, the record containing the ClientKeyExchange message uses the same record sequence number as the initial ClientHello. As shown in the log below, this results in the record being discarded.

stateless-cookie-exchange.zip

Log

May 15 13:08:00 INFO received message (117 bytes), starting with 'handshake', epoch 0
May 15 13:08:00 INFO handshake message epoch 0
May 15 13:08:00 INFO got 'handshake' epoch 0 sequence 0 (42 bytes)
May 15 13:08:00 DEBG dtls_handle_message: FOUND PEER
May 15 13:08:00 DEBG bitfield is ffffffffffffffff sequence base 1 rseqn 0
May 15 13:08:00 DEBG Drop: duplicate packet arrived (bitfield)```

[boaks]

That's not the case. You interpret some behavior, which is not based on keeping the record seqn of the initial CH.

RFC6347 4.1.2.6 Anti-Replay

Records that contain sequence numbers lower than the "left" edge of the window are rejected.

With the CH seqn 1 that window is started and so the 1 is the left edge. The 0 is then lower as that left edge and so rejected.

[boaks]

A test to verify my sayings:

Use a higher record seqn for the initial CH. The 0 will still be rejected, while the "higher record seqn" will be processed.
Or use a higher record seqn for the CH with cookie, and all lower numbers will be reject, not only the one of the initial CH.