jiebi/TextFlow huggingface dataset:
Original text:
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 <del> 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. </del>  This is a list of the symmetric cipher options supported by the client, specifically the record protection algorithm (including

Reviewer comments:
All other fields deprecated by this spec use "MUST be set to ...", such as ClientHello.legacyversion, ClientHello.legacycompressionmethods, TLSPlaintext.legacyrecordversion. Only ClientHello.legacysession_id "SHOULD be set as [...]" So I suggest changing this to "MUST" as well.

Revised text:
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  <ins> negotiating TLS 1.3 and MUST 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. </ins> This is a list of the symmetric cipher options supported by the client, specifically the record protection algorithm (including
Original text:
This document deals with the formatting of data in an external representation.  The following very basic and somewhat casually <del> defined presentation syntax will be used.  The syntax draws from several sources in its structure.  Although it resembles the programming language "C" in its syntax and XDR RFC4506 in both its syntax and intent, it would be risky to draw too many parallels.  The purpose of this presentation language is to document TLS only; it has no general application beyond that particular goal. </del>  3.1. Structure definitions may be embedded.  Anonymous structs may also be defined inside other structures. <del> 3.6.1. </del>  Defined structures may have variants based on some knowledge that is available within the environment.  The selector must be an enumerated For example: <del> 3.7. Typed constants can be defined for purposes of specification by declaring a symbol of the desired type and assigning values to it. Under-specified types (opaque, variable-length vectors, and structures that contain opaque) cannot be assigned values.  No fields of a multi-element structure or vector may be omitted. For example: </del> 3.8. TLS defines two generic alerts (see alert-protocol) to use upon

Reviewer comments:
The caveats at the beginning are silly We don't seem to every use Foo = { A, B} but we do use Foo = A;
Fixed, thanks

Revised text:
This document deals with the formatting of data in an external representation.  The following very basic and somewhat casually  <ins> defined presentation syntax will be used. </ins> 3.1. Structure definitions may be embedded.  Anonymous structs may also be defined inside other structures.  <ins> 3.7. Fields and variables may be assigned a fixed value using "=", as in: 3.7.1. </ins> Defined structures may have variants based on some knowledge that is available within the environment.  The selector must be an enumerated For example:  3.8. TLS defines two generic alerts (see alert-protocol) to use upon
Original text:
server sends an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message.  In TLS 1.3, the server's OCSP information is carried in an <del> extension in the CertificateEntry containing the assoiciated </del>  certificate.  Specifically: The body of the "status_request" or "status_request_v2" extension from the server MUST be a CertificateStatus structure as defined in RFC6066 and RFC6961

Reviewer comments:
I believe that these are just cleanup, though you might want to check the PSK one a little more carefully (happy to separate it if it is a problem).
We seem to have reached consensus that the record layer will use the AEAD form only. The stream and CBC forms will be removed.
Fixed.

Revised text:
server sends an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message.  In TLS 1.3, the server's OCSP information is carried in an  <ins> extension in the CertificateEntry containing the associated </ins> certificate.  Specifically: The body of the "status_request" or "status_request_v2" extension from the server MUST be a CertificateStatus structure as defined in RFC6066 and RFC6961
Original text:
qualification is not required if the target of the assignment is well specified. <del> For enumerateds that are never converted to external representation, the numerical information may be omitted. </del> The names assigned to enumerateds do not need to be unique.  The numerical value can describe a range over which the same name applies.  The value includes the minimum and maximum inclusive values

Reviewer comments:
We don't actually use this syntax, and having it in here just adds useless complexity. Defining syntax we don't actually use just risks confusing people reading the document for the first time.

Revised text:
qualification is not required if the target of the assignment is well specified.  The names assigned to enumerateds do not need to be unique.  The numerical value can describe a range over which the same name applies.  The value includes the minimum and maximum inclusive values
Original text:
the server has ignored any early data and an ordinary 1-RTT handshake is required. <del> Return an empty extension, indicating that it intends to process </del>  the early data.  It is not possible for the server to accept only a subset of the early data messages.

Reviewer comments:
This extension is now empty. Minor cleanup.
I think "it's own" is useful, but my instinct is that having the empty struct makes life easier.
If you would rather keep the empty struct, I don't have a strong objection. Repushed with just the minor wording tweak.

Revised text:
the server has ignored any early data and an ordinary 1-RTT handshake is required.  <ins> Return its own extension, indicating that it intends to process </ins> the early data.  It is not possible for the server to accept only a subset of the early data messages.
Original text:
The version and extensions fields have the same meanings as their corresponding values in the ServerHello.  The server SHOULD send only the extensions necessary for the client to generate a correct <del> ClientHello pair (currently no such extensions exist).  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see cookie) extension. </del>  Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake

Reviewer comments:
I think this aside is out-of-date: extensions cannot be empty, and there are now defined extensions to put here.

Revised text:
The version and extensions fields have the same meanings as their corresponding values in the ServerHello.  The server SHOULD send only the extensions necessary for the client to generate a correct  <ins> ClientHello pair.  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see cookie) extension. </ins> Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake
Original text:
The following table defines the Handshake Context and MAC Base Key for each scenario: <del> The [sender] in this table denotes the sending side. </del> In all cases, the handshake context is formed by concatenating the indicated handshake messages, including the handshake message type and length fields.

