jiebi/CodeConvo huggingface dataset:
Code change:
If the URIs learned via more than one option described in option are not all identical, this condition should be logged for the device <del> owner or administrator.  URI precedence in this situation is not specified by this document. </del> <ins> owner or administrator.  Implementations can select their own precedence order. </ins> 4.

Related discussion:
text: …ptive-portals/vIDCvkyKXdvMGjwvOHuTsSgFzt8/
LGTM, for this change to address 1/2 of the referenced comments.
Code change:
A side-benefit of the architecture described in this document is that devices without user interfaces are able to identify parameters of <del> captivity.  However, this document does not yet describe a mechanism for such devices to escape captivity. </del> <ins> captivity.  However, this document does not describe a mechanism for such devices to negotiate for unrestricted network access.  A future document could provide a solution to devices without user interfaces. This document focuses on devices with user interfaces. </ins> The architecture uses the following mechanisms:

Related discussion:
text: Multiple reviewers objected to the way in which we captured interactions with headless/UI-less devices. Clarify the document's intent. Do this by removing language that indicated that we would eventually get around to adding the requirements, and specify explicitly that we are not handling devices without UIs.
Eric points out in his review: He suggests as a solution: I propose we do this. The first mention is in section one. We can say something along the lines of "A future document could provide a solution for devices without user interfaces. This document focuses on devices with user interfaces."
On page 4: Joel Halpern writes,
We might want to avoid relying on the captivity concept so heavily, but this is a good change nonetheless.
Code change:
The entries in iana-frame-table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through </del> <ins> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, "0x21", "0x40", ..., through </ins> "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 11.2.2.

Related discussion:
text: Clarify reserved values for stream types, settings identifiers, frame types, and error codes. 0x1f N + 0x21 for the value of N = -1 is 0x02. Literal interpretation of the current text includes this as a reserved value. The parenthetical examples given in Section 11.2 make it clear that this was not the intention, rendering this PR editorial. The main motivation of this PR is not that the current text is inconsistent, but that parenthetical examples from 11.2 are necessary to correctly interpret the definitions in sections 6.2.3, 7.2.4.1, 7.2.8, and 8.1. Alternative wordings could be: "0x1f N + 0x21 for N = 0, 1, 2, ..." "0x1f N + 0x02 for positive integer values of N" "0x1f N + 0x02 for N = 1, 2, 3, ..." "0x21, 0x21 + 0x1f, 0x21 + 2 * 0x1f, ..." "a value of at least 0x21 with a remainder of 0x02 modulo 0x1f" "a value of at least 0x21 that is congruent to 0x21 modulo 0x1f" none of which is better than what this PR proposes.
Code change:
Path Identifier (Path ID): An identifier that is used to identify a path in a QUIC connection at an endpoint.  Path Identifier is <del> used in multipath control frames (etc.  PATH_ABANDON frame) to identify a path.  The Path ID is defined as the sequence number of the destination Connection ID used for sending packets on that particular path. Packet Number Space Identifier (PNS ID): An identifier that is used to distinguish packet number spaces for different paths.  It is used in 1-RTT packets and ACK_MP frames.  Each node maintains a list of "Received Packets" for each of the CID that it provided to the peer, which is used for acknowledging packets received with that CID. The difference between Path Identifier and Packet Number Space Identifier, is that the Path Identifier is used in multipath control frames to identify a path, and the Packet Number Space Identifier is used in 1-RTT packets and ACK_MP frames to distinguish packet number spaces for different paths.  Both identifiers have the same value, which is the sequence number of the connection ID, when a new path is established. The initial path that is used during the handshake (and multipath negotiation) has the path ID 0 and therefore all 0-RTT packets are also tracked and processed with the path ID 0.  For 1-RTT packets, the path ID is the sequence number of the Destination Connection ID present in the packet header, as defined in Section 5.1.1 of QUIC- TRANSPORT. </del> <ins> used in multipath control frames (e.g., PATH_ABANDON frame) to identify a path.  The initial path that is used during the handshake (and multipath negotiation) has the path ID 0 and therefore all 0-RTT packets are also tracked and processed with the path ID 0.  For 1-RTT packets, the path ID is the sequence number of the Destination Connection ID present in the packet header, as defined in Section 5.1.1 of QUIC-TRANSPORT that is used for sending packets on that particular path. </ins> 2.

