jiebi/TextFlow huggingface dataset:
Original text:
Same as for TLS 1.3. <del> Same as for TLS 1.3. </del>  A DTLS 1.3-only client MUST set the legacy_cookie field to zero length.  If a DTLS 1.3 ClientHello is received with any other

Reviewer comments:
It is not the same as TLS 1.3, as previously stated, because DTLS 1.3 does not support the compatibility mode.
It seems a natural consequence of not having compatibility mode, but is probably worth running by the list just to cover all bases.

Revised text:
Same as for TLS 1.3.  <ins> Versions of TLS and DTLS before version 1.3 supported a "session resumption" feature which has been merged with pre-shared keys in version 1.3.  A client which has a cached session ID set by a pre- DTLS 1.3 server SHOULD set this field to that value.  Otherwise, it MUST be set as a zero-length vector (i.e., a zero-valued single byte length field). </ins> A DTLS 1.3-only client MUST set the legacy_cookie field to zero length.  If a DTLS 1.3 ClientHello is received with any other
Original text:
Each DTLS record contains a sequence number to provide replay protection.  Sequence number verification SHOULD be performed using the following sliding window procedure, borrowed from Section 3.4.3 <del> of RFC4303. The received record counter for an association MUST be initialized to zero when that association is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the association.  This check SHOULD happen after deprotecting the record; otherwise the record discard might itself serve as a timing channel for the record number.  Note that computing the full record number from the partial is still a potential timing channel for the record number, though a less </del>  powerful one than whether the record was deprotected. Duplicates are rejected through the use of a sliding receive window. receiver does not notify the sender of the window size.) The "right" edge of the window represents the highest validated <del> sequence number value received on the association.  Records that contain sequence numbers lower than the "left" edge of the window are </del>  rejected.  Records falling within the window are checked against a list of received records within the window.  An efficient means for performing this check, based on the use of a bit mask, is described

Reviewer comments:
It gets reset each time the epoch does. Don't talk about values as being scoped only per association.

Revised text:
Each DTLS record contains a sequence number to provide replay protection.  Sequence number verification SHOULD be performed using the following sliding window procedure, borrowed from Section 3.4.3  <ins> of RFC4303.  Because each epoch resets the sequence number space, a separate sliding window is needed for each epoch. The received record counter for an epoch MUST be initialized to zero when that epoch is first used.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received in that epoch during the lifetime of the association.  This check SHOULD happen after deprotecting the record; otherwise the record discard might itself serve as a timing channel for the record number. Note that computing the full record number from the partial is still a potential timing channel for the record number, though a less </ins> powerful one than whether the record was deprotected. Duplicates are rejected through the use of a sliding receive window. receiver does not notify the sender of the window size.) The "right" edge of the window represents the highest validated  <ins> sequence number value received in the epoch.  Records that contain sequence numbers lower than the "left" edge of the window are </ins> rejected.  Records falling within the window are checked against a list of received records within the window.  An efficient means for performing this check, based on the use of a bit mask, is described
Original text:
are not the next expected message. During the handshake, ACKs only cover the current outstanding flight <del> (this is possible because DTLS is generally a lockstep protocol). Thus, an ACK from the server would not cover both the ClientHello and the client's Certificate.  Implementations can accomplish this by </del>  clearing their ACK list upon receiving the start of the next flight. After the handshake, ACKs SHOULD be sent once for each received and

Reviewer comments:
Clarify that being scoped to the current flight goes hand in hand with the implicit ACK behavior for an entire flight.

