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

Commentary: Cleaned up references to knownconfiguration extension ( merged into earlydata in draft-08 )
Paragraph (version A):
The semantics of this message are to establish a shared state between
the client and server for use with the "known_configuration"
extension with the key specified in key and with the handshake
parameters negotiated by this handshake.
Paragraph (version A):
When the ServerConfiguration message is sent, the server MUST also
send a Certificate message and a CertificateVerify message, even if
the "known_configuration" extension was used for this handshake, thus
requiring a signature over the configuration before it can be used by
the client.  Clients MUST NOT rely on the ServerConfiguration message
until successfully receiving and processing the server's Certificate,
CertificateVerify, and Finished.  If there is a failure in processing
those messages, the client MUST discard the ServerConfiguration.
Paragraph (version B):
The semantics of this message are to establish a shared state between
the client and server for use with the "early_data" extension with
the key specified in "static_key_share" and with the handshake
parameters negotiated by this handshake.
Paragraph (version B):
When the ServerConfiguration message is sent, the server MUST also
send a Certificate message and a CertificateVerify message, even if
the "early_data" extension was used for this handshake, thus
requiring a signature over the configuration before it can be used by
the client.  Clients MUST NOT rely on the ServerConfiguration message
until successfully receiving and processing the server's Certificate,
CertificateVerify, and Finished.  If there is a failure in processing
those messages, the client MUST discard the ServerConfiguration.
Draft: draft-ietf-tls-tls13

Commentary: ( via )
Paragraph (version A):
If this message is in response to a CertificateRequest, the value
if certificate_request_context in that message.  Otherwise, in the
case of server authentication or client authentication in 0-RTT,
this field SHALL be zero length.
Paragraph (version B):
If this message is in response to a CertificateRequest, the value
of certificate_request_context in that message.  Otherwise, in the
case of server authentication or client authentication in 0-RTT,
this field SHALL be zero length.
Draft: draft-ietf-tls-tls13

Commentary: Small simplification & clarification . Now that the server key share is in an extension , all TLS 1.3 endpoints will have at least one extension in their hello , either " keyshare " or " preshared_key " , at minimum . This changeset simplifies the ServerHello struct in the same manner as was previously done for ClientHello and adds short notes explicitly stating this .
Paragraph (version A):
TLS allows extensions to follow the compression_methods field in an
extensions block.  The presence of extensions can be detected by
determining whether there are bytes following the compression_methods
at the end of the ClientHello.  Note that this method of detecting
optional data differs from the normal TLS method of having a
variable-length field, but it is used for compatibility with TLS
before extensions were defined.
Paragraph (version B):
TLS allows extensions to follow the compression_methods field in an
extensions block.  The presence of extensions can be detected by
determining whether there are bytes following the compression_methods
at the end of the ClientHello.  Note that this method of detecting
optional data differs from the normal TLS method of having a
variable-length field, but it is used for compatibility with TLS
before extensions were defined.  As of TLS 1.3, all clients and
servers will send at least one extension (at least "key_share" or
"pre_shared_key").
Paragraph (version A):
Clients MAY request extended functionality from servers by sending
data in the extensions field.  The actual "Extension" format is
defined in hello-extensions.
Paragraph (version B):
Clients request extended functionality from servers by sending
data in the extensions field.  The actual "Extension" format is
defined in hello-extensions.
Paragraph (version A):
The presence of extensions can be detected by determining whether
there are bytes following the cipher_suite field at the end of the
ServerHello.
Paragraph (version B):
In prior versions of TLS, the extensions field could be omitted
entirely if not needed, similar to ClientHello.  As of TLS 1.3, all
clients and servers will send at least one extension (at least
"key_share" or "pre_shared_key").
Draft: draft-ietf-tls-tls13

