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

Commentary: The early_data extension should be listed as one of the few that ca n't go into EncryptedExtensions but must be sent with ServerHello .
Paragraph (version A):
A list of extensions.  Note that only extensions offered by the
client can appear in the server's list.  In TLS 1.3 as opposed to
previous versions of TLS, the server's extensions are split
between the ServerHello and the EncryptedExtensions encrypted-
extensions message.  The ServerHello MUST only include extensions
which are required to establish the cryptographic context.
Currently the only such extensions are "key_share" and
"pre_shared_key".  Clients MUST check the ServerHello for the
presence of any forbidden extensions and if any are found MUST
terminate the handshake with a "illegal_parameter" alert.
Paragraph (version B):
A list of extensions.  Note that only extensions offered by the
client can appear in the server's list.  In TLS 1.3 as opposed to
previous versions of TLS, the server's extensions are split
between the ServerHello and the EncryptedExtensions encrypted-
extensions message.  The ServerHello MUST only include extensions
which are required to establish the cryptographic context.
Currently the only such extensions are "key_share",
"pre_shared_key", and "early_data".  Clients MUST check the
ServerHello for the presence of any forbidden extensions and if
any are found MUST terminate the handshake with a
"illegal_parameter" alert.
Draft: draft-ietf-tls-tls13

Commentary: This addresses  's comment from . We do n't use " octet length " anywhere else in the document .
Paragraph (version A):
In RSA signing, the opaque vector contains the signature generated
using the RSASSA-PSS signature scheme defined in RFC3447 with MGF1.
The digest used in the mask generation function MUST be the same as
the digest which is being signed (i.e., what appears in
algorithm.signature).  The length of the salt MUST be equal to the
octet length of the digest output.  Note that previous versions of
TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS.
Paragraph (version B):
In RSA signing, the opaque vector contains the signature generated
using the RSASSA-PSS signature scheme defined in RFC3447 with MGF1.
The digest used in the mask generation function MUST be the same as
the digest which is being signed (i.e., what appears in
algorithm.signature).  The length of the salt MUST be equal to the
length of the digest output.  Note that previous versions of TLS used
RSASSA-PKCS1-v1_5, not RSASSA-PSS.
Draft: draft-ietf-tls-tls13

Commentary: Starts in this thread : spt 
 It 's the nonce after all .
Mailing list commentary: I do n't believe that there 's any reason to include the sequence number in the AD input of an AEAD . I think that an empty AD for TLS would be fine now that the content type is encrypted . ( Not that I deeply care either way . ) Cheers AGL
Paragraph (version B):
Remove sequence number and version from additional_data, which is
now empty.
Draft: draft-ietf-tls-tls13

Commentary: I think that the decision was to make this mandatory , since present - but - empty is harder to screw up . 
 Section 6.2 Figure 1 and others show messages as non - optional . Section 6.3.3 however states that : It seems that the message could indeed be omitted if the server does n't need to respond with any extensions , but I may be wrong here . We should fix one of the two places though as they contradict each other .
Paragraph (version A):
If this message is sent, it MUST be sent immediately after the
ServerHello message.  This is the first message that is encrypted
under keys derived from ES.
Paragraph (version B):
The EncryptedExtensions message MUST be sent immediately after the
ServerHello message.  This is the first message that is encrypted
under keys derived from ES.
Draft: draft-ietf-tls-tls13

Commentary: ready for merge ? 
 Merging per discussion with 
 It 's the nonce after all .
Paragraph (version A):
AEAD ciphers take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as
described in Section 2.1 of RFC5116.  The key is either the
client_write_key or the server_write_key.
Paragraph (version B):
AEAD ciphers take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as
described in Section 2.1 of RFC5116.  The key is either the
client_write_key or the server_write_key and in TLS 1.3 the
additional data input is empty (zero length).
Paragraph (version A):
where "+" denotes concatenation.
Paragraph (version A):
Note: In versions of TLS prior to 1.3, the additional_data included a
length field.  This presents a problem for cipher constructions with
data-dependent padding (such as CBC).  TLS 1.3 removes the length
field and relies on the AEAD cipher to provide integrity for the
length of the data.
Draft: draft-ietf-tls-tls13

