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

Commentary: With those , any open issues I 'm aware of except the single words from and the larger discussion or are resolved from my PoV. 
 s / freshness tokens / freshness indicators/ : Amended by a proposed term to solve the remaining point in -- feel free to change to something different , it 's just a shortcut suggestion . 
 " freshness indicators " : OK with  , 0.00 OK , endpoints with security associations OK 
 " Block - Wise " vs. " block - wise " vs. " blockwise " " Token " vs. " Token " I think it should be Token . " freshness tokens " I think we should rewrite " freshness tokens " to that the word " token " is only used for the CoAP Token . 
 The Token and block - wise have been addressed in your . Any candidates for " freshness tokens " replacement ? " freshness indicators " maybe ? 
 I tried to add security considerations for token reuse to the PR . Please review , this is not trivial . Token reuse for DTLS seem hard if not impossible to do securely . I do n't find Token reuse with DTLS possible to do securely ..... am I missing something ? Token reuse for TLS without Observer and without Groups communication seems quite easy . Do we need to say something about Group communication ? Do we need to say something about stateless tokens ? I think the current requirements on integrity protection and replay protection protection in the stateless draft should be enough . 
 I think  refers to 
 Taken care of in the version -07 
 While not designed for that , the Echo option can be abused as mechanism like HTTP 's Cookie ( especially when preemptive Echo values are passed around ) , and I 'm pretty sure we do n't want that . We should at least point that out somewhere , and say that servers MUST NOT abuse it ( however to phrase that -- " use Echo to correlate requests for other purposes than showing frechness and reachability " ? ) . For actual mitigation , we could recommend ( or even demand ? ) that clients only send preemptive Echo values on the same endpoint ( 5 - tuple ) on which they were received -- so that if their address changes , no Echo value will leak identity . 
 To still allow Echo in OSCORE groupcom ( new server asks for Echo , client repeats it in next multicast , others ignore it ) , we could limit that mitigation to unauthenticated use cases ( as the client has a known persistable identity with OSCORE anyway ) . 
 Yes , this should definitely be a privacy consideration . 
 I wrote some initial text for the privacy consideration regarding this . Please revieew , modify and add things . Should we have any considerations for group OSCORE ? of should we let draft - dijk - core - groupcomm - bis and group OSCORE discuss that .   is hopefully published before them . 
 I think  refers to this commit : 
 I 'm almost happy with it , the last word I 'm unhappy with is being addressed in an upcoming commit that closes it by drawing on a solution to the " the spec does not say anything regarding taking echo from ( no - security , DTLS , [ ... ] ) and using it in ( no - security , DTLS , [ ... ] ) " comment ,
Paragraph (version A):
tokens in CoAP payloads, but this only works for methods and response
codes defined to have a payload.  The Echo option provides a
convention to transfer freshness tokens that works for all methods
and response codes.
Paragraph (version B):
indicators in CoAP payloads, but this only works for methods and
response codes defined to have a payload.  The Echo option provides a
convention to transfer freshness indicators that works for all
methods and response codes.
Paragraph (version A):
A fresh request is one whose age has not yet exceeded the freshness
requirements set by the server.  The freshness requirements are
application specific and may vary based on resource, method, and
parameters outside of CoAP such as policies.  The Echo option is a
lightweight challenge-response mechanism for CoAP, motivated by a
need for a server to verify freshness of a request as described in
req-fresh.  The Echo option value is a challenge from the server to
the client included in a CoAP response and echoed back to the server
in one or more CoAP requests.  The Echo option provides a convention
to transfer freshness Tokens that works for all CoAP methods and
response codes.
Paragraph (version B):
A fresh request is one whose age has not yet exceeded the freshness
requirements set by the server.  The freshness requirements are
application specific and may vary based on resource, method, and
parameters outside of CoAP such as policies.  The Echo option is a
lightweight challenge-response mechanism for CoAP, motivated by a
need for a server to verify freshness of a request as described in
req-fresh.  The Echo option value is a challenge from the server to
the client included in a CoAP response and echoed back to the server
in one or more CoAP requests.  The Echo option provides a convention
to transfer freshness indicators that works for all CoAP methods and
response codes.