Reviewer comments:
NAME please double-check
URL The 1-RTT annotations are redundant and you also don't need [sender] in brackets because we can just fill in the values, as client/server have separate tables lines

Revised text:
The following table defines the Handshake Context and MAC Base Key for each scenario:  In all cases, the handshake context is formed by concatenating the indicated handshake messages, including the handshake message type and length fields.
Original text:
this connection (thus preventing replay of client CertificateVerify messages).  This field SHALL be zero length unless used for the post-handshake authentication exchanges <del> described in Section 4.5.2. </del>  A list of the signature algorithms that the server is able to verify, listed in descending order of preference.  Any

Reviewer comments:
Fix a reference to a section that's directly citing a section number in plain text. (not linkified and will break if sections change) I assume this is a copy/paste error.

Revised text:
this connection (thus preventing replay of client CertificateVerify messages).  This field SHALL be zero length unless used for the post-handshake authentication exchanges  <ins> described in post-handshake-authentication. </ins> A list of the signature algorithms that the server is able to verify, listed in descending order of preference.  Any
Original text:
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 <del> servers will send at least one extension (at least "key_share" or </del>  "pre_shared_key"). In previous versions of TLS, this field was used for version

Reviewer comments:
The current text works, but tweaking it to be more general for issue is simple.
In the Client Hello (4.1.2) it says: As of TLS 1.3, all clients and servers will send at least one extension (at least "keyshare" or "presharedkey"). I believe that at least the supportedversions extension is also required for a client.
Rather than enumerating everything here, I've pushed a PR to just change "at least" to "e.g.".
I changed this separately.

Revised text:
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  <ins> servers will send at least one extension (e.g. "key_share" or </ins> "pre_shared_key"). In previous versions of TLS, this field was used for version
Original text:
TLS Alert Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to <del> include values for "end_of_early_data" and "missing_extension". </del>  TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this

Reviewer comments:
and fix also not needed comma
:+1: was about to fix this too. Change was introduced by NAME in f6f752f9af24f99241ba98510cfb1dd758bf4bf9 (included with draft 16).
Hi, I have update the change !

Revised text:
TLS Alert Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to  <ins> include values for "end_of_early_data", "missing_extension", and "certificate_required". </ins> TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this
Original text:
The content to be signed This structure is intended to prevent an attack on previous versions <del> of previous versions of TLS in which the ServerKeyExchange format meant that attackers could obtain a signature of a message with a chosen, 32-byte prefix.  The initial 64 byte pad clears that prefix. </del>  The context string for a server signature is "TLS 1.3, server CertificateVerify" and for a client signature is "TLS 1.3, client

Reviewer comments:
I think this is a typo. But I'm not sure since I'm not a native English speaker. Please check it out.

Revised text:
The content to be signed This structure is intended to prevent an attack on previous versions  <ins> of TLS in which the ServerKeyExchange format meant that attackers could obtain a signature of a message with a chosen, 32-byte prefix. The initial 64 byte pad clears that prefix. </ins> The context string for a server signature is "TLS 1.3, server CertificateVerify" and for a client signature is "TLS 1.3, client
Original text:
The AEAD output consists of the ciphertext output by the AEAD encryption operation.  The length of the plaintext is greater than <del> TLSPlaintext.length due to the inclusion of TLSPlaintext.type and however much padding is supplied by the sender.  The length of the AEAD output will generally be larger than the plaintext, but by an amount that varies with the AEAD algorithm.  Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, </del>  In order to decrypt and verify, the cipher takes as input the key, nonce, and the AEADEncrypted value.  The output is either the

Reviewer comments:
TLSCiphertext.fragment is undefined. I guess it should be "TLSCiphertext.encrypted_record"? This sentence "due to the inclusion of URL and however much padding is supplied by the sender" is unclear to me. Does it mean "due to the inclusion of URL and the padding"?

Revised text:
The AEAD output consists of the ciphertext output by the AEAD encryption operation.  The length of the plaintext is greater than  <ins> TLSPlaintext.length due to the inclusion of TLSPlaintext.type and any padding supplied by the sender.  The length of the AEAD output will generally be larger than the plaintext, but by an amount that varies with the AEAD algorithm.  Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, </ins> In order to decrypt and verify, the cipher takes as input the key, nonce, and the AEADEncrypted value.  The output is either the
Original text:
In all cases, the handshake context is formed by concatenating the indicated handshake messages, including the handshake message type <del> and length fields. </del>  4.4.1. functions defined below: The Hash function and the HKDF hash are the cipher suite hash <del> algorithm.  Hash.length is its output length. </del>  Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1,

