Draft: draft-ietf-core-echo-request-tag

Commentary: 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 do n't want to pull another normative dependency into our cluster because we do n't normatively need anything from 1.3 .
Paragraph (version A):
A CoAP server receiving a request is in general not able to verify
when the request was sent by the CoAP client.  This remains true even
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-
core-coap-actuators).  Some attacks can be mitigated by establishing
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
overhead and latency.  Additionally, if there are proxies, fresh DTLS
session keys between server and proxy does not say anything about
when the client made the request.  In a general hop-by-hop setting,
freshness may need to be verified in each hop.
Paragraph (version B):
A CoAP server receiving a request is in general not able to verify
when the request was sent by the CoAP client.  This remains true even
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-
core-coap-attacks).  Some attacks can be mitigated by establishing
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
overhead and latency.  Additionally, if there are proxies, fresh DTLS
session keys between server and proxy does not say anything about
when the client made the request.  In a general hop-by-hop setting,
freshness may need to be verified in each hop.
Paragraph (version A):
Amplification mitigation is a trade-off between giving leverage
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
considered acceptable for unconstrained applications I-D.ietf-
quic-transport.
Paragraph (version B):
Amplification mitigation is a trade-off between giving leverage
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
considered acceptable for unconstrained applications in RFC9000
Section 8.
Paragraph (version A):
The block-wise transfer mechanism RFC7959 extends CoAP by defining
the transfer of a large resource representation (CoAP message body)
as a sequence of blocks (CoAP message payloads).  The mechanism uses
a pair of CoAP options, Block1 and Block2, pertaining to the request
and response payload, respectively.  The block-wise functionality
does not support the detection of interchanged blocks between
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
(I-D.mattsson-core-coap-actuators), which is a vulnerability of CoAP
when using RFC7959.
Paragraph (version B):
The block-wise transfer mechanism RFC7959 extends CoAP by defining
the transfer of a large resource representation (CoAP message body)
as a sequence of blocks (CoAP message payloads).  The mechanism uses
a pair of CoAP options, Block1 and Block2, pertaining to the request
and response payload, respectively.  The block-wise functionality
does not support the detection of interchanged blocks between
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
(I-D.mattsson-core-coap-attacks), which is a vulnerability of CoAP
when using RFC7959.
Paragraph (version A):
When a client fragments a request body into multiple message
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
Section 2.5 of I-D.mattsson-core-coap-actuators).  Therefore, the
integrity protection of each block does not extend to the operation's
request body.
Paragraph (version B):
When a client fragments a request body into multiple message
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
Section 2.5 of I-D.mattsson-core-coap-attacks).  Therefore, the
integrity protection of each block does not extend to the operation's
request body.
Paragraph (version A):
That approach would have been difficult to roll out reliably on DTLS
where many implementations do not expose sequence numbers, and would
still not prevent attacks like in I-D.mattsson-core-coap-actuators
Section 2.5.2.
Paragraph (version B):
That approach would have been difficult to roll out reliably on DTLS
where many implementations do not expose sequence numbers, and would
still not prevent attacks like in I-D.mattsson-core-coap-attacks
Section 2.5.2.
Paragraph (version A):
A fundamental requirement of secure REST operations is that the
client can bind a response to a particular request.  If this is not
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.
Section 2.3 of I-D.mattsson-core-coap-actuators).  For example, a
request for the alarm status "GET /status" may be associated to a
prior response "on", instead of the correct response "off".
Paragraph (version B):
A fundamental requirement of secure REST operations is that the
client can bind a response to a particular request.  If this is not
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.
Section 2.3 of I-D.mattsson-core-coap-attacks).  For example, a
request for the alarm status "GET /status" may be associated to a
prior response "on", instead of the correct response "off".