jiebi/CodeConvo huggingface dataset:
Code change:
Attempt to reword the 'Header Block Size' section to use more HTTP version neutral terms (for )
Is this a hangover from terminology changes elsewhere? URL says
Very possible that it's a hangover from terminology changes elsewhere. Very possible. But I'm not quite sure how to update it. HTTP/3 talks about the "size of the message header" (from your reference) while HTTP/2 talks about block size but now uses field block size URL rather than header block size URL How about the following though? Assuming I'm even adjusting the terminology you're suggesting needs adjusting. Message header seems more neutral and appropriate.
Thanks for the suggestion and PR. I think we're best off holding for NAME review since he had to do a similar renaming exercise for HTTP/3 and is an expert now
Makes sense. I, for one, would welcome such expertise.
URL Mike okayed it
Yes, this looks reasonable.

Related discussion:
text: 3.2. <del> A server in receipt of a larger header block than it is willing to </del> <ins> A server in receipt of a larger message header than it is willing to </ins> handle can send an HTTP 431 (Request Header Fields Too Large) status code per RFC6585.  Due to the typical size of the field values containing certificate data, recipients may need to be configured to <del> allow for a larger maximum header block size.  An intermediary generating client certificate header fields on connections that allow for advertising the maximum acceptable header block size (e.g. HTTP/2 RFC9113 or HTTP/3 RFC9114) should account for the additional size of the header block of the requests it sends vs. requests it receives by advertising a value to its clients that is sufficiently smaller so as to allow for the addition of certificate data. </del> <ins> allow for a larger maximum header size.  An intermediary generating client certificate header fields on connections that allow for advertising the maximum acceptable header size (e.g.  HTTP/2 RFC9113 or HTTP/3 RFC9114) should account for the additional size of the header of the requests it sends vs. requests it receives by advertising a value to its clients that is sufficiently smaller so as to allow for the addition of certificate data. </ins> 3.3.
Code change:
h/t NAME
The security considerations pay some good attention to the concerns of the actors that might deal with the headers defined in client-certs. It crossed my mind that you could mention header protection mechanisms, like Signatures, as one way to harden things.
Yeah, Signatures could be mentioned in there as a possible additional measure.

Related discussion:
text: deployments.  The communication between a TTRP and backend or origin server, for example, might be authenticated in some way with the insertion and consumption of the "Client-Cert" and "Client-Cert- <del> Chain" header fields occurring only on that connection. Alternatively the network topology might dictate a private network such that the backend application is only able to accept requests from the TTRP and the proxy can only make requests to that server. Other deployments that meet the requirements set forth herein are also possible. </del> <ins> Chain" header fields occurring only on that connection.  I-D.ietf- httpbis-message-signatures gives one example of this with an application of HTTP Message Signatures.  Alternatively the network topology might dictate a private network such that the backend application is only able to accept requests from the TTRP and the proxy can only make requests to that server.  Other deployments that meet the requirements set forth herein are also possible. </ins> 5.
Code change:
try to align better with the style guide on structured fields usage for
See URL, which would affect sections 2.2 and 2.3
Will update the structured fields parts to align with the style guide.
LGTM

Related discussion:
text: 1.2. <ins> This document uses the following terminology from RFC8941 to specify syntax and parsing: List and Byte Sequence. </ins> Phrases like TLS client certificate authentication or mutually- authenticated TLS are used throughout this document to refer to the process whereby, in addition to the normal TLS server authentication
Code change:
try to align better with the style guide on structured fields usage for
See URL, which would affect sections 2.2 and 2.3
Will update the structured fields parts to align with the style guide.
LGTM

