jiebi/CodeConvo huggingface dataset:
Change:
== COMMENTS == -- Section 3 -- s/TLS cannot be used directly in datagram environments/TLS cannot be used directly over a datagram transport/ ? [Hannes] DTLS is also used over non-IP-based networks (e.g. LoRaWAN, NB IoT, Bluetooth Smart) and "datagram transport". What would be the right term to describe "environments" that include transport layer protocols like UDP as well as those non-IP-based networks? Bullet 2) s/to enable reassembly in the correct order/to enable reordering/ ? [Hannes] The complete sentence is: " The DTLS handshake includes message sequence numbers to enable reassembly in the correct order in case datagrams are lost or reordered. " I believe that saying sequence numbers enable reassembly in the correct order is correct. -- Section 3.1 -- Should there be a hint to a maximum retry count ? [Hannes] There will be a retry count in an implementation. Do we need to say that if we don't have a number to suggest? Not sure. -- Section 3.3 -- I understand the motivation (and no need to reply), but, sigh... implementing frag/reassembly above the transport layer... [Hannes] Seems to be common these days. Examples: CoAP, and QUIC
I don't think I found the PR to match up with the "pr-exists" label; could I get a pointer?
My bad. URL

Discussion:
utilizes DTLS for key establishment, and Secure Real-time Transport Protocol (SRTP) for protection of data RFC5763. <del> TLS cannot be used directly in datagram environments for the following five reasons: </del> <ins> TLS cannot be used directly over datagram transports the following five reasons: </ins> TLS relies on an implicit sequence number on records.  If a record is not received, then the recipient will use the wrong sequence

The TLS handshake is a lock-step cryptographic protocol.  Messages must be transmitted and received in a defined order; any other order is an error.  The DTLS handshake includes message sequence <del> numbers to enable reassembly in the correct order in case datagrams are lost or reordered. </del> <ins> numbers to enable fragmented message reassembly and in-order delivery in case datagrams are lost or reordered. </ins> During the handshake, messages are implicitly acknowledged by other handshake messages.  Some handshake messages, such as the
Change:
Zaheduzzaman Sarker wrote -> need to add text
I don't actually understand the ask here. Why would it matter?
I believe he wants us to note that when an invalid record is received and silently discarded then it does not impact timers in any way. It would be surprising if it did but do we want to add a sentence about that?
Since we have a dedicated section for "handling invalid records" that does allow for things other than silent discard, it makes sense to mention the lack of effect on timers. "[...] however, an error MAY be logged for diagnostic purposes. In no case does an invalid record affect pending retransmission timers."?
I'm not sure I agree, but I added something.

