jiebi/TextFlow huggingface dataset:
Original text:
computing AES-ECB on the first 16 bytes of the ciphertext: When the AEAD is based on ChaCha20, then the mask is generated by <del> treating the first 12 bytes of the ciphertext as the Nonce and the next 4 bytes as the counter, passing them to the ChaCha20 block </del>  function (Section 2.3 of CHACHA): The sn_key is computed as follows:

Reviewer comments:
NAME NAME
... takes its sample inputs in a different order to the one used in QUIC. This issue tracks the possibility of erasing that difference.

Revised text:
computing AES-ECB on the first 16 bytes of the ciphertext: When the AEAD is based on ChaCha20, then the mask is generated by  <ins> treating the first 4 bytes of the ciphertext as the block counter and the next 12 bytes as the nonce, passing them to the ChaCha20 block </ins> function (Section 2.3 of CHACHA): The sn_key is computed as follows:
Original text:
The cookie extension is defined in Section 4.2.2 of TLS13.  When sending the initial ClientHello, the client does not have a cookie yet.  In this case, the cookie extension is omitted and the <del> legacy_cookie field in the ClientHello message SHOULD be set to a zero length vector (i.e., a single zero byte length field) and MUST be ignored by a server negotiating DTLS 1.3. </del>  When responding to a HelloRetryRequest, the client MUST create a new ClientHello message following the description in Section 4.1.2 of

Reviewer comments:
I can't reconcile: ... with: The MUSTs in these appear to be pulling in opposite directions. I suspect that the latter is correct though. It is possible that a DTLS 1.3 client could get a legacy cookie from a DTLS 1.2 server, so that it is valid for the legacy cookie to appear when supported_versions includes DTLS 1.3. However, that represents an attack and a DTLS 1.3 server shouldn't continue to establish the connection. Maybe it isn't a bad attack because the client doesn't change its posture in ways that would materially affect the resulting session, but we have generally tried to avoid these.

Revised text:
The cookie extension is defined in Section 4.2.2 of TLS13.  When sending the initial ClientHello, the client does not have a cookie yet.  In this case, the cookie extension is omitted and the  <ins> legacy_cookie field in the ClientHello message MUST be set to a zero length vector (i.e., a single zero byte length field). </ins> When responding to a HelloRetryRequest, the client MUST create a new ClientHello message following the description in Section 4.1.2 of
Original text:
flight of messages.  If the implementation has received one or more ACKs (see ack-msg) from the peer, then it SHOULD omit any messages or message fragments which have already been ACKed.  Once the messages <del> have been sent, the implementation then enters the FINISHED state if this is the last flight in the handshake.  Or, if the implementation expects to receive more messages, it sets a retransmit timer and then </del>  enters the WAITING state. There are four ways to exit the WAITING state:

Reviewer comments:
The previous version erroneously specified that implementations should transition from SENDING to FINISHED after sending the last flight in a handshake. Instead, they should transition to WAITING and only move to FINISHED upon receipt of ACKs for the entire last flight. This PR fixes the state machine diagram and text.
lgtm

Revised text:
flight of messages.  If the implementation has received one or more ACKs (see ack-msg) from the peer, then it SHOULD omit any messages or message fragments which have already been ACKed.  Once the messages  <ins> have been sent, the implementation then sets a retransmit timer and </ins> enters the WAITING state. There are four ways to exit the WAITING state:
Original text:
handshake, the server's transmission of the NewSessionTicket, and KeyUpdate messages.  ACKs SHOULD NOT be sent for other complete flights because they are implicitly acknowledged by the receipt of <del> the next flight, which generally immediately follows the flight. </del>  Each NewSessionTicket or KeyUpdate is an individual flight; in particular, a KeyUpdate sent in response to a KeyUpdate with update_requested does not implicitly acknowledge that message.