Related discussion:
text: 2.1. <del> The headers in this document encode certificates as Structured Field Byte Sequences (RFC8941) where the value of the binary data is a DER encoded ITU.X690.1994 X.509 certificate RFC5280.  In effect, this means that the binary DER certificate is encoded using base64 (without line breaks, spaces, or other characters outside the base64 alphabet) and delimited with colons on either side. </del> <ins> The headers in this document encode certificates as Byte Sequences (RFC8941) where the value of the binary data is a DER encoded ITU.X690.1994 X.509 certificate RFC5280.  In effect, this means that the binary DER certificate is encoded using base64 (without line breaks, spaces, or other characters outside the base64 alphabet) and delimited with colons on either side. </ins> Note that certificates are often stored encoded in a textual format, such as the one described in RFC7468, which is already nearly <del> compatible with a Structured Field Byte Sequence; if so, it will be sufficient to replace "---(BEGIN|END) CERTIFICATE---" with ":" and remove line breaks in order to generate an appropriate item. </del> <ins> compatible with a Byte Sequence; if so, it will be sufficient to replace "---(BEGIN|END) CERTIFICATE---" with ":" and remove line breaks in order to generate an appropriate item. </ins> 2.2.
Code change:
try to align better with the style guide on structured fields usage for
See URL, which would affect sections 2.2 and 2.3
Will update the structured fields parts to align with the style guide.
LGTM

Related discussion:
text: contains the end-entity certificate used by the client in the TLS handshake. <del> Client-Cert is an Item Structured Header RFC8941.  Its value MUST be a Byte Sequence (RFC8941).  Its ABNF is: The value of the header is encoded as described in encoding. </del> <ins> Client-Cert is a Byte Sequence with the value of the header encoded as described in encoding. </ins> The "Client-Cert" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a singleton header field
Code change:
try to align better with the style guide on structured fields usage for
See URL, which would affect sections 2.2 and 2.3
Will update the structured fields parts to align with the style guide.
LGTM

Related discussion:
text: proxy MAY make the certificate chain available to the backend application with the Client-Cert-Chain HTTP header field. <del> Client-Cert-Chain is a List Structured Header RFC8941.  Each item in the list MUST be a Byte Sequence (RFC8941) encoded as described in encoding.  The order is the same as the ordering in TLS (such as described in TLS). The header's ABNF is: </del> <ins> Client-Cert-Chain is a List (RFC8941).  Each item in the list MUST be a Byte Sequence encoded as described in encoding.  The order is the same as the ordering in TLS (such as described in TLS). </ins> The "Client-Cert-Chain" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It MAY have a list of values
Code change:
The HTTP message in Sec. 2.1.4 of draft -14 is not formatted correctly (both HTML and plain text).
NAME

Related discussion:
text: For example, given the following message: <del> ```http-message HTTP/1.1 200 OK Content-Type: text/plain Transfer- Encoding: chunked Trailer: Expires 4 HTTP 7 Message 10 Signatures 0 Expires: Wed, 9 Nov 2022 07:28:00 GMT ``` </del> The signer decides to add both the Trailer header field as well as <del> the Expires trailer to the signature base: ""@status": 200 "trailer": Expires "expires";tr: Wed, 9 Nov 2022 07:28:00 GMT " </del> <ins> the Expires trailer to the signature base, along with the status code derived component: </ins> <del> IF a field is available as both a header and trailer in a message, both values MAY be signed separately.  The values of header fields and trailer fields of the same name MUST NOT be combined. </del> <ins> If a field is available as both a header and trailer in a message, both values MAY be signed, but the values MUST be signed separately. The values of header fields and trailer fields of the same name MUST NOT be combined for purposes of the signature. </ins> Since trailer fields could be merged into the header fields or dropped entirely by intermediaries as per HTTP, it is NOT RECOMMENDED
Code change:
in the manner discussed in London: Admitting it exists, but we don't care.
Section 2 of includes these nuggets: to this specification MAY define flags. See . and but future updates to this specification (through IETF consensus) might use them to change its semantics. The first four flags (0x1, 0x2, 0x4, and 0x8) are reserved for backwards-incompatible changes; therefore, when any of them are set, the ORIGIN frame containing them MUST be ignored by clients conforming to this specification, unless the flag's semantics are understood. The remaining flags are reserved for backwards-compatible changes and do not affect processing by clients conformant to this specification. HTTP/3 frames don't have a Flags field in the generic frame layout. So, while I'm not sure we'll ever see a use of these flags in H2 ORIGIN, it might bite us later if it happened. I see a few options for dealing with this: Option 1) Defer. Future us will have a job to do trying to make H2 and H3 compatible if a flags related change is proposed. Perhaps its worth a little note to make sure people are aware of this divergence consideration. Option 2) Add a Flags field () to the HTTP/3 frame and add in all the same considerations about backards-(in)compatibility Option 3) Encode the flags in the frame type by picking a large enough value. A bit yuck. I'm leaning towards option 1.

