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

Commentary: This was the one extension that was n't in the extensions section , which made it hard to find . Note I 've also removed the indent on the trailing paragraphs to avoid the walloftext problem with the existing text . 
 Does the part that says need to be updated to point to this new location instead of { { certificate - request } } ? 
 Good catch . Fixed . 
 lgtm 
 merge this when ready
Paragraph (version B):
A list of certificate extension OIDs RFC5280 with their allowed
values, represented in DER-encoded X690 format.  Some certificate
extension OIDs allow multiple values (e.g., Extended Key Usage).
If the server has included a non-empty certificate_extensions
list, the client certificate included in the response MUST contain
all of the specified extension OIDs that the client recognizes.
For each extension OID recognized by the client, all of the
specified values MUST be present in the client certificate (but
the certificate MAY have other values as well).  However, the
client MUST ignore and skip any unrecognized certificate extension
OIDs.  If the client ignored some of the required certificate
extension OIDs and supplied a certificate that does not satisfy
the request, the server MAY at its discretion either continue the
connection without client authentication, or abort the handshake
with an "unsupported_certificate" alert.
Paragraph (version B):
PKIX RFCs define a variety of certificate extension OIDs and their
corresponding value types.  Depending on the type, matching
certificate extension values are not necessarily bitwise-equal.  It
is expected that TLS implementations will rely on their PKI libraries
to perform certificate selection using certificate extension OIDs.
Paragraph (version B):
The Key Usage extension in a certificate matches the request when
all key usage bits asserted in the request are also asserted in
the Key Usage certificate extension.
Paragraph (version B):
The Extended Key Usage extension in a certificate matches the
request when all key purpose OIDs present in the request are also
found in the Extended Key Usage certificate extension.  The
special anyExtendedKeyUsage OID MUST NOT be used in the request.
Paragraph (version A):
The Key Usage extension in a certificate matches the request
when all key usage bits asserted in the request are also
asserted in the Key Usage certificate extension.
Paragraph (version A):
The Extended Key Usage extension in a certificate matches the
request when all key purpose OIDs present in the request are
also found in the Extended Key Usage certificate extension.
The special anyExtendedKeyUsage OID MUST NOT be used in the
request.
Paragraph (version A):
If the certificate_extensions list in the CertificateRequest
message was non-empty, the end-entity certificate MUST match the
extension OIDs recognized by the client, as described in
certificate-request.
Paragraph (version B):
If the certificate_extensions list in the CertificateRequest
message was non-empty, the end-entity certificate MUST match the
extension OIDs recognized by the client, as described in oid-
filters.
Draft: draft-ietf-tls-tls13

Commentary: I disagree with this . Equally valid advice is to do as little as possible except abort the connection when receiving an alert . Some implementations will not send alerts at all . 
 can you please raise this on the list in response to Kathleen 's comments ? Thanks 
 Per  's AD review
Paragraph (version A):
universally considered fatal as of TLS 1.3 (see alert-protocol).
Paragraph (version B):
universally considered fatal as of TLS 1.3 (see alert-protocol).  The
implementation SHOULD provide a way to facilitate logging the sending
and receiving of alerts.
Draft: draft-ietf-tls-tls13

Commentary: by   . 
 Other than davegarrett 's editorial notes , this looks good .
Paragraph (version A):
32 bytes generated by a secure random number generator.  See
implementation-notes for additional information.  The last eight
bytes MUST be overwritten as described below if negotiating TLS
MUST be generated independently of the ClientHello.random.
Paragraph (version B):
32 bytes generated by a secure random number generator.  See
implementation-notes for additional information.  The last eight
bytes MUST be overwritten as described below if negotiating TLS
structure is generated by the server and MUST be generated
independently of the ClientHello.random.
Paragraph (version B):
Once all the values which are to be derived from a given secret have
been computed, that secret SHOULD be erased.
Draft: draft-ietf-tls-tls13