Reviewer comments:
Hanno Becker writes: I have a minor comment on DTLS 1.3 draft 37. On the topic of sending ACKs, the draft recommends: I wonder if the case of post-handshake authentication should be explicitly mentioned as a potential exception to this rule, since the TLS 1.3 RFC explicitly mentions that responses to may be delayed in some contexts: In this case, it would be beneficial to immediately explicitly ACK the message even though it is also implicitly acked through the eventual response via the message.

Revised text:
handshake, the server's transmission of the NewSessionTicket, and KeyUpdate messages.  ACKs SHOULD NOT be sent for other complete flights because they are implicitly acknowledged by the receipt of  <ins> the next flight, which generally immediately follows the flight, unless generating the responding flight takes significant time.  In this case, implementations MAY send explicit ACKs for the complete received flight even though it will eventually also be implicitly acknowledged through the responding flight.  A notable example for this is the case of post-handshake client authentication in constrained environments, where generating the CertificateVerify message can take considerable time on the client. </ins> Each NewSessionTicket or KeyUpdate is an individual flight; in particular, a KeyUpdate sent in response to a KeyUpdate with update_requested does not implicitly acknowledge that message.
Original text:
defines an algorithm for encrypting sequence numbers, see sne. Note that sequence number encryption is used for all encrypted DTLS 1.3 records irrespective of whether a CID is used or not.  DTLS 1.3 encrypts handshake messages much earlier than in previous DTLS versions.  Therefore, less information identifying the DTLS

Reviewer comments:
LGTM.
DTLS and QUIC share a lot of characteristics when it comes to protection of records/packets, but the DTLS sequence number encryption covers marginally less than the header protection in QUIC. Notably, this doesn't include the epoch in DTLS, where QUIC protects its one-bit epoch value. This avoids one issue QUIC has with respect to overuse of keys under an attempted forgery attack, because the choice of key is always clear, but it does mean that the epoch can be used to improve correlation between activity on different network paths. I don't think that this needs to be fixed, but it should be noted in the security considerations.

Revised text:
defines an algorithm for encrypting sequence numbers, see sne. Note that sequence number encryption is used for all encrypted DTLS 1.3 records irrespective of whether a CID is used or not. <ins> Unlike the sequence number, the epoch is not encrypted.  This may improve correlation of packets from a single connection across different network paths. </ins> DTLS 1.3 encrypts handshake messages much earlier than in previous DTLS versions.  Therefore, less information identifying the DTLS
Original text:
Using these reserved epoch values a receiver knows what cipher state has been used to encrypt and integrity protect a message. <del> Implementations that receive a payload with an epoch value for which no corresponding cipher state can be determined MUST generate a "unexpected_message" alert.  For example, if a client incorrectly uses epoch value 5 when sending early application data in a 0-RTT exchange.  A server will not be able to compute the appropriate keys and will therefore have to respond with an alert. </del>  Note that epoch values do not wrap.  If a DTLS implementation would need to wrap the epoch value, it MUST terminate the connection.

Reviewer comments:
What was the motivation for this change?
The idea was to bring us in line with the normal handling for invalid records, which is to ignore them rather than send an alert and tear things down. DTLS associations are supposed to be robust against injected packets. I suspect that there is also some remnant of the previous state of affairs when just incrementing the epoch was all that was needed to generate new keys, as opposed to requiring KeyUpdate+ACK, though that's not directly related to making this change.
Flagging as consensus-needed.

Revised text:
Using these reserved epoch values a receiver knows what cipher state has been used to encrypt and integrity protect a message.  <ins> Implementations that receive a record with an epoch value for which no corresponding cipher state can be determined SHOULD handle it as a record which fails deprotection. </ins> Note that epoch values do not wrap.  If a DTLS implementation would need to wrap the epoch value, it MUST terminate the connection.
Original text:
handshake and not dataflow, the effect on congestion should be minimal. <del> Implementations SHOULD retain the current timer value until a transmission without loss occurs, at which time the value may be reset to the initial value.  After a long period of idleness, no less than 10 times the current timer value, implementations MAY reset the timer to the initial value. </del>  5.7.3.