Related discussion:
text: ORIGIN frame is sent from servers to clients on the server's control stream. <ins> HTTP/3 does not define a Flags field in the generic frame layout.  As no flags have been defined for the ORIGIN frame, this specification does not define a mechanism for communicating such flags in HTTP/3. </ins> 2.1. The ORIGIN frame has a nearly identical layout to that used in
Code change:
correcting: The reference to RFC8740 is obsoleted by RFC9113 There are two separate references to RFC5246, once as "RFC5246" and once as "TLS1.2".

Related discussion:
text: CertificateVerify and Finished messages. HTTP/2 restricts TLS 1.2 renegotiation (RFC9113) and prohibits TLS <del> 1.3 post-handshake authentication RFC8740.  However, they are </del> <ins> 1.3 post-handshake authentication (RFC9113).  However, they are </ins> sometimes used to implement reactive client certificate authentication in HTTP/1.1 RFC9112 where the server decides whether to request a client certificate based on the HTTP request.  HTTP
Code change:
correcting: The reference to RFC8740 is obsoleted by RFC9113 There are two separate references to RFC5246, once as "RFC5246" and once as "TLS1.2".

Related discussion:
text: enabled. A TTRP negotiates the use of a mutually-authenticated TLS connection <del> with the client, such as is described in TLS or RFC5246, and validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following modifications: </del> <ins> with the client, such as is described in TLS or TLS1.2, and validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following modifications: </ins> The client certificate is placed in the "Client-Cert" header field of the dispatched request, as described in header.
Code change:
The draft currently has this example: I'd suggest always omitting trailing dots since it's clear that these names will be FQDNs, i.e.:

Related discussion:
text: indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the <del> CNAMEs "tracker.example.com." and "service1.example-cdn.com" in the </del> <ins> CNAMEs "tracker.example.com" and "service1.example-cdn.com" in the </ins> DNS resolution chain.  Note that while this example includes both the "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".
Code change:
NAME Adds the BCP14 boilerplate in a Notation Conventions section. As part of that, I noticed we don't reference any explanation of the frame layout language used -- it's the same used in QUIC and HTTP/3 -- so I added an RFC 9000 ref to pick that up in the same section.

Related discussion:
text: 1. Existing RFCs define extensions to HTTP/2 HTTP2 which remain useful <del> in HTTP/3.  Section A.2.3 of HTTP3 describes the required updates for HTTP/2 frames to be used with HTTP/3. </del> <ins> in HTTP/3.  HTTP3 describes the required updates for HTTP/2 frames to be used with HTTP/3. </ins> ORIGIN defines the HTTP/2 ORIGIN frame, which indicates what origins are available on a given connection.  It defines a single HTTP/2 frame type. <ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. Frame diagrams in this document use the format defined in QUIC- TRANSPORT to illustrate the order and size of fields. </ins> 2. The ORIGIN HTTP/3 frame allows a server to indicate what origin(s) (RFC6454) the server would like the client to consider as members of <del> the Origin Set (Section 2.3 of ORIGIN) for the connection within which it occurs. </del> <ins> the Origin Set (ORIGIN) for the connection within which it occurs. </ins> The semantics of the frame payload are identical to those of the HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves Stream 0 for
Code change:
NAME Adds the BCP14 boilerplate in a Notation Conventions section. As part of that, I noticed we don't reference any explanation of the frame layout language used -- it's the same used in QUIC and HTTP/3 -- so I added an RFC 9000 ref to pick that up in the same section.