Related discussion:
text: From PR from NAME
Let's do another editorial pass and evtl. some re-org first and then address this issue. I think we all already agreed that we only need one of the two. So we only need to decide with name we keep.
I prefer to use the name "Path ID", as it is more intuitive in the context of multipath.
The conflict was solved. LGTM.Sounds good.
Code change:
end-to-end RTT.  See spin-usage for further details. header type: the long header has a 2 bit packet type field <del> following the Header Form bit.  Header types correspond to stages of the handshake; see Section 17.2 of QUIC-TRANSPORT. </del> <ins> following the Header Form and fixed bits.  Header types correspond to stages of the handshake; see Section 17.2 of QUIC-TRANSPORT for details. </ins> version number: the version number present in the long header, and identifies the version used for that packet.  Note that during

Related discussion:
text: (which didn't require any non-editorial changes; the review is done now)
Also call out invariants (esp. in header structure and handshake) explicitly: v2 may/will break functionality outside the invariants.
Document is currently in in with final invariants; do one last pass to make sure everything documented in Section 17 as expose information appears here (which is basically the same check).
Code change:
This draft includes pseudocode that uses the functions and conventions defined in HPKE. <del> This draft uses the variable-length integer encoding from Section 16 of QUIC.  Encoding and decoding variable-length integers to a sequence of bytes are described using the functions "vencode()" and "vdecode()".  The function "len()" takes the length of a sequence of bytes. </del> <ins> Encoding an integer to a sequence of bytes in network byte order is described using the function "encode(n, v)", where "n" is the number of bytes and "v" is the integer value.  The function "len()" returns the length of a sequence of bytes. </ins> Formats are described using notation from Section 1.3 of QUIC.

Related discussion:
text: Switches to an 8-bit key identifier here as well. This format now doesn't need varints. Yay. Implemented this in my ohttp library and it's fine.
Splitting this from . It seems likely that a single KEM key will support multiple KDF or AEAD options (NSS will soon support 3 of the former, and 2 of the latter, maybe 3 of each). Having a configuration that includes a single set of (KEM, key, and key identifier) with a list of KDF+AEAD pairs, akin to ECH, would make it easier to support that sort of deployment. Without that, key identifiers need to carry information about the KDF and AEAD. To support this, the format needs to be adjusted to carry the KDF and AEAD identifier. In doing so, we probably want to encode the choice of KDF and AEAD in the key schedule or AAD accordingly.
Should the key ID length be explicitly authenticated, e.g., by including it in the AAD, or should the AEAD implicitly authenticate things? Unclear!
Should we even bother with an AAD at all? The best reason is that the keyID determines which key the server uses, which is information that factors into decisions. (A related question might be why doesn't HPKE take variables as input so that things like key identifiers can be integrated into the key schedule.)
My take: yes. I need to think through the implications of no additional authentication at all, and in the mean time, I'd be more comfortable with simply authenticating everything possible. I think it was discussed, but it makes the interface a mess. And since applications can accomplish the same thing by shoving what they want authenticated into the AAD, it was voted down.
Yeah, you and I both know that putting stuff in the AAD isn't a real substitute for having it in the key schedule. I completely understand how this would mess with the purity of the design, but TLS managed by wrapping its labels better (which also addresses a known problem with HKDF not being injective).
Fixed by virtue of making the key ID fixed length in .
Code change:
within the HPKE context created using the "message/bhttp request" label; see repurposing-the-encapsulation-format. <ins> 7.5. </ins> A server is responsible for either rejecting replayed requests or ensuring that the effect of replays does not adversely affect clients <del> or resources; see replay. 7.4. </del> <ins> or resources. </ins> Encrypted requests can be copied and replayed by the Oblivious Relay resource.  The threat model for Oblivious HTTP allows the possibility

Related discussion:
text: NAME noted that it was important to note that the Gateway needs to be trusted if gateway != target. As a practical matter, that means that you probably want gateway == target.
Hi, Since the gateways are seeing request/response pairs, there is a potential here for a side-channel attack at the gateway itself or at a relay. (if I understood the draft correctly - if not, please clarify my misunderstanding here). Are there mitigations planned for this type of issue that you could expand on in the Security Considerations section perhaps?
Does the new text in address this concern?
I don't think so, because the claim is the gateway does not have intimate knowledge of the contents of the request/response. If that assertion is true, the gateway shouldn't be able to ascertain information about the actual contents from those pairs (directly or indirectly, via a side-channel attack). If the burden is on the application developer to ensure that request/response pairs traversing the gateway are to be resilient to side-channel attacks of those pairings, then it would be good to explicitly call that out in this spec (perhaps in the security considerations section?) Thoughts?
NAME the gateway necessarily sees all request and response pairs, and will therefore always learn information about each transaction. This is fundamental to the design. Whether or not the gateway uses that information for malicious purposes, e.g., by providing different responses to different requests for the same target resource, depends on the trust model. And the change in addresses that. I don't think further text is needed here.
"Finally, a relay can also generate responses, though it assumed to not be able to examine the content of a request (other than to observe the choice of key identifier, KDF, and AEAD), so it is also assumed that it cannot generate an Encapsulated Response." I feel that a relay could certainly perform a side-channel attack here as well using R/R pairings.
Can you please be more specific here? What type of attack could the relay do to violate client privacy that is not already documented in the draft?
Typically in HTTPs scenarios, it is more difficult to perform side channel attacks as a flow observer, especially if multiplexing of requests and responses are performed.
Code change:
within the HPKE context created using the "message/bhttp request" label; see repurposing-the-encapsulation-format. <ins> 7.5. </ins> A server is responsible for either rejecting replayed requests or ensuring that the effect of replays does not adversely affect clients <del> or resources; see replay. 7.4. </del> <ins> or resources. </ins> Encrypted requests can be copied and replayed by the Oblivious Relay resource.  The threat model for Oblivious HTTP allows the possibility

Related discussion:
text: In this design, if I understand it correctly, the requests and responses are being broken out into distinct exchanges that the relay can see and therefore it makes it easier for a relay to perform these types of attacks that would be more difficult had the relay not been used in the first place. If my understanding of the protocol is incorrect here, please feel free to point that out.
You seem to be describing fingerprinting attacks, wherein the observer uses features extracted from otherwise encrypted traffic to try and learn information about the underlying (unencrypted) data. Yes, the relay does have a more fine-grained view of each exchange compared to a network observer in this protocol since it can see explicit message boundaries, and that might impact the efficacy of these attacks. This is partly already addressed in the document: We could extend this to note the relay's view of message boundaries. I don't think any additional text is needed for the gateway.
Whatever you feel is best. I think some language around the message level risks this creates vs non-relay scenarios might be helpful. Does the client intentionally break things up in a way that crosses the underlying application message boundaries (e.g. more like packetization) with a relay? I have more questions about the gateway functionality that we can discuss separately.
This means that the client really needs to trust that the gateway doesn't muck with it. As a practical matter, this incentivizes clients to choose a gateway that is effectively the same entity as the target. They don't have to, but the amount of trust required of the gateway is higher if gateway and target aren't operated by the same entity. We touch on this, but we could be clearer about it.
Code change:
The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value for this bit are not valid packets in this version and <del> MUST be discarded. </del> <ins> MUST be discarded.  A value of 1 for this bit allows QUIC to coexist with other protocols; see RFC7983. </ins> The next two bits (those with a mask of 0x30) of byte 0 contain a packet type.  Packet types are listed in long-packet-types.

Related discussion:
text: NAME said:
This particular choice has not a lot to do with QUIC and would therefore bring in a lot of non-sequitur references, but a single sentence won't hurt. It has to be repeated, which is gross, but I can live with that.
Code change:
The "extension_data" field of the quic_transport_parameters extension contains a value that is defined by the version of QUIC that is in use.  The quic_transport_parameters extension carries a <del> TransportParameters when the version of QUIC defined in QUIC- </del> <ins> TransportParameters struct when the version of QUIC defined in QUIC- </ins> TRANSPORT is used. The quic_transport_parameters extension is carried in the ClientHello

Related discussion:
text: I suspect these are uncontroversial.
All three Mart[ie]ns now agree, no further objections allowed.
LGTM, with the one change altered.
Code change:
Check that the "account" field of the key-change object contains the URL for the registration matching the old key <del> Check that the "oldKey" field of the key-change object contains the current account key. </del> Check that the "newKey" field of the key-change object contains the key used to sign the inner JWS.

Related discussion:
text: This was part of URL (see removal of oldKey from example payload), but I missed these two other spots. oldKey is fully specified by the account URL in the payload.
Code change:
restricted to certain users, but we assume that those restrictions are enforced by the application layer. <del> 2.1. </del> <ins> 2.3. </ins> While informally, a group can be considered to be a set of users possibly using multiple endpoint devices to interact with the Service

Related discussion:
text: This replaced PR which has broken merge conflicts.
I've reverted this. It was prematurely merged. I'll open a new PR once I have had time to examine this.
This was discussed in the interim today and is the same as the content that was in . Thanks, -rohan Rohan Mahy l Vice President Engineering, Architecture Chat: NAME on Wire Wire - Secure team messaging. Zeta Project Germany GmbH l Rosenthaler Straße 40, 10178 Berlin, Germany Geschäftsführer/Managing Director: Alan Duric HRB 149847 beim Handelsregister Charlottenburg, Berlin VAT-ID DE288748675
That's fine, but I still want to go over it before it merges.
Code change:
An endpoint MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID <del> field.  The value for Source Connection ID MUST be copied from the Destination Connection ID of the received packet, which is initially randomly selected by a client.  Echoing both connection IDs gives clients some assurance that the server received the packet and that the Version Negotiation packet was not generated by an attacker that is unable to observe packets. </del> <ins> field.  The value for the Source Connection ID field MUST be copied from the Destination Connection ID field of the received packet, which is initially randomly selected by a client.  Echoing both connection IDs gives clients some assurance that the server received the packet and that the Version Negotiation packet was not generated by an attacker that is unable to observe packets. </ins> An endpoint that receives a Version Negotiation packet might change the version that it decides to use for subsequent packets.  The

Related discussion:
text: The names are capitalized, but we don't say "the ... field." We probably should.
Code change:
error.  Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service (DoS) attacks because UDP forgery is so easy.  Thus, this practice is <del> NOT RECOMMENDED for such transports. </del> <ins> NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </ins> If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts

Related discussion:
text: Attempt to address though I'm not entirely happy with this text. Having gone through the existing text looking at "vulnerable" and "susceptible", it doesn't seem in particularly bad shape, so my comment there may have been stronger than needed.
Copied from EKR's repo Ben Kaduk wrote: "We talk in a couple places about datagram protocols being “vulnerable” or “susceptible” to DoS attacks, which leads me to at least partially read that as meaning that the protocol’s own service will be disrupted; as we know, this is not the whole story, as the reflection/amplification part can facilitate DoS attacks targeted at other services/networks. So perhaps some rewording is in order. "
NAME I would welcome a PR here.
NAME did this,
Code change:
Preconnections are reusable after being used to initiate a Connection.  Hence, for example, after the Connections were closed, <del> the following would be correct: ~~~ //.. carry out adjustments to the Preconnection, if desire Connection := Preconnection.Initiate() ~~~ </del> <ins> the following would be correct: </ins> 3.1.3.

Related discussion:
text: , , , , , .
In 8.1.1 the second sentence is convoluted. Is there a way to restate it without as many nots, nons, an different zeros?
Do you really mean "host" at "(endpoints) SHOULD represent the same host" in section 6, or do you mean something more like service, given that an endpoint may configured with a DNS name?
actually we mean service, good catch.
The "reformatted where necessary" part of the requirement in the last paragraph of 4.1 makes the MUST NOT almost impossible to conform to. I think I understand what the paragraph is trying to say, but the current formulation leaves the reader guessing. I think you are trying to say "Avoid using any of the terms listed as keywords in the protocol numbers registry as any part of a vendor or implementation-specific property name".
The first sentence-paragraph of section 4 is complex. Please break it apart.
has a comment that's too long for the text version
In the text version of the document, the last paragraph before 3.1.3 has some markup (~~~) that has leaked through.
As you can tell, I don't think the documents do what the first sentence of the API summary claims. This document would not lose anything if you deleted the sentence.
Agreed, we can lose this sentence.
Why? Removing this makes no sense to me.
For one, it's redundant - it only repeats what we already say earlier twice.
Ah, I see - so just this one instance..... then go ahead, we don't need to say something twice.
Code change:
receipt of a second ClientHello message with a ClientECH value, servers set up their HPKE context and decrypt ClientECH as follows: <del> It is an error for the client to offer ECH before the HelloRetryRequest but not after.  Likewise, it is an error for the client to offer ECH after the HelloRetryRequest but not before.  If the client-facing server accepts ECH for the first ClientHello but not the second, or it accepts ECH for the second ClientHello but not the first, then the client MUST abort the handshake with an "illegal_parameter" alert. </del> <ins> If the client offered ECH in the first ClientHello, then it MUST offer ECH in the second.  Likewise, if the client did not offer ECH in the first ClientHello, then it MUST NOT not offer ECH in the second. </ins> [[OPEN ISSUE: Should we be using the PSK input or the info input?  On the one hand, the requirements on info seem weaker, but maybe

Related discussion:
text: It is an error for the client to offer ECH after HRR but not before. Likewise, it is an error for the client to offer ECH before HRR but not after. This change ensures the server aborts in this case.
Suppose we hit one of the messy HRR cases (URL), where the HRR is valid for the outer ClientHello, but not the inner ClientHello. The client then cannot construct a valid inner ClientHello. How would that square with this text? Are you envisioning the client just generates a random ECH extension, or...?
I don't think this is a new problem. I see the PR as clarifying existing behavior. Can you please propose text for the HRR nightmare in ? :-)
Ah, you're right. Sorry, I misread this PR as introducing this requirement. In principle, we only need the server to require ECH in CH2 if it decided to accept ECH on CH1. That would allow the client to not send ECH the second time, but maybe we don't want to do that, depending on what we do for ... Do we know what we want to do for ? Simplest seems to be saying clients MUST align them. (Though how does that work with later HRR-sensitive extensions? Are funny ECH-adding proxies a thing?) Or maybe it's just a SHOULD? Or maybe we come up with some other protocol trick so ECH acceptance is visible at HRR (which would probably reopen the don't-stick-out can of worms yet again). Of these, only the MUST avoids collision with this PR's (existing) client requirement.
Yeah, that's my preference. This logic is already complicated enough. The primary pain point I see is enumerating (and prescribing) what is a HRR-sensitive field.
Same, with that pain point being the big question in my head. Whether an HRR is valid for a ClientHello isn't an implementation decision, so in theory it's enumerable. But more extensions may come in later. And in the other direction, even a very strong SHOULD means we need to pick a client behavior for the weird case and allow for it in server behavior.
Regardless of where we land on , this PR seems appropriate to me.