jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-dtls13

Commentary:  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 " 
 can you take these ? 
 PRs for the example updates are 
 Fixed
Paragraph (version A):
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
sent the server will continue retransmission of the NewSessionTicket
indefinitely until its transmission cap is reached.
Paragraph (version B):
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 4 (containing the NewSessionTicket message) and if it is not
sent the server will continue retransmission of the NewSessionTicket
indefinitely until its transmission cap is reached.
Draft: draft-ietf-tls-dtls13

Commentary: Based on review from  : 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 " 
 can you take these ? 
 PRs for the example updates are 
 Fixed
Paragraph (version A):
The following is an example of a handshake with lost packets and
retransmissions.
Paragraph (version B):
The following is an example of a handshake with lost packets and
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.
Draft: draft-ietf-tls-dtls13

Commentary: 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 " 
 can you take these ? 
 PRs for the example updates are 
 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 do n't have any better ideas , so we should probably roll with it ! )
Paragraph (version A):
DTLS messages are grouped into a series of message flights, according
to the diagrams below.
Paragraph (version A):
Note: The application data sent by the client is not included in the
timeout and retransmission calculation.
Paragraph (version B):
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.
Paragraph (version B):
The HelloRetryRequest shown in (1) is an optional message sent by
the server.
Paragraph (version B):
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.
Paragraph (version B):
Below are several example message exchange illustrating the flight
concept.
Draft: draft-ietf-tls-dtls13

Commentary: The proposed text sounds reasonable to me .
Paragraph (version A):
If the client and server have negotiated the "connection_id"
extension, either side can request a new CID using the
RequestConnectionId message.
Paragraph (version B):
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.
Draft: draft-ietf-tls-dtls13

Commentary: I am fine with the editorial improvements provided by  . Thanks ,  !
Paragraph (version A):
With multi-homing, an adversary is able to correlate the
communication interaction over the two paths, which adds further
privacy concerns.  In order to prevent this, implementations
SHOULD attempt to use fresh CIDs whenever they change local
addresses or ports (though this is not always possible to detect).
The RequestConnectionId message can be used by a peer to ask for
new CIDs to ensure that a pool of suitable CIDs is available.
Paragraph (version A):
Switching CID based on certain events, or even regularly, helps
against tracking by on-path adversaries but the sequence numbers
can still allow linkability.  For this reason this specification
defines an algorithm for encrypting sequence numbers, see rne.
Note that sequence number encryption is used for all encrypted
DTLS 1.3 records irrespective of whether a CID is used or not.
Unlike the sequence number, the epoch is not encrypted.  This may
improve correlation of packets from a single connection across
different network paths.
Paragraph (version B):
The ability to use multiple CIDs allows for improved privacy
properties in multi-homed scenarios.  When only a single CID is in
use on multiple paths from such a host, an adversary can correlate
the communication interaction across paths, which adds further
privacy concerns.  In order to prevent this, implementations
SHOULD attempt to use fresh CIDs whenever they change local
addresses or ports (though this is not always possible to detect).
The RequestConnectionId message can be used by a peer to ask for
new CIDs to ensure that a pool of suitable CIDs is available.
Paragraph (version B):
The mechanism for encrypting sequence numbers (rne) prevents
trivial tracking by on-path adversaries that attempt to correlate
the pattern of sequence numbers received on different paths; such
tracking could occur even when different CIDs are used on each
path, in the absence of sequence number encryption.  Switching
CIDs based on certain events, or even regularly, helps against
tracking by on-path adversaries.  Note that sequence number
encryption is used for all encrypted DTLS 1.3 records irrespective
of whether a CID is used or not.  Unlike the sequence number, the
epoch is not encrypted because it acts as a key identifier, which
may improve correlation of packets from a single connection across
different network paths.
Draft: draft-ietf-tls-dtls13

Commentary: This one needs consensus , but should certainly be non - controversial .
Paragraph (version A):
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
message if the offending record is received again (e.g., as a
retransmitted handshake message).  Implementations SHOULD detect when
a peer is persistently sending bad messages and terminate the local
connection state after such misbehavior is detected.
Paragraph (version B):
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
message if the offending record is received again (e.g., as a
retransmitted handshake message).  Implementations SHOULD detect when
a peer is persistently sending bad messages and terminate the local
connection state after such misbehavior is detected.  Note that
alerts are not reliably transmitted; implementation SHOULD NOT depend
on receiving alerts in order to signal errors or connection closure.
Draft: draft-ietf-tls-dtls13

Commentary: Fix a deadlock identified by 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 I d 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  " ? 
 Done .
Paragraph (version A):
Endpoints SHOULD respond to RequestConnectionId by sending a
NewConnectionId with usage "cid_spare" containing num_cid CIDs soon
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
ignore requests, which it considers excessive (though they MUST be
acknowledged as usual).
Paragraph (version B):
Endpoints SHOULD respond to RequestConnectionId by sending a
NewConnectionId with usage "cid_spare" containing num_cid CIDs soon
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
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.
Paragraph (version B):
IANA is requested to allocate "the too_many_cids_requested" alert in
the "TLS Alerts" registry with value 52.
Draft: draft-ietf-tls-dtls13

Commentary: 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 .
Paragraph (version A):
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.
Paragraph (version B):
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.
Draft: draft-ietf-tls-dtls13

Commentary: 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 .
Paragraph (version A):
Using these reserved epoch values a receiver knows what cipher state
has been used to encrypt and integrity protect a message.
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.
Paragraph (version B):
Using these reserved epoch values a receiver knows what cipher state
has been used to encrypt and integrity protect a message.
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.
Draft: draft-ietf-tls-dtls13

