jiebi/CodeConvo huggingface dataset:
Code change:
Oblivious Relay Resource also needs to observe the guidance in relay- responsibilities. <ins> An Oblivious Gateway Resource acts as a gateway for requests to the Target Resource (see HTTP).  The one exception is that any information it might forward in a response MUST be encapsulated, unless it is responding to errors it detects before removing encapsulation of the request; see errors. </ins> An Oblivious Gateway Resource, if it receives any response from the Target Resource, sends a single 200 response containing the encapsulated response.  Like the request from the client, this

Related discussion:
text: Section 5 details HTTP usage. It seems it's technically correct but the section closes with a sequence of paragraphs that jump back and forth between statements about how an Oblivious Gateway Resource treats requests or responses. Perhaps these could be consolidated to present requests first consistently. I.e. swap the final two paragraphs around
Code change:
versions are four-byte sequences with no additional constraints on format.  Leading zeros SHOULD be omitted for brevity. <del> Syntax: </del> <ins> Syntax of the "quic" parameter value: </ins> Where multiple versions are listed, the order of the values reflects the server's preference (with the first value being the most

Related discussion:
text: Use the correct ABNF grammar to express repetition and fix the Reserved Frame Type link.
There is some baggage with this parameter - URL People were a bit grumpy with changing their parser 18 months ago, I think they might be even grumpier now that we have even more client implementations in the wild. What is the benefit of this change? I think we need an issue for due process and discussion.
Oh joy. This caused me to go look at our parser in Chrome, and realized we're still doing the old (pre 1097) quic=;quic= format. So Chrome has work to do no matter how we resolve this. That being said, I'd really rather not have two different ways to do this, so +1 to NAME 's comment on the motivation.
I can remove the additional unquoted token change and keep this PR purely as editorial fix. Before the PR, the current text does not have correct ABNF grammar. I added the unquoted token variant since it is permitted (but not required) by the grammar at URL Since HTTP/3 over QUIC is not the only user of this Alt-Svc header, I can imagine that generic parsers are written such that they already understand the unquoted token value. Thus, adding support for this should not be an additional burden? I have no strong opinion here. The additional CPU cost of handling both unquoted and quoted forms should be neglible. Disallowing the unquoted form is a restriction of the RFC 7838 grammar. Should I bring this to the list and/or create a new issue?
Let's create a new issue. You're correct that non-HTTP/3 implementations might need to handle this - hence the original issue which related back to structured headers (an attempt at defining some best practice in this regard -URL). Part of the problem is not CPU cost of DQUOTEs but expressing "a list of versions" and making sure that implementations know how to do that. Alt-Svc defines the parameter syntax but not how to handle repetition of parameters.
I removed the single quote change, this should be a purely editorial fix now. I'll create a new issue for the unquoted parameter value.
Code change:
versions are four-byte sequences with no additional constraints on format.  Leading zeros SHOULD be omitted for brevity. <del> Syntax: </del> <ins> Syntax of the "quic" parameter value: </ins> Where multiple versions are listed, the order of the values reflects the server's preference (with the first value being the most

Related discussion:
text: The "list of versions" situation does not change, if you only support one version you would write: If you support multiple, you would still use one parameter, but you have to quote it since a comma is not valid in a .
According to URL, the Alt-Svc parameter value can be unquoted: This means that this can be written: instead of only: The current text in URL forbids the unquoted variant which is an additional constraint on the RFC 7838 grammar. Should unquoted parameter values also be permitted? Note that this does not change the situation when multiple versions are supported since an unquoted "token" type is not allowed to contain commas. See also the discussion in .
RFC 7838 allows unquoted strings, but there's nothing preventing new specifications of Alt-Svc parameters from being more restrictive. I'm not sure the added flexibility of allowing unquoted versions buys us much here, and it comes at an implementation cost.
If alt-svc can be specified in configuration files, it is likely to result in interop issues if unquoted is not permitted.
I support allowing unquoted token for alt-svc quic parameter. quic=1 and quic="1" are semantically the same, and there is no reason to disallow unquoted token. Moreover, requiring quoted-string means that we cannot use generic alt-svc parser because such parser can parse quic=1 without an error. You need to write your own parser to detect that the DQUOTE is really there. If you think that detecting it is not necessary, then requiring quoted-string is not necessary in the first place.
People and implementers will be surprised (and do wrong) if the rules and constraints of RFC7838 aren't kept.
To highlight my earlier point, on slack the following was posted The issue appears to not be the unquoted ma=3600, but it does suggest we will see unquoted strings in the wild, and URL is said to also use unquoted ma=3600.
But that's the ma= field, not the quic= field, right? (This issue is about the quic= field, I think)
As I said elsewhere, the current text in draft-23 stems from a Structured Headers issue related to wanting to advertise multiple versions of QUIC. URL Alt-Svc isn't a structured one but if it were (e.g.
Code change:
versions are four-byte sequences with no additional constraints on format.  Leading zeros SHOULD be omitted for brevity. <del> Syntax: </del> <ins> Syntax of the "quic" parameter value: </ins> Where multiple versions are listed, the order of the values reflects the server's preference (with the first value being the most

