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

Commentary: Closes : While the first commit is close to the text I 'd pick here ( and ready to be vetted ) , some points are still open : [ x ] It 's talking about " protecting the Echo value " , where what I mean is " use an Echo value the client ca n't forge " ( which can be either long random ,  , AEAD'd and there 's probably other equivalent options ) . Got ta find a better wording there . [ x ] Allowing the " for some applications " part may need some explaining ( but I 'd rather talk about it in the document than have implementers take the step on their own anyway ) . [ ] This probably needs alignment in other parts , especially where we talk about whether it MUST be identifiable etc . , in the appendix examples , and possibly in other places . ( I 'd rather start that after a first round of review from you ) . [ edit : and yeah , I did n't run this through a final reading yet after forming the underlying ideas as I was writing , so there may be some unclosed parens or odd sentences left ; sorry for those , hope the sentiment is clear still ] . 
 Updated now to align further parts of the document , requesting preliminary review . An open discussion point is that by the careful wording around source - of - truth , for the short Echo values we 're not really claiming " freshness " ( kind of leaving the term " freshness " for where the server can provably - even - with - a - malicious - client know that it is newer - than ) . I think it 's generally fine to use the strong sense of freshness , but that means that we illustrate in echo - figure - event does not deserve the term " freshness " . Options are : Keep the figure ( with the short Echo values ) and alter its description . This would be easiest if we introduce a term like " weak freshness " ( better suggestions pretty please ! ) for " freshness but only as claimed by the client not as provable by the server " , then the changes to the example / figure would be easy ( and the wording in appendix A item 3 would be less clumsy ) . Add a MAC to the figure . This would be consistent with the " when you use unprotected Echo values you better damn well know what you 're doing " sentiment of the rest of the text , but leaves us with no illustrated example of a short Echo . Suggestions ? I 'm undecided between them , and would prefer not to toss a coin . 
 ( Ticking off the " protected Echo " box now because the security considerations line " Echo values without the protection of randomness or a MAC " reads reasonably well ; if there 's clarification needed left we can find that during review ) . 
 Ping and I could really need a bit of feedback there . 
 I 'm merging this now to allow taking the final editing steps , but still would like to have another pair of eyes here -- but worst case that can happen after a submission tomorrow at cut - off date , and if the need for changes does come up , we work that into the P2P responses and let the reviewers know that a follow - up will come when the cut - off is over . 
 This is primarily a heads - up for how I intend to address  's comments that start with ( and the topic comes up again both in his individual points and other reviewers ' ) . Plan is ( and text is WIP ) to have a Characterization of Echo Applications subsection after the applications 1 - 4 that 's started with can be characterized by several criteria that help determine the required properties of the Echo value . These criteria apply both to those listed in { { echo - app } } and any novel applications . They provide rationale for the statements in the former , and guidance for the latter . and contains sub - items on what is the synchronized property , time - vs - event ( which may eventually say that events are in a sense a monotonic - but - very - non - uniform time ) and something about how good the assurance is that I ca n't quite put my finger on yet . The PR should , if I get it right , consist of a subsection addition , followed by some simplifcations / backreferences in other parts of the text where the statements are currently spread . 
 Sounds good to me to have a separate subsection . We may want to rethink the order of subsections of section 2 . Examples in current section 2.4 Applications ... may fit better at the very end , once the structure of different freshness requirements are laid out . Perhaps consider to write the subsection somewhat self - contained without too much thinking of current order of things ( if it makes sense ) .
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):
A server that sends large responses to unauthenticated peers
SHOULD mitigate amplification attacks such as described in
Section 11.3 of RFC7252 (where an attacker would put a victim's
address in the source address of a CoAP request).  A new way to do
this is to ask a client to Echo its request to verify its source
address.  This needs to be done only once per peer and limits the
range of potential victims from the general Internet to endpoints
that have been previously in contact with the server.  For this
application, the Echo option can be used in messages that are not
integrity protected, for example during discovery.
Paragraph (version B):
A server that sends a large response to an unauthenticated peer
SHOULD mitigate amplification attacks such as described in
Section 11.3 of RFC7252 to address, for example, the case where an
attacker puts a victim's address in the source address of a CoAP
request.  One way to do this is that the server responds to the
alleged source address of the request with an Echo option in short
response message (e.g. 4.01 Unauthorized), thereby requesting the
client to verify its source address.  This needs to be done only
once per peer and limits the range of potential victims from the
general Internet to endpoints that have been previously in contact
with the server.  For this application, the Echo option can be
used in messages that are not integrity protected, for example
during discovery.
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 B):
Use cases for the Echo option can be characterized by several
criteria that help determine the required properties of the Echo
value.  These criteria apply both to those listed in echo-app and any
novel applications.  They provide rationale for the statements in the
former, and guidance for the latter.
Paragraph (version B):
The property a client demonstrates by sending an Echo value is that
the request was sent after a certain point in time, or after some
event happened on the server.
Paragraph (version B):
When events are counted, they form something that can be used as a
monotonic but very non-uniform time line.  With highly regular events
and low-resolution time, the distinction between time and event based
freshness can be blurred: "No longer than a month ago" is similar to
"since the last full moon".
Paragraph (version B):
In an extreme form of event based freshness, the server can place an
event whenever an Echo value is used.  This makes the Echo value
effectively single-use.
Paragraph (version B):
Event and time based freshness can be combined in a single Echo
value, e.g. by encrypting a timestamp with a key that changes with
every event to obtain "usable once but only for 5 minutes"-style
semantics.
Paragraph (version B):
The information extracted by the server from the request Echo value
has different sources of truth depending on the application.
Understanding this helps the server implementer decide the necessary
protection of the Echo value.
Paragraph (version B):
If all that the server extracts is information which the client is
the sole source of truth for, (which is another way of saying that
the server has to trust the client on whatever Echo is used for),
then the server can issue Echo values that do not need to be
protected on their own.  They still need to be covered by the
security protocol that covers the rest of the message, but the Echo
value can be just short enough to be unique between this server and
client.
Paragraph (version B):
For example, the client's OSCORE sender sequence number (as used in
RFC8613 Appendix B.1.2) is such information.
Paragraph (version B):
In most other cases, there are properties extracted of which the
server is the authority ("The request must not be older than five
minutes" is counted on the server's clock, not the client's) or which
even involve the network (as when performing amplification
mitigation).  In these cases, the Echo value itself needs to be
protected against forgery by the client, e.g. by using a sufficiently
large random value or a MAC as described in echo-state items 1 and 2.
Paragraph (version B):
For some applications, the server may be able to trust the client to
also serve as a source of truth (e.g. when using time based freshness
purely to mitigate request delay attacks); these need careful case-
by-case evaluation.
Paragraph (version B):
To issue Echo values without own protection, the server needs to
trust the client to never produce requests with attacker controlled
Echo values.  The provisions of echo-proc (saying that an Echo value
may only be sent as received from the same server) allow that.  The
requirement stated there for the client to treat the Echo value as
opaque holds for these application like for all others.
Paragraph (version B):
When the client is the sole source of truth, the server can still use
time or events to issue new Echo values.  Then, the request's Echo
value not so much proves the indicated freshness to the server, but
reflects the client's intention to indicate reception of responses
containing that value when sending the later ones.
Paragraph (version B):
Note that a single Echo value can be used for multiple purposes (e.g.
to get both the sequence number information and perform amplification
mitigation); then, the stricter requirements apply.
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".
Paragraph (version A):
The freshness assertion of the Echo option comes from the client
reproducing the same value of the Echo option in a request as in a
previous response.  If the Echo value is a large random number then
there is a high probability that the request is generated after
having seen the response.  If the Echo value of the response can be
guessed, e.g. if based on a small random number or a counter (see
echo-state), then it is possible to compose a request with the right
Echo value ahead of time.  However, this may not be an issue if the
communication is integrity protected against third parties and the
client is trusted not misusing this capability.  Echo values MUST be
set by the CoAP server such that the risk associated with unintended
reuse can be managed.
Paragraph (version B):
The freshness assertion of the Echo option comes from the client
reproducing the same value of the Echo option in a request as in a
previous response.  If the Echo value is a large random number then
there is a high probability that the request is generated after
having seen the response.  If the Echo value of the response can be
guessed, e.g. if based on a small random number or a counter (see
echo-state), then it is possible to compose a request with the right
Echo value ahead of time.  Using guessable Echo values is only
permissible in a narrow set of cases described in source-of-truth.
Echo values MUST be set by the CoAP server such that the risk
associated with unintended reuse can be managed.
Paragraph (version A):
Counter Echo values can only be used to show freshness relative to
numbered events, and are the legitimate case for Echo values shorter
than four bytes, which are not necessarily secret.  They MUST NOT be
used unless the request Echo values are integrity protected as per
echo-proc.
Paragraph (version B):
Echo values without the protection of randomness or a MAC are limited
to cases when the client is the trusted source of all derived
properties (as per source-of-truth).  Using them needs per-
application consideration of both the impact of a malicous client and
of implementation errors in clients.  These Echo values are the only
legitimate case for Echo values shorter than four bytes, which are
not necessarily secret.  They MUST NOT be used unless the request
Echo values are integrity protected as per echo-proc.