jiebi/TextFlow huggingface dataset:
Original text:
valid authenticators. The set of extensions allowed in the CertificateRequest structure <del> are those defined in the TLS ExtensionType Values IANA registry containing CR in the TLS 1.3 column.  The extensions allowed in the ClientCertificateRequest are those containing CR in the TLS 1.3 column, along with the server_name RFC6066 extension. </del>  The uniqueness requirements of the certificate_request_context apply only to CertificateRequest and ClientCertificateRequest messages that

Reviewer comments:
Section 4: I find this confusing: extensions: The set of extensions allowed in the CertificateRequest structure are those defined in the TLS ExtensionType Values IANA registry containing CR in the TLS 1.3 column. The extensions allowed in the ClientCertificateRequest are those containing CR in the TLS 1.3 column, along with the servername [RFC6066] extension. I think it means: extensions: The set of extensions allowed in the CertificateRequest structure and the ClientCertificateRequest structure are those defined in the TLS ExtensionType Values IANA registry [cite] containing CR in the TLS 1.3 column. In addition, the set of extensions in the ClientCertificateRequest structure MAY include the servername [RFC6066] extension.
fixed in

Revised text:
valid authenticators. The set of extensions allowed in the CertificateRequest structure  <ins> and the ClientCertificateRequest structure are those defined in the TLS ExtensionType Values IANA registry RFC8447 containing CR in the TLS 1.3 column.  In addition, the set of extensions in the ClientCertificateRequest structure MAY include the server_name RFC6066 extension. </ins> The uniqueness requirements of the certificate_request_context apply only to CertificateRequest and ClientCertificateRequest messages that
Original text:
authenticator finished key" with "DTLS-OK" and "Recommended" set to "Y" and this document added to the "Reference" column.  9. The Certificate/Verify/Finished pattern intentionally looks like the

Reviewer comments:
Hmmm maybe it should be "clientcertificaterequest" to match the other values in the Description column.
If ClientCertificateRequest is a new HandshakeType then there needs to be a registry request. If is adopted will need to also request one for ServerCertificateRequest.

Revised text:
authenticator finished key" with "DTLS-OK" and "Recommended" set to "Y" and this document added to the "Reference" column. <ins> 8.3. IANA is requested to add the following entry to the registry for HandshakeType (defined in RFC8446): "client_certificate_request" with "DTLS-OK" and "Recommended" set to "Y" and this document added to the "Reference" column with the following in the "Note" column: "Used in TLS versions prior to 1.3." </ins> 9. The Certificate/Verify/Finished pattern intentionally looks like the
Original text:
In summary, unsolicited flags may appear only in ClientHello, CertificateRequest, and NewSessionTicket.  4. IANA is requested to assign a new value from the TLS ExtensionType

Reviewer comments:
This is to address a comment by Michael StJohns on the mailing list. To quote:

Revised text:
In summary, unsolicited flags may appear only in ClientHello, CertificateRequest, and NewSessionTicket. <ins> An implementation that receives an invalid tls_flags extension MUST terminate the TLS handshake with a fatal illegal_parameter alert. </ins> 4. IANA is requested to assign a new value from the TLS ExtensionType
Original text:
An implementation that receives an invalid tls_flags extension MUST terminate the TLS handshake with a fatal illegal_parameter alert.  4. IANA is requested to assign a new value from the TLS ExtensionType

Reviewer comments:
To solve issue
RFC8446 4.2.10 requires that: This extension does not (as far as I can see) do that. I think the text in tls-flags should prevaricate on this topic, because really it's an encoding framework for trivial extensions (that themselves need to define their interaction with 0-RTT.)
Created a PR. Let me know if this is satisfactory. URL
NAME NAME assume this one can be closed based on being merged?

Revised text:
An implementation that receives an invalid tls_flags extension MUST terminate the TLS handshake with a fatal illegal_parameter alert. <ins> 3.1. The 0-RTT handshake, defined in section 2.3 of RFC8446, has a ClientHello message, a ServerHello message, and an EncryptedExtensions message.  Those can include the tls_flags extension just as they can in a regular handshake. Future flag extensions MUST define their interaction with 0-RTT, just as other extensions are required to. </ins> 4. IANA is requested to assign a new value from the TLS ExtensionType
Original text:
The policy for this shall be "Specification Required" as described in RFC8126.  4. The extension described in this document provides a more concise way

Reviewer comments:
Provide guidance on what flag should be allocated to what extension, based on the likelihood of that extension being widely used.

