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

Commentary: 8126 obsoleted 5226 . Saving us a GENART comment .
Paragraph (version A):
TLS Cipher Suite Registry: values with the first byte in the range
0-254 (decimal) are assigned via Specification Required RFC5226.
Values with the first byte 255 (decimal) are reserved for Private
Use RFC5226.
Paragraph (version B):
TLS Cipher Suite Registry: values with the first byte in the range
0-254 (decimal) are assigned via Specification Required RFC8126.
Values with the first byte 255 (decimal) are reserved for Private
Use RFC8126.
Paragraph (version A):
TLS ContentType Registry: Future values are allocated via
Standards Action RFC5226.
Paragraph (version A):
TLS Alert Registry: Future values are allocated via Standards
Action RFC5226.  IANA [SHALL update/has updated] this registry to
include values for "missing_extension" and "certificate_required".
Paragraph (version A):
TLS HandshakeType Registry: Future values are allocated via
Standards Action RFC5226.  IANA [SHALL update/has updated] this
registry to rename item 4 from "NewSessionTicket" to
"new_session_ticket" and to add the
"hello_retry_request_RESERVED", "encrypted_extensions",
"end_of_early_data", "key_update", and "message_hash" values.
Paragraph (version B):
TLS ContentType Registry: Future values are allocated via
Standards Action RFC8126.
Paragraph (version B):
TLS Alert Registry: Future values are allocated via Standards
Action RFC8126.  IANA [SHALL update/has updated] this registry to
include values for "missing_extension" and "certificate_required".
Paragraph (version B):
TLS HandshakeType Registry: Future values are allocated via
Standards Action RFC8126.  IANA [SHALL update/has updated] this
registry to rename item 4 from "NewSessionTicket" to
"new_session_ticket" and to add the
"hello_retry_request_RESERVED", "encrypted_extensions",
"end_of_early_data", "key_update", and "message_hash" values.
Draft: draft-ietf-tls-tls13

Commentary: Without specifying the encoding , I do n't think it 's actually defined how you transit the certificates . RFC 5280 only says that the TBSCertificate is DER - encoded for computing the signature , which still allows insanity like  - encoded everything with the receiver re - encoding the TBSCertificate to DER before verifying the signature .
Paragraph (version A):
If the corresponding certificate type extension
("server_certificate_type" or "client_certificate_type") was not
negotiated in Encrypted Extensions, or the X.509 certificate type was
negotiated, then each CertificateEntry contains an X.509 certificate.
The sender's certificate MUST come in the first CertificateEntry in
the list.  Each following certificate SHOULD directly certify one
preceding it.  Because certificate validation requires that trust
anchors be distributed independently, a certificate that specifies a
trust anchor MAY be omitted from the chain, provided that supported
peers are known to possess any omitted certificates.
Paragraph (version B):
If the corresponding certificate type extension
("server_certificate_type" or "client_certificate_type") was not
negotiated in Encrypted Extensions, or the X.509 certificate type was
negotiated, then each CertificateEntry contains a DER-encoded X.509
certificate.  The sender's certificate MUST come in the first
CertificateEntry in the list.  Each following certificate SHOULD
directly certify one preceding it.  Because certificate validation
requires that trust anchors be distributed independently, a
certificate that specifies a trust anchor MAY be omitted from the
chain, provided that supported peers are known to possess any omitted
certificates.
Draft: draft-ietf-tls-tls13

Commentary: This is mentioned throughout the document , but not in the " Mandatory - to - Implement " section . 
 This is the same as , just without the extra new line additions , etc 
 In the section it states : In the section we have : However , this is not mentioned in the " Mandatory - to - Implement " extensions section .
Paragraph (version A):
"supported_versions" is REQUIRED for all ClientHello messages.
Paragraph (version B):
"supported_versions" is REQUIRED for all ClientHello, ServerHello
and HelloRetryRequest messages.
Draft: draft-ietf-tls-tls13

Commentary: The RFC editor found a few errors in a draft that used the same references . This updates the draft to use the automatically generated DOI references from rather than manual references . This is n't perfect , but it should help the RFC editor when it comes time to publish . 
 This changes : to LGTM (  is the author according to )
