jiebi/TextFlow huggingface dataset:
Original text:
7. <del> This section provides a summary on the content in previous sections. The fig:summary sums up some recommendations.  It is worth pointing out that the "coding without congestion" considers that coded packets are sent along with original data packets, in opposition with the solution where coded packets are transmitted only when there is no more original packets to transmit.  Moreover, the values indicated in this Figure consider a channel that does not exhibit a high loss pattern. </del>  8.

Reviewer comments:
This proposes a complete re-vamp of the document. I would also suggest to completely remove sections 6 and 7, but rather than doing this yet, I inserted comments that explain why.
Le 17/01/2020 à 09:28, mwelzl a écrit : Yes ! Definitely agree.
Le 17/01/2020 à 13:50, francoismichel a écrit : OK for me.

Revised text:
7.  <ins> [MICHAEL: I'm sorry to say that I find this table to be in the same style, of wrongly mixing things together, and would like to see it removed altogether.]  This section provides a summary on the content in previous sections.  The fig:summary sums up some recommendations. It is worth pointing out that the "coding without congestion" considers that coded packets are sent along with original data packets, in opposition with the solution where coded packets are transmitted only when there is no more original packets to transmit. Moreover, the values indicated in this Figure consider a channel that does not exhibit a high loss pattern. </ins> 8.
Original text:
5.4. <del> frames implicitly create a stream and carry stream data.  The Type field in the frame takes the form 0b00001XXX (or the set of values from 0x08 to 0x0f) to maximize compatibility with QUIC.  However, unlike QUIC, there are only one bit used to determine the fields that are present in the frame: The FIN bit (0x01) indicates that the frame marks the end of the stream.  The final size of the stream is the sum of the length, in bytes, of all data previously sent on this stream and the length of this frame without the length of the Stream ID. </del>  5.5.

Reviewer comments:
The definition was a little loose, so I rewrote it. We only need to use 0x0a and 0x0b, which is lucky and it lets us avoid much of the mess that QUIC has around bits in the type. I've also added definitions for the fields in the frame.

Revised text:
5.4.  <ins> frames implicitly create a stream and carry stream data. The Type field in the frame is either 0x0a or 0x0b.  This uses the same frame types as a QUIC STREAM frame with the OFF bit clear and the LEN bit set.  The FIN bit (0x01) in the frame type indicates that the frame marks the end of the stream in one direction.  Stream data consists of any number of 0x0a frames followed by a terminal 0x0b frame. frames contain the following fields: The stream ID for the stream. Zero or more bytes of data for the stream.  Empty frames MUST NOT be used unless they open or close a stream; an endpoint MAY treat an empty frame that neither starts nor ends a stream as a session error. </ins> 5.5.
Original text:
5.2. The following MAC algorithm applies to block ciphers that use the <del> with Encrypt-then-MAC processing described in RFC7366. </del>  5.3.

Reviewer comments:
URL Francesca Palombini has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you for the work on this document. I only have minor comments and nits below. Francesca sending messages to the client. A zero-length CID value indicates that the client is prepared to send with a CID but does not wish the server to use one when sending. ... to use when sending messages towards it. A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID. FP: clarification question: I am not sure the following formulation is very clear to me: "to send with a(/the client's) CID". Could "send with" be rephrased to clarify? The previous paragraph uses "using a CID value", that would be better IMO. the record format defined in {{dtls-ciphertext} with the new MAC FP: nit - missing "}" in markdown. The following MAC algorithm applies to block ciphers that use the with Encrypt-then-MAC processing described in [RFC7366]. FP: remove "with" Section 10.1 FP: I believe you should specify 1. what allowed values are for this column (i.e. Y or N, and what they mean) and 2. what happens to the existing entries - namely that they all get "N" value. Section 10.2 FP: Just checking - why is 53 "incompatible with this document"? Value Extension Name TLS 1.3 DTLS Only Recommended Reference FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1

Revised text:
5.2. The following MAC algorithm applies to block ciphers that use the  <ins> Encrypt-then-MAC processing described in RFC7366. </ins> 5.3.
Original text:
publication, the early allocation will be deprecated in favor of this assignment.  Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document describes the behavior of this extension for DTLS 1.2 only; it is not

Reviewer comments:
URL Francesca Palombini has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you for the work on this document. I only have minor comments and nits below. Francesca sending messages to the client. A zero-length CID value indicates that the client is prepared to send with a CID but does not wish the server to use one when sending. ... to use when sending messages towards it. A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID. FP: clarification question: I am not sure the following formulation is very clear to me: "to send with a(/the client's) CID". Could "send with" be rephrased to clarify? The previous paragraph uses "using a CID value", that would be better IMO. the record format defined in {{dtls-ciphertext} with the new MAC FP: nit - missing "}" in markdown. The following MAC algorithm applies to block ciphers that use the with Encrypt-then-MAC processing described in [RFC7366]. FP: remove "with" Section 10.1 FP: I believe you should specify 1. what allowed values are for this column (i.e. Y or N, and what they mean) and 2. what happens to the existing entries - namely that they all get "N" value. Section 10.2 FP: Just checking - why is 53 "incompatible with this document"? Value Extension Name TLS 1.3 DTLS Only Recommended Reference FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1

Revised text:
publication, the early allocation will be deprecated in favor of this assignment. <ins> A new column "DTLS-Only" is added to the registry.  The valid entries are "Y" if the extension is only applicable to DTLS, "N" otherwise. All the pre-existing entries are given the value "N". </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document describes the behavior of this extension for DTLS 1.2 only; it is not
Original text:
10.  IANA is requested to allocate an entry to the TLS "ContentType" registry, for the "return_routability_check(TBD2)" message defined in this document.  The "return_routability_check" content type is only applicable to DTLS 1.2 and 1.3.  IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext.  11. Issues against this document are tracked at https://github.com/tlswg/

Reviewer comments:
This PR is on top of
We probably need to create a new IANA registry for RRC message types. The registry should be initialised with the 3 message types we define in the draft.
Ok.

Revised text:
10. <ins> [[to-be-removed: RFC Editor: please replace RFCthis with this RFC number and remove this note.]] 10.1. </ins> IANA is requested to allocate an entry to the TLS "ContentType" registry, for the "return_routability_check(TBD2)" message defined in this document.  The "return_routability_check" content type is only applicable to DTLS 1.2 and 1.3. <ins> 10.2. </ins> IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext. <ins> 10.3. IANA is requested to create a new sub-registry for RRC Message Types in the TLS Parameters registry IANA.tls-parameters, with the policy "expert review" RFC8126. Each entry in the registry must include: The initial state of this sub-registry is as follows: </ins> 11. Issues against this document are tracked at https://github.com/tlswg/
Original text:
those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity.  10. [[to-be-removed: RFC Editor: please replace RFCthis with this RFC

Reviewer comments:
Signed-off-by: Thomas Fossati
CC NAME
We don't currently discuss any privacy implication associated with CID reuse. We should at least: document how to ensure a new CID is used during path validation in 1.3 flag that 1.2 has no way to work around linkability because CID have the same lifetime as the session

Revised text:
those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <ins> When using DTLS 1.3, peers SHOULD avoid using the same CID on multiple network paths, in particular when initiating connection migration or when probing a new network path, as described in path- validation, as an adversary can otherwise correlate the communication interaction across those different paths.  DTLS 1.3 provides mechanisms to ensure that a new CID can always be used.  In general, an endpoint should proactively send a RequestConnectionId message to ask for new CIDs as soon as the pool of spare CIDs is depleted (or goes below a threshold).  Also, in case a peer might have exhausted available CIDs, a migrating endpoint could include NewConnectionId in packets sent on the new path to make sure that the subsequent path validation can use fresh CIDs. Note that DTLS 1.2 does not offer the ability to request new CIDs during the session lifetime since CIDs have the same life-span of the connection.  Therefore, deployments that use DTLS in multihoming environments SHOULD refuse to use CIDs with DTLS 1.2 and switch to DTLS 1.3 if the correlation privacy threat is a concern. </ins> 10. [[to-be-removed: RFC Editor: please replace RFCthis with this RFC
Original text:
active path, implementations SHOULD use T = 3xRTT. If an implementation has no way to obtain information regarding the <del> RTT of the active path, a value of 1s SHOULD be used. </del>  Profiles for specific deployment environments - for example, constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a

Reviewer comments:
/cc NAME Signed-off-by: Thomas Fossati
In this second paragraph, does this mean T=1s or RTT=1s ?
FMPOV: (because that refers to the default timeout of DTLS 1.2 RFC6347)

Revised text:
active path, implementations SHOULD use T = 3xRTT. If an implementation has no way to obtain information regarding the  <ins> RTT of the active path, T SHOULD be set to 1s. </ins> Profiles for specific deployment environments - for example, constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a
Original text:
Handshake messages are potentially larger than any given datagram, thus creating the problem of IP fragmentation. <del> Datagram transport protocols, like UDP, are more vulnerable to denial of service attacks and require a return-routability check with the help of cookies to be integrated into the handshake.  A detailed discussion of countermeasures can be found in dos. </del>  3.1.

Reviewer comments:
Attempt to address though I'm not entirely happy with this text. Having gone through the existing text looking at "vulnerable" and "susceptible", it doesn't seem in particularly bad shape, so my comment there may have been stronger than needed.
Copied from EKR's repo Ben Kaduk wrote: "We talk in a couple places about datagram protocols being “vulnerable” or “susceptible” to DoS attacks, which leads me to at least partially read that as meaning that the protocol’s own service will be disrupted; as we know, this is not the whole story, as the reflection/amplification part can facilitate DoS attacks targeted at other services/networks. So perhaps some rewording is in order. "
NAME I would welcome a PR here.
NAME did this,

Revised text:
Handshake messages are potentially larger than any given datagram, thus creating the problem of IP fragmentation.  <ins> Datagram transport protocols, like UDP, are susceptible to abusive behavior effecting denial of service attacks against nonparticipants, and require a return-routability check with the help of cookies to be integrated into the handshake.  A detailed discussion of countermeasures can be found in dos. </ins> 3.1.
Original text:
error.  Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service (DoS) attacks because UDP forgery is so easy.  Thus, this practice is <del> NOT RECOMMENDED for such transports. </del>  If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts

Reviewer comments:
Attempt to address though I'm not entirely happy with this text. Having gone through the existing text looking at "vulnerable" and "susceptible", it doesn't seem in particularly bad shape, so my comment there may have been stronger than needed.
Copied from EKR's repo Ben Kaduk wrote: "We talk in a couple places about datagram protocols being “vulnerable” or “susceptible” to DoS attacks, which leads me to at least partially read that as meaning that the protocol’s own service will be disrupted; as we know, this is not the whole story, as the reflection/amplification part can facilitate DoS attacks targeted at other services/networks. So perhaps some rewording is in order. "
NAME I would welcome a PR here.
NAME did this,

Revised text:
error.  Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service (DoS) attacks because UDP forgery is so easy.  Thus, this practice is  <ins> NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </ins> If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts
Original text:
datagram.  Omitting the length field MUST only be used for the last record in a datagram. <del> Implementations which send multiple records in the same datagram SHOULD omit the connection id from all but the first record; receiving implementations MUST assume that any subsequent records without connection IDs belong to the same association.  Sending implementations MUST NOT mix records from multiple DTLS associations in the same datagram.  If the second or later record has a connection ID which does not correspond to the same association used for previous records, the rest of the datagram MUST be discarded. </del>  When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below:

Reviewer comments:
As proposed on list.
Hanno Becker points out that the current text does not cryptographically protect the CID when we have coalesced packets. I created PR to add this feature, but I think instead we should simply require that all packets have CIDs once the CID is established. This seems like a net reduction in complexity. There would be two changes here: Re-emphasize the point already in the DTLS CID spec that you abort if a CID is expected and none is found. Remove the text about allowing implicit CIDs.
NAME NAME
This was resolved by . Please re-open if that's not the case!

Revised text:
datagram.  Omitting the length field MUST only be used for the last record in a datagram.  <ins> If a connection ID is negotiated, then it MUST be contained in all datagrams.  Sending implementations MUST NOT mix records from multiple DTLS associations in the same datagram.  If the second or later record has a connection ID which does not correspond to the same association used for previous records, the rest of the datagram MUST be discarded. </ins> When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below:
Original text:
5.7.3.  DTLS 1.3 makes use of the following categories of post-handshake messages:

Reviewer comments:
NAME NAME
(Probably want to fix the typo for "Fixes" in the PR title, but the content looks good to me)
DTLS 1.3 does not really change this aspect compared to earlier DTLS versions. We could reference a number of the other TLS WG documents that attempt to reduce the size of the certificate message, such as Client Certificate URL Cached Info Certificate Compression Following the guidelines in RFC 7925 Other certificate types It may be possible to use the fragmentation mechanism to send one certificate after the other in the certificate chain. Is this what you had in mind?

Revised text:
5.7.3. <ins> DTLS does not have any built-in congestion control or rate control; in general this is not an issue because messages tend to be small. However, in principle, some messages - especially Certificate - can be quite large.  If all the messages in a large flight are sent at once, this can result in network congestion.  A better strategy is to send out only part of the flight, sending more when messages are acknowledged.  DTLS offers a number of mechanisms for minimizing the size of the certificate message, including the cached information extension RFC7924 and certificate compression RFC8879. 5.7.4. </ins> DTLS 1.3 makes use of the following categories of post-handshake messages:
Original text:
the "TLS Alerts" registry with value 52. IANA is requested to allocate two values in the "TLS Handshake Type" <del> registry, defined in TLS13, for RequestConnectionId (TBD), and NewConnectionId (TBD), as defined in this document.  The value for </del>  the "DTLS-OK" columns are "Y". IANA is requested to add this RFC as a reference to the TLS Cipher

Reviewer comments:
As far as referring to the snake case in the main body, I went and looked at RFC 8446 and it does not refer to the snake case. I tend to think that if we make the change in 5.2 and A.2, that should be enough breadcrumbs for people to figure it out. I put them in the same order as they are in the registry and moved up newsessionticket. Triple check this change please.
This I-D registers two TLS HandshakeTypes. All of the other fields in the registry use snake_case.

Revised text:
the "TLS Alerts" registry with value 52. IANA is requested to allocate two values in the "TLS Handshake Type"  <ins> registry, defined in TLS13, for request_connection_id (TBD), and new_connection_id (TBD), as defined in this document.  The value for </ins> the "DTLS-OK" columns are "Y". IANA is requested to add this RFC as a reference to the TLS Cipher
Original text:
the connection establishment. With these exceptions, the DTLS message formats, flows, and logic are <del> the same as those of TLS 1.3. </del>  5.1.

Reviewer comments:
Right now, my NSS patch for compatibility mode in TLS also includes changes to DTLS. Those changes include the ServerHello format changes, but NSS will ignore the session_id and never send a ChangeCipherSpec from either client or server.
Note that we probably still want to ignore CCS in DTLS - DTLS discards things that it doesn't want to see - this is about generating CCS.

Revised text:
the connection establishment. With these exceptions, the DTLS message formats, flows, and logic are  <ins> 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. </ins> 5.1.
Original text:
Same as for TLS 1.3. A DTLS 1.3-only client MUST set the legacy_cookie field to zero <del> length. </del>  Same as for TLS 1.3.

Reviewer comments:
Addressing issue raised by Martin at URL
Should the server reject the ClientHello if it appears as though the client is responding to a HelloVerifyRequest? What if it also contains a cookie extension?
I don't think the server should reject a ClientHello if it thinks the Client should provide a cookie previously sent with the HelloVerifyRequest. This would require the server to keep state and to implement more complex logic in the server-side. If the ClientHello contains a cookie in the ClientHello.legacycookie field in the DTLS 1.3 field then IMHO an "illegalparameter" alert has to be sent. I created a PR to add a note about this: URL There is, however, the question why whether we should omit some of the legacy fields for use with DTLS 1.3 (not in the ClientHello because it would be needed for backwards compatibility) but for the ServerHello/HelloRetryRequest.
Fixed

Revised text:
Same as for TLS 1.3. A DTLS 1.3-only client MUST set the legacy_cookie field to zero  <ins> length.  If a DTLS 1.3 ClientHello is received with any other value in this field, the server MUST abort the handshake with an "illegal_parameter" alert. </ins> Same as for TLS 1.3.