jiebi/CodeConvo huggingface dataset:
Change:
In the HTTPbis meeting in Montreal, it was suggested that recipients of a frame should validate that the claimed Request-ID matched the in the supplied authenticator request. However, the document defines no API which would permit us to do that.
Shouldn't this be implemented at the HTTP layer using the "get context" API? This document is not prescriptive about the content of the crc except that it is unpredictable and unique.
allows us to extract it from an authenticator, but doesn't allow performing the same operation on a request.
Good point. This should be a simple addition.
URL

Discussion:
The "get context" API takes as input: <del> authenticator </del> <ins> authenticator or authenticator request </ins> It returns the certificate_request_context.
Change:
Proposal to fix Issue
cc NAME
The Introduction limits this to TLS 1.2 and later, but DTLS is similar. Do you want to take that into account now, or ignore it? DTLS has additional fields to support fragmentation: URL URL
Exported authentication are meant to be embedded in a higher-layer protocol, so there's no need to support fragmentation.
The draft states that there should be no "TLS framing" but what is meant is that the handshake messages shouldn't be encapsulated by TLS Record Framing (which does the encryption of the handshake messages).

Discussion:
The CertificateRequest and ClientCertificateRequest messages are used to define the parameters in a request for an authenticator.  These <del> messages do not include any TLS framing and are not encrypted with a handshake key. </del> <ins> are encoded as TLS handshake messages, including length and type fields.  They do not include any TLS record layer framing and are not encrypted with a handshake key. </ins> The structures are defined to be:

hash is referred to as the authenticator hash. To avoid key synchronization attacks, Exported Authenticators MUST <del> NOT be generated or accepted on TLS 1.2 connectons that did not </del> <ins> NOT be generated or accepted on TLS 1.2 connections that did not </ins> negotiate the extended master secret RFC7627. 5.2. An authenticator is formed from the concatenation of TLS 1.3 TLS13 <del> Certificate, CertificateVerify, and Finished messages. </del> <ins> Certificate, CertificateVerify, and Finished messages.  These messages are encoded as TLS handshake messages, including length and type fields. </ins> If the peer creating the certificate_request_context has already created or correctly validated an authenticator with the same value,

a Certificate message containing no CertificateEntries and the CertificateVerify message omitted.  The HMAC is computed using the authenticator hash, using the Finished MAC Key as a key.  This <del> message does not include any TLS framing. </del> <ins> message is encoded as a TLS handshake message, including length and type field.  It does not include TLS record layer framing. </ins> 7.
Change:
got merged while I was reviewing it, so here's my feedback as a follow-up PR. I initially though line 244 needed a comma, but usage through the rest of the document suggests that supporting certificates are a property of one type of identity instead of something that could come along with a generic identity, so I dropped that one.
Thanks, Mike.

Discussion:
This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of an identity, such as an <del> X509 certificate.  This proof can be exported by one peer, </del> <ins> X.509 certificate.  This proof can be exported by one peer, </ins> transmitted out-of-band to the other peer, and verified by the receiving peer.

An authenticator message can be constructed by either the client or the server given an established TLS connection, an identity, such as <del> an X509 certificate, and a corresponding private key.  Clients MUST </del> <ins> an X.509 certificate, and a corresponding private key.  Clients MUST </ins> NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional.  For authenticators that do not correspond to authenticator requests, the

"oid_filters" (Section 4.2.5. of TLS13) extensions are used to guide certificate selection. <del> Only the X509 certificate type defined in TLS13 is supported. </del> <ins> Only the X.509 certificate type defined in TLS13 is supported. </ins> Alternative certificate formats such as RFC7250 Raw Public Keys are not supported in this version of the specification and their use in this context has not yet been analysed.

Where Hash is the authenticator hash defined in section 4.1.  If the authenticator request is not present, it is omitted from this <del> construction, i.e., it is zero length. </del> <ins> construction, i.e., it is zero-length. </ins> If the party that generates the exported authenticator does so with a different connection than the party that is validating it, then the
Change:
one minor nit: i would phrase "applying the function for validating the certificate chain contained in the authenticator." as "applying the function for validating the certificate chain to the chain contained in the authenticator." for clarity. Otherwise LGTM!
I've implemented earlier drafts. I do have a concern with the validate API as presented in the draft: it treats empty authenticators as valid, and then returns the identity as a certificate chain that must be validated by the application. Similar APIs have lead to easily foreseeable pwnage. Instead I would recommend the validate API carry out X509 validation against a trust store or validation function and treat the empty authenticator as invalid. That way someone has to think before not checking the certificate returned.
Closing this out as it was addressed.

