jiebi/CodeConvo huggingface dataset:
Code change:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Related discussion:
text: The above is necessary to protect against attacks that use datagrams with spoofed addresses or replayed datagrams to trigger attacks. <del> Note that there is no requirement to use of the anti-replay window </del> <ins> Note that there is no requirement for use of the anti-replay window </ins> mechanism defined in Section 4.1.2.6 of DTLS 1.2.  Both solutions, <del> the "anti-replay window" or "newer algorithm" will prevent address </del> <ins> the "anti-replay window" or "newer" algorithm, will prevent address </ins> updates from replay attacks while the latter will only apply to peer address updates and the former applies to any application layer traffic. <ins> Note that datagrams that pass the DTLS cryptographic verification procedures but do not trigger a change of peer address are still valid DTLS records and are still to be passed to the application. </ins> Application protocols that implement protection against these attacks depend on being aware of changes in peer addresses so that they can engage the necessary mechanisms.  When delivered such an event, an application layer-specific address validation mechanism can be <del> triggered, for example one that is based on successful exchange of </del> <ins> triggered, for example one that is based on successful exchange of a </ins> minimal amount of ping-pong traffic with the peer.  Alternatively, an DTLS-specific mechanism may be used, as described in I-D.tschofenig- tls-dtls-rrc.
Code change:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Related discussion:
text: dtls-example2 shows an example exchange where a CID is used uni- directionally from the client to the server.  To indicate that a <del> zero-length CID we use the term 'connection_id=empty'. </del> <ins> zero-length CID is present in the "connection_id" extension we use the notation 'connection_id=empty'. </ins> Note: In the example exchange the CID is included in the record layer once encryption is enabled.  In DTLS 1.2 only one handshake message is encrypted, namely the Finished message.  Since the example shows <del> how to use the CID for payloads sent from the client to the server only the record layer payloads containing the Finished messages include a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. </del> <ins> how to use the CID for payloads sent from the client to the server, only the record layer payloads containing the Finished message or application data include a CID. </ins> 8.
Code change:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Related discussion:
text: details about record padding can be found in Section 5.4 and Appendix E.3 of RFC 8446. <del> Finally, endpoints can use the CID to attach arbitrary metadata to each record they receive.  This may be used as a mechanism to communicate per-connection information to on-path observers.  There is no straightforward way to address this concern with CIDs that contain arbitrary values.  Implementations concerned about this aspects SHOULD refuse to use CIDs. </del> <ins> Finally, endpoints can use the CID to attach arbitrary per-connection metadata to each record they receive on a given connection.  This may be used as a mechanism to communicate per-connection information to on-path observers.  There is no straightforward way to address this concern with CIDs that contain arbitrary values.  Implementations concerned about this aspect SHOULD refuse to use CIDs. </ins> 9.
Code change:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Related discussion:
text: asymmetry of request/response message sizes. Additionally, an attacker able to observe the data traffic exchanged <del> between two DTLS peers is able to replay datagrams with modified IP address/port numbers. </del> <ins> between two DTLS peers is able to modify IP address/port numbers. When the optional DTLS replay detection is not in use, such an attacker can also replay the observed packets, and the multiple copies of each packet can have different IP address/port numbers as well. </ins> The topic of peer address updates is discussed in peer-address- update.
Code change:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Related discussion:
text: "ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD1) as described in the table below.  IANA is requested to add an extra column to the TLS ExtensionType Values <del> registry to indicate whether an extension is only applicable to DTLS. </del> <ins> registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document <del> describes an extension for DTLS 1.2 only; it is not to TLS (1.3). The DTLS 1.3 functionality is described in I-D.ietf-tls-dtls13. </del> <ins> describes the behavior of this extension for DTLS 1.2 only; it is not applicable to TLS, and its usage for DTLS 1.3 is described in I- D.ietf-tls-dtls13. </ins> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType Registry".  The tls12_cid ContentType is only applicable to DTLS 1.2.
Code change:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