Reviewer comments:
When I was implementing the key schedule, it was unclear to me what stands for. This additional note would help other implementors. Kazuho Oku pointed out the similarity to Handshake Context. So, I updated that part, too.

Revised text:
In all cases, the handshake context is formed by concatenating the indicated handshake messages, including the handshake message type  <ins> and length fields, but not including record layer headers. </ins> 4.4.1. functions defined below: The Hash function and the HKDF hash are the cipher suite hash  <ins> algorithm.  Hash.length is its output length.  Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers. </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1,
Original text:
ServerHello messages authenticates the protocol version, so this value is redundant. <del> The length (in bytes) of the following TLSCiphertext.fragment, which is the sum of the lengths of the content and the padding, plus one for the inner content type.  The length MUST NOT exceed 2^14 + 256.  An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. </del>  The AEAD encrypted form of the serialized TLSInnerPlaintext structure.

Reviewer comments:
Yes. There is a fair amount of other cleanup needed in this area; I have lots of red pen markings on a printout but haven't translated them into a patch yet.
Yes. There is a fair amount of other cleanup needed in this area; I have lots of red pen markings on a printout but haven't translated them into a patch yet.
Bah, github was angry-unicorning on me and did not indicate that the comment went through. I guess github doesn't like me this week...

Revised text:
ServerHello messages authenticates the protocol version, so this value is redundant.  <ins> The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of the content and the padding, plus one for the inner content type. The length MUST NOT exceed 2^14 + 256.  An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. </ins> The AEAD encrypted form of the serialized TLSInnerPlaintext structure.
Original text:
ticket_lifetime. A randomly generated 32-bit value that is used to obscure the age <del> of the ticket that the client includes in the "early_data" </del>  extension.  The client-side ticket age is added to this value modulo 2^32 to obtain the value that is transmitted by the client.

Reviewer comments:
Fix incorrect suggestion that of NST affects extension.
NAME merged. Please provide a PR adding yourself to the acknowledgements list in alphabetical order.

Revised text:
ticket_lifetime. A randomly generated 32-bit value that is used to obscure the age  <ins> of the ticket that the client includes in the "pre_shared_key" </ins> extension.  The client-side ticket age is added to this value modulo 2^32 to obtain the value that is transmitted by the client.
Original text:
send this message when authenticating via a certificate.  Clients MUST send this message whenever authenticating via a Certificate (i.e., when the Certificate message is non-empty).  When sent, this <del> message MUST appear immediately after the Certificate Message and </del>  immediately prior to the Finished message. Structure of this message: The digital signature is then computed using the signing key over the concatenation of: <del> 64 bytes of octet 32 </del>  The context string

Reviewer comments:
It could be just me, but the previous wording was kind of confusing (YMMV).

Revised text:
send this message when authenticating via a certificate.  Clients MUST send this message whenever authenticating via a Certificate (i.e., when the Certificate message is non-empty).  When sent, this  <ins> message MUST appear immediately after the Certificate message and </ins> immediately prior to the Finished message. Structure of this message: The digital signature is then computed using the signing key over the concatenation of:  <ins> A string that consists of octet 32 (0x20) repeated 64 times </ins> The context string
Original text:
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 <del> different keys.  After all the 0-RTT application data messages (if any) have been sent, an "end_of_early_data" alert of type "warning" is sent to indicate the end of the flight.  0-RTT MUST always be followed by an "end_of_early_data" alert, which will be encrypted with the 0-RTT traffic keys. </del>  A server which receives an "early_data" extension can behave in one of three ways: This alert is sent by the client to indicate that all 0-RTT application_data messages have been transmitted (or none will be <del> 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. </del>  This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a

Reviewer comments:
The alert is described as being part of the first flight, but it is really sent when the server Finished is received, per the processing order section. Notably, servers MUST NOT wait for endofearlydata before sending ServerHello through Finished. Group it with the client Finished flight, and fix the text about it terminating the first flight. (The division between the first and second client flight isn't especially well-defined because early data may flow in parallel with the ServerHello flight. But if there is to be a division, endofearlydata certainly falls into the second one.)
Yes, this should help avoid one of the most common mistakes in 0-RTT implementations.
LGTM.

Revised text:
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  <ins> different keys.  After receiving the server's Finished message, if the server has accepted early data, an "end_of_early_data" alert of type "warning" MUST be sent to indicate the key change.  This message will be encrypted with the 0-RTT traffic keys. </ins> A server which receives an "early_data" extension can behave in one of three ways: This alert is sent by the client to indicate that all 0-RTT application_data messages have been transmitted (or none will be  <ins> sent at all) and that the following records are protected under handshake traffic keys.  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. </ins> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a