jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-core-echo-request-tag

Commentary: I think it make sense to make a subsection 
 This is only mentioned in Abstract and intro . I think it need there needs to be some text in the body as well . The other Update has it 's own subsection . " 4.2 . Updated Token Processing Requirements for Clients " 
 I text on server requirements in 
 updated with one more commit : Shorten amplification - mitigateion - recommendation paragraph , align text The " RECOMMENDED " wording is removed from the description of the mechanism ( it was under - explained there , the new section does it right , and there 's no need to make readers wonder about updating at this point ) Reference updated simplified ( we 're already talking about server side in the paragraph ) Comment about moving text here removed , and replaced with a more precise reference I 've toyed with moved text , but it rips the use cases up to the point where we 'd have to re - do all the items as subsections for consistency . ... and merging ( comments still appreciated , but I need the branches consolidated for futher editing ) 
 ( ... and that comment should have gone to ... anyway ) 
 Some reformulations in . I think this is ready to close . 
 Has long been ready , and recently gotten a more explicit cross - reference too .
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).  The RECOMMENDED
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 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 CoAP server SHOULD mitigate potential amplification attacks by
responding to unauthenticated clients with 4.01 Unauthorized
including an Echo option, as described in echo-app item 3 of [[this
document]].
Draft: draft-ietf-core-echo-request-tag

Commentary: Closes : The text is a mixture of the suggestions of . 
 From Ines ' Genart review : and do you know of established references we could use there to avoid rolling our own definition ? 
 Hi , Googling a bit , I think we might need to define this ourselves . Found some papers and presentations taking about freshness , but they did not define it well . Found a very mathematical definition in some other paper that we do not want to use . I suggest something like this : Freshness is a measure of the time since time since the message was sent . What is considered a fresh message is application dependent . The Echo mechanism specified in this document allow a server to calculate an upper bound for when the message was encrypted . With this bound , the server can either verify that the message is fresh ( fresher than some application defined limit ) or determine that it can not be verified that the message is fresh . Cheers ,    we can slim that down and avoid talking of time too much ( because yes it 's time even in the event - based case , but a very odd discrete time , so might confuse people ): Would that work for you ?
Paragraph (version B):
A message's "freshness" is a measure of when a message was sent on a
time scale of the recipient.  A server that receives a request can
either verify that the request is fresh or determine that it cannot
be verified that the request is fresh.  What is considered a fresh
message is application dependent; examplary uses are "no more than
one hour ago" or "after this server's last reboot".
Draft: draft-ietf-core-echo-request-tag

Commentary: Closes : Not tagging any of you for reviewers because that 's a topic that primarily I was active on , but still not merging right away in case you want to chime in . 
 In the response to I promised better wording for the 152 bytes -- but let 's see whether anything gets back there first . As  pointed out , this is the derived number from the " three times " part , also accounting for the remainder of the UDP packet . Assuming an attacker wants to maximize the amplification possible by the factor 3 , they will send 14 octets Ethernet header 40 octets IP header 8 octets UDP header 4 octets CoAP header 8 octets of token allowsing the server to send Σ * 3 = 222 octets . Subtracting everything in the response including the UDP header , that gives 160 octets of UDP data . Given the token is variable length data of up to 8 octets the server implementer ca n't easily take into account , that leaves 152 octets . ( Granted , that last step does n't follow from the wording , and I 'm looing to sharpen that ) . Having some hard number there ( and I 'm happy to use better ways to come up with one ) is important because for generic server applications , the transports may not be known and the implementer would have to make assumptions ; we ca n't do much more , but at least ours get solid review . 
 In the course of this , we 'll also have to give a citation for the " x 3 " ( currently ) 
 Follow - up note to be factored into the resolution :
Paragraph (version A):
Amplification mitigation should be used when the response would
be more than three times the size of the request, considering
the complete frame on the wire as it is typically sent across
the Internet.  In practice, this allows UDP data of at least
152 Bytes without further checks.
Paragraph (version B):
Amplification mitigation is a trade-off between giving leverage
to an attacker and causing overheads.  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):
When that limit is applied and no further context is available,
a safe default is sending initial responses no larger than 136
Bytes in CoAP serialization.  (The number is assuming a 14 + 40
+ 8 Bytes Ethernet, IP and UDP header with 4 Bytes added for
the CoAP header.  Triple that minus the non-CoAP headers gives
the 136 Bytes).  Given the token also takes up space in the
request, responding with 132 Bytes after the token is safe as
well.
Draft: draft-ietf-core-echo-request-tag

Commentary: Closes : 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 .
Paragraph (version A):
The availability of a secure pseudorandom number generator and truly
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.
Paragraph (version A):
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.
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.).
Paragraph (version B):
The availability of a secure pseudorandom number generator and truly
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.
Paragraph (version B):
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.
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.).
Paragraph (version B):
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.
Draft: draft-ietf-core-echo-request-tag