Commentary: There are a number of different alerts that may be suitable for sending to indicate a non - acceptable cert chain , e.g. certificaterevoked , certificateexpired , unknown_ca , etc . We should not restrict the client to only sending one specific alert . 
 I have updated this PR with the wording as suggested by
Paragraph (version A):
If the server cannot produce a certificate chain that is signed only
via the indicated supported algorithms, then it SHOULD continue the
handshake by sending the client a certificate chain of its choice
that may include algorithms that are not known to be supported by the
client.  This fallback chain MAY use the deprecated SHA-1 hash
algorithm only if the "signature_algorithms" extension provided by
the client permits it.  If the client cannot construct an acceptable
chain using the provided certificates and decides to abort the
handshake, then it MUST abort the handshake with an
"unsupported_certificate" alert.
Paragraph (version B):
If the server cannot produce a certificate chain that is signed only
via the indicated supported algorithms, then it SHOULD continue the
handshake by sending the client a certificate chain of its choice
that may include algorithms that are not known to be supported by the
client.  This fallback chain MAY use the deprecated SHA-1 hash
algorithm only if the "signature_algorithms" extension provided by
the client permits it.  If the client cannot construct an acceptable
chain using the provided certificates and decides to abort the
handshake, then it MUST abort the handshake with an appropriate
certificate-related alert (by default, "unsupported_certificate"; see
error-alerts for more).
Draft: draft-ietf-tls-tls13

Commentary: This follows naturally from the inclusion of EndOfEarlyData in the handshake transcript , but it does n't hurt to mention it explicitly . See also , uh , . 
 I mention it explicitly because it tripped me up in implementation :)
Paragraph (version A):
If the server sent an "early_data" extension, the client MUST send an
EndOfEarlyData after receiving the server Finished.  This indicates
that all 0-RTT application_data messages, if any, have been
transmitted and that the following records are protected under
handshake traffic keys.  Servers MUST NOT send this message and
clients receiving it MUST terminate the connection with an
"unexpected_message" alert.  This message is encrypted under keys
derived from the client_early_traffic_secret.
Paragraph (version B):
If the server sent an "early_data" extension, the client MUST send an
EndOfEarlyData message after receiving the server Finished.  If the
server does not send an "early_data" extension, then the client MUST
NOT send an EndOfEarlyData message.  This message indicates that all
0-RTT application_data messages, if any, have been transmitted and
that the following records are protected under handshake traffic
keys.  Servers MUST NOT send this message and clients receiving it
MUST terminate the connection with an "unexpected_message" alert.
This message is encrypted under keys derived from the
client_early_traffic_secret.
Draft: draft-ietf-tls-tls13

Commentary: Follow up to PR . Add a link for the ALPN RFC to the relevant alert 's description . ( same as with other extension alerts above ) 
 & No feature in the TLS 1.3 spec , optional or required , needs ALPN to work . We merely cite places where it needs to be taken into consideration if it is in use . It could be argued that it is an " optional feature " of TLS ( as a whole ) , but not of this document , thus I do n't think it meets the qualifications to be normative . I think staying as informative is correct . 
 There 's a bunch of text that specifically mentions ALPN , some of it with normative statements . If those normative statements ca n't be understood , optional feature or not , then it 's normative .
Paragraph (version A):
Sent by servers when a client
"application_layer_protocol_negotiation" extension advertises
protocols that the server does not support.
Paragraph (version B):
Sent by servers when a client
"application_layer_protocol_negotiation" extension advertises
protocols that the server does not support (see RFC7301).
Draft: draft-ietf-tls-tls13

