jiebi/TextFlow huggingface dataset:
Original text:
the cryptographic context. The same extension types MUST NOT appear in both the ServerHello and <del> EncryptedExtensions.  If the same extension appears in both locations, the client MUST rely only on the value in the EncryptedExtensions block.  All server-sent extensions other than those explicitly listed in server-hello or designated in the IANA registry MUST only appear in EncryptedExtensions.  Extensions which are designated to appear in ServerHello MUST NOT appear in </del>  EncryptedExtensions.  Clients MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST terminate the handshake with an "illegal_parameter" alert.

Reviewer comments:
since server hello says that presence of extra extensions is a illegalparameter and encrypted extensions say that presence of server hello specific extensions is illegalparameter there is no reason to specify what to do with situation that MUST generate fatal alert

Revised text:
the cryptographic context. The same extension types MUST NOT appear in both the ServerHello and  <ins> EncryptedExtensions.  All server-sent extensions other than those explicitly listed in server-hello or designated in the IANA registry MUST only appear in EncryptedExtensions.  Extensions which are designated to appear in ServerHello MUST NOT appear in </ins> EncryptedExtensions.  Clients MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST terminate the handshake with an "illegal_parameter" alert.
Original text:
The selected ALPN RFC7443 value, if any. <del> The server_name RFC6066 value provided by the client, if any. </del> Future extensions MUST define their interaction with 0-RTT. If any of these checks fail, the server MUST NOT respond with the

Reviewer comments:
This seems to have just been a mistake? Unlike ALPN, servername isn't a value that is selected by the server, so there's no need to match it against a value stored in the session. There is the issue of whether sessions are resumable across names or other application-level contexts (for instance, whether we send client certificates, different cipher profiles, etc.), but that is a more complex issue than simply matching on servername on the server side. Moreover, any rules there would want to apply to resumption as a whole. It seems there's no reason to have 0-RTT-specific rules over resumption ones here.

Revised text:
The selected ALPN RFC7443 value, if any.  Future extensions MUST define their interaction with 0-RTT. If any of these checks fail, the server MUST NOT respond with the
Original text:
outputs of the corresponding functions defined in RFC7748, 32 bytes for x25519 and 56 bytes for x448. <del> Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS 1.3 removes this feature in favor of a single point format for each curve. </del>  4.2.5.

Reviewer comments:
TLS still permits shared point negotiation via ECDH, TLS 1.3 removes point format negotiation.

Revised text:
outputs of the corresponding functions defined in RFC7748, 32 bytes for x25519 and 56 bytes for x448.  <ins> Note: Versions of TLS prior to 1.3 permitted point format negotiation; TLS 1.3 removes this feature in favor of a single point format for each curve. </ins> 4.2.5.
Original text:
IANA [SHALL add/has added] the cipher suites listed in cipher- suites to the registry.  The "Value" and "Description" columns are <del> taken from the table.  The "DTLS-OK" column is marked as "Yes". IANA [SHALL add/has added] a "Recommended" column to the cipher suite registry.  All cipher suites listed in cipher-suites are marked as "Yes".  All other cipher suites are marked as "No". IANA [SHALL add/has added] add a note to this column reading: Cipher suites marked as "Yes" are those allocated via Standards Track RFCs.  Cipher suites marked as "No" are not; cipher suites marked "No" range from "good" to "bad" from a cryptographic standpoint. </del>  TLS ContentType Registry: Future values are allocated via Standards Action RFC2434.

Reviewer comments:
We are inconsistent about "AEAD cipher" and "AEAD algorithm". RFC 5116 uses "AEAD algorithm" and "AEAD cipher" is confusing with "cipher suite", so standardize on algorithm. IANA considerations were never updated to actually add the cipher suites. Fix that. Match the cipher suite name column with the IANA name so we can reuse the table. Finally, since we are defining new cipher suites, we should take care to cite where our AEADs come from. Do so.

Revised text:
IANA [SHALL add/has added] the cipher suites listed in cipher- suites to the registry.  The "Value" and "Description" columns are  <ins> taken from the table.  The "DTLS-OK" and "Recommended" columns are both marked as "Yes" for each new cipher suite.  [[This assumes draft-sandj-tls-iana-registry-updates-00 has been applied.]] </ins> TLS ContentType Registry: Future values are allocated via Standards Action RFC2434.
Original text:
Sent by servers when a client certificate is desired but none was provided by the client.  New Alert values are assigned by IANA as described in iana- considerations.

Reviewer comments:
There is no alert for a server which requested a client certificate, required it, but was not sent one. Servers today send a generic handshakefailure which means clients must use heuristics to show error messages to the user. Unlike nearly every other negotiation in TLS, client certificate selection is actually sometimes a user-level decision, so it is arguably the most important place for us to have a dedicated alert. (Also remove a "This alert is always fatal" note on badcertificatestatusresponse. All alerts are now fatal, so this is redundant.)
+1