Commentary: This should be " chose " not " choosed " , which is n't really an accepted word . 
 Added another commit here for a minor wording fix that snuck in with changing all extensions to be referred to by type ID name . 
 Ok , I switched it to " chooses " instead & squashed my little fixes together here . There 's also a fix for the " will MAY " bit that I think we discussed at some point but its fix did n't get in .
Paragraph (version A):
If the server choosed to accept the "early_data" extension, then it
MUST comply with the same error handling requirements specified for
all records when processing early data records.  Specifically,
decryption failure of any 0-RTT record following an accepted
"early_data" extension MUST produce a fatal "bad_record_mac" alert as
per record-payload-protection.
Paragraph (version B):
If the server chooses to accept the "early_data" extension, then it
MUST comply with the same error handling requirements specified for
all records when processing early data records.  Specifically,
decryption failure of any 0-RTT record following an accepted
"early_data" extension MUST produce a fatal "bad_record_mac" alert as
per record-payload-protection.
Paragraph (version A):
If (EC)DHE is being used, the server's version of "key_share".
Paragraph (version A):
If PSK is being used, the server's version of the "pre_shared_key"
(indicating the PSK the client is using).
Paragraph (version B):
If (EC)DHE is being used, the server's version of the "key_share"
extension.
Paragraph (version B):
If PSK is being used, the server's version of the "pre_shared_key"
extension (indicating the PSK the client is using).
Paragraph (version A):
The server's certificate list MUST always be non-empty.  A client
will MAY send an empty certificate list if it does not have an
appropriate certificate to send in response to the server's
authentication request.
Paragraph (version B):
The server's certificate list MUST always be non-empty.  A client
will send an empty certificate list if it does not have an
appropriate certificate to send in response to the server's
authentication request.
Draft: draft-ietf-tls-tls13

