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

Discussion:
Corresponds to the fragment of a given length. <del> The content type describing the payload. </del> <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
Change:
Signed-off-by: Thomas Fossati
A better name could be or -- one doesn't "delete" a path.
I agree. I prefer path_drop

Discussion:
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> <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 <del> "path_delete" MUST be returned.  In either case, the peer </del> <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. <del> When a "return_routability_check" message of type "path_delete" </del> <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" <del> or "path_delete" messages. </del> <ins> or "path_drop" messages. </ins> <del> The responder MUST send exactly one "path_response" or "path_delete" message for each received "path_challenge". </del> <ins> The responder MUST send exactly one "path_response" or "path_drop" message for each received "path_challenge". </ins> <del> The responder MUST send the "path_response" or the "path_delete" on the path where the corresponding "path_challenge" has been </del> <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.
Change:
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."

Discussion:
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. <del> path-challenge-reqs and path-response-reqs contain the requirements for the initiator and responder roles, broken down per protocol phase. </del> <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. <del> path-challenge-reqs and path-response-reqs contain the requirements for the initiator and responder roles, broken down per protocol phase. </del> <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.
Change:
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."_

Discussion:
functional in both directions.  The initiator MUST NOT enforce this behaviour. <del> The initiator MUST silently discard any invalid "path_response" it receives. </del> <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
Change:
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.

Discussion:
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> <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
Change:
Updated draft based on feedback from the working group. The following changes have been made: Usage of the TLS flags extension Enhanced IANA consideration section Expanded example section
added a few inline suggestions

Discussion:
3. <ins> This specification uses the tls_flags extension defined in I-D.-ietf- tls-tlsflags to allow a client and a server to negotiate support for this extension. The RRC flag is assigned the value (TBD1) and is used in the ClientHello (CH) and the ServerHello (SH). 4. </ins> When a record with CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID, the receiver MUST NOT update its view of the peer's IP

After this point, any pending send operation is resumed to the bound peer address. <del> 4. </del> <ins> 5. </ins> <del> The example shown in fig-rrc-example illustrates a client and a server exchanging application payloads protected by DTLS with an unilaterally used CIDs.  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 his new IP address, to avoid being abused (e.g., as an amplifier) by an attacker impersonating the client. </del> <ins> 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 extension. </ins> <del> 5. </del> <ins> Once a connection has been established the client and the server exchange application payloads protected by DTLS with an unilaterally used CIDs.  In our case, the client is requested to use CID 100 for 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 his new IP address. 6. </ins> Note that the return routability checks do not protect against flooding of third-parties if the attacker is on-path, as the attacker

those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <del> 6. </del> <ins> 7. </ins> <del> IANA is requested to allocate an entry to the existing TLS "ContentType" registry, for the return_routability_check(TBD) defined in this document. </del> <ins> IANA is requested to allocate an entry to the TLS "ContentType" registry, for the return_routability_check(TBD) defined in this document. </ins> <del> 7. </del> <ins> IANA is requested to allocate an entry to the TLS Flags registry in the tls_flags type: Value: [[IANA please assign a value from the 32-63 value range.]] Flag Name: RRC Message: CH,SH Recommended: Y Reference: [[This document]] 8. </ins> Issues against this document are tracked at https://github.com/tlswg/ dtls-rrc/issues <del> 8. </del> <ins> 9. </ins> We would like to thank Achim Kraus, Hanno Becker and Manuel Pegourie- Gonnard for their input to this document.
Change:
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.

Discussion:
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> <ins> described in path-validation, unless an application layer specific address validation mechanism can be triggered instead. </ins> 6.
Change:
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.

Discussion:
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> <ins> to parse and ignore messages with an unknown "msg_type". </ins> 5.
Change:
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.

Discussion:
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> <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.
Change:
Signed-off-by: Thomas Fossati
Also, remove NAME who's now a co-author.

Discussion:
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> <ins> We would like to thank Hanno Becker, , , Mohit Sahni and Rich Salz for their input to this document. </ins>
Change:
/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".

Discussion:
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> <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 <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> <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 <del> his new IP address. </del> <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.
Change:
Add references to RFC 768: UDP RFC 4347: DTLS 1.0 RFC 4346: TLS 1.1 RFC 6347: DTLS 1.2 RFC 5246: TLS 1.2 in the Introduction section. Currently they are mentioned but with no citations.

