The Response Delay and Mismatch Attack - amend on comment about http grants

[boaks]

The Response Delay and Mismatch Attack

In HTTPS, this type of binding is always assured by the ordered and reliable delivery, as well as mandating that the server sends responses in the same order that the requests were received.

Assuming N-START-1, and using the DTLS record sequence number filter with "only newest" (dropping application data, even if it passes a "record sequence number window", but has not the newest record sequence number), will provide in my experience a better request/response binding as well and so a better protection against delay-attack (in trade off, that some messages may require more retransmissions and no parallel request will be allowed).

[chrysn]

Turning off interleaving is certainly an option if the implications are acceptable.

The hard part is getting these properties agreed on: To my knowledge, the replay behavior of DTLS is not negotiated but configured per device; same goes for N_START.

In closed setups where a CoAP implementation can rely on configured properties of the peer this is easy; in all others that'd need two new negotiation (or property-advertisement) mechanisms.

[boaks]

You're right! Without negotiation possibilities it's not general usable. And even not in all cases. I mentioned it mainly for those, who may have the chance to do so.

With some limitation it's in my opinion also usable for only one-side. A server may accept block request only if newest, or a client may only accept responses if newest.

[emanjon]

The echo request document has a long discussion in the Security Considerations https://datatracker.ietf.org/doc/html/draft-ietf-core-echo-request-tag#section-5.1

[boaks]

Not sure, what section 5.1 should say about using "only newest"? Do you mean:

(In addition, for observations, any responses using that Token and a DTLS sequence number earlier than the cancellation Acknowledgement message need to be discarded. This is typically not supported in DTLS implementations.)

Well, Eclipse/Californium offers a NEWEST_RECORD in the EndpointContextattributes. For other implementations we will see, what gets offered over the time.

[emanjon]

Yes, that part and the part about TLS

   *  In CoAP over TLS, retransmissions are not handled by the CoAP
      layer and behaves like a replay window size of 1.  When a client
      is sending TLS-protected requests without Observe to a single
      server, the client can reuse a Token as soon as the previous
      response with that Token has been received.

are at least related to the issue even if they not discussing exactly the same thing.

[emanjon]

Good discussion. Should any clarification be done in draft-mattsson-core-coap-attacks?

[emanjon]

Seems like there are no concrete suggestions to add anything to draft-ietf-core-attacks-on-coap. I am therefore closing this issue. The new GitHub repository for draft-ietf-core-attacks-on-coap is

https://github.com/core-wg/attacks-on-coap

Let's continue any discussion there.