Original text:
secure CoAP operations.  This document specifies security enhancements to the Constrained Application Protocol (CoAP).  This document specifies two CoAP options, the Echo option and the Request-Tag option: The Echo option enables a CoAP server to verify the freshness of a request, synchronize state, or force a client to if the request was protected with a security protocol, such as DTLS. This makes CoAP requests vulnerable to certain delay attacks which are particularly perilous in the case of actuators (I-D.mattsson- <del> core-coap-actuators).  Some attacks can be mitigated by establishing </del>  fresh session keys, e.g. performing a DTLS handshake for each request, but in general this is not a solution suitable for constrained environments, for example, due to increased message to an attacker and causing overhead.  An amplification factor of 3 (i.e., don't send more than three times the number of bytes received until the peer's address is confirmed) is <del> considered acceptable for unconstrained applications I-D.ietf- quic-transport. </del>  When that limit is applied and no further context is available, a safe default is sending initial responses no larger than 136 different message bodies to the same resource having the same block number.  This remains true even when CoAP is used together with a security protocol such as DTLS or OSCORE, within the replay window <del> (I-D.mattsson-core-coap-actuators), which is a vulnerability of CoAP </del>  when using RFC7959. A straightforward mitigation of mixing up blocks from different payloads, even if the individual messages are integrity protected, it is still possible for an attacker to maliciously replace a later operation's blocks with an earlier operation's blocks (see <del> Section 2.5 of I-D.mattsson-core-coap-actuators).  Therefore, the </del>  integrity protection of each block does not extend to the operation's request body. That approach would have been difficult to roll out reliably on DTLS where many implementations do not expose sequence numbers, and would <del> still not prevent attacks like in I-D.mattsson-core-coap-actuators </del>  Section 2.5.2. 3.8. ensured, a client may erroneously associate the wrong response to a request.  The wrong response may be an old response for the same resource or a response for a completely different resource (see e.g. <del> Section 2.3 of I-D.mattsson-core-coap-actuators).  For example, a </del>  request for the alarm status "GET /status" may be associated to a prior response "on", instead of the correct response "off".

Reviewer comments:
We've mentioned outdated draft names at times. Details in individual commits, point-to-point updated in-PR too. The DTLS change is not so much an update but a not to the editor that they may update the reference at their discretion when the publication sequence is clear; I don't want to pull another normative dependency into our cluster because we don't normatively need anything from 1.3.

Revised text:
secure CoAP operations.  This document specifies security enhancements to the Constrained Application Protocol (CoAP). <ins> [ Note to RFC editor: If C321 gets published before C280, then the RFC6347 references can be upgraded to draft-ietf-tls-dtls13-43 without the need for further changes; the reference is to 6347 here because that was the stable DTLS reference when the document was last touched by the authors. ] </ins> This document specifies two CoAP options, the Echo option and the Request-Tag option: The Echo option enables a CoAP server to verify the freshness of a request, synchronize state, or force a client to if the request was protected with a security protocol, such as DTLS. This makes CoAP requests vulnerable to certain delay attacks which are particularly perilous in the case of actuators (I-D.mattsson-  <ins> core-coap-attacks).  Some attacks can be mitigated by establishing </ins> fresh session keys, e.g. performing a DTLS handshake for each request, but in general this is not a solution suitable for constrained environments, for example, due to increased message to an attacker and causing overhead.  An amplification factor of 3 (i.e., don't send more than three times the number of bytes received until the peer's address is confirmed) is  <ins> considered acceptable for unconstrained applications in RFC9000 Section 8. </ins> When that limit is applied and no further context is available, a safe default is sending initial responses no larger than 136 different message bodies to the same resource having the same block number.  This remains true even when CoAP is used together with a security protocol such as DTLS or OSCORE, within the replay window  <ins> (I-D.mattsson-core-coap-attacks), which is a vulnerability of CoAP </ins> when using RFC7959. A straightforward mitigation of mixing up blocks from different payloads, even if the individual messages are integrity protected, it is still possible for an attacker to maliciously replace a later operation's blocks with an earlier operation's blocks (see  <ins> Section 2.5 of I-D.mattsson-core-coap-attacks).  Therefore, the </ins> integrity protection of each block does not extend to the operation's request body. That approach would have been difficult to roll out reliably on DTLS where many implementations do not expose sequence numbers, and would  <ins> still not prevent attacks like in I-D.mattsson-core-coap-attacks </ins> Section 2.5.2. 3.8. ensured, a client may erroneously associate the wrong response to a request.  The wrong response may be an old response for the same resource or a response for a completely different resource (see e.g.  <ins> Section 2.3 of I-D.mattsson-core-coap-attacks).  For example, a </ins> request for the alarm status "GET /status" may be associated to a prior response "on", instead of the correct response "off".