Reviewer comments:
This says to reset when you get a transmission without loss, but I actually think this is potentially too conservative and we should just reset on every "first" transmission.

Revised text:
handshake and not dataflow, the effect on congestion should be minimal.  <ins> Implementations SHOULD retain the current timer value until a message is transmitted and acknowledged without having to be retransmitted, at which time the value may be reset to the initial value.  After a long period of idleness, no less than 10 times the current timer value, implementations MAY reset the timer to the initial value. </ins> 5.7.3.
Original text:
as possible.  Endpoints MUST NOT send a RequestConnectionId message when an existing request is still unfulfilled; this implies that endpoints needs to request new CIDs well in advance.  An endpoint MAY <del> ignore requests, which it considers excessive (though they MUST be acknowledged as usual). </del>  Endpoints MUST NOT send either of these messages if they did not negotiate a CID.  If an implementation receives these messages when reserve the content type range 32-63 so that content types in this range are not allocated.  IANA is requested to allocate two values in the "TLS Handshake Type" registry, defined in TLS13, for RequestConnectionId (TBD), and NewConnectionId (TBD), as defined in this document.  The value for

Reviewer comments:
Fix a deadlock identified by NAME This seems like it sets up a deadlock scenario. Consider peers A and B; A sends RequestConnectionId with num_cids=200 and B considers this request excessive, so ACKs it but sends no NewConnectionId in response. A is prohibited from sending another RequestConnection Id to indicate that it really needs new CIDs, since the requested 200 have not arrived yet; thus, B could end up not sending any NewConnectionIds even though A is essentially blocking on getting them. Unless "unfulfilled" is supposed to mean "not ACKed"?
NAME
Done.

Revised text:
as possible.  Endpoints MUST NOT send a RequestConnectionId message when an existing request is still unfulfilled; this implies that endpoints needs to request new CIDs well in advance.  An endpoint MAY  <ins> handle requests, which it considers excessive, by responding with a NewConnectionId message containing fewer than num_cid CIDs, including no CIDs at all.  Endpoints MAY handle an excessive number of RequestConnectionId messages by terminating the connection using a "too_many_cids_requested" (alert number 52) alert. </ins> Endpoints MUST NOT send either of these messages if they did not negotiate a CID.  If an implementation receives these messages when reserve the content type range 32-63 so that content types in this range are not allocated. <ins> IANA is requested to allocate "the too_many_cids_requested" alert in the "TLS Alerts" registry with value 52. </ins> IANA is requested to allocate two values in the "TLS Handshake Type" registry, defined in TLS13, for RequestConnectionId (TBD), and NewConnectionId (TBD), as defined in this document.  The value for
Original text:
5.6. <del> DTLS messages are grouped into a series of message flights, according to the diagrams below. </del>  <del> Note: The application data sent by the client is not included in the timeout and retransmission calculation. </del>  5.7.

Reviewer comments:
NAME I merged this. Any chance you want to send a PR or do you want me to?
I'm not in a great spot to make a PR at the moment; please go ahead.
I just fixed this in the main branch.
Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" It's 0. I think this example may have had an HRR. Will fix. Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples"
NAME can you take these?
PRs for the example updates are URL URL URL
Fixed
Thanks, this addresses the issues I had raised for this section. (It's perhaps a little janky to have just a box with "Flight" for each one, but I don't have any better ideas, so we should probably roll with it!)

Revised text:
5.6.  <ins> DTLS handshake messages are grouped into a series of message flights. A flight starts with the handshake message transmission of one peer and ends with the expected response from the other peer.  Table tab- flights contains a complete list of message combinations that consitute flights. </ins>  <ins> Remarks: The HelloRetryRequest shown in (1) is an optional message sent by the server. The ACK message is sent by a client in response to a NewSessionTicket message from the server (as noted in (3)) or sent by a server in response to receipt of flight (2).  In those cases it represent a flight on its own. Below are several example message exchange illustrating the flight concept. </ins> 5.7.
Original text:
6. The following is an example of a handshake with lost packets and <del> retransmissions. </del>  6.1.