Revised text:
are not the next expected message. During the handshake, ACKs only cover the current outstanding flight  <ins> (this is possible because DTLS is generally a lockstep protocol).  In particular, receiving a message from a handshake flight implicitly acknowledges all messages from the previous flight(s).  Accordingly, an ACK from the server would not cover both the ClientHello and the client's Certificate, because the ClientHello and client Certificate are in different flights.  Implementations can accomplish this by </ins> clearing their ACK list upon receiving the start of the next flight. After the handshake, ACKs SHOULD be sent once for each received and
Original text:
Note that DTLS does not defend against spoofed ICMP messages; implementations SHOULD ignore any such messages that indicate PMTUs <del> below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively </del>  If there is a transport protocol indication that the PMTU was exceeded (either via ICMP or via a refusal to send the datagram as in authentication that both limits the probability of forgery by the same amount and does not expose implementations to the risk of denial of service; see ccm-short.  Therefore, TLS_AES_128_CCM_8_SHA256 MUST <del> NOT used in DTLS without additional safeguards against forgery. </del>  Implementations MUST set usage limits for AEAD_AES_128_CCM_8 based on an understanding of any additional forgery protections that are used.

Reviewer comments:
[ section 4.4 ] "respectively" -> "respectively." Could a DTLS implementation packetize to a min-MTU for an IP version and avoid all pMTU issues? Such a strategy would probably be poor for IPv4 but might be acceptable for IPv6 communications. [ section 4.5.3 ] "MUST NOT used" -> "MUST NOT be used" [ section 5.8.4 ] "NOT have send" -> "NOT send", I think [ section 6 ] "which are needed to encrypt to decrypt"?
and avoid all pMTU issues? Such a strategy would probably be poor for IPv4 but might be acceptable for IPv6 communications. I'm reluctant to recommend this, given that we know one can run into situations where there is more overhead due to tunnels, etc.

Revised text:
Note that DTLS does not defend against spoofed ICMP messages; implementations SHOULD ignore any such messages that indicate PMTUs  <ins> below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively. </ins> If there is a transport protocol indication that the PMTU was exceeded (either via ICMP or via a refusal to send the datagram as in authentication that both limits the probability of forgery by the same amount and does not expose implementations to the risk of denial of service; see ccm-short.  Therefore, TLS_AES_128_CCM_8_SHA256 MUST  <ins> NOT be used in DTLS without additional safeguards against forgery. </ins> Implementations MUST set usage limits for AEAD_AES_128_CCM_8 based on an understanding of any additional forgery protections that are used.
Original text:
second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest).  5.2. In order to support message loss, reordering, and message

Reviewer comments:
NAME
The text is good for me.
LGTM, but we should confirm on the list.This definitely helps, thanks. It doesn't completely eliminate the possibility of QUIC-LB catastrophic failure, but it makes things way better.

Revised text:
second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). <ins> DTLS clients which do not want to receive a Connection ID SHOULD still offer the "connection_id" extension unless there is an application profile to the contrary.  This permits a server which wants to receive a CID to negotiate one. </ins> 5.2. In order to support message loss, reordering, and message
Original text:
utilizes DTLS for key establishment, and Secure Real-time Transport Protocol (SRTP) for protection of data RFC5763. <del> TLS cannot be used directly in datagram environments for the following five reasons: </del>  TLS relies on an implicit sequence number on records.  If a record is not received, then the recipient will use the wrong sequence The TLS handshake is a lock-step cryptographic protocol.  Messages must be transmitted and received in a defined order; any other order is an error.  The DTLS handshake includes message sequence <del> numbers to enable reassembly in the correct order in case datagrams are lost or reordered. </del>  During the handshake, messages are implicitly acknowledged by other handshake messages.  Some handshake messages, such as the

Reviewer comments:
== COMMENTS == -- Section 3 -- s/TLS cannot be used directly in datagram environments/TLS cannot be used directly over a datagram transport/ ? [Hannes] DTLS is also used over non-IP-based networks (e.g. LoRaWAN, NB IoT, Bluetooth Smart) and "datagram transport". What would be the right term to describe "environments" that include transport layer protocols like UDP as well as those non-IP-based networks? Bullet 2) s/to enable reassembly in the correct order/to enable reordering/ ? [Hannes] The complete sentence is: " The DTLS handshake includes message sequence numbers to enable reassembly in the correct order in case datagrams are lost or reordered. " I believe that saying sequence numbers enable reassembly in the correct order is correct. -- Section 3.1 -- Should there be a hint to a maximum retry count ? [Hannes] There will be a retry count in an implementation. Do we need to say that if we don't have a number to suggest? Not sure. -- Section 3.3 -- I understand the motivation (and no need to reply), but, sigh... implementing frag/reassembly above the transport layer... [Hannes] Seems to be common these days. Examples: CoAP, and QUIC
I don't think I found the PR to match up with the "pr-exists" label; could I get a pointer?
My bad. URL

Revised text:
utilizes DTLS for key establishment, and Secure Real-time Transport Protocol (SRTP) for protection of data RFC5763.  <ins> TLS cannot be used directly over datagram transports the following five reasons: </ins> TLS relies on an implicit sequence number on records.  If a record is not received, then the recipient will use the wrong sequence The TLS handshake is a lock-step cryptographic protocol.  Messages must be transmitted and received in a defined order; any other order is an error.  The DTLS handshake includes message sequence  <ins> numbers to enable fragmented message reassembly and in-order delivery in case datagrams are lost or reordered. </ins> During the handshake, messages are implicitly acknowledged by other handshake messages.  Some handshake messages, such as the
Original text:
because an attacker will have difficulty forging a datagram that will not be rejected by the transport layer.  4.5.3. Section 5.5 of TLS TLS13 defines limits on the number of records that