Related discussion:
text: if someone wanted to write a generic Structured Header parser) then there was a danger that the rules preventing dictionary key repetition would have prevented an endpoint sending multiple parameters e.g. . To mitigate the risk, the quic parameter was changed to a DQUOTED comma-separated list as part of URL This issue addresses the correctness within the Alt-Svc spec but does it reopen the can related to Structured Headers?
I think that the problem here is independent from whether structured headers should be applied or not. - Structured header issue: duplicate keys. - Invalid grammar according to RFC 7838 since "token" does not include commas. - valid grammar according to both RFC 7838 and the QUIC description. However, if only a single version has to be advertised, then the quoting is not necessary: - valid grammar according to both RFC 7838 and the QUIC description. - valid grammar according to both RFC 7838, but QUIC currently forbids it. In I proposed to fix the grammar (editorial issue). However, at the same time I could also make the grammar match RFC 7838 (the last bullet point above). NAME I would mind not making the semantics more restrictive (e.g. restricting the values of the QUIC parameter to hexadecimal only), but restricting the parser grammar would impose extra restrictions on those who have to generate the header. It is conceivable that implementations will continue accepting the RFC 7838 grammar, and end up accepting while others would reject it and accept only. By making sure that the grammars align, I hope that this becomes a non-issue. So far NAME NAME and NAME seems to support this proposal and NAME is not sure. Can this be considered consensus? :smiley:
Code change:
to those mailing lists should be given.  An example of this is at https://datatracker.ietf.org/wg/quic/charter/. <del> 2.3.1. One important policy is the IETF IPR policy (see RFC5378, RFC3979, and RFC4879).  Part of this policy requires making contributors aware of the policy. The IETF Trust license file for open source repositories [5] MUST be included prominently in any document repository. Including this information in the CONTRIBUTING file is sufficient. In addition to the boilerplate text there can be a benefit to including pointers to other working group materials, the IETF datatracker, specific drafts, or websites.  Adding such text is at the discretion of the Working Group Chairs. </del> 3. A Working Group Chairs are responsible for determining how to best

Related discussion:
text: I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.
Code change:
encapsulation key "enc". Construct associated data, "aad", by concatenating the values of <del> "keyID", "kdfID", and "aeadID", as 8-, 16- and 16-bit integers respectively, each in network byte order. </del> <ins> "keyID", "kemID", "kdfID", and "aeadID", as one 8-bit integer and three 16-bit integers, respectively, each in network byte order. </ins> Encrypt (seal) "request" with "aad" as associated data using "context", yielding ciphertext "ct".

Related discussion:
text: and . Given (either assuming a fixed key ID, or looking up the KEM based on key ID), I think this is a nice simplification. It also authenticates more, even if redundant. (The kemID is already part of the HPKE key schedule.) I implemented this change and it's straightforward.
Currently, an encapsulated request carries a key ID which maps to a KEM key that determines the size of the encapsulated public key in a request. This means that code parsing a request needs to know the ID -> KEM mapping in order to parse things correctly, which is somewhat annoying. I propose we add KEMID to the request so that this mapping isn't needed to just parse the message. As a bonus, that would also fold in the KEMID explicitly into the AAD alongside the KDFID and AEADID.
We currently length-prefix it, but we don't have to. Think about this a little.
Both the public key and encapsulated secret are fixed length. I think making these fixed length on the wire is good. However, it does require the parsing code to know the corresponding size, which depends on the KEM. This requires there to be a function to map the kem_id to the corresponding size(s). NAME do you have such an API in your implementation? I have one in mine, which would make this pretty straightforward to implement.
Code change:
semantics and encodings for any version-specific field.  In particular, different packet protection keys might be used for different versions.  Servers that do not support a particular version <del> are unlikely to be able to decrypt the payload of the packet. Servers SHOULD NOT attempt to decode or decrypt a packet from an unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long. </del> <ins> are unlikely to be able to decrypt the payload of the packet or properly interpret the result.  Servers SHOULD respond with a Version Negotiation packet, provided that the datagram is sufficiently long. </ins> Packets with a supported version, or no version field, are matched to a connection using the connection ID or - for packets with zero-

