Original text:
5. The availability of a secure pseudorandom number generator and truly <del> random seeds are essential for the security of the Echo option.  If no true random number generator is available, a truly random seed must be provided from an external source.  As each pseudoranom number must only be used once, an implementation need to get a new truly random seed after reboot, or continously store state in nonvolatile memory, see (RFC8613, Appendix B.1.1) for issues and solution approaches for writing to nonvolatile memory. </del>  A single active Echo value with 64 (pseudo-)random bits gives the same theoretical security level as a 64-bit MAC (as used in e.g. <del> AES_128_CCM_8).  The Echo option value MUST contain 32 (pseudo-)random bits that are not predictable for any other party than the server, and SHOULD contain 64 (pseudo-)random bits.  A server MAY use different security levels for different uses cases (client aliveness, request freshness, state synchronization, network address reachability, etc.). </del>  The security provided by the Echo and Request-Tag options depends on the security protocol used.  CoAP and HTTP proxies require (D)TLS to that all intermediaries are fully trusted and have not been compromised.  Servers SHOULD use a monotonic clock to generate timestamps and compute round-trip times.  Use of non-monotonic clocks is not secure as the server will accept expired Echo option values if the clock is

Reviewer comments:
Closes: URL The numeric part is trivial, the security implications (the use case for short Echo values has a different threat model than what's previously in seccons) is not.
As previously discussed in private mail: For the OSCORE state recovery use case, putting a new sequence number in the Echo option is good enough, and that can be short.

Revised text:
5. The availability of a secure pseudorandom number generator and truly  <ins> random seeds are essential for the security of the Echo option (except when using counting Echo values).  If no true random number generator is available, a truly random seed must be provided from an external source.  As each pseudoranom number must only be used once, an implementation need to get a new truly random seed after reboot, or continously store state in nonvolatile memory, see (RFC8613, Appendix B.1.1) for issues and solution approaches for writing to nonvolatile memory. </ins> A single active Echo value with 64 (pseudo-)random bits gives the same theoretical security level as a 64-bit MAC (as used in e.g.  <ins> AES_128_CCM_8).  Unless a counting Echo value is used, the Echo option value MUST contain 32 (pseudo-)random bits that are not predictable for any other party than the server, and SHOULD contain 64 (pseudo-)random bits.  A server MAY use different security levels for different uses cases (client aliveness, request freshness, state synchronization, network address reachability, etc.). </ins> The security provided by the Echo and Request-Tag options depends on the security protocol used.  CoAP and HTTP proxies require (D)TLS to that all intermediaries are fully trusted and have not been compromised. <ins> Counting 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 only be used when the request Echo values are integrity protected. </ins> Servers SHOULD use a monotonic clock to generate timestamps and compute round-trip times.  Use of non-monotonic clocks is not secure as the server will accept expired Echo option values if the clock is