Reviewer comments:
Based on review from Ben: Section 6 Figure 11 seems to show that the initial ServerHello has messageseq=1, but §5.2 says that "[t]he first message each side transmits in each association always has messageseq = 0". Which one is it? (A change here would affect all the server's messages except the final ACK.)
Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" It's 0. I think this example may have had an HRR. Will fix. Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples"
NAME can you take these?
PRs for the example updates are URL URL URL
Fixed

Revised text:
6. The following is an example of a handshake with lost packets and  <ins> retransmissions.  Note that the client sends an empty ACK message because it can only acknowledge Record 1 sent by the server once it has processed messages in Record 0 needed to establish epoch 2 keys, which are needed to encrypt to decrypt messages found in Record 1. ack-msg provides the necessary background details for this interaction. </ins> 6.1.
Original text:
The use of the ACK for the second case is mandatory for the proper functioning of the protocol.  For instance, the ACK message sent by the client in Figure 12, acknowledges receipt and processing of <del> record 2 (containing the NewSessionTicket message) and if it is not </del>  sent the server will continue retransmission of the NewSessionTicket indefinitely until its transmission cap is reached.

Reviewer comments:
Ben wrote: The use of the ACK for the second case is mandatory for the proper functioning of the protocol. For instance, the ACK message sent by the client in Figure 12, acknowledges receipt and processing of record 2 (containing the NewSessionTicket message) and if it is not The records in Figure 12 are not labeled (anymore?).
Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" It's 0. I think this example may have had an HRR. Will fix. Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples"
NAME can you take these?
PRs for the example updates are URL URL URL
Fixed

Revised text:
The use of the ACK for the second case is mandatory for the proper functioning of the protocol.  For instance, the ACK message sent by the client in Figure 12, acknowledges receipt and processing of  <ins> record 4 (containing the NewSessionTicket message) and if it is not </ins> sent the server will continue retransmission of the NewSessionTicket indefinitely until its transmission cap is reached.
Original text:
The C bit (0x10) is set if the Connection ID is present. The S bit (0x08) indicates the size of the sequence number.  0 <del> means an 8-bit sequence number, 1 means 16-bit. </del>  The L bit (0x04) is set if the length is present. level transport.  In this case it is not possible to have multiple DTLSCiphertext format records without length fields in the same datagram.  Omitting the length field MUST only be used for the last <del> record in a datagram. </del>  If a connection ID is negotiated, then it MUST be contained in all datagrams.  Sending implementations MUST NOT mix records from

Reviewer comments:
Andy Cunningham wrote Text would not hurt in the draft to explain this.
Chairs, please opine on whether this should get confirmed on the list.

Revised text:
The C bit (0x10) is set if the Connection ID is present. The S bit (0x08) indicates the size of the sequence number.  0  <ins> means an 8-bit sequence number, 1 means 16-bit.  Implementations MAY mix sequence numbers of different lengths on the same connection. </ins> The L bit (0x04) is set if the length is present. level transport.  In this case it is not possible to have multiple DTLSCiphertext format records without length fields in the same datagram.  Omitting the length field MUST only be used for the last  <ins> record in a datagram.  Implementations MAY mix records with and without length fields on the same connection. </ins> If a connection ID is negotiated, then it MUST be contained in all datagrams.  Sending implementations MUST NOT mix records from
Original text:
The three high bits of the first byte of the DTLSCiphertext header are set to 001.  This ensures that the value will fit within the DTLS region when multiplexing is performed as described in <del> RFC7983. </del>  The C bit (0x10) is set if the Connection ID is present.

Reviewer comments:
…
I don't.
It would also be good to add a note on how we tell the difference between DTLS 1.2 and 1.3. Version information is carried in various places and due to the use of the CID the multiplexing got more complex between 1.2 and 1.3.
This WFM

Revised text:
The three high bits of the first byte of the DTLSCiphertext header are set to 001.  This ensures that the value will fit within the DTLS region when multiplexing is performed as described in  <ins> RFC7983.  It also ensures that distinguishing encrypted DTLS 1.3 records from encrypted DTLS 1.2 records is possible when they are carried on the same host/port quartet; such multiplexing is only possible when connection IDs I-D.ietf-tls-dtls-connection-id are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25). </ins> The C bit (0x10) is set if the Connection ID is present.
Original text:
RFC7983.  It also ensures that distinguishing encrypted DTLS 1.3 records from encrypted DTLS 1.2 records is possible when they are carried on the same host/port quartet; such multiplexing is only <del> possible when connection IDs I-D.ietf-tls-dtls-connection-id are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25). </del>  The C bit (0x10) is set if the Connection ID is present. to invalid records by terminating the connection. The security and privacy properties of the CID for DTLS 1.3 builds on <del> top of what is described in I-D.ietf-tls-dtls-connection-id.  There are, however, several improvements: </del>  The use of the Post-Handshake message allows the client and the server to update their CIDs and those values are exchanged with