Commentary: etc . in an example or after such as can be removed .
Paragraph (version A):
The connection is private.  Symmetric cryptography is used for
data encryption (e.g., AES AES, etc.).  The keys for this
symmetric encryption are generated uniquely for each connection
and are based on a secret negotiated by another protocol (such as
the TLS Handshake Protocol).
Paragraph (version B):
The connection is private.  Symmetric cryptography is used for
data encryption (e.g., AES AES).  The keys for this symmetric
encryption are generated uniquely for each connection and are
based on a secret negotiated by another protocol (such as the TLS
Handshake Protocol).
Paragraph (version A):
The peer's identity can be authenticated using asymmetric, or
public key, cryptography (e.g., RSA RSA, ECDSA ECDSA, etc.).  This
authentication can be made optional, but is generally required for
at least one of the peers.
Paragraph (version B):
The peer's identity can be authenticated using asymmetric, or
public key, cryptography (e.g., RSA RSA, ECDSA ECDSA).  This
authentication can be made optional, but is generally required for
at least one of the peers.
Paragraph (version A):
If the server has multiple certificates, it chooses one of them based
on the above-mentioned criteria (in addition to other criteria, such
as transport layer endpoint, local configuration and preferences,
etc.).  If the server has a single certificate, it SHOULD attempt to
validate that it meets these criteria.
Paragraph (version B):
If the server has multiple certificates, it chooses one of them based
on the above-mentioned criteria (in addition to other criteria, such
as transport layer endpoint, local configuration and preferences).
If the server has a single certificate, it SHOULD attempt to validate
that it meets these criteria.
Draft: draft-ietf-tls-tls13

Commentary: Fix spacing to match other flow charts & fix one KeyShare - KeyShareEntry that was missed .
Paragraph (version A):
A single KeyShareEntry value for the negotiated cipher suite.
Servers MUST NOT send a KeyShare for a group not offered by the
client.
Paragraph (version B):
A single KeyShareEntry value for the negotiated cipher suite.
Servers MUST NOT send a KeyShareEntry value for a group not
offered by the client.
Draft: draft-ietf-tls-tls13

Commentary: The RSA - PSS salt length seems to be missing from the specification . The original post on the mailing list and a few other sources propose that where is the length of the digest output in bytes . Should this be raised on the mailing list again or was this agreed on already ? 
 Let 's just do it the way you propose . PR welcome
Paragraph (version A):
In RSA signing, the opaque vector contains the signature generated
using the RSASSA-PSS signature scheme defined in RFC3447 with MGF1.
The digest used in the mask generation function MUST be the same as
the digest which is being signed (i.e., what appears in
algorithm.signature).  Note that previous versions of TLS used
RSASSA-PKCS1-v1_5, not RSASSA-PSS.
Paragraph (version B):
In RSA signing, the opaque vector contains the signature generated
using the RSASSA-PSS signature scheme defined in RFC3447 with MGF1.
The digest used in the mask generation function MUST be the same as
the digest which is being signed (i.e., what appears in
algorithm.signature).  The length of the salt MUST be equal to the
octet length of the digest output.  Note that previous versions of
TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS.
Draft: draft-ietf-tls-tls13

Commentary: The struct contains a value named handshakehash , not sessionhash . I apparently had fixed this in PR . Pulling it out separately to get it in now , as it has n't even been decided for sure if we 're doing that .
Paragraph (version A):
Where session_hash is as described in the-handshake-hash and
includes the messages sent or received, starting at ClientHello
and up to, but not including, this message, including the type and
length fields of the handshake messages.  This is a digest of the
concatenation of all the Handshake structures (as defined in
handshake-protocol) exchanged thus far.  The digest MUST be the
Hash used as the basis for HKDF.
Paragraph (version B):
Where handshake_hash is as described in the-handshake-hash and
includes the messages sent or received, starting at ClientHello
and up to, but not including, this message, including the type and
length fields of the handshake messages.  This is a digest of the
concatenation of all the Handshake structures (as defined in
handshake-protocol) exchanged thus far.  The digest MUST be the
Hash used as the basis for HKDF.
Draft: draft-ietf-tls-tls13

Commentary: Chairs have judged that there is consensus to merge , see :
Mailing list commentary: It looks like we have rough consensus to accept this PR . We should make sure we note the limitations that brought up for PSK and RSA , . Procedurally , we should document the requirements for TLS 1.2 in a separate draft to update TLS 1.2 in parallel . This may be necessary to get us out of the situation where we have to update and obsolete a specification at the same time . Thanks , J&S
Paragraph (version A):
TLS 1.3 server implementations which respond to a ClientHello with a
client_version indicating TLS 1.2 or below MUST set the first eight
bytes of its Random value to the bytes 44 4F 57 4E 47 52 44 01.  TLS
the top eight octets are not equal to either this value or 44 4F 57
4E 47 52 44 00 (which SHOULD by used by TLS 1.2 servers which are
negotiating TLS 1.1 or below).  If a match is found the client MUST
abort the handshake with a fatal "illegal_parameter" alert.  This
mechanism provides limited protection against downgrade attacks over
and above that provided by the Finished exchange: because the
ServerKeyExchange includes a signature over both random values, it is
not possible for an active attacker to modify the randoms without
detection as long as ephemeral ciphers are used.  It does not provide
downgrade protection when static RSA is used.
Paragraph (version B):
TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check
that the top eight octets are not equal to either of these values.
TLS 1.2 clients SHOULD also perform this check if the ServerHello
indicates TLS 1.1 or below.  If a match is found the client MUST
abort the handshake with a fatal "illegal_parameter" alert.  This
mechanism provides limited protection against downgrade attacks over
and above that provided by the Finished exchange: because the
ServerKeyExchange includes a signature over both random values, it is
not possible for an active attacker to modify the randoms without
detection as long as ephemeral ciphers are used.  It does not provide
downgrade protection when static RSA is used.
Paragraph (version B):
Note: This is an update to TLS 1.2 so in practice many TLS 1.2
clients and servers will not behave as specified above.
Draft: draft-ietf-tls-tls13