Reviewer comments:
Zaheduzzaman Sarker wrote -> need to add text
I don't actually understand the ask here. Why would it matter?
I believe he wants us to note that when an invalid record is received and silently discarded then it does not impact timers in any way. It would be surprising if it did but do we want to add a sentence about that?
Since we have a dedicated section for "handling invalid records" that does allow for things other than silent discard, it makes sense to mention the lack of effect on timers. "[...] however, an error MAY be logged for diagnostic purposes. In no case does an invalid record affect pending retransmission timers."?
I'm not sure I agree, but I added something.

Revised text:
because an attacker will have difficulty forging a datagram that will not be rejected by the transport layer. <ins> Note that because invalid records are rejected at a layer lower than the handshake state machine, they do not affect pending retransmission timers. </ins> 4.5.3. Section 5.5 of TLS TLS13 defines limits on the number of records that
Original text:
The following is an example of a handshake with lost packets and retransmissions.  Note that the client sends an empty ACK message <del> because it can only acknowledge Record 1 sent by the server once it </del>  has processed messages in Record 0 needed to establish epoch 2 keys, <del> which are needed to encrypt or decrypt messages found in Record 1. </del>  ack-msg provides the necessary background details for this interaction.  Note: for simplicity we are not re-setting record numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0,

Reviewer comments:
The middle two commits should be looked at individually. Optional-ACK can be used (as in Figure 12) to short-circuit the retransmit timer in addition to selective acknowledgment.
(Looks like I still don't understand the kramdown reference behavior.)

Revised text:
The following is an example of a handshake with lost packets and retransmissions.  Note that the client sends an empty ACK message  <ins> because it can only acknowledge Record 2 sent by the server once it </ins> has processed messages in Record 0 needed to establish epoch 2 keys,  <ins> which are needed to encrypt or decrypt messages found in Record 2. </ins> ack-msg provides the necessary background details for this interaction.  Note: for simplicity we are not re-setting record numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0,
Original text:
covered by the cookie exchange during the handshake.  DTLS implementations MUST NOT update the address they send to in response to packets from a different address unless they first perform some <del> reachability test; no such test is defined in this specification. Even with such a test, an active on-path adversary can also black- hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </del>  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

Reviewer comments:
The DTLS 1.2 Connection ID draft (soon-to-be-RFC9146) section on "peer address update" and the text in DTLS 1.3 seems quite different. URL The "unless they first perform some reachability test" seems preferable to the soft text in soon-to-be-RFC9146, but DTLS 1.3 seems to be missing the DTLS 1.2 requirement on "The received datagram is "newer"". Feels spontanously like DTLS 1.2 and 1.3 should have similar requirements/guidance on "peer address update". FYI, I started writing some analysis of Peer Address Update in a draft that I intend to submit to T2TRG URL
Would be good to warn implementations that clients must not update the permanent server address based on the “Peer Address Update” mechanism. Using IP addresses instead of DNS names is not uncommon in e.g., IoT, DNS over DTLS (RFC 8094), and 3GPP DTLS interfaces. An client updating the permanent server address based on an MITM attack could be unable to recover.Would be good with a sentence or two on the problems changing the IP address of a gateway multiplexing a lot of DTLS connections with Connection ID. All the client and servers would have to send at least one record before the old IP address can be deactivated. Might take some time in a IoT deployment.
I tend to think we should at most provide warnings about how it's dangerous. NAME would you be willing to provide a quick PR?
In the interest of being done I opted for basically punting it to a future spec.
URL

Revised text:
covered by the cookie exchange during the handshake.  DTLS implementations MUST NOT update the address they send to in response to packets from a different address unless they first perform some  <ins> reachability test; no such test is defined in this specification and a future specification would need to specify a complete procedure for how and when to update addresses.  Even with such a test, an active on-path adversary can also black-hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </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
Original text:
The DTLSCiphertext structure omits the superfluous version number field <del> DTLS adds an explicit epoch and sequence number in the record </del>  header.  This sequence number allows the recipient to correctly verify the DTLS MAC. 4.4.1. <del> DTLS records contain a sequence number to provide replay protection. Sequence number verification SHOULD be performed using the following sliding window procedure, borrowed from Section 3.4.3 of RFC4303. </del>  <del> The receiver packet counter for this session MUST be initialized to zero when the session is established.  For each received record, the </del>  receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received <del> during the life of this session.  This SHOULD be the first check </del>  applied to a packet after it has been matched to a session, to speed <del> rejection of duplicate records. </del>  Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following size.) The "right" edge of the window represents the highest validated <del> sequence number value received on this session.  Records that contain </del>  sequence numbers lower than the "left" edge of the window are rejected.  Packets falling within the window are checked against a list of received packets within the window.  An efficient means for