Paragraph (version A):
For the curves secp256r1, secp384r1 and secp521r1, peers MUST
validate each other's public value Y by ensuring that the point is a
valid point on the elliptic curve.  The appropriate validation
procedures are defined in Section 4.3.7 of X962 and alternatively in
Section 5.6.2.6 of KEYAGREEMENT.  This process consists of three
steps: (1) verify that Y is not the point at infinity (O), (2) verify
that for Y = (x, y) both integers are in the correct interval, (3)
ensure that (x, y) is a correct solution to the elliptic curve
equation.  For these curves, implementers do not need to verify
membership in the correct subgroup.
Paragraph (version B):
For the curves secp256r1, secp384r1 and secp521r1, peers MUST
validate each other's public value Y by ensuring that the point is a
valid point on the elliptic curve.  The appropriate validation
procedures are defined in Section 4.3.7 of X962 and alternatively in
Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three
steps: (1) verify that Y is not the point at infinity (O), (2) verify
that for Y = (x, y) both integers are in the correct interval, (3)
ensure that (x, y) is a correct solution to the elliptic curve
equation.  For these curves, implementers do not need to verify
membership in the correct subgroup.
Draft: draft-ietf-tls-tls13

Commentary: Minor change to where RFC 6066 is referenced .
Paragraph (version A):
The "server_name" and "certificate_authorities" extensions RFC6066
are used to guide certificate selection.  As servers MAY require
the presence of the "server_name" extension, clients SHOULD send
this extension, when applicable.
Paragraph (version B):
The "server_name" RFC6066 and "certificate_authorities" extensions
are used to guide certificate selection.  As servers MAY require
the presence of the "server_name" extension, clients SHOULD send
this extension, when applicable.
Draft: draft-ietf-tls-tls13

Commentary: Currently , the draft says that servers MAY send multiple tickets to clients without further discussion . It might help to be concrete and provide an example for when more than one ticket is useful . This PR provides one example .
Paragraph (version A):
The client MAY use this PSK for future handshakes by including the
ticket value in the "pre_shared_key" extension in its ClientHello
(pre-shared-key-extension).  Servers MAY send multiple tickets on a
single connection, either immediately after each other or after
specific events.  For instance, the server might send a new ticket
after post-handshake authentication in order to encapsulate the
additional client authentication state.  Clients SHOULD attempt to
use each ticket no more than once, with more recent tickets being
used first.
Paragraph (version B):
Opening multiple parallel HTTP connections.
Paragraph (version B):
Performing connection racing across interfaces and address
families via, e.g., Happy Eyeballs RFC6555 or related techniques.
Paragraph (version B):
Clients SHOULD attempt to use each ticket no more than once, with
more recent tickets being used first.
Draft: draft-ietf-tls-tls13

Commentary: the RFC 7250 semantics that both certificate types are globally negotiated . There is no support for mixed certificates .
Paragraph (version A):
If the corresponding certificate type extension
("server_certificate_type" or "client_certificate_type") was not used
or the X.509 certificate type was negotiated, then each
CertificateEntry contains an X.509 certificate.  The sender's
certificate MUST come in the first CertificateEntry in the list.
Each following certificate SHOULD directly certify one preceding it.
Because certificate validation requires that trust anchors be
distributed independently, a certificate that specifies a trust
anchor MAY be omitted from the chain, provided that supported peers
are known to possess any omitted certificates.
Paragraph (version B):
If the corresponding certificate type extension
("server_certificate_type" or "client_certificate_type") was not
negotiated in Encrypted Extensions, or the X.509 certificate type was
negotiated, then each CertificateEntry contains an X.509 certificate.
The sender's certificate MUST come in the first CertificateEntry in
the list.  Each following certificate SHOULD directly certify one
preceding it.  Because certificate validation requires that trust
anchors be distributed independently, a certificate that specifies a
trust anchor MAY be omitted from the chain, provided that supported
peers are known to possess any omitted certificates.
Draft: draft-ietf-tls-tls13

Commentary: The padding extension is typically computed as part of serializing the ClientHello , in hopes of targetting a particular size . As specified right now , the second ClientHello must not use this same logic and instead must retain the previous extension sizethough this would likely not hit the same target size . The server 's going to ignore it anyway , so allow it to be recalcuated . This avoids unnecessary state in clients and extra logic to serialize the first and second ClientHellos differently . 
 Good catch ; +1
Paragraph (version B):
Optionally adding, removing, or changing the length of the
"padding" extension RFC7685.
Draft: draft-ietf-tls-tls13

Commentary: As mentioned by in .
Paragraph (version A):
The Hash function used by Transcript-Hash and HKDF is the cipher
suite hash algorithm.  Hash.length is its output length in bytes.
Messages are the concatenation of the indicated handshake messages,
including the handshake message type and length fields, but not
including record layer headers.  Note that in some cases a zero-
length Context (indicated by "") is passed to HKDF-Expand-Label.
Paragraph (version B):
The Hash function used by Transcript-Hash and HKDF is the cipher
suite hash algorithm.  Hash.length is its output length in bytes.
Messages are the concatenation of the indicated handshake messages,
including the handshake message type and length fields, but not
including record layer headers.  Note that in some cases a zero-
length Context (indicated by "") is passed to HKDF-Expand-Label.  The
Labels specified in this document are all ASCII strings, and do not
include a trailing NUL byte.
Draft: draft-ietf-tls-tls13

