Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing
draft-ietf-core-echo-request-tag-14

[[ nits ]]

[ section 2.4 ]

* "causing overheads" -> "causing overhead"

5.1 This is optional, but please replace "blacklisted" with "deny-listed".

6. What is a "preemptive" echo value?

There are several SHOULDs (e.g., near the top of page 8, and again at the end of Section 2.3) that left me wondering why an implementer would do something other than what it says.  Since SHOULD offers a choice, some advice would be helpful here.  Otherwise, maybe those ought to be MUSTs.  I suggest giving them all a once-over to see if any such advice would be helpful to include.

Thank you for writing this mitigation for draft-mattsson-core-coap-actuators.

** Section 5.  Per “As each pseudorandom number most only be used once …”, how will that be possible when echo values as small are 1-byte are possible?

** Section 5.
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.  

-- Why is the use of integrity presented as only a possibility here?  Didn’t Section 2.3 require it when assuring the freshness requirement – “When used to serve freshness requirements including client aliveness and state synchronizing), the Echo option value MUST be integrity protected between the intended endpoints ...”

-- Would it be clearer here to say that this is mitigation against an on-path attacker, not against rogue/compromised clients?

** Appendix A helpfully tries to lay out recommendations.  A few comments:

-- all of the recommendations here have option values much larger than the permitted minimum of 1-byte.  In addition to the recommendations, could the circumstances of the lower bound also be discussed

-- it would be helpful to explicitly state which methods apply to the specific use cases (client aliveness, request freshness, state synchronization, network  address reachability).  For example, method 3 (persistent counter) notes that it can be used for state synchronization but not client aliveness

Much thanks to Juergen Schoenwaelder for the OpsDir review, and the authors for addressing the comments...

It's a good and easy read.

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated).

Eliot Lear (in copy) has also reviewed the document as IoT directorate reviewer at:
https://datatracker.ietf.org/doc/review-ietf-core-echo-request-tag-12-iotdir-telechat-lear-2021-02-05/ 
So, please address/reply to his comment.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2.2 --
"The Echo option value is a challenge from the server to the client..." Just wondering whether "echo" is the right choice for the option as it is too close to ICMP_ECHO_REQUEST, why not "challenge" ?

I would have expected some statements related to non-idempotent requests (generic statement) and then specific examples such as actuators.

-- Section 2.2.1 --
Are the authors confident enough to state a minimum length of 1 octet ? If the intent of the document is to prevent replay attack, then I wonder whether one octet is enough... Unsure whether Section 5 (security considerations) addresses this issue correctly.

I really like the changes made in the -13 overall; thank you for adding
in all the additional discussion.

I only have editorial/nit-level comments remaining.

Section 2.5.2

   The information extracted by the server from the request Echo value  
   has different sources of truth depending on the application. 

I think that the "sources of truth" phrase might be a source of
confusion for some readers.
I'd consider something more like:

% The request Echo value conveys freshness information to the server,
% and the freshness is applied to some data or information related
% to the request.

which then transitions decently into "Understanding who or what is the
authoritative source of that information helps the server implementer
decide ..."

   If all that the server extracts is information which the client is
   authorized to provide arbitrarily, (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

(nit) I'd suggest "whatever Echo is being used for" (add "being")

   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

[If my above suggestion is used, that removes the word "extracted", this
use of "extracted" should probably be reworded as well.]

Section 3.5.1

      When security services are provided by DTLS, this can only be
      confirmed if there was no CoAP retransmission of the request, the
      request was responded to, and the server performs replay
      protection.

(nit) I think the server would either "perform replay detection" or
"[provide/use] replay protection" -- performing protection is not a
common phrasing.

   way, the server can rely on a conforming client to set the Request-
   Tag option when required, and thereby have confidence the integrity
   of the assembled body.

(nit) "have confidence in"

Appendix A

   This method is suitable both for time and for event base freshness
   (e.g. by clearing the cache when an event occurs), and independent of
   the client authority.

(nit) "for time- and for event-based freshness" (and again a couple
paragraphs later)