Related discussion:
text: An Origin-Entry is a length-delimited string.  Specifically, it contains two fields: <del> An unsigned, 16-bit integer indicating the length, in octets, of the ASCII-Origin field. An OPTIONAL sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender asserts this connection is or could be authoritative for. </del> 3. This document introduces no new security considerations beyond those
Code change:
This draft (-00) is using the term "alias" in a slightly different way than used in DNS: A CNAME record has two names, the owner name on the left-hand side or "alias", and the target name on the right-hand side or "canonical name". RFC 8499 (DNS Terminology): In other words, to use the example in the draft: Which might correspond to a DNS response that looked something like: and are DNS aliases (because there are CNAME records with those owner names) whereas is a DNS "canonical name" without an alias. But is included in the example in this draft. This might be confusing for the DNS name at the end of the CNAME chain (which is not an alias from a DNS perspective), so I might suggest changing: to something like:

Related discussion:
text: Abstract This document defines an HTTP Proxy-Status Parameter that contains a <del> list of aliases received over DNS when establishing a connection to the next hop. </del> <ins> list of aliases and canonical names received over DNS when establishing a connection to the next hop. </ins> 1.
Code change:
This draft (-00) is using the term "alias" in a slightly different way than used in DNS: A CNAME record has two names, the owner name on the left-hand side or "alias", and the target name on the right-hand side or "canonical name". RFC 8499 (DNS Terminology): In other words, to use the example in the draft: Which might correspond to a DNS response that looked something like: and are DNS aliases (because there are CNAME records with those owner names) whereas is a DNS "canonical name" without an alias. But is included in the example in this draft. This might be confusing for the DNS name at the end of the CNAME chain (which is not an alias from a DNS perspective), so I might suggest changing: to something like:

Related discussion:
text: chain of aliases encountered during DNS resolution when connecting to the next hop. <del> Knowing the full chain of aliases that were used during DNS resolution is particularly useful for clients of forward proxies, in which the client is requesting to connect to a specific target hostname using the CONNECT method HTTP or UDP proxying CONNECT-UDP. DNS aliases can be used to "cloak" hosts that perform tracking or malicious activity behind more innocuous hostnames, and clients such as web browsers use the chain of DNS aliases to influence behavior like cookie usage policies COOKIES or blocking of malicious hosts. This document allows clients to receive the chain of DNS aliases for the next hop by including the list of names in a new "next-hop- </del> <ins> Knowing the full chain of names that were used during DNS resolution via CNAME records DNS is particularly useful for clients of forward proxies, in which the client is requesting to connect to a specific target hostname using the CONNECT method HTTP or UDP proxying CONNECT-UDP.  CNAME records can be used to "cloak" hosts that perform tracking or malicious activity behind more innocuous hostnames, and clients such as web browsers use the chain of DNS names to influence behavior like cookie usage policies COOKIES or blocking of malicious hosts. This document allows clients to receive the CNAME chain of DNS names for the next hop by including the list of names in a new "next-hop- </ins> aliases" Proxy-Status parameter. 1.1.
Code change:
This draft (-00) is using the term "alias" in a slightly different way than used in DNS: A CNAME record has two names, the owner name on the left-hand side or "alias", and the target name on the right-hand side or "canonical name". RFC 8499 (DNS Terminology): In other words, to use the example in the draft: Which might correspond to a DNS response that looked something like: and are DNS aliases (because there are CNAME records with those owner names) whereas is a DNS "canonical name" without an alias. But is included in the example in this draft. This might be confusing for the DNS name at the end of the CNAME chain (which is not an alias from a DNS perspective), so I might suggest changing: to something like:

Related discussion:
text: The "next-hop-aliases" parameter's value is a String that contains one or more DNS names in a comma-separated list.  The items in the <del> list include all names received in CNAME records DNS during the course of resolving the next hop's hostname using DNS.  Since DNS names can include comma (",") characters in them, any commas that appear in a DNS names MUST be represented using a percent-encoded "%2C" value instead.  The aliases SHOULD appear in the order in which they were received in DNS; that is, if a name has a CNAME record with a first alias, which has a CNAME record for a second alias, the aliases should appear in that order. For example: indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the CNAMEs "tracker.example.com" and "service1.example-cdn.com" in the DNS resolution chain.  Note that while this example includes both the </del> <ins> list include all alias names and canonical names received in CNAME records DNS during the course of resolving the next hop's hostname using DNS, not including the original requested hostname itself.  The names SHOULD appear in the order in which they were received in DNS. If there are multiple CNAME records in the chain, the first name in the "next-hop-aliases" list would be the value in the CNAME record for the original hostname, and the final name in the "next-hop- aliases" list would be the name that ultimately resolved to one or more addresses. For example, consider a proxy "proxy.example.net" that receives the following records when performing DNS resolution for the next hop "host.example.com": The proxy could include the following proxy status in its response: This indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the names "tracker.example.com" and "service1.example-cdn.com" in the DNS resolution chain.  Note that while this example includes both the </ins> "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".
Code change:
This draft (-00) is using the term "alias" in a slightly different way than used in DNS: A CNAME record has two names, the owner name on the left-hand side or "alias", and the target name on the right-hand side or "canonical name". RFC 8499 (DNS Terminology): In other words, to use the example in the draft: Which might correspond to a DNS response that looked something like: and are DNS aliases (because there are CNAME records with those owner names) whereas is a DNS "canonical name" without an alias. But is included in the example in this draft. This might be confusing for the DNS name at the end of the CNAME chain (which is not an alias from a DNS perspective), so I might suggest changing: to something like:

Related discussion:
text: next-hop-aliases <del> A string containing one or more DNS alises used to establish a proxied connection to the next hop. </del> <ins> A string containing one or more DNS aliases or canonical names used to establish a proxied connection to the next hop. </ins> This document
Code change:
Agreed, but I don't see a way around having a "." be allowed there. If a system wants to further escape dots within labels if they know about them, that's OK...
The current text says names MUST be represented using a percent-encoded value instead. However, domain names can also contain and , so I think the escaping rule has to be a bit more generic than just escaping commas, as indicated in the current text.
Wire format DNS names can contain arbitrary octets. I'd suggest allowing characters in the set and %-encoding any other character. This is similar to the filtering that the glibc stub resolver performs on CNAME alias chains.
Reference RFC 1035 section 3.1 for the fact that these can be arbitrary Percent encode everything that it not alphanumeric or dash Mention in the security considerations that if you don't do this, you could inject newlines, etc.
Actually, sf-string already prohibits things like newlines:
The unreserved characters are: is a valid interior label character in a wire-format DNS name, which seems like it would allow spoofing a label boundary. Not sure how much of a problem this is.

Related discussion:
text: aliases" list would be the name that ultimately resolved to one or more addresses. <ins> The list of DNS names in "next-hop-aliases" use a comma (",") as a separator between names.  DNS names normally just contain alphanumeric characters and hyphens ("-"), although they are allowed to contain any character RFC1035, Section 3.1, including a comma.  To prevent commas or other special characters in names leading to incorrect parsing, any characters that appear in names in this list that do not belong to the set of URI Unreserved Characters RFC3986, Section 2.3 MUST be percent-encoded as defined in RFC3986, Section 2.1. </ins> For example, consider a proxy "proxy.example.net" that receives the following records when performing DNS resolution for the next hop "host.example.com":