Related discussion:
text: instead of saying servers SHOULD NOT attempt to parse unknown versions, stick with the factual statement that they will likely be unable to do so. Flips the SHOULD to the second half of the sentence, the expected response. I believe this is editorial, since we're not modifying expected behavior, but it's touching normative language, so please speak up if you're not convinced.
Actually, it seems like there should be a normative MUST NOT attempt.
I would have said "cannot". The contents are unknown, after all. Attempting to prohibit someone from doing something impossible seems like it might be unnecessary (or at least futile). Edit: of course, this change avoids having to deal with that question, which is better.
Why do you say it's impossible? You could simply hope that version n+1 was the same as version n in terms of structure and try to parse it as that, ignoring the version number.
Which is why the PR says "unlikely," not "impossible." But the impossible thing is for the server to know whether it's doing things correctly.
Right, but my point is that we should prohibit trying, not just give people advice that it's dumb.
(Broken out of .) This seems like tuning? Or is the intention to protect the endpoint from an attack, please explain the SHOULD.
encodings for any version-specific field. In particular, different packet protection keys might be used for different versions. Servers that do not support a particular version are unlikely to be able to decrypt the payload of the packet. Servers SHOULD NOT attempt to decode or decrypt a packet from an unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long. I'm having trouble seeing what's needed here. The endpoint has received a packet professing to be in a version it does not understand. It can't know the semantics or encoding of any field there -- and the paragraph already explains that. Yes, I'm sure there are potential attacks in interpreting a packet of unknown provenance and unknown semantics against a different set of semantics and expectations, but I'm not convinced we need to explain them. The text recommends sending a Version Negotiation packet, which seems like the only sensible response.
This refers to .
Code change:
semantics and encodings for any version-specific field.  In particular, different packet protection keys might be used for different versions.  Servers that do not support a particular version <del> are unlikely to be able to decrypt the payload of the packet. Servers SHOULD NOT attempt to decode or decrypt a packet from an unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long. </del> <ins> are unlikely to be able to decrypt the payload of the packet or properly interpret the result.  Servers SHOULD respond with a Version Negotiation packet, provided that the datagram is sufficiently long. </ins> Packets with a supported version, or no version field, are matched to a connection using the connection ID or - for packets with zero-

Related discussion:
text: NAME
I'm looking for two things: (i) I think this ought to clarify the intention for the SHOULD, I suspect it is clear to those working on this part, but not clear to me why this is a recommendation - i.e., specifically can you give me a use-case of why the Server would otherwise USE information from a packet from an unknown version, unless the intention is to say the server shouldn't waste resources to do try to do this? (ii) I think this implies understanding of Section 14.1 later in the spec, and a ref would help. So... Is it equally true that.. "Servers MUST NOT use the contents of a packet with an unknown version, and SHOULD NOT decrypt this packet, but instead send a Version Negotiation packet, provided that the packet is sufficiently long (see Section 14.1)."? Or perhaps simply explain something like: "Servers SHOULD NOT commit resources to attempt to decode or decrypt a packet from an unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long (see Section 14.1)."?
Fundamentally, it's a caution against assumptions which could prove incorrect, such as "this looks like an unencrypted TLS ClientHello, so I can go find the field that contains...." The server will either process information in a way that could be used maliciously, or the server will generate a response that won't be understood by the client. Ideally, this would be a MUST, except that it's entirely unenforceable by the client what the server does internally. Perhaps the right solution here is to remove the normative language with regard to that piece and stick to the statement of fact we already have:
That approach seems fine.
Code change:
as expected. Form a URI by populating the URI template RFC6570 <del> "{scheme}://{domain}/.well-known/acme-challenge/{token}", where: * the scheme field is set to "http" if the "tls" field in the response is present and set to false, and "https" otherwise; * the </del> <ins> "http://{domain}/.well-known/acme-challenge/{token}", where: * the </ins> domain field is set to the domain name being verified; and * the token field is set to the token in the authorized key object.

