jiebi/CodeConvo huggingface dataset:
Change:
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.

Discussion:
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> <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.
Change:
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.

Discussion:
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
Change:
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.

Discussion:
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> <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.
Change:
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.

Discussion:
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> <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.
Change:
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.

Discussion:
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> <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
Change:
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!)

Discussion:
5.6. <del> DTLS messages are grouped into a series of message flights, according to the diagrams below. </del> <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> <del> Note: The application data sent by the client is not included in the timeout and retransmission calculation. </del> <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.
Change:
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

Discussion:
6. The following is an example of a handshake with lost packets and <del> retransmissions. </del> <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.
Change:
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

Discussion:
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> <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.
Change:
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.

Discussion:
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> <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 <del> record in a datagram. </del> <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
Change:
…
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

Discussion:
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> <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.
Change:
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

Discussion:
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> <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 <del> top of what is described in I-D.ietf-tls-dtls-connection-id.  There are, however, several improvements: </del> <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
Change:
I have re-drawn the figure to take Ekr's comments into account. I hope the new figure is better.
LGTM

Discussion:
4.1. <del> Implementations can distinguish the two header formats by examining the first byte: </del> <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
Change:
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.

Discussion:
Same as for TLS 1.3. <del> Same as for TLS 1.3. </del> <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
Change:
It gets reset each time the epoch does. Don't talk about values as being scoped only per association.

Discussion:
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> <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 <del> sequence number value received on the association.  Records that contain sequence numbers lower than the "left" edge of the window are </del> <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
Change:
Clarify that being scoped to the current flight goes hand in hand with the implicit ACK behavior for an entire flight.

Discussion:
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> <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
Change:
[ 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.

Discussion:
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> <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 <del> NOT used in DTLS without additional safeguards against forgery. </del> <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.
Change:
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.

Discussion:
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