Commentary: Even when ( EC)DHE is in use , the " supported_groups " extension is only mandatory in the ClientHello ; it can be omitted from the EncryptedExtensions , as per section 4.2.6 . Given that , it is not MTI for the server sending to the client , but the client must be prepared to accept the extension in  ( at least to the point of not crashing or aborting the handshake ) , so leave the MTI text unchanged . It would be too awkward to try to express this subtlety in such a concise list .
Paragraph (version A):
"supported_groups" and "key_share" are REQUIRED for DHE or ECDHE
key exchange.
Paragraph (version B):
"supported_groups" is REQUIRED for ClientHello messages using DHE
or ECDHE key exchange.
Paragraph (version B):
"key_share" is REQUIRED for DHE or ECDHE key exchange.
Draft: draft-ietf-tls-tls13

Commentary: Just a minor editorial correction .
Paragraph (version A):
Indicates algorithms which are being deprecated because they use
algorithms with known weaknesses, specifically SHA-1 which is used
in this context with either with RSA using RSASSA-PKCS1-v1_5 or
ECDSA.  These values refer solely to signatures which appear in
certificates (see server-certificate-selection) and are not
defined for use in signed TLS handshake messages.  Endpoints
SHOULD NOT these algorithms but are permitted to do so solely for
backward compatibility.  Clients offering these values MUST list
them as the lowest priority (listed after all other algorithms in
SignatureSchemeList).  TLS 1.3 servers MUST NOT offer a SHA-1
signed certificate unless no valid certificate chain can be
produced without it (see server-certificate-selection).
Paragraph (version B):
Indicates algorithms which are being deprecated because they use
algorithms with known weaknesses, specifically SHA-1 which is used
in this context with either with RSA using RSASSA-PKCS1-v1_5 or
ECDSA.  These values refer solely to signatures which appear in
certificates (see server-certificate-selection) and are not
defined for use in signed TLS handshake messages.  Endpoints
SHOULD NOT negotiate these algorithms but are permitted to do so
solely for backward compatibility.  Clients offering these values
MUST list them as the lowest priority (listed after all other
algorithms in SignatureSchemeList).  TLS 1.3 servers MUST NOT
offer a SHA-1 signed certificate unless no valid certificate chain
can be produced without it (see server-certificate-selection).
Draft: draft-ietf-tls-tls13

Commentary: The " Because ... " sentence seemed like it should be combined with the next sentence .
Paragraph (version A):
This document supersedes and obsoletes previous versions of TLS
including version 1.2 RFC5246.  It also obsoletes the TLS ticket
mechanism defined in RFC5077 and replaces it with the mechanism
defined in resumption-and-psk. negotiated-groups updates RFC4492 by
modifying the protocol attributes used to negotiate Elliptic Curves.
Because TLS 1.3 changes the way keys are derived it updates RFC5705
as described in exporters.  It also changes how OCSP messages are
carried and therefore updates RFC6066 and obsoletes RFC6961 as
described in section ocsp-and-sct.
Paragraph (version B):
This document supersedes and obsoletes previous versions of TLS
including version 1.2 RFC5246.  It also obsoletes the TLS ticket
mechanism defined in RFC5077 and replaces it with the mechanism
defined in resumption-and-psk. negotiated-groups updates RFC4492 by
modifying the protocol attributes used to negotiate Elliptic Curves.
Because TLS 1.3 changes the way keys are derived it updates RFC5705
as described in exporters it also changes how OCSP messages are
carried and therefore updates RFC6066 and obsoletes RFC6961 as
described in section ocsp-and-sct.
Draft: draft-ietf-tls-tls13