Commentary: Proposed resolution to Francesca 's review comments on Section 6 .
Paragraph (version A):
Servers SHOULD NOT use wall clock time for timestamps, as wall clock
time have large deviations from a monotonic clock.  Furthermore, an
attacker may be able to affect the server's wall clock time in
various ways such as setting up a fake NTP server or broadcasting
false time signals to radio-controlled clocks.
Paragraph (version B):
An attacker may be able to affect the server's system time in various
ways such as setting up a fake NTP server or broadcasting false time
signals to radio-controlled clocks.
Paragraph (version A):
Tokens that cannot be reused need to be blacklisted.  This could be
solved by increasing the Token as soon as the currently used Token
cannot be reused, or by keeping a list of all blacklisted Tokens.
Paragraph (version B):
Tokens that cannot be reused need to be handled appropriately.  This
could be solved by increasing the Token as soon as the currently used
Token cannot be reused, or by keeping a list of all blacklisted
Tokens.
Paragraph (version A):
Implementations SHOULD NOT put any privacy sensitive information in
the Echo or Request-Tag option values.  Unencrypted timestamps MAY
reveal information about the server such as location or time since
reboot.  The use of wall clock time is not allowed (see sec-cons) and
there also privacy reasons, e.g. it may reveal that the server will
accept expired certificates.  Timestamps MAY be used if Echo is
encrypted between the client and the server, e.g. in the case of DTLS
without proxies or when using OSCORE with an Inner Echo option.
Paragraph (version B):
Implementations SHOULD NOT put any privacy sensitive information in
the Echo or Request-Tag option values.  Unencrypted timestamps MAY
reveal information about the server such as location or time since
reboot, or that the server will accept expired certificates.
Timestamps MAY be used if Echo is encrypted between the client and
the server, e.g. in the case of DTLS without proxies or when using
OSCORE with an Inner Echo option.
Draft: draft-ietf-core-echo-request-tag

Commentary: " the encoding of the sequence number has to be chosen . . . " Replace " has to " with " MUST " ? ( I merged now and proposed the commit in the master branch ) 
 I had to resolve a conflict before merging . Hope I did that right .
Paragraph (version A):
When CoAP is used with a security protocol not providing bindings
between requests and responses, the tokens have cryptographic
importance.  The client MUST make sure that tokens are not used in a
way so that responses risk being associated with the wrong request.
One easy way to accomplish this is to implement the Token (or part of
the Token) as a sequence number for each connection, starting at zero
and reset to zero after rekeying, this approach SHOULD be followed.
To avoid collisions the sequence number can be encoded with a fixed
length or with some length-value encoding.
Paragraph (version B):
When CoAP is used with a security protocol not providing bindings
between requests and responses, the tokens have cryptographic
importance.  The client MUST make sure that tokens are not used in a
way so that responses risk being associated with the wrong request.
One easy way to accomplish this is to implement the Token (or part of
the Token) as a sequence number starting at zero for each new or
rekeyed secure connection, this approach SHOULD be followed.
Paragraph (version B):
When the Token (or part of the Token) contains a sequence number, the
encoding of the sequence number has to be chosen in a way to avoid
any collisions.  This is especially true when the Token contains more
information than just the sequence number (e.g. serialized state).
Draft: draft-ietf-core-echo-request-tag