Discussion:
because an attacker will have difficulty forging a datagram that will not be rejected by the transport layer. <ins> Note that because invalid records are rejected at a layer lower than the handshake state machine, they do not affect pending retransmission timers. </ins> 4.5.3. Section 5.5 of TLS TLS13 defines limits on the number of records that
Change:
The middle two commits should be looked at individually. Optional-ACK can be used (as in Figure 12) to short-circuit the retransmit timer in addition to selective acknowledgment.
(Looks like I still don't understand the kramdown reference behavior.)

Discussion:
The following is an example of a handshake with lost packets and retransmissions.  Note that the client sends an empty ACK message <del> because it can only acknowledge Record 1 sent by the server once it </del> <ins> because it can only acknowledge Record 2 sent by the server once it </ins> has processed messages in Record 0 needed to establish epoch 2 keys, <del> which are needed to encrypt or decrypt messages found in Record 1. </del> <ins> which are needed to encrypt or decrypt messages found in Record 2. </ins> ack-msg provides the necessary background details for this interaction.  Note: for simplicity we are not re-setting record numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0,
Change:
The DTLS 1.2 Connection ID draft (soon-to-be-RFC9146) section on "peer address update" and the text in DTLS 1.3 seems quite different. URL The "unless they first perform some reachability test" seems preferable to the soft text in soon-to-be-RFC9146, but DTLS 1.3 seems to be missing the DTLS 1.2 requirement on "The received datagram is "newer"". Feels spontanously like DTLS 1.2 and 1.3 should have similar requirements/guidance on "peer address update". FYI, I started writing some analysis of Peer Address Update in a draft that I intend to submit to T2TRG URL
Would be good to warn implementations that clients must not update the permanent server address based on the “Peer Address Update” mechanism. Using IP addresses instead of DNS names is not uncommon in e.g., IoT, DNS over DTLS (RFC 8094), and 3GPP DTLS interfaces. An client updating the permanent server address based on an MITM attack could be unable to recover.Would be good with a sentence or two on the problems changing the IP address of a gateway multiplexing a lot of DTLS connections with Connection ID. All the client and servers would have to send at least one record before the old IP address can be deactivated. Might take some time in a IoT deployment.
I tend to think we should at most provide warnings about how it's dangerous. NAME would you be willing to provide a quick PR?
In the interest of being done I opted for basically punting it to a future spec.
URL

Discussion:
covered by the cookie exchange during the handshake.  DTLS implementations MUST NOT update the address they send to in response to packets from a different address unless they first perform some <del> reachability test; no such test is defined in this specification. Even with such a test, an active on-path adversary can also black- hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </del> <ins> reachability test; no such test is defined in this specification and a future specification would need to specify a complete procedure for how and when to update addresses.  Even with such a test, an active on-path adversary can also black-hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </ins> With the exception of order protection and non-replayability, the security guarantees for DTLS 1.3 are the same as TLS 1.3.  While TLS
Change:
I do understand that the text is consistent with the one in , but I think that it could benefit from some rework.

Discussion:
The DTLSCiphertext structure omits the superfluous version number field <del> DTLS adds an explicit epoch and sequence number in the record </del> <ins> DTLS adds an explicit epoch and sequence numbers in the record </ins> header.  This sequence number allows the recipient to correctly verify the DTLS MAC.

4.4.1. <del> DTLS records contain 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 of RFC4303. </del> <ins> 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 of RFC4303. </ins> <del> The receiver packet counter for this session MUST be initialized to zero when the session is established.  For each received record, the </del> <ins> The received packet counter for a session MUST be initialized to zero when that session is established.  For each received record, the </ins> receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received <del> during the life of this session.  This SHOULD be the first check </del> <ins> during the lifetime of the session.  This SHOULD be the first check </ins> applied to a packet after it has been matched to a session, to speed <del> rejection of duplicate records. </del> <ins> up the rejection of duplicate records. </ins> Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following

size.) The "right" edge of the window represents the highest validated <del> sequence number value received on this session.  Records that contain </del> <ins> sequence number value received on the session.  Records that contain </ins> sequence numbers lower than the "left" edge of the window are rejected.  Packets falling within the window are checked against a list of received packets within the window.  An efficient means for
Change:
"Transcript-Hash" is the name of the function. I belive it would be more appropriate to use the "transcript hash" term here.

Discussion:
If the HelloRetryRequest message is used, the initial ClientHello and the HelloRetryRequest are included in the calculation of the <del> Transcript-Hash.  The computation of the message hash for the </del> <ins> transcript hash.  The computation of the message hash for the </ins> HelloRetryRequest is done according to the description in Section 4.4.1 of I-D.ietf-tls-tls13.
Change:
This pull request aims to address the open issues regarding sequence number encryption. The approach chosen follows the design used in QUIC.

Discussion:
epoch and sequence number fields in the DTLSCiphertext structure have been reduced. <del> The DTLSCiphertext structure is a variable length header. </del> <ins> The DTLSCiphertext structure has a variable length header. </ins> Note that the DTLS 1.3 record layer is different from the DTLS 1.2 record layer.

Identical to the encrypted_record field in a TLS 1.3 record. <del> 14 bit sequence number field. </del> <ins> The DTLSCiphertext header is tightly bit-packed, as shown below: The low order two bits of the epoch. The low order 14 bits of the record sequence number. </ins> Identical to the length field in a TLS 1.3 record.

(though they MUST be ACKed as usual). Endpoints MUST NOT send either of these messages if they did not <del> negotiate a connection ID. 10. Application data messages are carried by the record layer and are fragmented and encrypted based on the current connection state.  The messages are treated as transparent data to the record layer. </del> <ins> negotiate a connection ID.  If an implementation receives these messages when connection IDs were not negotiated, it MUST abort the connection with an unexpected_message alert. </ins> <del> 11. </del> <ins> 9.1. </ins> Below is an example exchange for DTLS 1.3 using a single connection id in each direction.

Note: The connection_id extension is defined in I-D.ietf-tls-dtls- connection-id, which is used in ClientHello and ServerHello messages. <del> 12. </del> <ins> 10. Application data messages are carried by the record layer and are fragmented and encrypted based on the current connection state.  The messages are treated as transparent data to the record layer. 11. </ins> Security issues are discussed primarily in I-D.ietf-tls-tls13.