Commentary: ID nits complains about : * * Obsolete normative reference : RFC 3447
Paragraph (version A):
Indicates a signature algorithm using RSASSA-PKCS1-v1_5 RFC3447
with the corresponding hash algorithm as defined in SHS.  These
values refer solely to signatures which appear in certificates
(see server-certificate-selection) and are not defined for use in
signed TLS handshake messages.
Paragraph (version B):
Indicates a signature algorithm using RSASSA-PKCS1-v1_5 RFC8017
with the corresponding hash algorithm as defined in SHS.  These
values refer solely to signatures which appear in certificates
(see server-certificate-selection) and are not defined for use in
signed TLS handshake messages.
Paragraph (version A):
Indicates a signature algorithm using RSASSA-PSS RFC3447 with mask
generation function 1.  The digest used in the mask generation
function and the digest being signed are both the corresponding
hash algorithm as defined in SHS.  When used in signed TLS
handshake messages, the length of the salt MUST be equal to the
length of the digest output.  This codepoint is new in this
document and is also defined for use with TLS 1.2.
Paragraph (version B):
Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask
generation function 1.  The digest used in the mask generation
function and the digest being signed are both the corresponding
hash algorithm as defined in SHS.  When used in signed TLS
handshake messages, the length of the salt MUST be equal to the
length of the digest output.  This codepoint is new in this
document and is also defined for use with TLS 1.2.
Draft: draft-ietf-tls-tls13

Commentary: RFC 7301 defines the ALPN extension and defined a new alert " noapplicationprotocol " . TLS 1.3 uses ALPN but currently misses the alert in Section 6 . 
 You also need to add it to the Error Alerts section with a description .
Paragraph (version B):
Sent by servers when a client advertises protocols that the server
does not support.
Draft: draft-ietf-tls-tls13

Commentary: Per mailing list discussion , this allows us to have every HKDF - Expand just have one hash block of info . would love your feedback . 
 Should n't " TLS 1.3 , " be shortened to " tls13 " ? Without that , several of the labels would seem to blow blocks . Also , " derived secret " seems unchanged , and is too long to fit into a block , even with " tls13 " prefix . 
 Oops . Good catch . Script fail . 
 fixed ? 
 Yeah , I 'll add a note . I still have an issue for the ChangeLog so I will add this as well 
 Also , minimum label size looks to be still 10 , presumably should be 7 with 6 - byte prefix ( as it 10 with 9 - byte prefix ) .
Paragraph (version B):
Shorten labels for HKDF-Expand-Label so that we can fit within one
compression block (*).
Paragraph (version B):
Note: with common hash functions, any label longer than 12 characters
requires an additional iteration of the hash function to compute.
The labels in this specification have all been chosen to fit within
this limit.
Paragraph (version A):
If a given secret is not available, then the 0-value consisting of a
string of Hash.length zero bytes is used.  Note that this does not
mean skipping rounds, so if PSK is not in use Early Secret will still
be HKDF-Extract(0, 0).  For the computation of the binder_secret, the
label is "external psk binder key" for external PSKs (those
provisioned outside of TLS) and "resumption psk binder key" for
resumption PSKs (those provisioned as the resumption master secret of
a previous handshake).  The different labels prevent the substitution
of one type of PSK for the other.
Paragraph (version B):
If a given secret is not available, then the 0-value consisting of a
string of Hash.length zero bytes is used.  Note that this does not
mean skipping rounds, so if PSK is not in use Early Secret will still
be HKDF-Extract(0, 0).  For the computation of the binder_secret, the
label is "external psk binder key" for external PSKs (those
provisioned outside of TLS) and "res binder" for resumption PSKs
(those provisioned as the resumption master secret of a previous
handshake).  The different labels prevent the substitution of one
type of PSK for the other.
Draft: draft-ietf-tls-tls13

Commentary: When we banned client auth and PSK , we only meant to do it for the main handshake , not the post - handshake phase . This reverts that change , as well as clarifies the prophibition on PSK plus cert - based auth .
Paragraph (version A):
Servers which are authenticating with a PSK MUST NOT send the
CertificateRequest message.
Paragraph (version B):
Servers which are authenticating with a PSK MUST NOT send the
CertificateRequest message in the main handshake, though they MAY
send it in post-handshake authentication (see post-handshake-
authentication) provided that the client has sent the
"post_handshake_auth" extension (see post_handshake_auth).
Draft: draft-ietf-tls-tls13