Commentary: Addresses  's comment :
Paragraph (version A):
A straightforward mitigation is to mandate clients to not reuse
tokens until the traffic keys have been replaced.  The easiest way to
accomplish this is to implement the token as a counter starting at
zero for each new or rekeyed secure connection.  This document
updates the Token processing in RFC7252 to always assure a
cryptographically secure binding of responses to requests for secure
REST operations like "coaps".
Paragraph (version B):
A straightforward mitigation is to mandate clients to not reuse
tokens until the traffic keys have been replaced.  One easy way to
accomplish this is to implement the token as a counter starting at
zero for each new or rekeyed secure connection.  This document
updates the Token processing in RFC7252 to always assure a
cryptographically secure binding of responses to requests for secure
REST operations like "coaps".
Paragraph (version A):
When CoAP is used with a security protocol not providing bindings
between requests and responses, the tokens have cryptographic
importance.  The client MUST make sure that tokens are not used in a
way so that responses risk being associated with the wrong request.
The easiest way to accomplish this is to implement the Token (or part
of the Token) as a sequence number starting at zero for each new or
rekeyed secure connection, this approach SHOULD be followed.  To
avoid collisions the sequence number can be encoded with a fixed
length or with some length-value encoding.
Paragraph (version B):
When CoAP is used with a security protocol not providing bindings
between requests and responses, the tokens have cryptographic
importance.  The client MUST make sure that tokens are not used in a
way so that responses risk being associated with the wrong request.
One easy way to accomplish this is to implement the Token (or part of
the Token) as a sequence number for each connection, starting at zero
and reset to zero after rekeying, this approach SHOULD be followed.
To avoid collisions the sequence number can be encoded with a fixed
length or with some length-value encoding.
Draft: draft-ietf-core-echo-request-tag

Commentary: Changes in response to  's comments Disposition : Will merge soon if nobody objects . 
 Updated to match the changes to master
Paragraph (version B):
The Request-Tag options MAY be present in request messages that carry
a Block2 option even if those messages are not part of a blockwise
request operation (this is to allow the operation described in
simpleproxy).  The Request-Tag option MUST NOT be present in response
messages, and MUST NOT be present if neither the Block1 nor the
Block2 option is present.
Draft: draft-ietf-core-echo-request-tag

Commentary: " AEAD keys " -"traffic keys " In ( D)TLS , the algorithms may be other types than AEAD . " thus mitigating error cases and attacks where the client may erroneously associate the wrong response to a request . " Some more text about this in the intro , the current text was very barebone .
Paragraph (version A):
The document also updates the processing requirements on the Token.
The updated processing ensures secure binding of responses to
requests.
Paragraph (version B):
The document also updates the processing requirements on the Token.
The updated processing ensures secure binding of responses to
requests, thus mitigating error cases and attacks where the client
may erroneously associate the wrong response to a request.
Paragraph (version A):
When CoAP is used with a security protocol not providing bindings
between requests and responses, the client MUST NOT reuse tokens
until the AEAD keys have been replaced.  The easiest way to
accomplish this is to implement the Token as a counter, this approach
SHOULD be followed.
Paragraph (version B):
When CoAP is used with a security protocol not providing bindings
between requests and responses, the client MUST NOT reuse tokens
until the traffic keys have been replaced.  The easiest way to
accomplish this is to implement the Token as a counter, this approach
SHOULD be followed.
Draft: draft-ietf-core-echo-request-tag