DTLS client, such as the client certificate, less information is available to an on-path adversary. <del> 13. </del> <ins> 12. </ins> Since TLS 1.3 introduces a large number of changes to TLS 1.2, the list of changes from DTLS 1.2 to DTLS 1.3 is equally large.  For this

Sequence numbers are encrypted. <del> 14. </del> <ins> 13. </ins> IANA is requested to allocate a new value in the "TLS ContentType" registry for the ACK message, defined in ack-msg, with content type
Change:
I split and reordered the paragragh to maintain the integrity of the "aside from these exceptions, this is TLS 1.3".

Discussion:
transport like TCP that performs return-routability checks as part of the connection establishment. <ins> DTLS implementations do not use the TLS 1.3 "compatibility mode" described in I-D.ietf-tls-tls13, Section D.4.  DTLS servers MUST NOT echo the "session_id" value from the client and endpoints MUST NOT send ChangeCipherSpec messages.  Note however that implementations MUST ignore ChangeCipherSpec messages received in unprotected records. </ins> With these exceptions, the DTLS message formats, flows, and logic are <del> the same as those of TLS 1.3.  DTLS implementations SHOULD not use the TLS 1.3 "compatibility mode" described in I-D.ietf-tls-tls13, Section D.4 and DTLS servers SHOULD ignore the "session_id" value generated by the client rather than sending ChangeCipherSpec messages.  Implementations MUST still ignore ChangeCipherSpec messages received during the handshake and at all other times SHOULD treat them as if they had failed to deprotect. </del> <ins> the same as those of TLS 1.3. </ins> 5.1.
Change:
As I understand, the intent with the record header in AD business was so that DTLS 1.3 would inherit putting the entire header into the AD. However, TLS 1.3 defines the AD as: and DTLS 1.3 defines encryptedrecord as: If one takes the first half of the clause, it works out, but "record header" isn't defined formally. If one takes the second half, it suggests that is not in the AD and it's not clear how 's AD is defined at all. Probably worth clarifying this.

Discussion:
[sender]_application_traffic_secret for message protection, Implementations MAY include the length field at their discretion. <ins> The entire header value shown above is used as it appears on the wire as the additional data value for the AEAD function. </ins> 4.1. Implementations can distinguish the two header formats by examining
Change:
NAME
s'OK wi' me. The other thing to consider mentioning is that record shadowing (key compromise at epoch N allowing the attacker to send records that cause records at epoch >N to be dropped) isn't a concern because dropping records in DTLS is trivial.
NAME thoughts?

Discussion:
5.5. <ins> The DTLS 1.3 handshake has one important difference from the TLS 1.3 handshake: the EndOfEarlyData message is omitted both from the wire and the handshake transcript: because DTLS records have epochs, 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 SHOULD aggressively age out the epoch 1 keys upon receiving the first epoch 1 record and SHOULD NOT accept epoch 1 data after the first epoch 3 record is received. 5.6. </ins> DTLS messages are grouped into a series of message flights, according to the diagrams below. Note: The application data sent by the client is not included in the timeout and retransmission calculation. <del> 5.6. </del> <ins> 5.7. </ins> <del> 5.6.1. </del> <ins> 5.7.1. </ins> DTLS uses a simple timeout and retransmission scheme with the state machine shown in dtls-timeout-state-machine.  Because DTLS clients

evidence of reordering or packet loss and retransmit their final flight immediately, shortcutting the retransmission timer. <del> 5.6.2. </del> <ins> 5.7.2. </ins> Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems; for example, if

timer to the initial value.  One situation where this might occur is when a rehandshake is used after substantial data transfer. <del> 5.7. </del> <ins> 5.8. </ins> CertificateVerify and Finished messages have the same format as in TLS 1.3.  Hash calculations include entire handshake messages,

been sent as a single fragment following the algorithm described in Section 4.4.3 and Section 4.4.4 of TLS13, respectively. <del> 5.8. </del> <ins> 5.9. </ins> Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake.  However, a DTLS implementation

a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected. <del> 5.9. </del> <ins> 5.10. </ins> If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is
Change:
Suggested pull request related to issue
The Abstract states that: "The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees." This is not true when it comes to Order protection/non-replayability which is states as a guarantee in Appendix E.2 of RFC 8446. DTLS does not provide order protection and may not provide replay protection. I suggested this statement "equivalent security guarantees" is deleted (or rewritten) in the abstract and that some short text describing this is added to the Security Considerations.
Fixed.