Revised text:
Sent by servers when a client certificate is desired but none was provided by the client. <ins> [[TODO: IANA Considerations for new alert values.]] </ins> New Alert values are assigned by IANA as described in iana- considerations.
Original text:
TLS SignatureScheme Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required RFC2434.  Values with the first byte 255 (decimal) are reserved <del> for Private Use RFC2434.  This registry SHALL have a "Recommended" column.  The registry [shall be/ has been] initially populated with the values described in signature-algorithms.  The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. [[TODO: How to denote that values ending in 0x00 through 0x03 are also reserved?]] </del>  Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in

Reviewer comments:
Avoid both starting with an existing hash AND ending with an existing SignatureAlgorithm. In principle, this should not be necessary, but TLS says: Bouncy Castle appears to have been enforcing this, causing interop issues. As this was a straight-up MUST NOT, it seems prudent to renumber. And if we're renumbering anyway, may as well avoid all the old SignatureAlgorithms and avoid confusing tools like Wireshark.

Revised text:
TLS SignatureScheme Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required RFC2434.  Values with the first byte 255 (decimal) are reserved  <ins> for Private Use RFC2434.  Values with the first byte in the range 0-6 or with the second byte in the range 0-3 that are not currently allocated are reserved for backwards compatibility. This registry SHALL have a "Recommended" column.  The registry [shall be/ has been] initially populated with the values described in signature-algorithms.  The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. </ins> Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in
Original text:
server's selected version is contained in the ServerHello.version field as in previous versions of TLS.  4.2.2. %%% Cookie Extension

Reviewer comments:
By the way, you also need to update Version Negotiation section of the .
lgtm
Done , Xiaoyin Liu EMAIL wrote:

Revised text:
server's selected version is contained in the ServerHello.version field as in previous versions of TLS. <ins> 4.2.1.1. RFC EDITOR: PLEASE REMOVE THIS SECTION While the eventual version indicator for the RFC version of TLS 1.3 will be {3, 4}, implementations of draft versions of this specification SHOULD instead advertise {0x7f, [draft-version]} in their "supported_versions" extension, in ServerHello.version, and HelloRetryRequest.server_version.  This allows pre-RFC implementations to safely negotiate with each other, even if they would otherwise be incompatible. </ins> 4.2.2. %%% Cookie Extension
Original text:
preferences and MUST only select a version of TLS present in that extension.  They MUST ignore any unknown versions.  If the extension is not present, they MUST negotiate TLS 1.2 or prior as specified in <del> RFC5246, even if ClientHello.version is {3, 4} or later. </del>  The server MUST NOT send the "supported_versions" extension.  The server's selected version is contained in the ServerHello.version

Reviewer comments:
ClientHello.version -> ClientHello.legacy_version
Merged. Please send me a PR adding yourself to Contributors in alphabetical order
NAME Thank you! Done in PR .

Revised text:
preferences and MUST only select a version of TLS present in that extension.  They MUST ignore any unknown versions.  If the extension is not present, they MUST negotiate TLS 1.2 or prior as specified in  <ins> RFC5246, even if ClientHello.legacy_version is {3, 4} or later. </ins> The server MUST NOT send the "supported_versions" extension.  The server's selected version is contained in the ServerHello.version
Original text:
When a client first connects to a server, it is REQUIRED to send the ClientHello as its first message.  The client will also send a ClientHello when the server has responded to its ClientHello with <del> a HelloRetryRequest that selects cryptographic parameters that don't match the client's "key_share" extension.  In that case, the client MUST send the same ClientHello (without modification) except: </del>  Including a new KeyShareEntry as the lowest priority share (i.e., appended to the list of shares in the "key_share" extension).

Reviewer comments:
In the first paragraph, remove "that selects cryptographic parameters that don’t match the client’s 'keyshare' extension". Reason: According to section 4.2.5, HelloRetryRequest might not include the “keyshare” extension. Also there is a whole section for Hello Retry Request. So I don't think we need to explain what a HelloRetryRequest is here.

Revised text:
When a client first connects to a server, it is REQUIRED to send the ClientHello as its first message.  The client will also send a ClientHello when the server has responded to its ClientHello with  <ins> a HelloRetryRequest.  In that case, the client MUST send the same ClientHello (without modification) except: </ins> Including a new KeyShareEntry as the lowest priority share (i.e., appended to the list of shares in the "key_share" extension).
Original text:
(*) indicates changes to the wire protocol which may require implementations to update.  draft-15 New negotiation syntax as discussed in Berlin (*)

Reviewer comments:
PR changed enum values which would need updating by any experimental implementations that were actually using them. Even if this doesn't come up in practice, it should be listed in the changelog.