Commentary: LGTM 
   writes : And how does the client know that the algorithms came from the server . We should have a " client  wait for the full handshake to finish before recording this information " or we will have a very nice cipher downgrade . Just having it signed is likely not a good idea , as they may depend on ciphersuites advertised by client . 
 Since the ServerConfiguration and the suites are covered by the signature the server provides , is n't it safe to use the configuration add soon as you have verified the server identity ? 
 n.b . , I have no problem with mandating that clients wait for finished , because it is immediately after the signature , but I was n't the properties to be clear .
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.
Paragraph (version B):
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.
Draft: draft-ietf-tls-tls13

Commentary: LGTM 
 This was always a hack . We should just remove mention of this as a " cipher suite " and just talk about certain messages being encrypted and others not . 
 If issue is done , then I think the only cleartext messages left would be the 3 hello messages : ClientHello , ServerHello , & HelloRetryRequest . TLSPlaintext could then just be renamed to TLSHelloRecord , which would make the distinction between cleartext and encrypted records relatively easy . 
 I agree that this psuedo - cipher - suite should be removed . It is confusing . Some implementations may work in a way where they implement some TLSNULLNULLWITHNULL _ ...   , but that 's an implementation detail . Other implementations , particularly implementations that do n't do renegotiation , likely wo n't work like that .
Paragraph (version B):
When record protection has not yet been engaged, TLSPlaintext
structures are written directly onto the wire.  Once record
protection has started, TLSPlaintext records are protected and sent
as described in the following section.
Draft: draft-ietf-tls-tls13

Commentary: … che ) . 
 Aside from the little nits and typo , the text itself looks good to me .
Paragraph (version A):
The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document
except DH_anon and PSK).  This message will always immediately
follow the EncryptedExtensions message.
Paragraph (version B):
The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document
except PSK).  This message will always immediately follow the
EncryptedExtensions message.
Draft: draft-ietf-tls-tls13

Commentary: missed one " key agreement " -"key exchange "
Paragraph (version A):
These cipher suites MUST support both digital signatures and key
exchange with secp256r1 (NIST P-256) and SHOULD support key agrement
with X25519 I-D.irtf-cfrg-curves.
Paragraph (version B):
These cipher suites MUST support both digital signatures and key
exchange with secp256r1 (NIST P-256) and SHOULD support key exchange
with X25519 I-D.irtf-cfrg-curves.
Draft: draft-ietf-tls-tls13

Commentary: please confirm this matches consensus 
 Now that we are removing static RSA cipher suites , we need a new MTI cipher suite . 
 From Sean 's mail o Symmetric : MUST AES - GCM 128 [ SHOULD ChaCha20 - Poly1305 ] o Hash : MUST SHA-256 o Key Agreement : ECDH MUST P-256 [ SHOULD ] o Signature : MUST ECDSA P-256 MUST RSA 
 Dear Mr. currently I 'm very interested in studying non - repudiation , then I found S - HTTP ( RFC 2660 ) that offer non - repudiation security service . I also found that AS2 ( RFC 4130 ) also offers this kind of service , but then I wonder why non - repudiation service is not becoming ubiquotus ? Why AEAD replace HMAC , does hash function is too heavy , or hash is more appropriate for digital signature world ? Thanks
