jiebi/TextFlow huggingface dataset:
Original text:
The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security <del> guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol. </del>  1. not a threat in their environment.  Clients MUST be prepared to do a cookie exchange with every handshake.  Unlike TLS implementations, DTLS implementations SHOULD NOT respond to invalid records by terminating the connection.

Reviewer comments:
Suggested pull request related to issue
The Abstract states that: "The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees." This is not true when it comes to Order protection/non-replayability which is states as a guarantee in Appendix E.2 of RFC 8446. DTLS does not provide order protection and may not provide replay protection. I suggested this statement "equivalent security guarantees" is deleted (or rewritten) in the abstract and that some short text describing this is added to the Security Considerations.
Fixed.

Revised text:
The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security  <ins> guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. </ins> 1. not a threat in their environment.  Clients MUST be prepared to do a cookie exchange with every handshake. <ins> With the exception of order protection and non-replayability, the security guarantees for DTLS 1.3 are the same as TLS 1.3.  While TLS always provides order protection and non-replayability, DTLS does not provide order protection and may not provide replay protection. </ins> Unlike TLS implementations, DTLS implementations SHOULD NOT respond to invalid records by terminating the connection.
Original text:
Implementations MAY include the length field at their discretion. The entire header value shown above is used as it appears on the wire <del> as the additional data value for the AEAD function. </del>  4.1.

Reviewer comments:
I added this remark following my implementation experience of DTLS 1.2 CID followed by the work on the DTLS 1.3. We noticed this issue at the Prague IETF meeting (March 2019).

Revised text:
Implementations MAY include the length field at their discretion. The entire header value shown above is used as it appears on the wire  <ins> as the additional data value for the AEAD function.  Note that this design is different to the additional data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. </ins> 4.1.
Original text:
TCP RFC0793 to allow for packet reordering.  (Note that the intention here is that implementers use the current guidance from the IETF for MSL, as specified in RFC0793 or successors not that they attempt to <del> interrogate the MSL that the system TCP stack is using.)  Until the handshake has completed, implementations MUST accept packets from the old epoch. </del>  Conversely, it is possible for records that are protected with the new epoch to be received prior to the completion of a handshake.  For

Reviewer comments:
Deleted the following statement: "Until the handshake has completed, implementations MUST accept packets from the old epoch." because it appears to be redundant. Martin raised this issue in URL
I think that this is a vestige of renegotiation and can be removed. But we might want to say something more helpful about accepting 0-RTT and Handshake at the same time.
I think we should delete this sentence because it is redundant. We have already text in the same section saying the following: " Because DTLS records could be reordered, a record from epoch 1 may be received after epoch 2 has begun. In general, implementations SHOULD discard packets from earlier epochs, but if packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP to allow for packet reordering. " NAME If you think there is someone else that should be said, we are happy to add it. Here is the PR: URL
Fixed.

Revised text:
TCP RFC0793 to allow for packet reordering.  (Note that the intention here is that implementers use the current guidance from the IETF for MSL, as specified in RFC0793 or successors not that they attempt to  <ins> interrogate the MSL that the system TCP stack is using.) </ins> Conversely, it is possible for records that are protected with the new epoch to be received prior to the completion of a handshake.  For
Original text:
5.9.  Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake.  However, a DTLS implementation which would ordinarily issue an alert SHOULD generate a new alert a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected. <del> 5.10. </del>  If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is

Reviewer comments:
omit the trailing space because TLS 1.3 went right up to the limit.
No, no, DTLS also uses HKDR for Key Separation++
Hearing no objections, we're merging this change. I'll fix the HKDR->HKDF typo in a followup PR.
This is perfectly fine. Thanks for making the edit.

