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

Commentary: This pull request aims to address the open issues regarding sequence number encryption . The approach chosen follows the design used in QUIC .
Paragraph (version A):
The DTLSCiphertext structure is a variable length header.
Paragraph (version B):
The DTLSCiphertext structure has a variable length header.
Paragraph (version A):
14 bit sequence number field.
Paragraph (version B):
The low order two bits of the epoch.
Paragraph (version B):
The low order 14 bits of the record sequence number.
Paragraph (version A):
Endpoints MUST NOT send either of these messages if they did not
negotiate a connection ID.
Paragraph (version B):
Endpoints MUST NOT send either of these messages if they did not
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.
Draft: draft-ietf-tls-dtls13

Commentary: " Transcript - Hash " is the name of the function . I belive it would be more appropriate to use the " transcript hash " term here .
Paragraph (version A):
If the HelloRetryRequest message is used, the initial ClientHello and
the HelloRetryRequest are included in the calculation of the
Transcript-Hash.  The computation of the message hash for the
HelloRetryRequest is done according to the description in
Section 4.4.1 of I-D.ietf-tls-tls13.
Paragraph (version B):
If the HelloRetryRequest message is used, the initial ClientHello and
the HelloRetryRequest are included in the calculation of the
transcript hash.  The computation of the message hash for the
HelloRetryRequest is done according to the description in
Section 4.4.1 of I-D.ietf-tls-tls13.
Draft: draft-ietf-tls-dtls13

Commentary: A collection of nits I noted while reviewing the draft .
Paragraph (version A):
DTLSShortCiphertext MUST only be used for data which is protected
with one of the application_traffic_secret values, and not for
messages protected with either [sender]_handshake_sercret or
[sender]_early_traffic_secret values.  When using an
[sender]_application_traffic_secret for message protection,
Implementations MAY use either DTLSCiphertext or DTLSShortCiphertext
at their discretion.
Paragraph (version B):
DTLSShortCiphertext MUST only be used for data which is protected
with one of the application_traffic_secret values, and not for
messages protected with either [sender]_handshake_traffic_sercret or
[sender]_early_traffic_secret values.  When using an
[sender]_application_traffic_secret for message protection,
Implementations MAY use either DTLSCiphertext or DTLSShortCiphertext
at their discretion.
Draft: draft-ietf-tls-dtls13

Commentary: Avoid GEN - ART comment .
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 RFC2119.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Draft: draft-ietf-tls-dtls13

Commentary: Avoid I - D nit .
Paragraph (version A):
One potential attack on this scheme is for the attacker to collect a
number of cookies from different addresses where it controls
endpoints and then reuse them to attack the server.  The server can
defend against this attack by changing the secret value frequently,
thus invalidating those cookies.  If the server wishes that
legitimate clients be able to handshake through the transition (e.g.,
they received a cookie with Secret 1 and then sent the second
ClientHello after the server has changed to Secret 2), the server can
have a limited window during which it accepts both secrets.  RFC5996
suggests adding a key identifier to cookies to detect this case.  An
alternative approach is simply to try verifying with both secrets.
It is RECOMMENDED that servers implement a key rotation scheme that
allows the server to manage keys with overlapping lifetime.
Paragraph (version B):
One potential attack on this scheme is for the attacker to collect a
number of cookies from different addresses where it controls
endpoints and then reuse them to attack the server.  The server can
defend against this attack by changing the secret value frequently,
thus invalidating those cookies.  If the server wishes that
legitimate clients be able to handshake through the transition (e.g.,
they received a cookie with Secret 1 and then sent the second
ClientHello after the server has changed to Secret 2), the server can
have a limited window during which it accepts both secrets.  RFC7296
suggests adding a key identifier to cookies to detect this case.  An
alternative approach is simply to try verifying with both secrets.
It is RECOMMENDED that servers implement a key rotation scheme that
allows the server to manage keys with overlapping lifetime.
Draft: draft-ietf-tls-dtls13