Commentary: Clarifications based on  's review . " t0 is the time when the Echo option value was generated . " " If the server can not verify that the Echo option value was generated by the server or the round - trip time is not below the threshold the request is not processed further , and an error message MAY be sent . The error message SHOULD include a new Echo option . "
Paragraph (version A):
Upon receiving a request with the Echo option, the server determines
if the request has freshness requirement.  If the request does not
have freshness requirements, the Echo option MAY be ignored.  If the
request has freshness requirements and the server cannot verify the
freshness of the request in some other way, the server MUST verify
that the Echo option value was generated by the server; otherwise the
request is not processed further.  The server MUST then calculate the
round-trip time RTT = (t1 - t0), where t1 is the request receive time
and t0 is the transmit time of the response that included the
specific Echo option value.  The server MUST only accept requests
with a round-trip time below a certain threshold T, i.e. RTT < T,
otherwise the request is not processed further, and an error message
MAY be sent.  The threshold T is application specific, its value
depends e.g. on the freshness requirements of the request.  An
example message flow is illustrated in echo-figure.
Paragraph (version B):
Upon receiving a request with the Echo option, the server determines
if the request has freshness requirement.  If the request does not
have freshness requirements, the Echo option MAY be ignored.  If the
request has freshness requirements and the server cannot verify the
freshness of the request in some other way, the server MUST verify
that the Echo option value was generated by the server; otherwise the
request is not processed further.  The server MUST then calculate the
round-trip time RTT = (t1 - t0), where t1 is the request receive time
and t0 is the time when the Echo option value was generated.  The
server MUST only accept requests with a round-trip time below a
certain threshold T, i.e. RTT < T.  If the server cannot verify that
the Echo option value was generated by the server or the round-trip
time is not below the threshold the request is not processed further,
and an error message MAY be sent.  The error message SHOULD include a
new Echo option.  The threshold T is application specific, its value
depends e.g. on the freshness requirements of the request.  An
example message flow is illustrated in echo-figure.
Draft: draft-ietf-core-echo-request-tag

Commentary: " The server MAY include the same Echo option value in several different responses and to different clients . " Clarification based on  's review .
Paragraph (version B):
If the server receives a request which has freshness requirements,
the request does not contain a fresh Echo option value, and the
server cannot verify the freshness of the request in some other way,
the server MUST NOT process the request further and SHOULD send a
include the same Echo option value in several different responses and
to different clients.
Draft: draft-ietf-core-echo-request-tag

Commentary: This was an IESG comment on OSCORE . Also fix a nit
Paragraph (version A):
The Echo Option is elective, safe-to-forward, not part of the cache-
key, and not repeatable, see echo-table.
Paragraph (version B):
The Echo Option is elective, safe-to-forward, not part of the cache-
key, and not repeatable, see echo-table, which extends Table 4 of
RFC7252).
Paragraph (version A):
Upon receiving a 4.01 Unauthorized response with the Echo option, the
client SHOULD resend the original request with the addition of an
Echo option with the received Echo option value.  The client MAY send
a different request compared to the original request.  Upon receiving
any other response with the Echo option, the client SHOULD echo the
Echo option value in a next request to the server.  The client MAY
include the same Echo option value in several different requests to
the server.
Paragraph (version B):
Upon receiving a 4.01 Unauthorized response with the Echo option, the
client SHOULD resend the original request with the addition of an
Echo option with the received Echo option value.  The client MAY send
a different request compared to the original request.  Upon receiving
any other response with the Echo option, the client SHOULD echo the
Echo option value in the next request to the server.  The client MAY
include the same Echo option value in several different requests to
the server.
Paragraph (version A):
The Request-Tag option is not critical, safe to forward, and part of
the cache key as illustrated in req-tag-table.
Paragraph (version B):
The Request-Tag option is not critical, safe to forward, and part of
the cache key, see req-tag-table, which extends Table 4 of RFC7252).
Draft: draft-amsuess-core-repeat-request-tag

Commentary: This opens up questions in Closes : 
 Like OSCOAP asked that new options declare themselves E or U , the HTTP mapping document asked for clarification what a cross proxy should do . Looks like both  and Request - Tag are never expressed in HTTP , and that a cross proxy needs to repeat the request or run an operation with a Request - Tag just as a CoAP client ; a CH proxy ( CoAP server ) needs to use its own discretion on when to ask for a Repeat .
Paragraph (version B):
CoAP-CoAP proxies MUST relay the Echo option unmodified, and SHOULD
NOT cache responses when a Echo option is present in request or
response for more than the exchange.  CoAP-HTTP proxies MAY request
freshness, especially if they have reason to assume that access may
require it (eg. because it is a PUT or POST); how this is determined
is out of scope for this document.  HTTP-CoAP-Proxies SHOULD respond
to Echo challenges themselves, as they know that the HTTP request is
fresh, and can not forward the option anyway.