jiebi/TextFlow huggingface dataset:
Original text:
Structure of this message: %%% Authentication Messages struct { digitally-signed struct { opaque <del> handshake_hash[hash_length]; } } CertificateVerify; </del>  Where session_hash is as described in the-handshake-hash and includes the messages sent or received, starting at ClientHello for CertificateVerify, Finished and other messages. The signature algorithm and hash algorithm MUST be a pair offered <del> in the "signature_algorithms" extension (see signature- </del>  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.

Reviewer comments:
Missing semi-colon in the message definition. Also, the signature_algorithms of the client are what matter.

Revised text:
Structure of this message: %%% Authentication Messages struct { digitally-signed struct { opaque  <ins> handshake_hash[hash_length]; }; } CertificateVerify; </ins> Where session_hash is as described in the-handshake-hash and includes the messages sent or received, starting at ClientHello for CertificateVerify, Finished and other messages. The signature algorithm and hash algorithm MUST be a pair offered  <ins> in the client's "signature_algorithms" extension (see signature- </ins> 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.
Original text:
1.2 remain in this version.  Thanks to Mark Nottingham for doing the markdown translation.  The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications.  The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake

Reviewer comments:
Provide a temporary URL in the draft for people wanting to submit pull requests, so that they don't have to search the archives for Sean's message from April 17.
We should probably wrap long lines that reviewing is a little easier. The rest of the doc wraps at 80.

Revised text:
1.2 remain in this version.  Thanks to Mark Nottingham for doing the markdown translation. <ins> [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. </ins> The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications.  The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake
Original text:
All ECDSA computations MUST be performed according to ANSI X9.62 X962 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional <del> hashing.  The default hash function is SHA-1 SHS.  However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-4 SHS SHOULD be used instead if the certificate containing the EC public key explicitly requires use of another hash function.  (The mechanism for specifying the required hash function has not been standardized, but this provision anticipates such standardization and obviates the need to update this document in response.  Future PKIX RFCs may choose, for example, to specify the hash function to be used with a public key in the parameters field of subjectPublicKeyInfo.)  [[OPEN ISSUE: This needs updating per 4492-bis https://github.com/tlswg/tls13-spec/issues/59]]. </del>  In the following example be used with any permitted hash algorithm, subject to restrictions in the certificate, if any.  RSA signatures MUST be based on RSASSA-PSS, regardless of whether RSASSA-PKCS-v1_5 appears in  "signature_algorithms". 6.3.9. permitted hash algorithm, subject to restrictions in the certificate, if any.  RSA signatures MUST be based on RSASSA-PSS, regardless of whether RSASSA-PKCS-v1_5 appears in  "signature_algorithms". 6.3.12.

Reviewer comments:
This completes the removal of SHA-1 for CertificateVerify. There's no reason to allow it there at all
LGTM

Revised text:
All ECDSA computations MUST be performed according to ANSI X9.62 X962 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional  <ins> hashing.  The SignatureAndHashAlgorithm parameter in the DigitallySigned object indicates the digest algorithm which was used in the signature. </ins> In the following example be used with any permitted hash algorithm, subject to restrictions in the certificate, if any.  RSA signatures MUST be based on RSASSA-PSS, regardless of whether RSASSA-PKCS-v1_5 appears in <ins> "signature_algorithms".  SHA-1 MUST NOT be used in any signatures in CertificateVerify, regardless of whether SHA-1 appears in </ins> "signature_algorithms". 6.3.9. permitted hash algorithm, subject to restrictions in the certificate, if any.  RSA signatures MUST be based on RSASSA-PSS, regardless of whether RSASSA-PKCS-v1_5 appears in <ins> "signature_algorithms".  SHA-1 MUST NOT be used in any signatures in CertificateVerify, regardless of whether SHA-1 appears in </ins> "signature_algorithms". 6.3.12.
Original text:
sha1_RESERVED(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm;  Each SignatureAndHashAlgorithm value lists a single hash/signature pair that the client is willing to verify.  The values are indicated in descending order of preference.

Reviewer comments:
This is stated to exist in the definition for "signature", however the value wasn't actually added to the enum. ( URL )

Revised text:
sha1_RESERVED(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; <ins> [[TODO: IANA considerations for new SignatureAlgorithm value]] </ins> Each SignatureAndHashAlgorithm value lists a single hash/signature pair that the client is willing to verify.  The values are indicated in descending order of preference.
Original text:
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 <del> except DH_anon and PSK).  This message will always immediately follow the EncryptedExtensions message. </del>  Meaning of this message:

Reviewer comments:
…che).
Aside from the little nits and typo, the text itself looks good to me.

Revised text:
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  <ins> except PSK).  This message will always immediately follow the EncryptedExtensions message. </ins> Meaning of this message:
Original text:
fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure.  5.2.2. The record protection functions translate a TLSPlaintext structure maximum TLSPlaintext length of 2^14 octets + 1 octet for ContentType + the maximum AEAD expansion of 255 octets. <del> TODO: explain how TLS_NULL_WITH_NULL_NULL is not actually a cipher at all, and that in that state we should send raw TLSPlaintext instead of sending a phony TLSCiphertext </del> 5.2.3. All encrypted TLS records can be padded to inflate the size of the

Reviewer comments:
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_... cipher suite, but that's an implementation detail. Other implementations, particularly implementations that don't do renegotiation, likely won't work like that.

Revised text:
fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure. <ins> 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. </ins> 5.2.2. The record protection functions translate a TLSPlaintext structure maximum TLSPlaintext length of 2^14 octets + 1 octet for ContentType + the maximum AEAD expansion of 255 octets.  5.2.3. All encrypted TLS records can be padded to inflate the size of the
Original text:
TLSPlaintext or TLSCiphertext structures, which are processed and transmitted as specified by the current active session state. <del> %%% Handshake Protocol enum { reserved(0), client_hello(1), server_hello(2), session_ticket(4), hello_retry_request(6), server_key_share(7), encrypted_extensions(8), certificate(11), reserved(12), certificate_request(13), reserved(14), certificate_verify(15), reserved(16), server_configuration(17), finished(20), (255) } HandshakeType; </del>  The TLS Handshake Protocol messages are presented below in the order they MUST be sent; sending handshake messages in an unexpected order

Reviewer comments:
There are a couple of times the reserved values don't include the string "RESERVED". Can we either note this in the intro or add "RESERVED" to the appropriate places in ContentType and HandshakeType:
If we can remove all the fields suffixed by it would make the enums more easy to read. =)

Revised text:
TLSPlaintext or TLSCiphertext structures, which are processed and transmitted as specified by the current active session state.  <ins> %%% Handshake Protocol enum { hello_request_RESERVED(0), client_hello(1), server_hello(2), session_ticket(4), hello_retry_request(6), server_key_share(7), encrypted_extensions(8), certificate(11), server_key_exchange_RESERVED(12), certificate_request(13), server_hello_done_RESERVED(14), certificate_verify(15), client_key_exchange_RESERVED(16), server_configuration(17), finished(20), (255) } HandshakeType; </ins> The TLS Handshake Protocol messages are presented below in the order they MUST be sent; sending handshake messages in an unexpected order
Original text:
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 <del> bytes of its Random value to the bytes 44 4F 57 4E 47 52 44 01.  TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check that 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 </del>  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 detection as long as ephemeral ciphers are used.  It does not provide downgrade protection when static RSA is used.  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.  The sentinel value above was selected to avoid conflicting with any valid TLS 1.2

Reviewer comments:
Chairs have judged that there is consensus to merge, see: URL It looks like we have rough consensus to accept this PR. We should make sure we note the limitations that Karthink brought up for PSK and RSA, URL 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 , Eric Rescorla wrote:

Revised text:
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  <ins> bytes of their Random value to the bytes: TLS 1.2 server implementations which respond to a ClientHello with a client_version indicating TLS 1.1 or below SHOULD set the first eight bytes of their Random value to the bytes: 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 </ins> 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 detection as long as ephemeral ciphers are used.  It does not provide downgrade protection when static RSA is used. <ins> 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. </ins> 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.  The sentinel value above was selected to avoid conflicting with any valid TLS 1.2
Original text:
%%% Authentication Messages struct { digitally-signed struct { opaque handshake_hash[hash_length]; }; } CertificateVerify; <del> Where session_hash is as described in the-handshake-hash and </del>  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

Reviewer comments:
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 hasn't even been decided for sure if we're doing that.

Revised text:
%%% Authentication Messages struct { digitally-signed struct { opaque handshake_hash[hash_length]; }; } CertificateVerify;  <ins> Where handshake_hash is as described in the-handshake-hash and </ins> 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
Original text:
"supported_signature_algorithms" value: %%% Signature Algorithm Extension enum { none(0), md5_RESERVED(1), <del> sha1, sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } </del>  HashAlgorithm; [[TODO: IANA considerations for new SignatureAlgorithm value]]

Reviewer comments:
I think sha1 is supposed to be removed from this? If not, the int is missing sha2. enum { none(0), sha1, sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm;
No, it's there because you can offer it for certs. It is missing the assignment. PRs welcome :)
Okay so it's just missing the "(2)". I'll get on the PR.
Fixed by PR

Revised text:
"supported_signature_algorithms" value: %%% Signature Algorithm Extension enum { none(0), md5_RESERVED(1),  <ins> sha1(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } </ins> HashAlgorithm; [[TODO: IANA considerations for new SignatureAlgorithm value]]
Original text:
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 <del> algorithm.signature).  Note that previous versions of TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS. </del>  All ECDSA computations MUST be performed according to ANSI X9.62 X962 or its successors.  Data to be signed/verified is hashed, and the

Reviewer comments:
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

Revised text:
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  <ins> 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. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 X962 or its successors.  Data to be signed/verified is hashed, and the
Original text:
A single KeyShareEntry value for the negotiated cipher suite. <del> Servers MUST NOT send a KeyShare for a group not offered by the client. </del>  Servers offer exactly one KeyShareEntry value, which corresponds to the key exchange used for the negotiated cipher suite.

Reviewer comments:
Fix spacing to match other flow charts & fix one KeyShare->KeyShareEntry that was missed.

Revised text:
A single KeyShareEntry value for the negotiated cipher suite.  <ins> Servers MUST NOT send a KeyShareEntry value for a group not offered by the client. </ins> Servers offer exactly one KeyShareEntry value, which corresponds to the key exchange used for the negotiated cipher suite.
Original text:
Merge client and server key shares into a single extension.  draft-09 Change to RSA-PSS signatures for handshake messages.

Reviewer comments:
Starts in this thread: URL spt
It's the nonce after all. On Monday, October 19, 2015, Martin Thomson wrote: I don'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 Adam Langley EMAIL URL

Revised text:
Merge client and server key shares into a single extension. <ins> Remove sequence number and version from additional_data, which is now empty. </ins> draft-09 Change to RSA-PSS signatures for handshake messages.
Original text:
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 <del> octet length of the digest output.  Note that previous versions of TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS. </del>  All ECDSA computations MUST be performed according to ANSI X9.62 X962 or its successors.  Data to be signed/verified is hashed, and the

Reviewer comments:
This addresses Brian's comment from . We don't use "octet length" anywhere else in the document.

Revised text:
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  <ins> length of the digest output.  Note that previous versions of TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 X962 or its successors.  Data to be signed/verified is hashed, and the
Original text:
zero-rtt-exchange) it also authenticates the handshake using the the Static Secret. [server-finished] <del> Upon receiving the server's messages, the client responds with his </del>  final flight of messages:

Reviewer comments:
The spec always uses the gender-neutral possessive pronoun "its" for "client", so I think we should definitely fix that occurrence. Also, it seems that throughout the document we try to not use gender-specific pronouns for "attacker". I'm not sure about "their" though, as it looks like we usually try to avoid that by restructuring sentences, but I may be mistaken. We could also refer to multiple attackers?
In technical writing, we should generally use "they" and "their" everywhere when (potentially) referring to a person or persons. ("it" is best for denoting clients/servers) The word "they" gives both gender & quantity neutral language; no assumptions. (this use is older than Shakespeare; it's just underused)

Revised text:
zero-rtt-exchange) it also authenticates the handshake using the the Static Secret. [server-finished]  <ins> Upon receiving the server's messages, the client responds with its </ins> final flight of messages:
Original text:
between the ServerHello and the EncryptedExtensions encrypted- extensions message.  The ServerHello MUST only include extensions which are required to establish the cryptographic context. <del> 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. </del>  6.3.1.3.

Reviewer comments:
The early_data extension should be listed as one of the few that can't go into EncryptedExtensions but must be sent with ServerHello.

Revised text:
between the ServerHello and the EncryptedExtensions encrypted- extensions message.  The ServerHello MUST only include extensions which are required to establish the cryptographic context.  <ins> 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. </ins> 6.3.1.3.
Original text:
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 <del> corresponding KeyShare. </del>  If no mutually supported group is available between the two endpoints' KeyShare offers, yet there is a mutually supported group

Reviewer comments:
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
NAME 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).

Revised text:
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  <ins> corresponding KeyShare.  Implementations receiving any KeyShare containing any of these prohibited values MUST abort the connection with a fatal "illegal_parameter" alert. </ins> If no mutually supported group is available between the two endpoints' KeyShare offers, yet there is a mutually supported group