Commentary: Proposed clarification based on mailing list discussion . Explicitly state that 0 - RTT records MUST NOT get special treatment and 1 - RTT fallback on decryption errors is prohibited . This may technically already be the intended situation , however any ambiguity here will undoubtedly lead to some implementations falling back to avoid breakage in this scenario , which risks 0 - RTT data stripping attacks . As I agree with the expected behavior stated by on - list , this is just a matter of adding some clarification here ( even if it might be redundant ; someone interpreting the text the way I initially did could do something dangerous if they do n't also notice the risk ) .
Paragraph (version B):
Servers MUST comply with the same error handling requirements
specified for all records when processing early data records and MUST
NOT fall back to 1-RTT on any such errors.  Specifically, decryption
failure of any 0-RTT record following an accepted "early_data"
extension MUST produce a fatal "bad_record_mac" alert as per record-
payload-protection.
Draft: draft-ietf-tls-tls13

Commentary: The current version is missing a word and I tried to improve it a bit more .
Paragraph (version A):
This alert is sent by the client to indicate that all 0-RTT
application_data messages have been transmitted and that the next
message will be handshake message protected with the 1-RTT
handshake keys.  This alert MUST be at the warning level.  Servers
MUST NOT send this alert and clients receiving this alert MUST
terminate the connection with an "unexpected_message" alert.
Paragraph (version B):
This alert is sent by the client to indicate that all 0-RTT
application_data messages have been transmitted (or none will be
sent at all) and that this is the end of the flight.  This alert
MUST be at the warning level.  Servers MUST NOT send this alert
and clients receiving it MUST terminate the connection with an
"unexpected_message" alert.
Draft: draft-ietf-tls-tls13

Commentary: … inconsistencies around string presentation
Paragraph (version A):
Following that padding is a NUL-terminated context string in order to
disambiguate signatures for different purposes.  The context string
will be specified whenever a digitally-signed element is used.
Paragraph (version B):
Following that padding is a context string used to disambiguate
signatures for different purposes.  The context string will be
specified whenever a digitally-signed element is used.  A single 0
byte is appended to the context to act as a separator.
Draft: draft-ietf-tls-tls13

Commentary: Per a question by Ilari
Paragraph (version A):
The client's cryptographic determining parameters match the
parameters that the server has negotiated based on the rest of the
ClientHello.
Paragraph (version B):
The client's cryptographic determining parameters match the
parameters that the server has negotiated based on the rest of the
ClientHello.  If (EC)DHE is selected, this includes verifying that
(1) the ClientHello contains a key from the same group that is
indicated by the server configuration and (2) that the server has
negotiated that group and will therefore include a share from that
group in its own "key_share" extension.
Draft: draft-ietf-tls-tls13

Commentary: did a massive message - alert change a while back and I did yet more when we were rebasing his patch . Looks like there 's more up here in Closure Alerts . We 're referring to alerts , not the messages that carry them . Switch to " alerts " instead to remain consistent with the rest of the document , notably the following section .
Paragraph (version A):
This message notifies the recipient that the sender will not send
any more messages on this connection.  Any data received after a
closure MUST be ignored.
Paragraph (version A):
This message is sent by the client to indicate that all 0-RTT
application_data messages have been transmitted and that the next
message will be handshake message protected with the 1-RTT
handshake keys.  This alert MUST be at the warning level.  Servers
MUST NOT send this message and clients receiving this message MUST
terminate the connection with an "unexpected_message" alert.
Paragraph (version A):
This message notifies the recipient that the sender is canceling
the handshake for some reason unrelated to a protocol failure.  If
a user cancels an operation after the handshake is complete, just
closing the connection by sending a "close_notify" is more
appropriate.  This alert SHOULD be followed by a "close_notify".
This alert is generally a warning.
Paragraph (version B):
This alert notifies the recipient that the sender will not send
any more messages on this connection.  Any data received after a
closure MUST be ignored.
Paragraph (version B):
This alert is sent by the client to indicate that all 0-RTT
application_data messages have been transmitted and that the next
message will be handshake message protected with the 1-RTT
handshake keys.  This alert MUST be at the warning level.  Servers
MUST NOT send this alert and clients receiving this alert MUST
terminate the connection with an "unexpected_message" alert.
Paragraph (version B):
This alert notifies the recipient that the sender is canceling the
handshake for some reason unrelated to a protocol failure.  If a
user cancels an operation after the handshake is complete, just
closing the connection by sending a "close_notify" is more
appropriate.  This alert SHOULD be followed by a "close_notify".
This alert is generally a warning.
Draft: draft-ietf-tls-tls13

Commentary: This cleans up some of the text around EarlyDataIndication that was introduced previously . 
 The early data indication parameters are defined as clientauthentication(1 ) , earlydata(2 ) , and clientauthenticationanddata(3 ) . A few paragraph after that , some text refers to them by what was probably an old name : If TLS client authentication is being used , then either " earlyhandshake " or " earlyhandshakeand_data " MUST be indicated in order to send the client authentication data on the first flight . Easy fix ... 
 See 
 This should now be fixed .
Paragraph (version A):
0-RTT messages sent in the first flight have the same content types
as their corresponding messages sent in other flights (handshake,
application_data, and alert respectively) but are protected under
different keys.  After all the 0-RTT application data messages (if
any) have been sent, a "end_of_early_data" alert of type "warning" is
sent to indicate the end of the flight.
Paragraph (version B):
0-RTT messages sent in the first flight have the same content types
as their corresponding messages sent in other flights (handshake,
application_data, and alert respectively) but are protected under
different keys.  After all the 0-RTT application data messages (if
any) have been sent, a "end_of_early_data" alert of type "warning" is
sent to indicate the end of the flight.  Clients which do 0-RTT MUST
always send "end_of_early_data" even if the ServerConfiguration
indicates that no application data is allowed (EarlyDataType of
"client_authentication"), though in that case it MUST NOT send any
non-empty data records (i.e., those which consist of anything other
than padding).
Paragraph (version A):
The client MUST send a Certificate message whenever the server has
requested client authentication via a CertificateRequest message
(certificate-request) or when the EarlyDataIndication indicates
client authentication.  This message is only sent if the server
requests a certificate.  If no suitable certificate is available,
the client MUST send a Certificate message containing no
certificates (i.e., with the "certificate_list" field having
length 0).
Paragraph (version B):
The client MUST send a Certificate message whenever the server has
requested client authentication via a CertificateRequest message
(certificate-request) or when the EarlyDataType provided with the
server configuration indicates a need for client authentication.
This message is only sent if the server requests a certificate via
one of these mechanisms.  If no suitable certificate is available,
the client MUST send a Certificate message containing no
certificates (i.e., with the "certificate_list" field having
length 0).
Draft: draft-ietf-tls-tls13

Commentary: This section has a strange table that looked a little messy . So I cleaned that up . However , I noticed that it used to say this : Which does n't make any sense . Should this be signature_algorithms extension instead ?
Paragraph (version A):
The certificate MUST allow the key to be used for signing (i.e.,
the digitalSignature bit MUST be set if the key usage extension is
present) with the signature scheme and hash algorithm that will be
employed in the server's KeyShare extension.
Paragraph (version B):
The certificate MUST allow the key to be used for signing (i.e.,
the digitalSignature bit MUST be set if the key usage extension is
present) with the signature scheme and hash algorithm that will be
employed in the server's signature_algorithms extension.
Draft: draft-ietf-tls-tls13

Commentary: When talking about handling downlevel clients , the spec variously says a server " MAY " receive such messages , or " may " receive such messages . Since this is discussing a possibility ( not a permitted behavior ) , the normative language is n't correct ; lower - case versions of the RFC2119 terms have the potential to confuse readers . Suggest changing all of these to " might " to denote a possible occurrence server implementers will need to handle . 
 Yes , this looks like an improvement . 
 LGTM
Paragraph (version A):
Versions of TLS before 1.3 supported compression and the list of
compression methods was supplied in this field.  For any TLS 1.3
ClientHello, this vector MUST contain exactly one byte set to
zero, which corresponds to the "null" compression method in prior
versions of TLS.  If a TLS 1.3 ClientHello is received with any
other value in this field, the server MUST generate a fatal
"illegal_parameter" alert.  Note that TLS 1.3 servers may receive
TLS 1.2 or prior ClientHellos which contain other compression
methods and MUST follow the procedures for the appropriate prior
version of TLS.
Paragraph (version B):
Versions of TLS before 1.3 supported compression and the list of
compression methods was supplied in this field.  For any TLS 1.3
ClientHello, this vector MUST contain exactly one byte set to
zero, which corresponds to the "null" compression method in prior
versions of TLS.  If a TLS 1.3 ClientHello is received with any
other value in this field, the server MUST generate a fatal
"illegal_parameter" alert.  Note that TLS 1.3 servers might
receive TLS 1.2 or prior ClientHellos which contain other
compression methods and MUST follow the procedures for the
appropriate prior version of TLS.
Paragraph (version A):
Note: TLS 1.3 servers MAY receive TLS 1.2 ClientHellos which do not
contain this extension.  If those servers are willing to negotiate
TLS 1.2, they MUST behave in accordance with the requirements of
RFC5246 when negotiating that version.
Paragraph (version B):
Note: TLS 1.3 servers might receive TLS 1.2 ClientHellos which do not
contain this extension.  If those servers are willing to negotiate
TLS 1.2, they MUST behave in accordance with the requirements of
RFC5246 when negotiating that version.
Draft: draft-ietf-tls-tls13

Commentary: I manually rebased and merged .
Paragraph (version A):
Versions of TLS prior to TLS 1.3 supported a session resumption
feature which has been merged with Pre-Shared Keys in this version
(see resumption-and-psk).  This field MUST be ignored by a server
negotiating TLS 1.3 and should be set as a zero length vector
(i.e., a single zero byte length field) by clients which do not
have a cached session_id set by a pre-TLS 1.3 server.
Paragraph (version B):
Versions of TLS before TLS 1.3 supported a session resumption
feature which has been merged with Pre-Shared Keys in this version
(see resumption-and-psk).  This field MUST be ignored by a server
negotiating TLS 1.3 and SHOULD be set as a zero length vector
(i.e., a single zero byte length field) by clients which do not
have a cached session ID set by a pre-TLS 1.3 server.
Paragraph (version A):
Versions of TLS before 1.3 supported compression and the list of
compression methods was supplied in this field.  For any TLS 1.3
ClientHello, this field MUST contain only the "null" compression
method with the code point of 0.  If a TLS 1.3 ClientHello is
received with any other value in this field, the server MUST
generate a fatal "illegal_parameter" alert.  Note that TLS 1.3
servers may receive TLS 1.2 or prior ClientHellos which contain
other compression methods and MUST follow the procedures for the
appropriate prior version of TLS.
Paragraph (version B):
Versions of TLS before 1.3 supported compression and the list of
compression methods was supplied in this field.  For any TLS 1.3
ClientHello, this vector MUST contain exactly one byte set to
zero, which corresponds to the "null" compression method in prior
versions of TLS.  If a TLS 1.3 ClientHello is received with any
other value in this field, the server MUST generate a fatal
"illegal_parameter" alert.  Note that TLS 1.3 servers may receive
TLS 1.2 or prior ClientHellos which contain other compression
methods and MUST follow the procedures for the appropriate prior
version of TLS.
Draft: draft-ietf-tls-tls13

Commentary: The current text is a mix of omitting and sending empty , as pointed out by Ilari on the mailing list . This fixes things and switches to an always - send model . 
 This looks good to me modulo the issue noted above 
 Ok , I 've pushed a second commit here which clarifies that point and also reconciles the fact that the two extensions here both claim to determine group priority . Suggestions to reduce verbosity without reducing clarity would be appreciated . ( this commit fixes issue ) 
 Typo fixed & rebased . 
 Since the list is in favor of " forward secrecy " over " forward security " , I 've changed my use of the term in this PR to the former ( a commit just landed to change the existing uses elsewhere ) . Not rebased again ; still merges cleanly ( for the moment , at least ) .
Paragraph (version A):
Clients offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters.  For instance,
a client might offer shares for several elliptic curves or multiple
integer DH groups.  The key_exchange values for each KeyShareEntry
MUST by generated independently.  Clients MUST NOT offer multiple
KeyShareEntry values for the same parameters.  Clients and servers
MUST NOT offer any KeyShareEntry values for groups not listed in the
client's "supported_groups" extension.  Servers MUST NOT offer a
KeyShareEntry value for a group not offered by the client in its
corresponding KeyShare.
Paragraph (version B):
Clients offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters.  For instance,
a client might offer shares for several elliptic curves or multiple
integer DH groups.  The key_exchange values for each KeyShareEntry
MUST by generated independently.  Clients MUST NOT offer multiple
KeyShareEntry values for the same parameters.  Clients and servers
MUST NOT offer any KeyShareEntry values for groups not listed in the
client's "supported_groups" extension.  Servers MUST NOT offer a
KeyShareEntry value for a group not offered by the client in its
corresponding KeyShare.  Implementations receiving any KeyShare
containing any of these prohibited values MUST abort the connection
with a fatal "illegal_parameter" alert.
Draft: draft-ietf-tls-tls13

Commentary: We should generate each traffic key on its own
Paragraph (version A):
The Record Protocol requires an algorithm to generate keys required
by the current connection state (see the-security-parameters) from
the security parameters provided by the handshake protocol.
Paragraph (version A):
A string label that indicates the purpose of keys being generated.
Paragraph (version A):
The total length in octets of the key block.
Paragraph (version B):
A phase value indicating the phase of the protocol the keys are
being generated for.
Paragraph (version B):
The length of the key.