jiebi/TextFlow huggingface dataset:
Original text:
rebinding leads to connection failure, with the resulting cost of a new handshake. <del> This document defines an extension to DTLS to add a connection ID to the DTLS record layer.  The presence of the connection ID is </del>  negotiated via a DTLS extension. 2. The extension type is specified as follows. The extension_data field of this extension, when included in the <del> ClientHello, MUST contain the CID structure, which carries the CID which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client is prepared to send with a connection ID but does not wish the server to use one when sending (alternately, this can be interpreted as the </del>  client wishes the server to use a zero-length CID; the result is the same). With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further <del> privacy concerns.  In order to prevent this, implementations SHOULD attempt to use fresh connection IDs whenever they change local addresses or ports (though this is not always possible to detect). </del>  Importantly, the sequence number makes it possible for a passive attacker to correlate packets across CID changes.  Thus, even if a

Reviewer comments:
This is pretty trivial, but the first use of CID in the draft isn't mated to the expanded "connection ID". Probably more seriously, that first mention is actually to cite a struct: The structure is called .

Revised text:
rebinding leads to connection failure, with the resulting cost of a new handshake.  <ins> This document defines an extension to DTLS to add a connection ID (CID) to the DTLS record layer.  The presence of the connection ID is </ins> negotiated via a DTLS extension. 2. The extension type is specified as follows. The extension_data field of this extension, when included in the  <ins> ClientHello, MUST contain the ConnectionId structure, which carries the CID which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client is prepared to send with a connection ID but does not wish the server to use one when sending (alternately, this can be interpreted as the </ins> client wishes the server to use a zero-length CID; the result is the same). With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further  <ins> privacy concerns. </ins> Importantly, the sequence number makes it possible for a passive attacker to correlate packets across CID changes.  Thus, even if a
Original text:
"ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD) defined in this document. <del> IANA is requested to allocate the following new values in the "TLS ContentType Registry": alert_with_cid(25) handshake_with_cid(26) application_data_with_cid(27) heartbeat_with_cid(28) </del> 

Reviewer comments:
URL Still contains the content types removed in PR . alertwithcid(25) handshakewithcid(26) applicationdatawithcid(27) heartbeatwithcid(28) I guess, it should be updated towards PR ? tls12cid(25)
The PR can be found here: URL
The PR will fix it.

Revised text:
"ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD) defined in this document.  <ins> IANA is requested to allocate tls12_cid(25) in the "TLS ContentType Registry". </ins>
Original text:
All other fields are as defined in the cited documents. The length (in bytes) of the serialised DTLSInnerPlaintext.  The <del> length MUST NOT exceed 2^14. </del>  6.

Reviewer comments:
To address URL
Thanks! This PR fixes the missing size of the introduced length.
I miss the hint for the size of . I would assume it's a 2 bytes value. Is that right? Is this information already in the document and have overseen it? Both introduce a special "length" and use different approaches to do so. One with extra definition, one with a included definition. Is this intended?
Fixed with

Revised text:
All other fields are as defined in the cited documents. The length (in bytes) of the serialised DTLSInnerPlaintext.  The  <ins> length MUST NOT exceed 2^14.  This field is of type uint16. </ins> 6.
Original text:
<del> Value of the negotiated CID. </del>  <del> 1 byte field indicating the length of the negotiated CID. </del>  All other fields are as defined in the cited documents.

Reviewer comments:
Addresses URL
Thanks! This PR clarifies the used cid value.
In my opinion, it's the actual cid on the record header, not the negotiated cid, even if both are intended to be the same. Therefore it is . Or has this changed? Is the MAC now extended by the negotiated CID?
Fixed with

Revised text:
 <ins> The DTLSCiphertext.cid value. </ins>  <ins> 1 byte field indicating the length of the DTLSCiphertext.cid. </ins> All other fields are as defined in the cited documents.
Original text:
To allow a receiver to determine whether a record has a CID or not, connections which have negotiated this extension use a distinguished <del> record type tls12_cid(25).  Use of this content type has the </del>  following three implications: The CID field is present and contains one or more bytes. produce the final DTLSCiphertext. The outer content type of a DTLSCiphertext record carrying a CID <del> is always set to the value 25 (tls12_cid).  The actual content type of the record is found in DTLSInnerPlaintext.real_type after decryption. </del>  The CID value, cid_length bytes long, as agreed at the time the extension has been negotiated. IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for <del> connection_id(TBD) defined in this document. </del>  <del> IANA is requested to allocate tls12_cid(25) in the "TLS ContentType </del>  Registry".