Commentary: I do understand that the text is consistent with the one in , but I think that it could benefit from some rework .
Paragraph (version A):
DTLS adds an explicit epoch and sequence number in the record
header.  This sequence number allows the recipient to correctly
verify the DTLS MAC.
Paragraph (version B):
DTLS adds an explicit epoch and sequence numbers in the record
header.  This sequence number allows the recipient to correctly
verify the DTLS MAC.
Paragraph (version A):
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.
Paragraph (version A):
The receiver packet counter for this session MUST be initialized to
zero when the session is established.  For each received record, the
receiver MUST verify that the record contains a sequence number that
does not duplicate the sequence number of any other record received
during the life of this session.  This SHOULD be the first check
applied to a packet after it has been matched to a session, to speed
rejection of duplicate records.
Paragraph (version B):
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.
Paragraph (version B):
The received packet counter for a session MUST be initialized to zero
when that session is established.  For each received record, the
receiver MUST verify that the record contains a sequence number that
does not duplicate the sequence number of any other record received
during the lifetime of the session.  This SHOULD be the first check
applied to a packet after it has been matched to a session, to speed
up the rejection of duplicate records.
Paragraph (version A):
The "right" edge of the window represents the highest validated
sequence number value received on this session.  Records that contain
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
performing this check, based on the use of a bit mask, is described
in Section 3.4.3 of RFC4303.
Paragraph (version B):
The "right" edge of the window represents the highest validated
sequence number value received on the session.  Records that contain
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
performing this check, based on the use of a bit mask, is described
in Section 3.4.3 of RFC4303.
Draft: draft-ietf-tls-dtls13

Commentary: Right now , my NSS patch for compatibility mode in TLS also includes changes to DTLS . Those changes include the ServerHello format changes , but NSS will ignore the session_id and never send a ChangeCipherSpec from either client or server . 
 Note that we probably still want to ignore CCS in DTLS - DTLS discards things that it does n't want to see - this is about generating CCS .
Paragraph (version A):
With these exceptions, the DTLS message formats, flows, and logic are
the same as those of TLS 1.3.
Paragraph (version B):
With these exceptions, the DTLS message formats, flows, and logic are
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.
Draft: draft-ietf-tls-dtls13

Commentary: … procedure
Paragraph (version B):
Updating sending traffic keys is done implicitly by increasing the
epoch value, as described in dtls-epoch, instead of using the
KeyUpdate handshake message.  While this is more efficient it also
creates a denial of service risk since an adverary could inject
packets with fake epoch values.  This forces the recipient to compute
the next-generation application_traffic_secret using the HKDF-Expand-
Label construct to only find out that the message was does not pass
the AEAD cipher processing.  The impact of this attack is small since
the HKDF-Expand-Label only performs symmetric key hashing operations.
Draft: draft-ietf-tls-dtls13

Commentary: Attempt to address though I 'm not entirely happy with this text . Having gone through the existing text looking at " vulnerable " and " susceptible " , it does n't seem in particularly bad shape , so my comment there may have been stronger than needed . 
 Copied from EKR 's repo   wrote : " We talk in a couple places about datagram protocols being “ vulnerable ” or “ susceptible ” to DoS attacks , which leads me to at least partially read that as meaning that the protocol ’s own service will be disrupted ; as we know , this is not the whole story , as the reflection / amplification part can facilitate DoS attacks targeted at other services / networks . So perhaps some rewording is in order . " 
 I would welcome a PR here . 
 did this ,
Paragraph (version A):
Datagram transport protocols, like UDP, are more vulnerable to
denial of service attacks and require a return-routability check
with the help of cookies to be integrated into the handshake.  A
detailed discussion of countermeasures can be found in dos.
Paragraph (version B):
Datagram transport protocols, like UDP, are susceptible to abusive
behavior effecting denial of service attacks against
nonparticipants, and require a return-routability check with the
help of cookies to be integrated into the handshake.  A detailed
discussion of countermeasures can be found in dos.
Paragraph (version A):
NOT RECOMMENDED for such transports.
Paragraph (version B):
NOT RECOMMENDED for such transports, both to increase the reliability
of DTLS service and to avoid the risk of spoofing attacks sending
traffic to unrelated third parties.
Draft: draft-ietf-tls-dtls13

Commentary: 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 .
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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
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.
Paragraph (version A):
client: The endpoint initiating the TLS connection.
Paragraph (version B):
client: The endpoint initiating the DTLS connection.
Paragraph (version A):
server: The endpoint which did not initiate the TLS connection.
Paragraph (version B):
server: The endpoint which did not initiate the DTLS connection.
Paragraph (version A):
Since TLS 1.3 introduce 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
reason this section focuses on the most important changes only.
Paragraph (version B):
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
reason this section focuses on the most important changes only.