Discussion:
an authenticator <ins> a function for validating a certificate chain </ins> It returns the identity, such as the certificate chain and its extensions, and a status to indicate whether the authenticator is <del> valid or not.  The API SHOULD return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator.  Well-formed empty authenticators are returned as valid. </del> <ins> valid or not after applying the function for validating the certificate chain to the chain contained in the authenticator. The API SHOULD return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator. Well-formed empty authenticators are returned as invalid. </ins> 8.
Change:
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

Discussion:
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> <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
Change:
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.

Discussion:
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
Change:
This is to address a comment by Michael StJohns on the mailing list. To quote:

Discussion:
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
Change:
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?

Discussion:
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
Change:
Provide guidance on what flag should be allocated to what extension, based on the likelihood of that extension being widely used.

Discussion:
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
Change:
All messages that carry extensions can have a tls_flags extension: CH, SH, EE, Cert, NST
NAME can you please respond to the comments above?
Ping NAME :-)
Done.
I might have framed this slightly differently, but this accurately captures the outcome of the discussion. Thanks for doing this.

Discussion:
of the flag-type features that use this extension and that were declared by the ClientHello extension SHALL send this extension with the intersection of the flags it supports with the flags declared by <del> the client.  The intersection operation MAY be implemented as a bitwise AND.  The server may need to send two tls_flags extensions, one in the ServerHello and the other in the EncryptedExtensions message.  It is up to the document for the specific feature to determine whether support should be acknowledged in the ServerHello or the EncryptedExtensions message. </del> <ins> the client.  The intersection operation may be implemented as a bitwise AND.  The server may need to send multiple tls_flags extensions, up to one in each of the four response messages that may carry extensions: ServerHello (SH), EncryptedExtensions (EE), Certificate (CT), and HelloRetryRequest (HRR).  It is up to the document for the specific feature to determine which of these should be used to acknowledge support. </ins> A server MUST NOT indicate support for any flag-type feature not <del> previously indicated by the client.  It MUST NOT include this extension in either message (ServerHello or EncryptedExtensions) if it has no appropriate flag-type to indicate.  This extension MUST NOT be included empty. </del> <ins> previously indicated by the client in the ClientHello in any response message.  It MUST NOT include this extension in any of the four messages if it has no appropriate flag-type to indicate.  This extension MUST NOT be included empty. A server MAY indicate support for flag-type features in a flags extension of CertificateRequest (CR).  Flag-type extensions that have been indicated in CR (and only such extensions) MAY be also be present in a flags extension of the Certificate (CT) message sent by the client.  However, a client MUST NOT indicate support for any flag-type feature in a Certificate message that was not previously indicated by the server in its CertificateRequest message. A server MAY indicate support for flag-type features in a flags extension of NewSessionTicket (NST).  This message has no client-side response. In summary, unsolicited flags may appear only in ClientHello, CertificateRequest, and NewSessionTicket. </ins> 4.

extensions.  It does not send in the clear any information that would otherwise be sent encrypted, nor vice versa.  For this reason this extension is neutral as far as security is concerned. <ins> Extension authors should be aware that acknowledging flags in a tls_flags extension of the ServerHello and HelloRetryRequest messages expose this response to passive observers.  Unless there is a special reason to place the response in the ServerHello, most flags should go in other (encrypted) messages. </ins>
Change:
Show the initial registry value is a decimal number rather than a hex number.
LGTM.

Discussion:
The initial contents of the registry shall be one entry, as follows: <del> Value shall be 0x8 </del> <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 <del> will be used by all web clients or all smart objects. </del> <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.
Change:
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.

Discussion:
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
Change:
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.

Discussion:
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 <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> <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
Change:
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?

Discussion:
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> <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
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
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> <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