Reviewer comments:
URL If this PR is postponed to that date (12. April), may be the final values could be used. We have received a request for early code-point assignment of values for draft-ietf-tls-dtls-connection-id-04. We believe that only editorial changes are pending. Please respond to this list of you have concerns about these assignments by April 12, 2019. Thanks, Joe, Sean and Chris

Revised text:
To allow a receiver to determine whether a record has a CID or not, connections which have negotiated this extension use a distinguished  <ins> record type tls12_cid(TBD2).  Use of this content type has the </ins> following three implications: The CID field is present and contains one or more bytes. produce the final DTLSCiphertext. The outer content type of a DTLSCiphertext record carrying a CID  <ins> is always set to tls12_cid(TBD2).  The real content type of the record is found in DTLSInnerPlaintext.real_type after decryption. </ins> The CID value, cid_length bytes long, as agreed at the time the extension has been negotiated. IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for  <ins> connection_id(TBD1) defined in this document. </ins>  <ins> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType </ins> Registry".
Original text:
Corresponds to the fragment of a given length. <del> The content type describing the payload. </del>  An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field.  This provides an opportunity for

Reviewer comments:
Russ Housley's secdir review: URL Reviewer: Russ Housley Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tls-dtls-connection-id-10 Reviewer: Russ Housley Review Date: 2021-03-15 IETF LC End Date: 2021-03-28 IESG Telechat date: Unknown Summary: Ready Major Concerns: None. Minor Concerns: None. Nits: Section 4: For increased clarity, I suggest: OLD: realtype The content type describing the payload. NEW: realtype The content type describing the cleartext payload.

Revised text:
Corresponds to the fragment of a given length.  <ins> The content type describing the cleartext payload. </ins> An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field.  This provides an opportunity for
Original text:
Case 2: The old path is alive but not preferred. This case is shown in fig-old-path-not-preferred whereby the sender <del> replies with a "path_delete" message (2) on the old path.  This </del>  triggers the receiver to send a "path_challenge" (3) on the new path. The sender will reply with a "path_response" (4) on the new path, thus providing confirmation for the path migration. If the path through which the message was received is not preferred, a "return_routability_check" message of type <del> "path_delete" MUST be returned.  In either case, the peer </del>  endpoint echoes the cookie value in the response. The initiator receives and verifies that the the previously valid address, i.e. no switch to the new path takes place and the peer address binding is not updated. <del> When a "return_routability_check" message of type "path_delete" </del>  was received, the initiator MUST perform a return routability check on the observed new address, as described in regular. 7.2. The responder MUST NOT delay sending an elicited "path_response" <del> or "path_delete" messages. </del>  <del> The responder MUST send exactly one "path_response" or "path_delete" message for each received "path_challenge". </del>  <del> The responder MUST send the "path_response" or the "path_delete" on the path where the corresponding "path_challenge" has been </del>  received, so that validation succeeds only if the path is functional in both directions.  The initiator MUST NOT enforce this behaviour.

Reviewer comments:
Signed-off-by: Thomas Fossati
A better name could be or -- one doesn't "delete" a path.
I agree. I prefer path_drop

Revised text:
Case 2: The old path is alive but not preferred. This case is shown in fig-old-path-not-preferred whereby the sender  <ins> replies with a "path_drop" message (2) on the old path.  This </ins> triggers the receiver to send a "path_challenge" (3) on the new path. The sender will reply with a "path_response" (4) on the new path, thus providing confirmation for the path migration. If the path through which the message was received is not preferred, a "return_routability_check" message of type  <ins> "path_drop" MUST be returned.  In either case, the peer </ins> endpoint echoes the cookie value in the response. The initiator receives and verifies that the the previously valid address, i.e. no switch to the new path takes place and the peer address binding is not updated.  <ins> When a "return_routability_check" message of type "path_drop" </ins> was received, the initiator MUST perform a return routability check on the observed new address, as described in regular. 7.2. The responder MUST NOT delay sending an elicited "path_response"  <ins> or "path_drop" messages. </ins>  <ins> The responder MUST send exactly one "path_response" or "path_drop" message for each received "path_challenge". </ins>  <ins> The responder MUST send the "path_response" or the "path_drop" on the path where the corresponding "path_challenge" has been </ins> received, so that validation succeeds only if the path is functional in both directions.  The initiator MUST NOT enforce this behaviour.
Original text:
6.  An off-path attacker that can observe packets might forward copies of genuine packets to endpoints over a different path.  If the copied packet arrives before the genuine packet, this will appear as a path After this point, any pending send operation is resumed to the bound peer address. <del> path-challenge-reqs and path-response-reqs contain the requirements for the initiator and responder roles, broken down per protocol phase. </del>  7.2. After the path validation procedure is completed, any pending send operation is resumed to the bound peer address. <del> path-challenge-reqs and path-response-reqs contain the requirements for the initiator and responder roles, broken down per protocol phase. </del>  7.3.