Revised text:
The policy for this shall be "Specification Required" as described in RFC8126. <ins> 3.1. This extension allows up to 2040 flags.  However, they are not all the same, because the length of the extension is determined by the highest set bit. We would like to allocate the flags in such a way that the typical extension is as short as possible.  The scenario we want to guard against is that in a few years some extension is defined that all implementations need to support and that is assigned a high number because all of the lower numbers have already been allocated.  An example of such an extension is the Renegotiation Indication Extension defined in RFC5746. For this reason, the IANA experts should allocate the flags as follows: Flags 0-7 are reserved for documents coming out of the TLS working group with a specific request to assign a low number. Flags 8-31 are for standards-track documents that the experts believe will see wide adoption among either all users of TLS or a significant group of TLS users.  For example, an extension that will be used by all web clients or all smart objects. Flags 32-63 are for other documents, including experimental, that are likely to see significant adoption. Flags 64-79 are not to be allocated.  They are for reserved for private use. Flags 80-2039 can be used for temporary allocation in experiments, for flags that are likely to see use only in very specific environments, for national and corporate extensions, and as overflow, in case one of the previous categories has been exhausted. </ins> 4. The extension described in this document provides a more concise way
Original text:
The initial contents of the registry shall be one entry, as follows: <del> Value shall be 0x8 </del>  Flag Name shall be resumption_across_names Flags 8-31 are for standards-track documents that the experts believe will see wide adoption among either all users of TLS or a significant group of TLS users.  For example, an extension that <del> will be used by all web clients or all smart objects. </del>  Flags 32-63 are for other documents, including experimental, that are likely to see significant adoption.

Reviewer comments:
Show the initial registry value is a decimal number rather than a hex number.
LGTM.

Revised text:
The initial contents of the registry shall be one entry, as follows:  <ins> Value shall be 8 </ins> Flag Name shall be resumption_across_names Flags 8-31 are for standards-track documents that the experts believe will see wide adoption among either all users of TLS or a significant group of TLS users.  For example, an extension that  <ins> will be used by all web clients or all smart objects.  The only entry in the initial registry is from this range. </ins> Flags 32-63 are for other documents, including experimental, that are likely to see significant adoption.
Original text:
This extension replaces "max_fragment_length" RFC6066, which this document deprecates.  This extension is valid in all versions of TLS.  2. The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this records.  This admits the possibility that the extension might not be negotiated when a connection is renegotiated or resumed.  4.1. The size limit expressed in the "record_size_limit" extension doesn't

Reviewer comments:
Add an applicability statement. This only addresses buffer space issues, not processing or bandwidth constraints. I didn't observe (in the introduction) that this can negatively affect bandwidth, that's later. Hannes also observed that we don't really talk about the path MTU. I made it clear that these are separate and independent limitations. For NAME
Thanks for providing this text. While I had been hoping for more clarifications about the interactions between the MTU information entering the stack from below and the RSL parameter passed to the stack from the application side I think it is a good start.
Oh, also, I have moved the intro text down a paragraph. I think that it is better to talk about the properties of this extension rather than focus more on what MFL does or doesn't do.