Discussion:
Protocol.  However, TLS must run over a reliable transport channel - typically TCP RFC0793. <del> There are applications that utilize UDP as a transport and to offer communication security protection for those applications the Datagram Transport Layer Security (DTLS) protocol has been designed.  DTLS is deliberately designed to be as similar to TLS as possible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse. DTLS 1.0 was originally defined as a delta from TLS 1.1 and DTLS 1.2 was defined as a series of deltas to TLS 1.2.  There is no DTLS 1.1; that version number was skipped in order to harmonize version numbers with TLS.  This specification describes the most current version of the DTLS protocol aligning with the efforts around TLS 1.3. </del> <ins> There are applications that utilize UDP RFC0768 as a transport and to offer communication security protection for those applications the Datagram Transport Layer Security (DTLS) protocol has been designed. DTLS is deliberately designed to be as similar to TLS as possible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse. DTLS 1.0 RFC4347 was originally defined as a delta from TLS 1.1 RFC4346 and DTLS 1.2 RFC6347 was defined as a series of deltas to TLS 1.2 RFC5246.  There is no DTLS 1.1; that version number was skipped in order to harmonize version numbers with TLS.  This specification describes the most current version of the DTLS protocol aligning with the efforts around TLS 1.3 I-D.ietf-tls-tls13. </ins> Implementations that speak both DTLS 1.2 and DTLS 1.3 can interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of

The following terms are used: <del> client: The endpoint initiating the TLS connection. </del> <ins> client: The endpoint initiating the DTLS connection. </ins> connection: A transport-layer connection between two endpoints.

session: An association between a client and a server resulting from a handshake. <del> server: The endpoint which did not initiate the TLS connection. </del> <ins> server: The endpoint which did not initiate the DTLS connection. </ins> The reader is assumed to be familiar with the TLS 1.3 specification since this document defined as a delta from TLS 1.3.

8. <del> Since TLS 1.3 introduce a large number of changes to TLS 1.2, the </del> <ins> Since TLS 1.3 introduces a large number of changes to TLS 1.2, the </ins> list of changes from DTLS 1.2 to DTLS 1.3 is equally large.  For this reason this section focuses on the most important changes only.
Change:
DTLS recommends using 25 as the ACK Content Type. CID is using that number based on an early IANA assignment will change DTLS.

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

Discussion:
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> <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:
Change:
I-D.ietf-tls-dtls-connection-id became a normative reference Removed duplicate reference to I-D.ietf-tls-dtls-connection-id.

Discussion:
The two low bits (0x03) include the low order two bits of the epoch. <del> Variable length CID.  The CID concept is described in DTLS-CID. An example can be found in connection-id-example. </del> <ins> Variable length CID.  The CID concept is described in I-D.ietf- tls-dtls-connection-id.  An example can be found in connection-id- example. </ins> The low order 8 or 16 bits of the record sequence number.  This value is 16 bits if the S bit is set to 1, and 8 bits if the S bit

association identifiers and applications must arrange to multiplex between associations.  With UDP, the host/port number is used to look up the appropriate security association for incoming records. <del> However, the CID extension defined in DTLS-CID adds an association identifier to DTLS records. </del> <ins> However, the CID extension defined in I-D.ietf-tls-dtls-connection-id adds an association identifier to DTLS records. </ins> Some transports, such as DCCP RFC4340, provide their own sequence numbers.  When carried over those transports, both the DTLS and the

9. If the client and server have negotiated the "connection_id" <del> extension DTLS-CID, either side can send a new CID which it wishes the other side to use in a NewConnectionId message. </del> <ins> extension I-D.ietf-tls-dtls-connection-id, either side can send a new CID which it wishes the other side to use in a NewConnectionId message. </ins> %%% Connection ID Management enum { cid_immediate(0), cid_spare(1), (255) } ConnectionIdUsage;

Below is an example exchange for DTLS 1.3 using a single CID in each direction. <del> Note: The connection_id extension is defined in DTLS-CID, which is used in ClientHello and ServerHello messages. </del> <ins> Note: The connection_id extension is defined in I-D.ietf-tls-dtls- connection-id, which is used in ClientHello and ServerHello messages. </ins> If no CID is negotiated, then the receiver MUST reject any records it receives that contain a CID.

concerned about this form of attack can discard out-of-epoch records. The security and privacy properties of the CID for DTLS 1.3 builds on <del> top of what is described in DTLS-CID.  There are, however, several improvements: </del> <ins> top of what is described in I-D.ietf-tls-dtls-connection-id.  There are, however, several improvements: </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 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.

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

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