Reviewer comments:
Section 5 title "Off-path packet forwarding" should be "Attack model" instead? Also, is this the right position? ISTM this should go after we discuss the base challenge/response mechanics. There is also a missing premise, I think: "RRC is not designed to counter on-path attackers. These can never be distinguished from, for example, a genuine network device. However, RRC can resist off-path attackers when enhanced path validation ({{enhanced}}) is used."

Revised text:
6. <ins> RRC is not designed to counter on-path attackers.  These can never be distinguished from, for example, a genuine network device.  However, RRC can withstand off-path attackers of the type described below when the enhanced path validation algorithm (enhanced) is used. 6.1. </ins> An off-path attacker that can observe packets might forward copies of genuine packets to endpoints over a different path.  If the copied packet arrives before the genuine packet, this will appear as a path After this point, any pending send operation is resumed to the bound peer address.  <ins> path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. </ins> 7.2. After the path validation procedure is completed, any pending send operation is resumed to the bound peer address.  <ins> path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. </ins> 7.3.
Original text:
functional in both directions.  The initiator MUST NOT enforce this behaviour. <del> The initiator MUST silently discard any invalid "path_response" it receives. </del>  Note that RRC does not cater for PMTU discovery on the reverse path. If the responder wants to do PMTU discovery using RRC, it should

Reviewer comments:
Signed-off-by: Thomas Fossati
We say: "The initiator MUST silently discard any invalid pathresponse it receives." we should say instead: "The initiator MUST silently discard any invalid pathresponse or pathdrop it receives."_

Revised text:
functional in both directions.  The initiator MUST NOT enforce this behaviour.  <ins> The initiator MUST silently discard any invalid "path_response" or "path_drop" it receives. </ins> Note that RRC does not cater for PMTU discovery on the reverse path. If the responder wants to do PMTU discovery using RRC, it should
Original text:
6. <del> RRC is not designed to counter on-path attackers.  These can never be distinguished from, for example, a genuine network device.  However, RRC can withstand off-path attackers of the type described below when the enhanced path validation algorithm (enhanced) is used. </del>  6.1.  An off-path attacker that can observe packets might forward copies of genuine packets to endpoints over a different path.  If the copied packet arrives before the genuine packet, this will appear as a path

Reviewer comments:
fix/improve the "attacker model" section Signed-off-by: Thomas Fossati
CC NAME
At the top of the "Attacker model" section we say: "RRC is not designed to counter on-path attackers." What we should say instead is "RRC is not designed to counter man-in-the-middle attackers." We do take care of on-path attackers, via the challenge/response exchange, and we should say that.
I don't think the CR exchange solves the problem, because the attacker can just change the IP addresses.

Revised text:
6.  <ins> RRC is not designed to counter man-in-the-middle attackers.  These can never be distinguished from a genuine network device.  Instead, the types of attacker RRC is designed to withstand are: On-path attackers that try to trigger a connection migration (on- path); Off-path attackers that try to put themselves on-path (off-path) - provided that the enhanced path validation algorithm is used, see enhanced. </ins> 6.1. <ins> An on-path attacker could make a copy of a packet, replace the source address with a spoofed one and forward it to the original destination.  If the spoofed packet arrives before the original it will be regarded as a migration, while the original packet will be flagged as a duplicate and dropped. The subsequent path validation (path-validation) will fail because the entity at the (spoofed) source address does not have the cryptographic keys needed to decode the "path_challenge" message that is sent to it, and therefore to produce the corresponding "path_response".  Since the path validation fails, the address binding is not altered, thus thwarting the attack. 6.2. </ins> An off-path attacker that can observe packets might forward copies of genuine packets to endpoints over a different path.  If the copied packet arrives before the genuine packet, this will appear as a path
Original text:
CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID value, the receiver SHOULD perform a return routability check as <del> described in path-validation. </del>  6.

Reviewer comments:
Signed-off-by: Thomas Fossati
cc NAME
Works for me.
When discussing that in RFC9146, my consideration was, that a "similar mechanism" maybe used also on the next layer. With that, I would consider
Just to mention, for me the idea of UDP is: Do, what could be done, but be also open, to delegate functions to the next layer, if it could be done there maybe more efficient. Therefore RRC with DTLS is great as one option, but other options in upper layers should not be discredited.

Revised text:
CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID value, the receiver SHOULD perform a return routability check as  <ins> described in path-validation, unless an application layer specific address validation mechanism can be triggered instead. </ins> 6.
Original text:
Future extensions or additions to the Return Routability Check protocol may define new message types.  Implementations MUST be able <del> to parse and ignore unknown values. </del>  5.