Revised text:
(*) indicates changes to the wire protocol which may require implementations to update. <ins> draft-16 Change RSASSA-PSS and EdDSA SignatureScheme codepoints for better backwards compatibility (*) </ins> draft-15 New negotiation syntax as discussed in Berlin (*)
Original text:
by sending the client an empty "signature_algorithms" extension. The "extension_data" field of this extension in a ClientHello <del> contains a "supported_signature_algorithms" value: </del>  %%% Signature Algorithm Extension rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list <del> them as the lowest priority (listed after all other algorithms in the supported_signature_algorithms vector).  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see server-certificate-selection). </del>  The signatures on certificates that are self-signed or certificates that are trust anchors are not validated since they begin a

Reviewer comments:
Criteria for one member structure / non structure is as follows: Non structure: basic type -- not messages nor extensions One member structure: others such as messages or extensions
LGTM

Revised text:
by sending the client an empty "signature_algorithms" extension. The "extension_data" field of this extension in a ClientHello  <ins> contains a SignatureSchemeList value: </ins> %%% Signature Algorithm Extension rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list  <ins> them as the lowest priority (listed after all other algorithms in SignatureSchemeList).  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see server-certificate-selection). </ins> The signatures on certificates that are self-signed or certificates that are trust anchors are not validated since they begin a
Original text:
2.3. <del> When resuming via a PSK with an appropriate ticket (i.e., one with the "early_data_info" extension), clients can also send data on their first flight ("early data").  This data is encrypted solely under keys derived using the first offered PSK as the static secret.  As shown in tls-0-rtt, the Zero-RTT data is just added to the 1-RTT </del>  handshake in the first flight.  The rest of the handshake uses the same messages as with a 1-RTT handshake with PSK resumption. IMPORTANT NOTE: The security properties for 0-RTT data are weaker than those for other kinds of TLS data.  Specifically: <del> This data is not forward secret, because it is encrypted solely with the PSK. </del>  There are no guarantees of non-replay between connections.  Unless the server takes special measures outside those provided by TLS,

Reviewer comments:
I am proposing that a client can also use the Zero-RTT with PSK-based authentication without having to rely on a previously obtained ticket.
Surely there would need to be additional security considerations for this behavior?!
This seems reasonable and was my intent, at least. Can you fix the build problem.
Could you please add linebreaks to wrap to about 80 character or so lines? Our line length is often rather inconsistent, but we do generally try to keep lines shorter than in the current changeset.
This LGTM. I'll let it sit for a little but in case anyone wants to weigh in (NAME NAME NAME
That's the sort of additional considerations that I was expecting to see, yes. I think that you got the list basically right, though there are a few things here that could be clearer.

Revised text:
2.3.  <ins> With the Zero-RTT mode clients can send data on their first flight ("early data") whereby the client uses a PSK either obtained out-of- band or as a ticket (i.e., one with the "early_data_info" extension) from an earlier exchange to authenticate to the server. When clients use a PSK obtained out-of-band then the following information MUST be provisioned to both parties: * PSK identity, * ciphersuite for use with this PSK, * key exchange and authentication modes this PSK is allowed to be used with, * the Application-Layer Protocol Negotiation (ALPN) label(s), and * optionally the Server Name Indication (SNI). As shown in tls-0-rtt, the Zero-RTT data is just added to the 1-RTT </ins> handshake in the first flight.  The rest of the handshake uses the same messages as with a 1-RTT handshake with PSK resumption. IMPORTANT NOTE: The security properties for 0-RTT data are weaker than those for other kinds of TLS data.  Specifically:  <ins> The early data is encrypted solely under keys derived using the offered PSK as the static secret.  Hence, this data is not forward secret, because it is encrypted solely with the PSK. </ins> There are no guarantees of non-replay between connections.  Unless the server takes special measures outside those provided by TLS,
Original text:
which will be echoed in the client's Certificate message.  The certificate_request_context MUST be unique within the scope of this connection (thus preventing replay of client <del> CertificateVerify messages).  Within the handshake, this field MUST be empty. </del>  A list of the signature algorithms that the server is able to verify, listed in descending order of preference.  Any

Reviewer comments:
I wanted to clarify in what part of the exchange the certificaterequestcontext field has a zero length.

Revised text:
which will be echoed in the client's Certificate message.  The certificate_request_context MUST be unique within the scope of this connection (thus preventing replay of client  <ins> CertificateVerify messages).  This field SHALL be zero length unless used for the post-handshake authentication exchanges described in Section 4.5.2. </ins> A list of the signature algorithms that the server is able to verify, listed in descending order of preference.  Any
Original text:
is provided, the value is computed as: Where Secret is either the early_exporter_secret or the <del> exporter_secret. </del>  If no context is provided, the value is computed as:

Reviewer comments:
Various changes to make exporters/resumption work better. The rationale is to be able to do stuff in 0/0.5RTT. Add a 0-RTT exporter and change the transcript for the regular exporter (*). Explicitly allow predicting ClientFinished for NST when not doing Client auth.

Revised text:
is provided, the value is computed as: Where Secret is either the early_exporter_secret or the  <ins> exporter_secret.  Implementations MUST use the exporter_secret unless explicitly specified by the application.  When adding TLS 1.3 to TLS 1.2 stacks, the exporter_secret MUST be for the existing exporter interface. </ins> If no context is provided, the value is computed as:
Original text:
T.f2 refers to the second field of the previous declaration. Structure definitions may be embedded.  3.6.1. Defined structures may have variants based on some knowledge that is

Reviewer comments:
To let's add some explanations to Section 3.
I have written a syntax validator to check the validity of definitions. In this issue, I would like to point out what I noticed.
(1) Some enum definitions use "floor..ceiling" notation which is not defined. Section 3.5 should clearly define this.
(2) I think that the keyword is allowed only in the top level definitions. But is used inside of EarlyDataIndication. I would suggest to defined the following in the top level:
(3) The following assignment is really strange: I would suggest to change this to:
On Wednesday, September 07, 2016 04:24:15 am Kazu Yamamoto wrote: I don't understand why you consider this current notation here strange. It's the same notation used for enum values elsewhere.
What I can tell from Section 3 is as follows: The "symbol(num)" notation is allowed in the declaration of enum. "symbol" can be used as label of the case clause. "{num, ...}" can be used for assignment. I don't see that "symbol(num)" can be used for assignment. I wrote a parse based on Section 3 and what I reported here is the errors reported by the parser.

Revised text:
T.f2 refers to the second field of the previous declaration. Structure definitions may be embedded. <ins> Basically the "struct" notation is used in the top level to define a new type.  However, there is one exception that an anonymous structure "struct {}", which means empty, can be used inside of another structure. </ins> 3.6.1. Defined structures may have variants based on some knowledge that is
Original text:
3.5. <del> An additional sparse data type is available called enum.  A field of type enum can only assume the values declared in the definition. Each definition is a different type.  Only enumerateds of the same type may be assigned or compared.  Every element of an enumerated must be assigned a value, as demonstrated in the following example. Since the elements of the enumerated are not ordered, they can be assigned any unique value, in any order. </del>  An enumerated occupies as much space in the byte stream as would its maximal defined ordinal value.  The following definition would cause force the width definition without defining a superfluous element. In the following example, Taste will consume two bytes in the data <del> stream but can only assume the values 1, 2, or 4. </del>  The names of the elements of an enumeration are scoped within the defined type.  In the first example, a fully qualified reference to

Reviewer comments:
with few possible exceptions, enumerateds will assume values different than the ones they were originally defined with. Backwards compatibility of Client Hello is dependent on implementations being able to ignore values they do not know about.
This doesn't seem quite right. Some enums are complete in the sense that you should not ignore unknown ones (HandshakeType) and some are not complete (ExtensionType, CipherSuite).
How about then "URL parse and ignore them unless the their deifnition states otherwise".?
sure that would be fine

Revised text:
3.5.  <ins> An additional sparse data type is available called enum.  Each definition is a different type.  Only enumerateds of the same type may be assigned or compared.  Every element of an enumerated must be assigned a value, as demonstrated in the following example.  Since the elements of the enumerated are not ordered, they can be assigned any unique value, in any order. Future extension or additions to the protocol may define new values. Implementations need to be able to parse and ignore them unless their definition states otherwise. </ins> An enumerated occupies as much space in the byte stream as would its maximal defined ordinal value.  The following definition would cause force the width definition without defining a superfluous element. In the following example, Taste will consume two bytes in the data  <ins> stream but can only assume the values 1, 2, or 4 in current version of protocol. </ins> The names of the elements of an enumeration are scoped within the defined type.  In the first example, a fully qualified reference to
Original text:
deprecated and MUST be ignored for all purposes. The length (in bytes) of the following TLSPlaintext.fragment.  The <del> length MUST NOT exceed 2^14. </del>  The data being transmitted.  This value transparent and treated as an independent block to be dealt with by the higher-level protocol

Reviewer comments:
Before record protection is established, if an endpoint receives a TLSPlaintext structure whose "length" field is too large (>2^14), should it send a "record_overflow" alert?

Revised text:
deprecated and MUST be ignored for all purposes. The length (in bytes) of the following TLSPlaintext.fragment.  The  <ins> length MUST NOT exceed 2^14.  An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. </ins> The data being transmitted.  This value transparent and treated as an independent block to be dealt with by the higher-level protocol