Revised text:
5.9. <ins> Section 7.1 of RFC8446 specifies that HKDR-Expand-Label uses a label prefix of "tls13 ".  For DTLS 1.3, that label SHALL be "dtls13". This ensures key separation between DTLS 1.3 and TLS 1.3.  Note that there is no trailing space; this is necessary in order to keep the overall label size inside of one hash iteration because "DTLS" is one letter longer than "TLS". 5.10. </ins> Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake.  However, a DTLS implementation which would ordinarily issue an alert SHOULD generate a new alert a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected.  <ins> 5.11. </ins> If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is
Original text:
Forward Secrecy for EAP-AKA' is achieved by using an Elliptic Curve Diffie-Hellman (ECDH) exchange RFC7748.  To provide FS, the exchange must be run in an ephemeral manner, i.e., both sides generate <del> temporary keys as specified in e.g., RFC7748.  This method is referred to as ECDHE, where the last 'E' stands for Ephemeral.  The two initially registered elliptic curves and their wire format is chosen to align with the elliptic curves and formats specified for </del>  Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 of 3GPP TS 33.501 TS.33.501.

Reviewer comments:
Karl: Why is this "e.g." inserted in section 5? "generate temporary keys as specified in e.g., [RFC7748]" It sounds non-deterministic. If using RFC7748 is an option that can be negotiated or need to be pre-established, then maybe we could write something like: "according to the negotiated ciphersuite, e.g. [7748]." If the sentence is more describing a general way of how one would go about designing FS here, then perhaps something like: "To provide FS, a key exchange must run in an ephemeral manner...".
I think you are right. The text is a bit sloppy (but I don’t think it has changed in a while). I like your first formulation. Once you know the ciphersuite this is all specified & determined.
Will make a PR
Solution merged to the base.

Revised text:
Forward Secrecy for EAP-AKA' is achieved by using an Elliptic Curve Diffie-Hellman (ECDH) exchange RFC7748.  To provide FS, the exchange must be run in an ephemeral manner, i.e., both sides generate  <ins> temporary keys according to the negotiated ciphersuite, e.g., for X25519 this is done as specified in RFC7748.  This method is referred to as ECDHE, where the last 'E' stands for Ephemeral.  The two initially registered elliptic curves and their wire format is chosen to align with the elliptic curves and formats specified for </ins> Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 of 3GPP TS 33.501 TS.33.501.
Original text:
essential zero-trust principles. This specification updates RFC 9048, the EAP-AKA' authentication <del> method, with an optional extension.  The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP-AKA'.  This prevents an attacker who has gained access to the long-term pre-shared secret in a SIM card from being able to decrypt any past communications.  In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions.  This forces attackers to use active attacks instead. </del>  1.

Reviewer comments:
Can you NAME review (and Karl)?
... since 9048 did not obsolete 5448
That is is good question. I changed "updates" from RFC 5448 to RFC 9048 as the document do not even mention RFC 5448 except in the Acknowledgments. Updating increases visability and makes it easier to find the EAP-AKA'-FS document. If it updates 5448 some more mentioning of 5448 would be needed in the introduction
Closing, fix merged to the document.

Revised text:
essential zero-trust principles. This specification updates RFC 9048, the EAP-AKA' authentication  <ins> method, with an optional extension.  Similarly, this specification also updates the earlier version of the EAP-AKA' specification in RFC 5448.  The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP- AKA'.  This prevents an attacker who has gained access to the long- term pre-shared secret in a SIM card from being able to decrypt any past communications.  In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions.  This forces attackers to use active attacks instead. </ins> 1.
Original text:
echo-state to minimize the memory impact of having many unanswered Echo responses.  2.3. Actuation requests often require freshness guarantees to avoid

Reviewer comments:
This opens up questions in URL Closes: URL
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 Repeat 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.

Revised text:
echo-state to minimize the memory impact of having many unanswered Echo responses. <ins> 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. </ins> 2.3. Actuation requests often require freshness guarantees to avoid
Original text:
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 <del> 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 </del>  depends e.g. on the freshness requirements of the request.  An example message flow is illustrated in echo-figure.

Reviewer comments:
Clarifications based on Jim's review. "t0 is the time when the Echo option value was generated." "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."

Revised text:
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  <ins> 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 </ins> depends e.g. on the freshness requirements of the request.  An example message flow is illustrated in echo-figure.
Original text:
The document also updates the processing requirements on the Token. The updated processing ensures secure binding of responses to <del> requests. </del>  1.1. When CoAP is used with a security protocol not providing bindings between requests and responses, the client MUST NOT reuse tokens <del> until the AEAD keys have been replaced.  The easiest way to </del>  accomplish this is to implement the Token as a counter, this approach SHOULD be followed.