Reviewer comments:
In both versions of DTLS we have to do the extension negotiation because you have to agree on the CID values. In both versions we have to carry the CID in the record layer (if the CID is used). The way we incorporated the CID into the headers is different between the different versions. In DTLS 1.3 we have this variable length header and in DTLS 1.2 we don't. There are also privacy differences.
I'm inclined not to add anything here. If you feel strongly maybe you could provide a PR?
I think the privacy differences (and ability to change values over the lifetime of an association, e.g., when roaming) are probably worth mentioning. NAME do you plan to write some text? If not I can try to squeeze it in.
PR is available at
Fixed in . Closing.
LGTM

Revised text:
RFC7983.  It also ensures that distinguishing encrypted DTLS 1.3 records from encrypted DTLS 1.2 records is possible when they are carried on the same host/port quartet; such multiplexing is only  <ins> possible when CIDs I-D.ietf-tls-dtls-connection-id are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25). </ins> The C bit (0x10) is set if the Connection ID is present. to invalid records by terminating the connection. The security and privacy properties of the CID for DTLS 1.3 builds on  <ins> top of what is described for DTLS 1.2 in I-D.ietf-tls-dtls- connection-id.  There are, however, several differences: In both versions of DTLS extension negotiation is used to agree on the use of the CID feature and the CID values.  In both versions the CID is carried in the DTLS record header (if negotiated). However, the way the CID is included in the record header differs between the two versions. </ins> The use of the Post-Handshake message allows the client and the server to update their CIDs and those values are exchanged with
Original text:
4.1. <del> Implementations can distinguish the two header formats by examining the first byte: </del>  If the first byte is alert(21), handshake(22), or ack(proposed, 26), the record MUST be interpreted as a DTLSPlaintext record. Otherwise, the record MUST be rejected as if it had failed deprotection, as described in handling-invalid-records.  4.2. DTLS uses an explicit or partly explicit sequence number, rather than

Reviewer comments:
I have re-drawn the figure to take Ekr's comments into account. I hope the new figure is better.
LGTM

Revised text:
4.1.  <ins> DTLS 1.3 uses a variable length record format and hence the demultiplexing process is more complex since more header formats need to be distinguished.  Implementations can demultiplex DTLS 1.3 records by examining the first byte as follows: </ins> If the first byte is alert(21), handshake(22), or ack(proposed, 26), the record MUST be interpreted as a DTLSPlaintext record. Otherwise, the record MUST be rejected as if it had failed deprotection, as described in handling-invalid-records. <ins> demux shows this demultiplexing procedure graphically taking DTLS 1.3 and earlier versions of DTLS into account. </ins> 4.2. DTLS uses an explicit or partly explicit sequence number, rather than