Revised text:
This extension replaces "max_fragment_length" RFC6066, which this document deprecates.  This extension is valid in all versions of TLS. <ins> A smaller protected record size is just one of many problems that a constrained implementation might need to address.  The "record_size_limit" extension only addresses the memory allocation problem, it does not address limits of code size, or processing and bandwidth capacity. </ins> 2. The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this records.  This admits the possibility that the extension might not be negotiated when a connection is renegotiated or resumed. <ins> The record size limit can interact with the maximum transmission unit (MTU) in DTLS, but it is a separate and independent constraint on record size.  In particular, it is not appropriate to use the record size limit in place of path MTU detection.  The record size limit is a fixed property of an endpoint that is set during the handshake and fixed thereafter.  In comparison, the MTU is determined by the network path and can change dynamically over time. </ins> 4.1. The size limit expressed in the "record_size_limit" extension doesn't
Original text:
the allowance for expansion to 256 octets.  Allocating up to 18K of memory for ciphertext is beyond the capacity of some implementations.  The "max_fragment_length" extension RFC6066 was designed to enable constrained clients to negotiate a lower record size.  However, "max_fragment_length" suffers from several design problems (see mfl- The "max_fragment_length" extension is also ill-suited to cases where the capabilities of client and server are asymmetric.  Constraints on <del> record size are often receiver constraints.  In particular, an Authentication Encryption with Additional Data (AEAD) ciphers (see RFC5116) API requires that an entire record be present to decrypt and authenticate it.  Some implementations choose not to implement an AEAD interface in this way to avoid this problem, but that exposes them to risks that an AEAD is intended to protect against. </del>  In comparison, an implementation might be able to send data incrementally.  Encryption does not have the same atomicity

Reviewer comments:
This is a good part of what motivates the existence of the mechanism.
The text changes look good to me. I only had a minor remark regarding another sentence.

Revised text:
the allowance for expansion to 256 octets.  Allocating up to 18K of memory for ciphertext is beyond the capacity of some implementations. <ins> An Authentication Encryption with Additional Data (AEAD) ciphers (see RFC5116) API requires that an entire record be present to decrypt and authenticate it.  Similarly, other ciphers cannot produce authenticated data until the entire record is present.  Thus, incremental processing of records minimally exposes endpoints to the risk of forged data. </ins> The "max_fragment_length" extension RFC6066 was designed to enable constrained clients to negotiate a lower record size.  However, "max_fragment_length" suffers from several design problems (see mfl- The "max_fragment_length" extension is also ill-suited to cases where the capabilities of client and server are asymmetric.  Constraints on  <ins> record size are often receiver constraints. </ins> In comparison, an implementation might be able to send data incrementally.  Encryption does not have the same atomicity
Original text:
This value is the length of the plaintext of a protected record.  The value includes the content type and padding added in TLS 1.3 (that <del> is, the complete length of TLSInnerPlaintext).  Padding added as part of encryption, such as that added by a block cipher, is not included in this count (see expansion). </del>  An endpoint that supports all record sizes can include any limit up to the protocol-defined limit for maximum record size.  For TLS 1.3

Reviewer comments:
This isn't as easy as in TLS 1.3, which has a clearly defined structure for what is fed into the AEAD. I've done my best. NAME this is the only change from your email that you might disagree with. Can you have a look please?

Revised text:
This value is the length of the plaintext of a protected record.  The value includes the content type and padding added in TLS 1.3 (that  <ins> is, the complete length of TLSInnerPlaintext).  In TLS 1.2 and earlier, the limit covers all input to compression and encryption, that is the data that ultimately produces TLSCiphertext.fragment. Padding added as part of encryption, such as that added by a block cipher, is not included in this count (see expansion). </ins> An endpoint that supports all record sizes can include any limit up to the protocol-defined limit for maximum record size.  For TLS 1.3
Original text:
protocol permits. For large data transfers, small record sizes can materially affect <del> performance TARREAU.  Consequently, clients that are capable of receiving large records could be unwilling to risk reducing performance by offering the extension, especially if the extension is rarely needed. </del>  This would not be an issue if a codepoint were available or could be added for fragments of 2^14 octets.  However, RFC 6066 requires that

Reviewer comments:
And simply explain what the costs of smaller records actually are.
Great summary. Thanks for adding the text. One minor question: My reading of the referenced email discussion is that the computational overhead is not just a matter of cryptographic processing but also the processing related to multiplexing, TCP-related processing and other implementation details (e.g., threading). Is this also your understanding of what the folks in the email thread were referring to?
My understanding is that the performance costs are largely due to context switching. That might be worse because of multiplexing. Willy did a separate talk on the costs of doing crypto at high data rates that I wish that I could reference. He had some great numbers about what it took just to move data from the kernel to user space and that was a significant impact on overall throughput.

Revised text:
protocol permits. For large data transfers, small record sizes can materially affect  <ins> performance.  Every record incurs additional costs, both in the additional octets for record headers and for expansion due to encryption.  Processing more records also adds computational overheads that can be amortized more effectively for larger record sizes.  Consequently, clients that are capable of receiving large records could be unwilling to risk reducing performance by offering the extension, especially if the extension is rarely needed. </ins> This would not be an issue if a codepoint were available or could be added for fragments of 2^14 octets.  However, RFC 6066 requires that
Original text:
RecordSizeLimit: The value of RecordSizeLimit is the maximum size of record in octets <del> that the endpoint is willing to receive.  When the "record_size_limit" extension is negotiated, an endpoint MUST NOT generate a protected record with plaintext that is larger than the RecordSizeLimit value it receives from its peer.  Unprotected messages - handshake messages in particular - are not subject to this limit. </del>  This value is the length of the plaintext of a protected record.  The value includes the content type and padding added in TLS 1.3 (that

Reviewer comments:
NAME requests: I believe we should re-word the text in the draft in such a way that it does not say record with plaintext that is larger than the RecordSizeLimit value it receives from its peer. but instead says what you explained below. In essence, the RecordSizeLimit value can then be used by the TLS stack to determine the size of the fragments. "below" being that when writing, the limit determines when to create new records. It shouldn't prohibit writes that exceed the limit.

Revised text:
RecordSizeLimit: The value of RecordSizeLimit is the maximum size of record in octets  <ins> that the endpoint is willing to receive.  This value is used to limit the size of records that are created when encoding application data and handshake message into records. When the "record_size_limit" extension is negotiated, an endpoint MUST NOT generate a protected record with plaintext that is larger than the RecordSizeLimit value it receives from its peer. Unprotected messages - handshake messages in particular - are not subject to this limit. </ins> This value is the length of the plaintext of a protected record.  The value includes the content type and padding added in TLS 1.3 (that
Original text:
Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or <del> CA) RFC5246 RFC5280.  This organizational separation makes the TLS </del>  server operator dependent on the CA for some aspects of its operations, for example: draft-02 <del> Change public key type (*) </del>  <del> Change DelegationUsage extension to be NULL. </del>  Drop support for TLS 1.2. is no longer valid. The signature algorithm of the credential key pair, where the type <del> SignatureScheme is as defined in the TLS 1.3 standard.  This is expected to be the same as CertificateVerify.algorithm sent by the server. </del>  The version of TLS in which the credential will be used, where the <del> type ProtocolVersion is as defined in TLS 1.3.  This is expected </del>  to match the protocol version that is negotiated by the client and server.

Reviewer comments:
The suggested OID for the DelegationUsage extension will be 1.3.6.1.4.1.44363.44.

Revised text:
Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or  <ins> CA) RFC8446 RFC5280.  This organizational separation makes the TLS </ins> server operator dependent on the CA for some aspects of its operations, for example: draft-02  <ins> Change public key type. (*) </ins>  <ins> Change DelegationUsage extension to be NULL and define its object identifier. </ins> Drop support for TLS 1.2. is no longer valid. The signature algorithm of the credential key pair, where the type  <ins> SignatureScheme is as defined in RFC8446.  This is expected to be the same as CertificateVerify.algorithm sent by the server. </ins> The version of TLS in which the credential will be used, where the  <ins> type ProtocolVersion is as defined in RFC8446.  This is expected </ins> to match the protocol version that is negotiated by the client and server.
Original text:
We define a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated <del> credentials. </del>  The extension MUST be marked non-critical.  (See Section 4.2 of RFC5280.)  The client MUST NOT accept a delegated credential unless it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in TLS 1.3 RFC8446.  5. 5.1.

Reviewer comments:
I suspect at some point somebody would have asked for an ASN.1 module. I know not everybody uses an ASN.1 compiler, but some do. I also know Russ Housley was going through an making for all of the RFCs that include ASN.1. He also double checked that the ASN.1 module compiles (if you put a dummy OID in for the TBD it will compile). An OID is need from the PKIX arc, but Russ is the IANA DE there so it is not like we do not know who we need to ask - hence the updated IANA considerations sections.
"An OID is need from the PKIX arc, but Russ is the IANA DE there so it is not like we do not know who we need to ask - hence the updated IANA considerations sections." Are you thinking of getting a different OID for the DCs, does the cf OID not work?
Sean is talking about the Module Identifier. The CF OID inside the module is fine.
The CF OID for the extension works just fine - in fact I should have left the sentence in the PR explaining that. We need an OID for the ASN.1 module (TBD). Technically, I guess we do not need an OID if CF has an ASN.1 module already. But, I suspect there wasn't an ASN.1 module. Make sense?
NAME do you know if CF has an ASN.1 module already?
since noone seems to have any objections, merging away.
Not having an ASN.1 module for the certificate extension has bit us in the a** before. I will make one and add it in as an appendix.

Revised text:
We define a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated  <ins> credentials.  What follows is the ASN.1 X680 for the DelegationUsage certificate extension. </ins> The extension MUST be marked non-critical.  (See Section 4.2 of RFC5280.)  The client MUST NOT accept a delegated credential unless it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in TLS 1.3 RFC8446. <ins> This document also defines an ASN.1 module for the DelegationUsage certificate extension in module.  IANA is requested to register an Object Identfiier (OID) for the ASN.1 in "SMI Security for PKIX Module Identifier" arc.  An OID for the DelegationUsage certificate extension is not needed as it is already assigned to the extension from Cloudflare's IANA Private Enterprise Number (PEN) arc. </ins> 5. 5.1.
Original text:
(*) indicates changes to the wire protocol. <del> draft-05 * Removed support for PKCS 1.5 RSA signature algorithms.  * Additional security considerations. </del>  draft-04

Reviewer comments:
Fix formatting issue in changes.
This is trivial and straightforward change so I'm just going to merge this directly.

Revised text:
(*) indicates changes to the wire protocol.  <ins> draft-05 Removed support for PKCS 1.5 RSA signature algorithms. Additional security considerations. </ins> draft-04