Commentary: Do n't require always buffering and require that retransmission be identical .
Paragraph (version A):
When a DTLS implementation receives a handshake message fragment, it
MUST buffer it until it has the entire handshake message.  DTLS
implementations MUST be able to handle overlapping fragment ranges.
This allows senders to retransmit handshake messages with smaller
fragment sizes if the PMTU estimate changes.
Paragraph (version B):
When a DTLS implementation receives a handshake message fragment
corresponding to the next expected handshake message sequence number,
it MUST buffer it until it has the entire handshake message.  DTLS
implementations MUST be able to handle overlapping fragment ranges.
This allows senders to retransmit handshake messages with smaller
fragment sizes if the PMTU estimate changes.  Senders MUST NOT change
handshake message bytes upon retransmission.  Receivers MAY check
that retransmitted bytes are identical and SHOULD abort the handshake
with an "illegal_parameter" alert if the value of a byte changes.
Draft: draft-ietf-tls-dtls13

Commentary: 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 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 .
Paragraph (version A):
The DTLS record layer SHOULD allow the upper layer protocol to
discover the amount of record expansion expected by the DTLS
processing.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
If the DTLS record layer informs the DTLS handshake layer that a
message is too big, it SHOULD immediately attempt to fragment it,
using any existing information about the PMTU.
Paragraph (version B):
If the DTLS record layer informs the DTLS handshake layer that a
message is too big, the handshake layer SHOULD immediately attempt
to fragment the message, using any existing information about the
PMTU.
Draft: draft-ietf-tls-dtls13

Commentary: I guess not . Ugh .
Paragraph (version B):
Future cipher suites which are not based on AES or ChaCha20 MUST
define their own record sequence number encryption in order to be
used with DTLS.
Draft: draft-ietf-tls-dtls13

Commentary: Thanks to feedback from   .
Paragraph (version A):
Identical to the encrypted_record field in a TLS 1.3 record.
Paragraph (version B):
The AEAD-encrypted form of the serialized DTLSInnerPlaintext
structure.
Draft: draft-ietf-tls-dtls13

Commentary: 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 does n'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 do n't think that this needs to be fixed , but it should be noted in the security considerations .
Paragraph (version A):
Switching CID based on certain events, or even regularly, helps
against tracking by on-path adversaries but the sequence numbers
can still allow linkability.  For this reason this specification
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.
Paragraph (version B):
Switching CID based on certain events, or even regularly, helps
against tracking by on-path adversaries but the sequence numbers
can still allow linkability.  For this reason this specification
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.
Unlike the sequence number, the epoch is not encrypted.  This may
improve correlation of packets from a single connection across
different network paths.
Draft: draft-ietf-tls-dtls13

Commentary: This is editorial , so I 'm merging as is .
Paragraph (version A):
one.
Paragraph (version B):
one.  In general, implementations SHOULD ACK as many received packets
as can fit into the ACK record, as this provides the most complete
information and thus reduces the chance of spurious retransmission;
if space is limited, implementations SHOULD favor including records
which have not yet been acknowledged.
Paragraph (version A):
When an implementation receives an ACK, it SHOULD record that the
messages or message fragments sent in the records being ACKed were
received and omit them from any future retransmissions.  Upon receipt
of an ACK for only some messages from a flight, an implementation
SHOULD retransmit the remaining messages or fragments.  Note that
this requires implementations to track which messages appear in which
records.  Once all the messages in a flight have been acknowledged,
the implementation MUST cancel all retransmissions of that flight.
As noted above, the receipt of any record responding to a given
flight MUST be taken as an implicit acknowledgement for the entire
flight.
Paragraph (version B):
When an implementation receives an ACK, it SHOULD record that the
messages or message fragments sent in the records being ACKed were
received and omit them from any future retransmissions.  Upon receipt
of an ACK that leaves it with only some messages from a flight having
been acknowledged an implementation SHOULD retransmit the
unacknowledged messages or fragments.  Note that this requires
implementations to track which messages appear in which records.
Once all the messages in a flight have been acknowledged, the
implementation MUST cancel all retransmissions of that flight.
Implementations MUST treat a record as having been acknowledged if it
appears in any ACK; this prevents spurious retransmission in cases
where a flight is very large and the receiver is forced to elide
acknowledgements for records which have already been ACKed.  As noted
above, the receipt of any record responding to a given flight MUST be
taken as an implicit acknowledgement for the entire flight.
Draft: draft-ietf-tls-dtls13

Commentary: As proposed on list . 
   points out that the current text does not cryptographically protect the CID when we have coalesced packets . I created PR to add this feature , but I think instead we should simply require that all packets have CIDs once the CID is established . This seems like a net reduction in complexity . There would be two changes here : -emphasize the point already in the DTLS CID spec that you abort if a CID is expected and none is found . the text about allowing implicit CIDs . 
 This was resolved by . Please re - open if that 's not the case !
Paragraph (version A):
Implementations which send multiple records in the same datagram
SHOULD omit the connection id from all but the first record;
receiving implementations MUST assume that any subsequent records
without connection IDs belong to the same association.  Sending
implementations MUST NOT mix records from multiple DTLS associations
in the same datagram.  If the second or later record has a connection
ID which does not correspond to the same association used for
previous records, the rest of the datagram MUST be discarded.
Paragraph (version B):
If a connection ID is negotiated, then it MUST be contained in all
datagrams.  Sending implementations MUST NOT mix records from
multiple DTLS associations in the same datagram.  If the second or
later record has a connection ID which does not correspond to the
same association used for previous records, the rest of the datagram
MUST be discarded.