Discussion:
The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security <del> guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol. </del> <ins> guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. </ins> 1.

not a threat in their environment.  Clients MUST be prepared to do a cookie exchange with every handshake. <ins> With the exception of order protection and non-replayability, the security guarantees for DTLS 1.3 are the same as TLS 1.3.  While TLS always provides order protection and non-replayability, DTLS does not provide order protection and may not provide replay protection. </ins> Unlike TLS implementations, DTLS implementations SHOULD NOT respond to invalid records by terminating the connection.
Change:
I added this remark following my implementation experience of DTLS 1.2 CID followed by the work on the DTLS 1.3. We noticed this issue at the Prague IETF meeting (March 2019).

Discussion:
Implementations MAY include the length field at their discretion. The entire header value shown above is used as it appears on the wire <del> as the additional data value for the AEAD function. </del> <ins> as the additional data value for the AEAD function.  Note that this design is different to the additional data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. </ins> 4.1.
Change:
Deleted the following statement: "Until the handshake has completed, implementations MUST accept packets from the old epoch." because it appears to be redundant. Martin raised this issue in URL
I think that this is a vestige of renegotiation and can be removed. But we might want to say something more helpful about accepting 0-RTT and Handshake at the same time.
I think we should delete this sentence because it is redundant. We have already text in the same section saying the following: " Because DTLS records could be reordered, a record from epoch 1 may be received after epoch 2 has begun. In general, implementations SHOULD discard packets from earlier epochs, but if packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP to allow for packet reordering. " NAME If you think there is someone else that should be said, we are happy to add it. Here is the PR: URL
Fixed.

Discussion:
TCP RFC0793 to allow for packet reordering.  (Note that the intention here is that implementers use the current guidance from the IETF for MSL, as specified in RFC0793 or successors not that they attempt to <del> interrogate the MSL that the system TCP stack is using.)  Until the handshake has completed, implementations MUST accept packets from the old epoch. </del> <ins> interrogate the MSL that the system TCP stack is using.) </ins> Conversely, it is possible for records that are protected with the new epoch to be received prior to the completion of a handshake.  For
Change:
omit the trailing space because TLS 1.3 went right up to the limit.
No, no, DTLS also uses HKDR for Key Separation++
Hearing no objections, we're merging this change. I'll fix the HKDR->HKDF typo in a followup PR.
This is perfectly fine. Thanks for making the edit.

Discussion:
5.9. <ins> Section 7.1 of RFC8446 specifies that HKDR-Expand-Label uses a label prefix of "tls13 ".  For DTLS 1.3, that label SHALL be "dtls13". This ensures key separation between DTLS 1.3 and TLS 1.3.  Note that there is no trailing space; this is necessary in order to keep the overall label size inside of one hash iteration because "DTLS" is one letter longer than "TLS". 5.10. </ins> Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake.  However, a DTLS implementation which would ordinarily issue an alert SHOULD generate a new alert

a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected. <del> 5.10. </del> <ins> 5.11. </ins> If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is
Change:
Karl: Why is this "e.g." inserted in section 5? "generate temporary keys as specified in e.g., [RFC7748]" It sounds non-deterministic. If using RFC7748 is an option that can be negotiated or need to be pre-established, then maybe we could write something like: "according to the negotiated ciphersuite, e.g. [7748]." If the sentence is more describing a general way of how one would go about designing FS here, then perhaps something like: "To provide FS, a key exchange must run in an ephemeral manner...".
I think you are right. The text is a bit sloppy (but I don’t think it has changed in a while). I like your first formulation. Once you know the ciphersuite this is all specified & determined.
Will make a PR
Solution merged to the base.

Discussion:
Forward Secrecy for EAP-AKA' is achieved by using an Elliptic Curve Diffie-Hellman (ECDH) exchange RFC7748.  To provide FS, the exchange must be run in an ephemeral manner, i.e., both sides generate <del> temporary keys as specified in e.g., RFC7748.  This method is referred to as ECDHE, where the last 'E' stands for Ephemeral.  The two initially registered elliptic curves and their wire format is chosen to align with the elliptic curves and formats specified for </del> <ins> temporary keys according to the negotiated ciphersuite, e.g., for X25519 this is done as specified in RFC7748.  This method is referred to as ECDHE, where the last 'E' stands for Ephemeral.  The two initially registered elliptic curves and their wire format is chosen to align with the elliptic curves and formats specified for </ins> Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 of 3GPP TS 33.501 TS.33.501.