Paragraph (version B):
Add MTI algorithms.
Paragraph (version A):
Clients may offer an arbitrary number of ClientKeyShareOffer values,
each representing a single set of key agreement parameters; for
instance a client might offer shares for several elliptic curves or
multiple integer DH groups.  The shares for each ClientKeyShareOffer
MUST by generated independently.  Clients MUST NOT offer multiple
ClientKeyShareOffers for the same parameters.  It is explicitly
permitted to send an empty "client_key_share" extension as this is
used to elicit the server's parameters if the client has no useful
information.
Paragraph (version B):
Clients may offer an arbitrary number of ClientKeyShareOffer 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 shares for each ClientKeyShareOffer
MUST by generated independently.  Clients MUST NOT offer multiple
ClientKeyShareOffers for the same parameters.  It is explicitly
permitted to send an empty "client_key_share" extension as this is
used to elicit the server's parameters if the client has no useful
information.
Paragraph (version A):
In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and
the client and server random values.  The authentication, key
agreement, and record protection algorithms are determined by the
cipher_suite selected by the server and revealed in the ServerHello
message.  The random values are exchanged in the hello messages.  All
that remains is to calculate the key schedule.
Paragraph (version B):
In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and
the client and server random values.  The authentication, key
exchange, and record protection algorithms are determined by the
cipher_suite selected by the server and revealed in the ServerHello
message.  The random values are exchanged in the hello messages.  All
that remains is to calculate the key schedule.
Paragraph (version B):
These cipher suites MUST support both digital signatures and key
exchange with secp256r1 (NIST P-256) and SHOULD support key agrement
with X25519 I-D.irtf-cfrg-curves.
Draft: draft-ietf-tls-tls13

Commentary: Just a quick PR to add today 's major changes to the log . 
 Thanks
Paragraph (version B):
Add support for per-record padding.
Paragraph (version B):
Switch to encrypted record ContentType.
Paragraph (version B):
Change HKDF labeling to include protocol version and value
lengths.
Draft: draft-ietf-tls-tls13

Commentary: Missing semi - colon in the message definition . Also , the signature_algorithms of the client are what matter .
Paragraph (version A):
The signature algorithm and hash algorithm MUST be a pair offered
in the "signature_algorithms" extension (see signature-
algorithms).  Note that there is a possibility for inconsistencies
here.  For instance, the client might offer DHE_DSS key exchange
but omit any DSA pairs from its "signature_algorithms" extension.
In order to negotiate correctly, the server MUST check any
candidate cipher suites against the "signature_algorithms"
extension before selecting them.  This is somewhat inelegant but
is a compromise designed to minimize changes to the original
cipher suite design.
Paragraph (version B):
The signature algorithm and hash algorithm MUST be a pair offered
in the client's "signature_algorithms" extension (see signature-
algorithms).  Note that there is a possibility for inconsistencies
here.  For instance, the client might offer DHE_DSS key exchange
but omit any DSA pairs from its "signature_algorithms" extension.
In order to negotiate correctly, the server MUST check any
candidate cipher suites against the "signature_algorithms"
extension before selecting them.  This is somewhat inelegant but
is a compromise designed to minimize changes to the original
cipher suite design.
Draft: draft-ietf-tls-tls13

Commentary: The current wording at the end of the section on resumption and PSK should be changed to indicate that if a server declines resumption then a full handshake , including the server Certificate and CertificateVerify messages , should take place . In its current state , the comment on omission of these messages is not disjoint from the statement regarding the server 's rejection of resumption .
Paragraph (version A):
Note that the client supplies a ClientKeyShare to the server as well,
which allows the server to decline resumption and fall back to a full
handshake.  However, because the server is authenticating via a PSK,
it does not send a Certificate or a CertificateVerify.  PSK-based
resumption cannot be used to provide a new ServerConfiguration.
Paragraph (version B):
As the server is authenticating via a PSK, it does not send a
Certificate or a CertificateVerify.  PSK-based resumption cannot be
used to provide a new ServerConfiguration.  Note that the client
supplies a ClientKeyShare to the server as well, which allows the
server to decline resumption and fall back to a full handshake.
Draft: draft-ietf-tls-tls13

Commentary: Quick PR for fix noted for PR plus a couple other small nits . Still on draft 08 . Fix a typo . ( " permittion " is not a word ) Consistently use spaces around the " + " in " 2 ^ 14 + 256 " . ( some did ; some did n't )
Paragraph (version A):
The maximum permittion record expansion for AEAD has been reduced
from 2048 to 256 octets.
Paragraph (version B):
Reduce maximum permitted record expansion for AEAD from 2048 to
256 octets.
Paragraph (version A):
An AEAD cipher MUST NOT produce an expansion of greater than 256
bytes.  An endpoint that receives a record that is larger than
2^14+256 octets MUST generate a fatal "record_overflow" alert.
Paragraph (version B):
An AEAD cipher MUST NOT produce an expansion of greater than 256
bytes.  An endpoint that receives a record that is larger than 2^14 +
256 octets MUST generate a fatal "record_overflow" alert.
Paragraph (version A):
A TLSCiphertext record was received that had a length more than
2^14+256 bytes, or a record decrypted to a TLSPlaintext record
with more than 2^14 bytes.  This alert is always fatal and should
never be observed in communication between proper implementations
(except when messages were corrupted in the network).
Paragraph (version B):
A TLSCiphertext record was received that had a length more than
2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record
with more than 2^14 bytes.  This alert is always fatal and should
never be observed in communication between proper implementations
(except when messages were corrupted in the network).