Commentary: We never need embedded nor anonymous structs , so remove them from the presentation language .
Paragraph (version A):
The fields within a structure may be qualified using the type's name,
with a syntax much like that available for enumerateds.  For example,
T.f2 refers to the second field of the previous declaration.
Structure definitions may be embedded.  Anonymous structs may also be
defined inside other structures.
Paragraph (version B):
The fields within a structure may be qualified using the type's name,
with a syntax much like that available for enumerateds.  For example,
T.f2 refers to the second field of the previous declaration.
Draft: draft-ietf-tls-tls13

Commentary: Be explicit that vectors are allowed in structures .
Paragraph (version B):
Fixed- and variable-length vector fields are allowed using the
standard vector syntax.  Structures V1 and V2 in the variants example
below demonstrate this.
Draft: draft-ietf-tls-tls13

Commentary: This change rephrases the requirements and recommendations from prescribing specific mechanisms of 0 - RTT replay protection to prescribing the guarantees expected from implementations , thus letting the implementations to choose the way they can provide those guarantees . This change also introduces a MUST - level requirement for protection equivalent to having at least local strike register . 
 I 've addressed all editorial nits suggested ( except for the comma one , which I leave to editor 's discretion ) . 
 There are some nits noted inline ( by me and others ) , but those are subject to editorial discretion , so I will mark my overall approval .
Paragraph (version A):
The first class of attack can be prevented by the mechanism described
in this section.  Servers need not permit 0-RTT at all, but those
which do SHOULD implement either the single-use tickets or
ClientHello recording techniques described in the following two
sections.
Paragraph (version A):
In normal operation, clients will not know which, if any, of these
mechanisms servers actually implement and therefore MUST only send
early data which they are willing to have subject to the attacks
described in replay-0rtt.
Paragraph (version B):
The first class of attack can be prevented by sharing state to
guarantee that the 0-RTT data is accepted at most once.  Servers
SHOULD provide that level of replay safety, by implementing one of
the methods described in this section or by equivalent means.  It is
understood, however, that due to operational concerns not all
deployments will maintain state at that level.  Therefore, in normal
operation, clients will not know which, if any, of these mechanisms
servers actually implement and hence MUST only send early data which
they deem safe to be replayed.
Paragraph (version B):
In addition to the direct effects of replays, there is a class of
attacks where even operations normally considered idempotent could be
exploited by a large number of replays (timing attacks, resource
limit exhaustion and others described in replay-0rtt).  Those can be
mitigated by ensuring that every 0-RTT payload can be replayed only a
limited number of times.  The server MUST ensure that any instance of
it (be it a machine, a thread or any other entity within the relevant
serving infrastructure) would accept 0-RTT for the same 0-RTT
handshake at most once; this limits the number of replays to the
number of server instances in the deployment.  Such a guarantee can
be accomplished by locally recording data from recently-received
ClientHellos and rejecting repeats, or by any other method that
provides the same or a stronger guarantee.  The "at most once per
server instance" guarantee is a minimum requirement; servers SHOULD
limit 0-RTT replays further when feasible.
Draft: draft-ietf-tls-tls13

Commentary: s / security / secrecy/
Paragraph (version A):
If the tickets are not self-contained but rather are database keys,
and the corresponding PSKs are deleted upon use, then connections
established using one PSK enjoy forward security.  This improves
security for all 0-RTT data and PSK usage when PSK is used without
(EC)DHE.
Paragraph (version B):
If the tickets are not self-contained but rather are database keys,
and the corresponding PSKs are deleted upon use, then connections
established using one PSK enjoy forward secrecy.  This improves
security for all 0-RTT data and PSK usage when PSK is used without
(EC)DHE.
Draft: draft-ietf-tls-tls13

Commentary: This is no longer a hash value throughout , using a different name might reduce confusion a little . 
 Seems like an improvement.+1
Paragraph (version A):
The Hash function used by Transcript-Hash and HKDF is the cipher
suite hash algorithm.  Hash.length is its output length in bytes.
Messages are the concatenation of the indicated handshake messages,
including the handshake message type and length fields, but not
including record layer headers.  Note that in some cases a zero-
length HashValue (indicated by "") is passed to HKDF-Expand-Label.
Paragraph (version B):
The Hash function used by Transcript-Hash and HKDF is the cipher
suite hash algorithm.  Hash.length is its output length in bytes.
Messages are the concatenation of the indicated handshake messages,
including the handshake message type and length fields, but not
including record layer headers.  Note that in some cases a zero-
length Context (indicated by "") is passed to HKDF-Expand-Label.
Draft: draft-ietf-tls-tls13

