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

Commentary: Hello is slightly confusing english . Must this be generated from the I 'm pretty sure the opposite is the intent . A clearer form of words might be : or 
 Merged .
Paragraph (version A):
This structure is generated by the server and MUST be
independently generated from the ClientHello.random.
Paragraph (version B):
This structure is generated by the server and MUST be generated
independently of the ClientHello.random.
Draft: draft-ietf-tls-tls13

Commentary: It has a proper definition in appendix A.4 . Note though that RFC 4507 section 7 has allocated this value for the session_ticket / NewSessionTicket handshake type . This point may be moot if RFC 4507 has been integrated with TLS 1.3 , in which case RFC 4507 should be to the list of obsoleted RFCs . 
 The handshake packets in TLS 1.2 and earlier are numbered so that the HandshakeType for each of client and server is strictly increasing when packets arrive in correct order , and HandshakeType/10 indicates the flight number . This allows for using a simpler state - machine . The new handshake packets { server , client}keyshare break this convention by using numbers in the flight 2 range ( 17 & 18 ) , while belonging in flight 1 . This suggestion is to renumber them to eg clientkeyshare(5 ) and serverkeyshare(6 )
Paragraph (version B):
Renumber the new handshake messages to be somewhat more consistent
with existing convention and to remove a duplicate registration.
Draft: draft-ietf-tls-tls13

Commentary: TLS 1.1 [ RFC 4346 ] & TLS 1.2 [ RFC 5246 ] each only have a list of changes from the immediately previous version . This current draft has both the current changelog since TLS 1.2 and the old list of changes from TLS 1.1 to 1.2 . The contents of this old section are no longer relevant , in particular it mentions TLSRSAWITHAES128CBCSHA as MTI which is no longer permitted at all . Suggesting just removing this now . 
 Thanks . Merged .
Paragraph (version A):
The MD5/SHA-1 combination in the pseudorandom function (PRF) has
been replaced with cipher-suite-specified PRFs.  All cipher suites
in this document use P_SHA256.
Paragraph (version A):
The MD5/SHA-1 combination in the digitally-signed element has been
replaced with a single hash.  Signed elements now include a field
that explicitly specifies the hash algorithm used.
Paragraph (version A):
Substantial cleanup to the client's and server's ability to
specify which hash and signature algorithms they will accept.
Note that this also relaxes some of the constraints on signature
and hash algorithms from previous versions of TLS.
Paragraph (version A):
Addition of support for authenticated encryption with additional
data modes.
Paragraph (version A):
TLS Extensions definition and AES Cipher Suites were merged in
from external TLSEXT and RFC3268.
Paragraph (version A):
Tighter checking of EncryptedPreMasterSecret version numbers.
Paragraph (version A):
Tightened up a number of requirements.
Paragraph (version A):
Verify_data length now depends on the cipher suite (default is
still 12).
Paragraph (version A):
Cleaned up description of Bleichenbacher/Klima attack defenses.
Paragraph (version A):
Alerts MUST now be sent in many cases.
Paragraph (version A):
After a certificate_request, if no certificates are available,
clients now MUST send an empty certificate list.
Paragraph (version A):
TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
cipher suite.
Paragraph (version A):
Added HMAC-SHA256 cipher suites.
Paragraph (version A):
Removed IDEA and DES cipher suites.  They are now deprecated and
will be documented in a separate document.
Paragraph (version A):
Support for the SSLv2 backward-compatible hello is now a MAY, not
a SHOULD, with sending it a SHOULD NOT.  Support will probably
become a SHOULD NOT in the future.
Paragraph (version A):
Added limited "fall-through" to the presentation language to allow
multiple case arms to have the same encoding.
Paragraph (version A):
The usual clarifications and editorial work.
Draft: draft-ietf-tls-tls13

Commentary: MT , please double - check 
 Should remove Dierks . 
 LGTM
Paragraph (version B):
Note: Versions of TLS prior to TLS 1.3 used the top 32 bits of the
Random value to encode the time since the UNIX epoch.
Paragraph (version A):
If the client supplies a Supported Points Formats Extension in the
ClientHello, the server may send its own Supported Points Format
extension in the ServerHello.  This extension allows a server to
enumerate the point formats it can parse (for the curve that will
appear in its ServerKeyExchange message when using the ECDHE_ECDSA,
ECDHE_RSA, or ECDH_anon key exchange algorithm, or for the curve that
is used in the server's public key that will appear in its
Certificate message when using the ECDH_ECDSA or ECDH_RSA key
exchange algorithm).
Paragraph (version B):
If the client supplies a Supported Points Formats Extension in the
ClientHello, the server may send its own Supported Points Format
extension in the ServerHello.  This extension allows a server to
enumerate the point formats it can parse (for the curve that will
appear in its ServerKeyExchange message when using the ECDHE_ECDSA or
ECDHE_RSA key exchange algorithm, or for the curve that is used in
the server's public key that will appear in its Certificate message
when using the ECDH_ECDSA or ECDH_RSA key exchange algorithm).
Paragraph (version A):
An endpoint that receives a ServerHello message containing a
Supported Point Formats Extension MUST respect the sender's choice of
point formats during the handshake.  If no Supported Point Formats
Extension is received this is equivalent to an extension allowing
only the uncompressed point format.
Paragraph (version B):
An endpoint that receives a hello message containing a Supported
Point Formats Extension MUST respect the sender's choice of point
formats during the handshake.  If no Supported Point Formats
Extension is received this is equivalent to an extension allowing
only the uncompressed point format.
Draft: draft-ietf-tls-tls13