Related discussion:
text: confidence to the receiving peer that the sending peer is reachable at the indicated address and port. <ins> Note however that, irrespective of CID, if RRC has been successfully negotiated by the peers, path validation can be used at any time by either endpoint.  For instance, an endpoint might use RRC to check that a peer is still in possession of its address after a period of quiescence. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Code change:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

Related discussion:
text: I-D.ietf-tls-dtls13.  The presentation language used in this document is described in Section 4 of RFC8446. <ins> This document reuses the definition of "anti-amplification limit" from RFC9000 to mean three times the amount of data received from an unvalidated address.  This includes all DTLS records originating from that source address, excluding discarded ones. </ins> 3. The use of RRC is negotiated via the "rrc" DTLS-only extension.  On
Code change:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

Related discussion:
text: The "return_routability_check" message MUST be authenticated and encrypted using the currently active security context. <del> The receiver that observes the peer's address and or port update MUST </del> <ins> 5. The receiver that observes the peer's address or port update MUST </ins> stop sending any buffered application data (or limit the data sent to <del> a TBD threshold) and initiate the return routability check that proceeds as follows: </del> <ins> the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows: </ins> <del> A cookie is placed in a "return_routability_check" message of type path_challenge; </del> <ins> An unpredictable cookie is placed in a "return_routability_check" message of type path_challenge; </ins> <del> The message is sent to the observed new address and a timeout T is started; </del> <ins> The message is sent to the observed new address and a timer T (see timer-choice) is started; </ins> The peer endpoint, after successfully verifying the received <del> "return_routability_check" message echoes the cookie value in a "return_routability_check" message of type path_response; </del> <ins> "return_routability_check" message responds by echoing the cookie value in a "return_routability_check" message of type path_response; </ins> When the initiator receives and verifies the "return_routability_check" message contains the sent cookie, it
Code change:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

Related discussion:
text: However, the server wants to test the reachability of the client at his new IP address. <del> 6. </del> <ins> 7. </ins> Note that the return routability checks do not protect against flooding of third-parties if the attacker is on-path, as the attacker
Code change:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

Related discussion:
text: those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <del> 7. </del> <ins> 8. </ins> IANA is requested to allocate an entry to the TLS "ContentType" registry, for the "return_routability_check(TBD2)" defined in this
Code change:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

Related discussion:
text: "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext. <del> 8. </del> <ins> 9. </ins> Issues against this document are tracked at https://github.com/tlswg/ dtls-rrc/issues <del> 9. </del> <ins> 10. </ins> We would like to thank Achim Kraus, Hanno Becker, Hanno Boeck, Manuel Pegourie-Gonnard, Mohit Sahni and Rich Salz for their input to this
Code change:
I am OK with this change. There are no normative changes in there because the normative text segment is only moved to a different paragraph.
I was referring to this added clause: "alternately it MAY report PMTU estimates minus the estimated expansion from the transport layer and DTLS record framing."
What is awkward here is that this is phrased as normative requirements on an API. Maybe worded as advice "an application that uses DTLS might need information from DTLS to allow it to estimate the PMTU; DTLS could report a PMTU estimate less any DTLS overheads, or it can report those overheads and allow the application to perform its own estimation"
There has historically been API language here, so I think we should keep it and just adjust it as here.
This one probably needs consensus given new normative language.