Commentary: Looks good , full stop .
Paragraph (version B):
The TLS handshake establishes one or more input secrets which are
combined to create the actual working keying material, as detailed
below.  The key derivation process incorporates both the input
secrets and the handshake transcript.  Note that because the
handshake transcript includes the random values from the Hello
messages, any given handshake will have different traffic secrets,
even if the same input secrets are used, as is the case when the same
PSK is used for multiple connections.
Draft: draft-ietf-tls-tls13

Commentary: Some more editorial bits from looking at the diff between draft-20 and draft-21
Paragraph (version A):
A unique per-ticket value.
Paragraph (version B):
A per-ticket value that is unique across all tickets issued on
this connection.
Draft: draft-ietf-tls-tls13

Commentary: All extremely minor .
Paragraph (version A):
ECC is now in the base spec and includes new signature algorithms,
such as ed25519 and ed448.  TLS 1.3 removed point format
negotiation in favor of a single point format for each curve.
Paragraph (version B):
Elliptic curve algorithms are now in the base spec and includes
new signature algorithms, such as ed25519 and ed448.  TLS 1.3
removed point format negotiation in favor of a single point format
for each curve.
Paragraph (version A):
At this point, the handshake is complete, and the client and server
must derive the keying material required by the record layer to
exchange application-layer data protected through authenticated
encryption.  Application data MUST NOT be sent prior to sending the
Finished message and until the record layer starts using encryption
keys.  Note that while the server may send application data prior to
receiving the client's Authentication messages, any data sent at that
point is, of course, being sent to an unauthenticated peer.
Paragraph (version B):
At this point, the handshake is complete, and the client and server
derive the keying material required by the record layer to exchange
application-layer data protected through authenticated encryption.
Application data MUST NOT be sent prior to sending the Finished
message and until the record layer starts using encryption keys.
Note that while the server may send application data prior to
receiving the client's Authentication messages, any data sent at that
point is, of course, being sent to an unauthenticated peer.
Paragraph (version A):
When PSKs are provisioned out of band, the PSK identity and the KDF
hash algorithm to be used with the PSK MUST also be provisioned.
Note: When using an out-of-band provisioned pre-shared secret, a
critical consideration is using sufficient entropy during the key
generation, as discussed in RFC4086.  Deriving a shared secret from a
password or other low-entropy sources is not secure.  A low-entropy
secret, or password, is subject to dictionary attacks based on the
PSK binder.  The specified PSK authentication is not a strong
password-based authenticated key exchange even when used with Diffie-
Hellman key establishment.
Paragraph (version B):
When PSKs are provisioned out of band, the PSK identity and the KDF
hash algorithm to be used with the PSK MUST also be provisioned.
Paragraph (version B):
When using an out-of-band provisioned pre-shared secret, a
critical consideration is using sufficient entropy during the key
generation, as discussed in RFC4086.  Deriving a shared secret
from a password or other low-entropy sources is not secure.  A
low-entropy secret, or password, is subject to dictionary attacks
based on the PSK binder.  The specified PSK authentication is not
a strong password-based authenticated key exchange even when used
with Diffie-Hellman key establishment.
Draft: draft-ietf-tls-tls13

Commentary: I would appreciate a sanity check here . 
 Maybe remove the " arguably " statement and the *
Paragraph (version B):
Clarify that clients should change to sending with handshake keys
immediately upon reading ServerHello.  Arguably a wire format
change. (*).
Paragraph (version A):
Servers MAY send data after sending their first flight, but
because the handshake is not yet complete, they have no assurance
of either the peer's identity or of it's liveness (i.e., the
ClientHello might have been replayed).
Paragraph (version B):
Servers MAY send data after sending their first flight, but
because the handshake is not yet complete, they have no assurance
of either the peer's identity or of its liveness (i.e., the
ClientHello might have been replayed).
Draft: draft-ietf-tls-tls13

Commentary: Reported by Xuelei Fan .
Paragraph (version A):
The "server_name" and "trusted_ca_keys" extensions RFC6066 are
used to guide certificate selection.  As servers MAY require the
presence of the "server_name" extension, clients SHOULD send this
extension, when applicable.
Paragraph (version B):
The "server_name" and "certificate_authorities" extensions RFC6066
are used to guide certificate selection.  As servers MAY require
the presence of the "server_name" extension, clients SHOULD send
this extension, when applicable.