Related discussion:
text: On the mailing list, NAME and NAME pointed out some risks arising from the default virtual host behavior of some web servers. This PR integrates the changes they suggest, namely (1) removing the "tls" option from the challenge, and (2) adding iterations to the challenge. This PR is based on top of and .
Sorry, feel free to tell me to go away, but reading the backing decision to drop HTTPS for SimpleHTTP doesn't make sense to me. If I understand everything correctly, you control the originator of the HTTPS requests and the requests are always sent to domains. So why can't you just enforce to always send the Host header and this wouldn't be an issue?
From : behaviour that if a default TLS/HTTPS virtual host is not configured explicitly, one will be selected based on the ordering of vhosts in the webserver configuration (in practice, this often amounts to alphabetical ordering of files in a configuration directory). As far as I know Apache does the exact same thing for nonencrypted HTTP hosts (this is also acknowledged by a later mail in the thread), so the reasoning is a little weird. I suppose the idea is that hosters are more likely to have HTTP configured correctly rather than HTTPS?
The section on the "" registry says that "Fields marked as "client configurable" may be included in a new-account request". This seems like a copy-paste-o, and perhaps should say that such fields may be included in a new-order request.
Good catch. I opened URL to fix. Thanks! Apache (and I gather nginx too) have the subtle and non-intuitive behaviour that if a default TLS/HTTPS virtual host is not configured explicitly, one will be selected based on the ordering of vhosts in the webserver configuration (in practice, this often amounts to alphabetical ordering of files in a configuration directory). URL URL This creates a vulnerability for SimpleHTTP and DVSNI in any multiple-tenant virtual hosting environment that failed to explicitly select a default vhost [1]. The vulnerability allows one tenant (typically one with the alphabetically lowest domain name -- a situation that may be easy for an attacker to arrange) to obtain certificates for other tenants.
Code change:
as expected. Form a URI by populating the URI template RFC6570 <del> "{scheme}://{domain}/.well-known/acme-challenge/{token}", where: * the scheme field is set to "http" if the "tls" field in the response is present and set to false, and "https" otherwise; * the </del> <ins> "http://{domain}/.well-known/acme-challenge/{token}", where: * the </ins> domain field is set to the domain name being verified; and * the token field is set to the token in the authorized key object.

Related discussion:
text: The exact conditions for the vulerability vary: SimpleHTTP is vulnerable if no default vhost is set explicitly, the server accepts the "tls": true parameter as currently specified, and the domains served over TLS/HTTPS are a strict subset of those served over HTTP. DVSNI is vulnerable if no default vhost is set explicitly, and the hosting environment provides a way for tenants to upload arbitrary certificates to be served on their vhost. James Kasten and Alex Halderman have done great work proposing a fix for DVSNI: URL That fix also has some significant performance benefits on systems with many virtual hosts, and the resulting challenge type should perhaps be called DVSNI2. The simplest fix for SimpleHTTP is to remove the "tls" option from the client's SimpleHTTP response, and require that the challenge be completed on port 80. URL Alternatively, the protocol could allow the server to specify which ports it will perform SimpleHTTP and SimpleHTTPS requests on; HTTPS on port 443 SHOULD be avoided unless the CA can confirm that the server has an explicitly configured default vhost. The above diffs are currently against Let's Encrypt's version of the ACME spec, we'll be happy to rebase them against the IETF version upon request. [1] though I haven't confirmed it, it's possible that sites that attempted to set a default vhost are vulernable if they followed advice like this when doing so: URL ; an attacker need only sign up with a lexicographically lower name on that hosting platform to obtain control of the default. Peter Eckersley EMAIL Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993
Code change:
Extensions that add a label that is intended for use with EXI need to create a new XSD Schema that includes all the labels in the IANA <del> registry then allocate a new EXI schemaId value.  Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId.  Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaId value. </del> <ins> registry and then allocate a new EXI schemaId value.  Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId.  Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaId value. </ins> Extensions that are mandatory to understand to correctly process the Pack MUST have a label name that ends with the '_' character.

Related discussion:
text: Set of small editorial tweaks and aligned fragment text with new way of positioning base values
LGTM ( other than we need to decide if we use field or attribute but we can do that as separate PR)
Code change:
detected using heuristics similar to those used to detect TLS over TCP.  A client initiating a connection may also send data in 0-RTT packets directly after the Initial packet containing the TLS Client <del> Hello.  Since these packets may be reordered in the network, 0-RTT </del> <ins> Hello.  Since packets may be reordered or lost in the network, 0-RTT </ins> packets could be seen before the Initial packet. Note that in this version of QUIC, clients send Initial packets

Related discussion:
text: This goes to the end of "Server Name Indication" Some changes are attempts at clarifications, but I could have incorrectly clarified something, so feel free to reject changes.
Code change:
Release messages can indicate one or more reasons using elective options.  The following options are defined: <del> The elective Bad-Default-Uri-Host Option indicates that the default indicated by the CSM Default-Uri-Host Option is unlikely to be useful for this server. </del> The elective Alternative-Address Option requests the peer to instead open a connection of the same scheme as the present connection to the alternative transport address given.  Its value is in the form

Related discussion:
text: The next pass will add text related to the default URI-Host for TLS SNI cases.