Related discussion:
text: upper layer protocol MUST NOT write any record that exceeds the maximum record size of 2^14 bytes. <ins> The DTLS record layer SHOULD also allow the upper layer protocol to discover the amount of record expansion expected by the DTLS processing; alternately it MAY report PMTU estimates minus the estimated expansion from the transport layer and DTLS record framing. </ins> Note that DTLS does not defend against spoofed ICMP messages; implementations SHOULD ignore any such messages that indicate PMTUs below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively <del> The DTLS record layer SHOULD allow the upper layer protocol to discover the amount of record expansion expected by the DTLS processing. If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in Section 14 of RFC4340), then the DTLS record layer MUST inform the upper layer protocol of the error. </del> <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 Section 14 of RFC4340), then the DTLS record layer MUST inform the upper layer protocol of the error. </ins> The DTLS record layer SHOULD NOT interfere with upper layer protocols performing PMTU discovery, whether via RFC1191 or RFC4821 mechanisms.
Code change:
I am OK with this change. There are no normative changes in there because the normative text segment is only moved to a different paragraph.
I was referring to this added clause: "alternately it MAY report PMTU estimates minus the estimated expansion from the transport layer and DTLS record framing."
What is awkward here is that this is phrased as normative requirements on an API. Maybe worded as advice "an application that uses DTLS might need information from DTLS to allow it to estimate the PMTU; DTLS could report a PMTU estimate less any DTLS overheads, or it can report those overheads and allow the application to perform its own estimation"
There has historically been API language here, so I think we should keep it and just adjust it as here.
This one probably needs consensus given new normative language.

Related discussion:
text: DTLS implementations SHOULD follow the following rules: If the DTLS record layer informs the DTLS handshake layer that a <del> message is too big, it SHOULD immediately attempt to fragment it, using any existing information about the PMTU. </del> <ins> message is too big, the handshake layer SHOULD immediately attempt to fragment the message, using any existing information about the PMTU. </ins> If repeated retransmissions do not result in a response, and the PMTU is unknown, subsequent retransmissions SHOULD back off to a
Code change:
You don't want to age out before you get epoch 3 because otherwise you might be dropping when you have handshake packets.
For my understanding: what is the harm of keeping the 0-RTT keys around till the end of the handshake?
"Yes, the goal is to encourage people not to keep 0-RTT keys too long, because they might not have PCS. The replay risk is essentially a non-issue, except to the extent that it might already have been replayed."

Related discussion:
text: EndOfEarlyData is not necessary to determine when the early data is complete, and because DTLS is lossy, attackers can trivially mount the deletion attacks that EndOfEarlyData prevents in TLS.  Servers <del> SHOULD aggressively age out the epoch 1 keys upon receiving the first epoch 2 record and SHOULD NOT accept epoch 1 data after the first epoch 3 record is received.  (See dtls-epoch for the definitions of each epoch.) </del> <ins> SHOULD NOT accept records from epoch 1 indefinitely once they are able to process records from epoch 3.  Though reordering of IP packets can result in records from epoch 1 arriving after records from epoch 3, this is not likely to persist for very long relative to the round trip time.  Servers could discard epoch 1 keys after the first epoch 3 data arrives, or retain keys for processing epoch 1 data for a short period.  is received.  (See dtls-epoch for the definitions of each epoch.) </ins> 5.6.
Code change:
It's possible to negotiate the CID extension but that you want to receive an empty CID (this is how you get asymmetrical CID lengths). The current text says: CID. If an implementation receives these messages when CIDs were not negotiated, it MUST abort the connection with an unexpected_message alert. But does this mean that (for instance) you can negotiate receiving an empty CID and then switch to a non-empty? I am tempted to say "no" as I recall QUIC did.
Doing what QUIC did seems prudent ... and if I didn't know what QUIC did I think I would also lean towards disallowing switching between empty and non-empty on a live connection.

Related discussion:
text: provided.  Endpoints MUST NOT have more than one NewConnectionId message outstanding. <del> If the client and server have negotiated use of the "connection_id" extension, either side can request a new CID using the RequestConnectionId message.  In general, implementations SHOULD use a new CID whenever sending on a new path, and SHOULD request new CIDs for this purpose if path changes are anticipated. </del> <ins> Implementations which either did not negotiate the "connection_id" extension or which have negotiated receiving an empty CID MUST NOT send NewConnectionId.  Implementations MUST NOT send RequestConnectionId when sending an empty connection ID. Implementations which detect a violation of these rules MUST terminate the connection with an "unexpected_message" alert. Implementations SHOULD use a new CID whenever sending on a new path, and SHOULD request new CIDs for this purpose if path changes are anticipated. </ins> The number of CIDs desired.