Commentary: See discussion on
Paragraph (version A):
A Zero-RTT mode was added, saving a round-trip at connection
setup.
Paragraph (version B):
A Zero-RTT mode was added, saving a round-trip at connection setup
for some application data, at the cost of certain security
properties.
Draft: draft-ietf-tls-tls13

Commentary: Make the variable names of various secrets correspond to the labels used for Derive - Secret ( ) . This is not a wire format change , but just a change in the internal variable names . 
 you see any misses here ? 
 The legends for the message flows still say " trafficsecretN " for the " [ ] " parts . Also , " Updating Traffic Keys and IVs " still uses " trafficsecretN " in the formula and text prior to it . 
 In the key schedule
Paragraph (version A):
The same warnings apply to any use of the early_exporter_secret.
Paragraph (version B):
The same warnings apply to any use of the
early_exporter_master_secret.
Paragraph (version A):
Once the handshake is complete, it is possible for either side to
update its sending traffic keys using the KeyUpdate handshake message
defined in key-update.  The next generation of traffic keys is
computed by generating client_/server_traffic_secret_N+1 from
client_/server_traffic_secret_N as described in this section then re-
deriving the traffic keys as described in traffic-key-calculation.
Paragraph (version A):
Once client/server_traffic_secret_N+1 and its associated traffic keys
have been computed, implementations SHOULD delete client_/
server_traffic_secret_N and its associated traffic keys.
Paragraph (version B):
Once the handshake is complete, it is possible for either side to
update its sending traffic keys using the KeyUpdate handshake message
defined in key-update.  The next generation of traffic keys is
computed by generating client_/server_application_traffic_secret_N+1
from client_/server_application_traffic_secret_N as described in this
section then re-deriving the traffic keys as described in traffic-
key-calculation.
Paragraph (version B):
Once client/server_application_traffic_secret_N+1 and its associated
traffic keys have been computed, implementations SHOULD delete
client_/server_application_traffic_secret_N and its associated
traffic keys.
Paragraph (version A):
Where Secret is either the early_exporter_secret or the
exporter_secret.  Implementations MUST use the exporter_secret unless
explicitly specified by the application.  The early_exporter_secret
is define for use in settings where an exporter is needed for 0-RTT
data.  A separate interface for the early exporter is RECOMMENDED,
especially on a server where a single interface can make the early
exporter inaccessible.
Paragraph (version B):
Where Secret is either the early_exporter_master_secret or the
exporter_master_secret.  Implementations MUST use the
exporter_master_secret unless explicitly specified by the
application.  The early_exporter_master_secret is define for use in
settings where an exporter is needed for 0-RTT data.  A separate
interface for the early exporter is RECOMMENDED, especially on a
server where a single interface can make the early exporter
inaccessible.
Draft: draft-ietf-tls-tls13

Commentary: As suggested by Nikos , provide a formal description of the point format modelled on 4492 - bis . 
 Per  's comment .
Paragraph (version A):
For secp256r1, secp384r1 and secp521r1, the contents are the byte
string representation of an elliptic curve public value following the
conversion routine in Section 4.3.6 of ANSI X9.62 X962.
Paragraph (version A):
Although X9.62 supports multiple point formats, any given curve MUST
specify only a single point format.  All curves currently specified
in this document MUST only be used with the uncompressed point format
(the format for all ECDH functions is considered uncompressed).
Peers MUST validate each other's public value Y by ensuring that the
point is a valid point on the elliptic curve.
Paragraph (version A):
For the curves secp256r1, secp384r1 and secp521r1, 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):
X and Y respectively are the binary representations of the X and Y
values in network byte order.  There are no internal length markers,
so each number representation occupies as many octets as implied by
the curve parameters.  For P-256 this means that each of X and Y use
32 octets, padded on the left by zeros if necessary.  For P-384 they
take 48 octets each, and for P-521 they take 66 octets each.
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.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.