2.3. The Response Delay and Mismatch Attack / DTLS

[boaks]

The following attack can be performed if CoAP is protected by a security protocol where the response is not bound to the request in any way except by the CoAP token. This would include most general security protocols, such as DTLS, TLS, and IPsec, but not OSCORE.

The attacker performs the attack by delaying delivery of a response until the client sends a request with the same token

Using DTLS, it seems to be hard to determine, that the client uses the same token. Are there any additional assumptions about determining the token, if DTLS is used?

[boaks]

Let me add: RFC7252 is not that explicit about that, but, If the response is a "piggybacked response", the client may additionally check the MID and drop it on mismatch. That doesn't make the attack impossible, but lowers the probability.

[emanjon]

Good comments

• Added the assumption that the attacker needs to predict when the Token is reused. This might be very easy or very hard. In some libraries this might be quite hard. In some others it is definitly very easy. The described attack is intended to mostly be a theoretical attack on the CoAP specification. When doing research I mostly looked for weak implementations.
• Added the text suggested by Achim on "piggybacked response".
• Added text on why this type of attack is not possible in HTTPS.

[boaks]

Addressed. (I have an additional comment for the http and nstart-1, but I will open an new issue).