Reviewer comments:
"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.

Revised text:
The document also updates the processing requirements on the Token. The updated processing ensures secure binding of responses to  <ins> requests, thus mitigating error cases and attacks where the client may erroneously associate the wrong response to a request. </ins> 1.1. When CoAP is used with a security protocol not providing bindings between requests and responses, the client MUST NOT reuse tokens  <ins> until the traffic keys have been replaced.  The easiest way to </ins> accomplish this is to implement the Token as a counter, this approach SHOULD be followed.
Original text:
sending messages without Request-Tag options whenever possible, and using short values when the absent option can not be recycled.  3.4. 3.4.1.

Reviewer comments:
Changes in response to Carsten's comments Disposition: Will merge soon if nobody objects.
Updated to match the changes to master

Revised text:
sending messages without Request-Tag options whenever possible, and using short values when the absent option can not be recycled. <ins> 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. </ins> 3.4. 3.4.1.
Original text:
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 <del> 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. </del>  6. exhaustion attacks.  One way to minimize state is to use the Integrity Protected Timestamp method described in echo-state.  7. Implementations SHOULD NOT put any privacy sensitive information in

Reviewer comments:
"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.

Revised text:
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  <ins> the Token) as a sequence number starting at zero for each new or rekeyed secure connection, this approach SHOULD be followed. </ins> 6. exhaustion attacks.  One way to minimize state is to use the Integrity Protected Timestamp method described in echo-state. <ins> 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). </ins> 7. Implementations SHOULD NOT put any privacy sensitive information in
Original text:
the original request was never retransmitted, <del> the response was piggybacked in an Acknowledgement message (a confirmable response may have been transmitted multiple times), and </del>  if observation was used, the same holds for the registration, all re-registrations, and the cancellation.

Reviewer comments:
This is my take on , pointing to the cases when it's possible to reuse tokens, at the same time discouraging it for all other cases. The acceptable cases are the ones identified in the last authors' call, and TLS and OSCORE I've added in a potential third case in source comments; it's still something we can dig up if people ask for more comprehensive exceptions, but there's so many things that can go wrong that I'd rather not have it in.
Thanks, merged. I did put in a clarification on the f81c97221a1f0e7571ad06811a8b713659741336 edit -- acutally both CON and NON would be unusable.
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 don'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 John refers to e49ff36
Taken care of in the version -07

Revised text:
the original request was never retransmitted,  <ins> the response was piggybacked in an Acknowledgement message (as a confirmable or non-confirmable response may have been transmitted multiple times), and </ins> if observation was used, the same holds for the registration, all re-registrations, and the cancellation.
Original text:
requests immediately to have a cached result available when the client's Echoed request arrives. <del> 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. </del>  When an Echo response is sent to mitigate amplification, it MUST be sent as a piggybacked or Non-confirmable response,

Reviewer comments:
Closes: URL 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 URL I promised better wording for the 152 bytes -- but let's see whether anything gets back there first. As Carsten 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 can't easily take into account, that leaves 152 octets. (Granted, that last step doesn'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 can'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 URL)
Follow-up note to be factored into the resolution:

Revised text:
requests immediately to have a cached result available when the client's Echoed request arrives.  <ins> 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. 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. </ins> When an Echo response is sent to mitigate amplification, it MUST be sent as a piggybacked or Non-confirmable response,
Original text:
client" is used in this document to denote the client from which a request originates; to distinguish from clients in proxies.  The terms "payload" and "body" of a message are used as in RFC7959. The complete interchange of a request and a response body is called a (REST) "operation".  An operation fragmented using RFC7959 is called

Reviewer comments:
Closes: URL The text is a mixture of the suggestions of .
From Ines' Genart review: NAME and NAME 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 cannot be verified that the message is fresh. Cheers, John
Maybe 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?

Revised text:
client" is used in this document to denote the client from which a request originates; to distinguish from clients in proxies. <ins> 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". </ins> The terms "payload" and "body" of a message are used as in RFC7959. The complete interchange of a request and a response body is called a (REST) "operation".  An operation fragmented using RFC7959 is called