Commentary: In order to support aead suites that pad or otherwise modify length , we need to stop using the plaintext length in the aead input . An implied requirement on the cipher is to validate length . 
 : +1 : Also note that I have also opened a documentation errata for TLS 1.2 related to this . (  ID : 2390 , ) 
 It 's been observed a number of times that the AEAD cipher suite definitions do n't actually accommodate ciphers which pad . See : We should either fix this or remove padding .
Paragraph (version B):
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: A number of people have suggested this to reduce fingerprinting surface . 
 Needs to be removed from server and client , as mentioned in draft - mathewson - no - gmtunixtime , because DTLS ( and TLS ) are used with WebRTC / SIP / XMPP peer - to - peer communication . 
 I will be removing this shortly per the chair 's declaration of conesnsus at :
Paragraph (version B):
Remove GMT time.
Paragraph (version A):
The current time and date in standard UNIX 32-bit format (seconds
since the midnight starting Jan 1, 1970, UTC, ignoring leap
seconds) according to the sender's internal clock.  Clocks are not
required to be set correctly by the basic TLS protocol; higher-
level or application protocols may define additional requirements.
Note that, for historical reasons, the data element is named using
GMT, the predecessor of the current worldwide time base, UTC.
Paragraph (version A):
28 bytes generated by a secure random number generator.
Paragraph (version B):
32 bytes generated by a secure random number generator.
Draft: draft-ietf-tls-tls13

Commentary: This change clarifies that the signature over ServerDHParams data is a signature over the hash of the client + server hello random random data and the ServerDHParams data . I believe this small regression was introduced in TLS1.2 with the result that the TLS1.2 RFC ( and current TLS1.3 draft ) does not contain sufficient detail to implement TLS + DHE . All TLS1.2 clients and servers that I have tested do include the hello random data ( and omitting it would leave implementations open to replay attacks ) . 
 Thanks for the PR . Note that the formal PDU definitions here appear to be correct , so there should be enough information to implement things correctly : I agree it would n't hurt to have the explanatory text be clearer . However , in TLS 1.2 we stopped explicitly saying that things were hashed before signing ( because we are treating signing as a primitive ) , so we probably do n't want to say " hash " . Maybe just say a signature over the random values and the params ? 
 Ah , this explains my confusion . After reading section 7.4.1.4.1 , I formed the opposite impression about signing ; that hashing and signing are explicitly different primitive operations and may be composed in a variety of ways . But I see how that " digitally - signed " seems to be a reserved term that implies both operations . 
 I 'm not trying to discourage you here . If you were confused , others will probably be as well , so if you have some text that you think would clear this up , it would be welcome . 
 Thanks ! I 've updated the PR with an even simpler diff that I think would have made me less confused when I got to it .
Paragraph (version A):
For non-anonymous key exchanges, a signature over the server's key
exchange parameters.
Paragraph (version B):
For non-anonymous key exchanges, a signature over the client and
server hello random data and the server's key exchange parameters.
Draft: draft-ietf-tls-tls13

Commentary: The draft was in a sort of halfway state between whether TLSCiphertext has a fragment that is a selection or just embedding the AEAD elements directly . This should normalize it to the embedded view without the extra GenericAEADCipher struct definition . ( i do n't think this changes the logic of the draft at all )
Paragraph (version A):
Each AEAD cipher suite MUST specify how the nonce supplied to the
AEAD operation is constructed, and what is the length of the
GenericAEADCipher.nonce_explicit part.  In many cases, it is
appropriate to use the partially implicit nonce technique described
in Section 3.2.1 of RFC5116; with record_iv_length being the length
of the explicit part.  In this case, the implicit part SHOULD be
derived from key_block as client_write_iv and server_write_iv (as
described in key-calculation), and the explicit part is included in
GenericAEAEDCipher.nonce_explicit.
Paragraph (version B):
Each AEAD cipher suite MUST specify how the nonce supplied to the
AEAD operation is constructed, and what is the length of the
TLSCiphertext.nonce_explicit part.  In many cases, it is appropriate
to use the partially implicit nonce technique described in
Section 3.2.1 of RFC5116; with record_iv_length being the length of
the explicit part.  In this case, the implicit part SHOULD be derived
from key_block as client_write_iv and server_write_iv (as described
in key-calculation), and the explicit part is included in
GenericAEAEDCipher.nonce_explicit.
Draft: draft-ietf-tls-tls13

Commentary: I do n't think that this is valid any more .
Paragraph (version A):
DISCLAIMER: This document is simply a copy of RFC 5246 translated
into markdown format with no intentional technical or editorial
changes beyond updating the references and minor reformatting
introduced by the translation.  It is being submitted as-is to create
a clearer revision history for future versions.  Any errata in TLS
markdown translation.
Paragraph (version B):
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this
draft is maintained in GitHub.  Suggested changes should be submitted
as pull requests at https://github.com/tlswg/tls13-spec.
Instructions are on that page as well.  Editorial changes can be
managed in GitHub, but any substantive change should be discussed on
the TLS mailing list.