Reviewer comments:
I do understand that the text is consistent with the one in , but I think that it could benefit from some rework.

Revised text:
The DTLSCiphertext structure omits the superfluous version number field  <ins> DTLS adds an explicit epoch and sequence numbers in the record </ins> header.  This sequence number allows the recipient to correctly verify the DTLS MAC. 4.4.1.  <ins> Each DTLS record contains a sequence number to provide replay protection.  Sequence number verification SHOULD be performed using the following sliding window procedure, borrowed from Section 3.4.3 of RFC4303. </ins>  <ins> The received packet counter for a session MUST be initialized to zero when that session is established.  For each received record, the </ins> receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received  <ins> during the lifetime of the session.  This SHOULD be the first check </ins> applied to a packet after it has been matched to a session, to speed  <ins> up the rejection of duplicate records. </ins> Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following size.) The "right" edge of the window represents the highest validated  <ins> sequence number value received on the session.  Records that contain </ins> sequence numbers lower than the "left" edge of the window are rejected.  Packets falling within the window are checked against a list of received packets within the window.  An efficient means for
Original text:
If the HelloRetryRequest message is used, the initial ClientHello and the HelloRetryRequest are included in the calculation of the <del> Transcript-Hash.  The computation of the message hash for the </del>  HelloRetryRequest is done according to the description in Section 4.4.1 of I-D.ietf-tls-tls13.

Reviewer comments:
"Transcript-Hash" is the name of the function. I belive it would be more appropriate to use the "transcript hash" term here.

Revised text:
If the HelloRetryRequest message is used, the initial ClientHello and the HelloRetryRequest are included in the calculation of the  <ins> transcript hash.  The computation of the message hash for the </ins> HelloRetryRequest is done according to the description in Section 4.4.1 of I-D.ietf-tls-tls13.
Original text:
transport like TCP that performs return-routability checks as part of the connection establishment.  With these exceptions, the DTLS message formats, flows, and logic are <del> the same as those of TLS 1.3.  DTLS implementations SHOULD not use the TLS 1.3 "compatibility mode" described in I-D.ietf-tls-tls13, Section D.4 and DTLS servers SHOULD ignore the "session_id" value generated by the client rather than sending ChangeCipherSpec messages.  Implementations MUST still ignore ChangeCipherSpec messages received during the handshake and at all other times SHOULD treat them as if they had failed to deprotect. </del>  5.1.

Reviewer comments:
I split and reordered the paragragh to maintain the integrity of the "aside from these exceptions, this is TLS 1.3".

Revised text:
transport like TCP that performs return-routability checks as part of the connection establishment. <ins> DTLS implementations do not use the TLS 1.3 "compatibility mode" described in I-D.ietf-tls-tls13, Section D.4.  DTLS servers MUST NOT echo the "session_id" value from the client and endpoints MUST NOT send ChangeCipherSpec messages.  Note however that implementations MUST ignore ChangeCipherSpec messages received in unprotected records. </ins> With these exceptions, the DTLS message formats, flows, and logic are  <ins> the same as those of TLS 1.3. </ins> 5.1.
Original text:
[sender]_application_traffic_secret for message protection, Implementations MAY include the length field at their discretion.  4.1. Implementations can distinguish the two header formats by examining

Reviewer comments:
As I understand, the intent with the record header in AD business was so that DTLS 1.3 would inherit putting the entire header into the AD. However, TLS 1.3 defines the AD as: and DTLS 1.3 defines encryptedrecord as: If one takes the first half of the clause, it works out, but "record header" isn't defined formally. If one takes the second half, it suggests that is not in the AD and it's not clear how 's AD is defined at all. Probably worth clarifying this.

Revised text:
[sender]_application_traffic_secret for message protection, Implementations MAY include the length field at their discretion. <ins> The entire header value shown above is used as it appears on the wire as the additional data value for the AEAD function. </ins> 4.1. Implementations can distinguish the two header formats by examining