Reviewer comments:
Signed-off-by: Thomas Fossati
cc NAME
Works for me.
What are the considerations about that select? For me it looks like all "cases" are the same? Do I oversee something?
Maybe the idea of that select is a "future extension". If so, "ignore unknown values" includes, to skip what ever follows, or? Then maybe
Yep, exactly: RRC is not closed (see URL) so the select anticipates extensions that might need a value different from Cookie.
Thanks. WDYT about the extended formulation:
I think the current text is already saying what you propose :-) In the context of the paragraph, there is no "rest of the RRC message" that isn't the "unknown value", so the addition seems redundant to me. NAME WDYT?
Assuming: If is unknown, what is then to be ignored? Maybe:
This is exactly what I wanted the current text to say. Apparently I failed :-) I'll do the suggested tweak.

Revised text:
Future extensions or additions to the Return Routability Check protocol may define new message types.  Implementations MUST be able  <ins> to parse and ignore messages with an unknown "msg_type". </ins> 5.
Original text:
described in RFC9146.  Specifically, when both CID RFC9146 and RRC have been successfully negotiated for the session, if a record with CID is received that has the source address of the enclosing UDP <del> datagram different from the one previously associated with that CID </del>  value, the receiver SHOULD perform a return routability check as described in path-validation, unless an application layer specific address validation mechanism can be triggered instead.

Reviewer comments:
Signed-off-by: Thomas Fossati
cc NAME
works for me
For me the is misleading. My understanding was, that RFC9146 recommend to not update the association before passing the address check. So, for me "currently" may be the better choice.

Revised text:
described in RFC9146.  Specifically, when both CID RFC9146 and RRC have been successfully negotiated for the session, if a record with CID is received that has the source address of the enclosing UDP  <ins> datagram different from the one currently associated with that CID </ins> value, the receiver SHOULD perform a return routability check as described in path-validation, unless an application layer specific address validation mechanism can be triggered instead.
Original text:
12. <del> We would like to thank Achim Kraus, Hanno Becker, Hanno Boeck, Manuel Pegourie-Gonnard, Mohit Sahni and Rich Salz for their input to this document. </del> 

Reviewer comments:
Signed-off-by: Thomas Fossati
Also, remove NAME who's now a co-author.

Revised text:
12.  <ins> We would like to thank Hanno Becker, , , Mohit Sahni and Rich Salz for their input to this document. </ins>
Original text:
8. <del> The example TLS 1.3 handshake shown in fig-handshake shows a client and a server negotiating the support for CID and for the RRC </del>  extension. Once a connection has been established the client and the server <del> exchange application payloads protected by DTLS with an unilaterally used CIDs.  In our case, the client is requested to use CID 100 for </del>  records sent to the server. At some point in the communication interaction the IP address used by the client changes and, thanks to the CID usage, the security context to interpret the record is successfully located by the server. However, the server wants to test the reachability of the client at <del> his new IP address. </del>  9.

Reviewer comments:
/cc NAME Signed-off-by: Thomas Fossati
This is important and so the example should show it.
The draft splits the probes in and . The example demonstrates the so I think, we should add that to the figure description "Basic Return Routability Example".

Revised text:
8.  <ins> In the example TLS 1.3 handshake shown in fig-handshake, a client and a server successfully negotiate support for CID as well as the RRC </ins> extension. Once a connection has been established the client and the server  <ins> exchange application payloads protected by DTLS with a unilaterally used CID.  In our case, the client is requested to use CID 100 for </ins> records sent to the server. At some point in the communication interaction the IP address used by the client changes and, thanks to the CID usage, the security context to interpret the record is successfully located by the server. However, the server wants to test the reachability of the client at  <ins> its new IP address. fig-rrc-example shows the server initiating a "basic" RRC exchange (see regular) that establishes reachability of the client at the new IP address. </ins> 9.
Original text:
IANA is requested to allocate a new value in the "TLS ContentType" registry for the ACK message, defined in ack-msg, with content type <del> 25.  IANA is requested to reserve the content type range 32-63 so </del>  that content types in this range are not allocated. IANA is requested to allocate two values in the "TLS Handshake Type"

Reviewer comments:
DTLS recommends using 25 as the ACK Content Type. CID is using that number based on an early IANA assignment will change DTLS.

Revised text:
IANA is requested to allocate a new value in the "TLS ContentType" registry for the ACK message, defined in ack-msg, with content type  <ins> 26.  IANA is requested to reserve the content type range 32-63 so </ins> that content types in this range are not allocated. IANA is requested to allocate two values in the "TLS Handshake Type"