jiebi/CodeConvo huggingface dataset:
Change:
This may not be obvious, so perhaps good to note.
I'll move most of the text to the client section, leaving a pointer in the proxy section.
It probably depends. One could fetch the HPKE key and apply policy for each OHTTP message, which would be equivalent to applying policy for each HTTP connection if you were not using OHTTP, or one could fetch and apply policy to the HPKE key for many OHTTP messages. The results are different.
NAME this should be good to go.
Thanks for changing it up. I'm not 100% on the structure of this yet, but it is more important to get the info in place.

Discussion:
authenticated so that it can be attributed to the oblivious request resource; see key-configuration. <ins> Since clients connect directly to the proxy instead of the target, application configurations wherein clients make policy decisions about target connections, e.g., to apply certificate pinning, are incompatible with Oblivious HTTP.  In such cases, alternative technologies such as HTTP CONNECT (Section 9.3.6 of HTTP) can be used.  Applications could implement related policies on key configurations and proxy connections, though these might not provide the same properties as policies enforced directly on target connections.  When this difference is relevant, applications can instead connect directly to the target at the cost of either privacy or performance. </ins> Clients MUST NOT include identifying information in the request that is encapsulated.  Identifying information includes cookies COOKIES, authentication credentials or tokens, and any information that might
Change:
See discussion on-list.
See also URL
If we're pinning the contents of the encapsulation to message/bhttp, it seems like we also ought to change the HPKE info strings to match ("request" -> "message/bhttp-request" or whatever). When someone tries to reuse this layer of encapsulation, I think they ought to change the info string accordingly to match whatever the underlying type is. And it might not hurt to add guidance to such people in the security considerations. Can we do this in a followup PR?
I agree that we should think about content types a bit more, but that seems appropriate for another PR.
With , we're enforcing a 1:1 mapping between message/ohttp-req and message/bhttp, but we don't have any cryptographic enforcement of this pairing. If someone were to reuse the encapsulation mechanism in this document with another message type, say, to encapsulate application/dns-message values with a application/oblivious-dns-message wrapper, then we'd probably want to ensure that targets can't get confused between these two types. We could use the HPKE info string to separate these two protocols. (This is related to .)
The format I've sketched out for binary messages can be padded with zeros without needing a separate padding field. That's probably a feature worth mentioning in both drafts.
Padding is in the binary HTTP draft now.

Discussion:
5. HTTP message encapsulation uses HPKE for request and response <del> encryption.  An encapsulated HTTP message includes the following values: A binary-encoded HTTP message; see BINARY. Padding of arbitrary length which MUST contain all zeroes. The encoding of an HTTP message is as follows: </del> <ins> encryption.  An encapsulated HTTP message includes a binary-encoded HTTP message and no other content; see BINARY. </ins> An Encapsulated Request is comprised of a length-prefixed key identifier and a HPKE-protected request message.  HPKE protection

response, which might not be what some clients want. A proxy can use padding to reduce the effectiveness of traffic <del> analysis. </del> <ins> analysis.  Padding is a capability provided by binary HTTP messages; see Section 3.8 of BINARY. </ins> A proxy that forwards large volumes of exchanges can provide better privacy by providing larger sets of messages that need to be matched.
Change:
This is a breaking change, but I think that it's worthwhile. "request" is an extraordinary generic string and the risk of it being used in another context is too high.
We can address test vectors in a followup PR.

Discussion:
The client then constructs an encapsulated request, "enc_request", as follows: <del> Compute an HPKE context using "pkR", yielding "context" and encapsulation key "enc". </del> <ins> Compute an HPKE context using "pkR" and a label of "ohttp request", yielding "context" and encapsulation key "enc". </ins> Construct associated data, "aad", by concatenating the values of "keyID", "kemID", "kdfID", and "aeadID", as one 8-bit integer and

that the server is unwilling to use with "skR", the server returns an error. <del> Compute an HPKE context using "skR" and the encapsulated key "enc", yielding "context". </del> <ins> Compute an HPKE context using "skR", a label of "ohttp request", and the encapsulated key "enc", yielding "context". </ins> Construct additional associated data, "aad", from "keyID", "kemID", "kdfID", and "aeadID" or as the first seven bytes of

response "response", servers generate an Encapsulated Response "enc_response" as follows: <del> Export a secret "secret" from "context", using the string "response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce </del> <ins> Export a secret "secret" from "context", using the string "ohttp response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce </ins> associated with "context". Generate a random value of length "max(Nn, Nk)" bytes, called

corresponds to the key identifier, but the encapsulated request cannot be successfully decrypted using the key. <ins> A server MUST ensure that the HPKE keys it uses are not valid for any other protocol that uses HPKE with the "ohttp request" label. Designers of other protocols, especially new versions of this protocol, can ensure key diversity by choosing a different label in their use of HPKE.  The "ohttp response" label was chosen for symmetry only as it provides key diversity only within the HPKE context created using the "ohttp request" label. </ins> 8.4. Encapsulated requests can be copied and replayed by the oblivious
Change:
What do we want to do with this draft? Should we dispatch it and find it a home?
Good question. I wonder if secdispatch would be a good place to ask.
Clients should cache server keys for some time. TTL can be supply in a cache-control header of a ohttp-keys response. Should this be mentioned or is it implied?
The document doesn't really define the key configuration acquisition method, so it can't really cover details like caching (or retention). Getting into specifics with HTTP Cache-Control is out of scope. There is discussion of retention periods in , which are relevant and might be worth pointing to. That document has uncertain status, but we might still use an informative reference.

Discussion:
key configurations is not included in this specification.  Clients need to consider these tracking vectors when choosing a discovery method.  Applications using this design should provide accommodations <del> to mitigate tracking using key configurations. </del> <ins> to mitigate tracking using key configurations.  CONSISTENCY provides an analysis of the options for ensuring the key configurations are consistent between different clients. </ins> 10.
Change:
For and NAME
I recognize that / added some conditions and use cases, but it would help readers like me to have even more. A separate explainer document/readme would be fine too. In the meeting chat today, I heard the suggestion of requesting map tiles as another use case, which makes sense to me: asking for map tiles is itself pretty revealing if connected to the user's identity (it might reveal your current location, or a location where you're going to be) and can be pretty transactional/stateless. Maybe search queries are similar. Safe browsing lookups was also mentioned. Having more example use cases might help in resolving other questions, like whether to support multiple HTTP requests at a time, or non-HTTP message bodies, etc. Ideally, we could explain the conditions under which adoption of ohttp will be useful -- maybe, a privacy need for reducing linkability of multiple requests or of a single request from user identity, and HTTP requests that are typically stateless or single-shot in some way, and frequent or performant-requiring at a certain level.
NAME added some more examples. NAME I think we can safely close this now, so I'm going to go ahead and do that. Please reopen with concrete suggestions if you think the new text is insufficient!

Discussion:
their usage to their developers might use oblivious HTTP for some types of moderately sensitive data. <ins> These are examples of requests where there is information in a request that - if it were connected to the identity of the user - might allow a server to learn something about that user even if the identity of the user is pseudonymous.  Other examples include the submission of anonymous surveys, making search queries, or requesting location-specific content (such as retrieving tiles of a map display). </ins> 4. A client needs to acquire information about the key configuration of
Change:
But how long...?
For discussion: should the manageability draft advise that idle timeouts should be longer for flows inferred/detected to be QUIC flows? I think the answer here is "it depends": for NATs, yes, state at the edge is not all that scarce anymore. For firewalls? Maybe not so much. Are there other applications to consider here, and is there any generalized advice this document could give? If so, is there any generalized advice for how long the timeout should be?
PR is an attempt to address this issue but doesn't provide much concrete guidance...

Discussion:
on-path devices that a flow has ended is that packets are no longer observed.  Stateful devices on path such as NATs and firewalls must therefore use idle timeouts to determine when to drop state for QUIC <del> flows. </del> <ins> flows, see further section sec-stateful. </ins> 3.6.

either through timers or through least-recently-used eviction, depending on application requirements. <ins> RFC4787 recommends a 2 minute timeout interval for UDP, however, often timer are lower in the range of 15 to 30 second.  In constrast RFC5382 recommends a timeout of more than 2 hours for TCP, given TCP is a connection-oriented protocol with well defined closure semantics.  For network devices that are QUIC-aware, it is recommended to also use longer timeouts for QUIC traffic, as QUIC is connection-oriented and as such a handshake packet from the server indicates the willingness of the server to communicate with the client. </ins> The QUIC header optionally contains a Connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the
Change:
References to quic-load-balancers and RFC5077 (due to lack of a better reference) added
I thought the plan was to have a dependency on the load balancing draft rather than merging this part into the applicability draft. However, I would also be fine to add more text here and only have an informational reference, if some is willing to provide text!
... in the applicability statement? I mean one example mechanism maybe...
Can anybody help with that?
URL
The 5077 construction is pretty outdated (it's not even AEAD), unfortunately.
NAME is there somewhere else we should look for current best practice, or do we need to invent something new here?
I'll find a stuckee for up-to-date crypto language here at the Zurich interim.
closing for now, couldn't find any takers.
...actually, it's in the LB draft. Reference it.
PR proposed to address this issue...
Are you prepared to take a dependency on QUIC-LB?

Discussion:
balancers that forward the traffic based on the Connection ID.  A server can choose the Connection ID in the Server Retry packet such that the load balancer will redirect the next Client Initial packet <del> to a different server in that pool. </del> <ins> to a different server in that pool.  Alternatively the load balancer can directly offer a Retry services as further described in QUIC-LB. RFC5077 Section 4 describes an example approach for constructing TLS resumption tickets that can be also applied for validation tokens, however, the use of more modern cryptographic algorithms is highly recommended. </ins> 10.
Change:
…ancers for further algos
The intention was not to encrypt the length (as you say that would not be helpful) but you should probably "grease" the length such that those bit can not be used to identify a certain system. That was the intention here. However, maybe this is too much detail and we should remove that sentence and only refer to the load-balancer draft instead...?
Note in section about CID that as the server chooses the CIDs, it could use some own scheme to embed the length of the CID in the CID itself, instead remembering it, e.g. use the first few bits to indicate which of the sizes that are support was chosen.
can be done together with , referencing the LB draft
PR to address this and reference to load balancer draft
Reading this again, I'm not sure how I would improve the phrasing. Perhaps "embed the length of the connection ID in plaintext ...".

Discussion:
attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, <del> which is most rigorously achieved with encryption. </del> <ins> which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly. QUIC_LB further specified possible algorithms to generate Connection IDs at load balancers. </ins> 9.2.
Change:
addresses issue
Is this something application designers need to think about or manage? I would hope QUIC implementations would handle this transparently. To the extent you have to configure something like QUIC-LB, that's a manageability thing.
Connection IDs are weird, in that they are important to both implementors / deployers (so applicability) as opposed to operators of networks that are not necessarily at the endpoints (so manageability)
There is text about Connection ID in both documents. We can double-check though that the text is well aligned and splitter correctly.
Well, implementors are explicitly out of scope according to the document's introduction. I would hope that apps didn't have to worry about Connection ID properties very much, or at all. Maybe there is knob or two for information exposure, at most, but I'd consider most of this text to be extraneous to the applicabilty draft.
I think we actually put some text in the wrong doc. PR moves this text from applicability to manageability.

Discussion:
the new connection ID being negotiated via encrypted frames.  See Section 5.1 of QUIC-TRANSPORT. <ins> Server-generated connection IDs should seek to obscure any encoding, of routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly. QUIC_LB further specified possible algorithms to generate Connection IDs at load balancers. </ins> 2.7. The packet number field is always present in the QUIC packet header;

forward the packets to that server without retaining connection state. <del> Server-generated connection IDs should seek to obscure any encoding, of routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly. QUIC_LB further specified possible algorithms to generate Connection IDs at load balancers. </del> 9.2. While sufficiently robust connection ID generation schemes will
Change:
It might be the case that this is true for the whole draft and we should just state this at the beginning but better to double-check!
we will leave this issue open to double-check at the end

Discussion:
location of fields used in the version negotiation process is invariant QUIC-INVARIANTS. <del> This document is focused on the protocol as presently defined in QUIC-TRANSPORT and QUIC-TLS.  Non-invariant parts of the wire image as described herein and in those documents cannot be used to identify QUIC as a protocol, and cannot be relied upon to infer behavior of future versions of QUIC. </del> <ins> This document describes only version 1 the QUIC protocol, whose wire image is fully defined in QUIC-TRANSPORT and QUIC-TLS.  Note that features of the wire image described herein and in those documents may change in future versions of the protocol, and cannot be used to identify QUIC as a protocol or to infer the behavior of future versions of QUIC. sec-google-version provides non-normative guidance on the identification of QUIC version 1 packets compared to other deployed versions at the date if publication. </ins> 2.1.
Change:
This text in is incorrect. When you have sent that much data, the connection flow control limit cannot be increased further. Consequently, though many additional streams can be opened when a stream hits this limit, you cannot send any bytes on any of those streams. I recommend striking this sentence or replacing it with a note about this fundamental limit applying to all data conveyed in streams.
Happy to take a PR :-)
Pretty good. Thanks.

Discussion:
Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server.  Only the initiator of a <del> unidirectional stream can send data on it.  Due to offset encoding limitations, a stream can carry a maximum of 2^62-1 bytes in each direction.  In the presently unlikely event that this limit is reached by an application, the stream can simply be closed and replaced with a new one. </del> <ins> unidirectional stream can send data on it. Due to encoding limitations on stream offsets and connection flow control limits, both streams and connections can carry a maximum of 2^62-1 bytes in each direction.  In the presently unlikely event that this limit is reached by an application, a new connection would need to be established. </ins> Streams can be independently opened and closed, gracefully or by error.  An application can gracefully close the egress direction of a
Change:
after discussion with NAME we probably do want to keep the information that "all streams are equal" here. Reverse the order of the sentences here to not bury the lede.
I think that the text on can be removed. This was an interesting discussion in HTTP/3, but I'm not sure that the applicability statement needs to concern itself with this detail.
The intention was, given it was an interesting discussion in H3, it might worth mentioning as other application may have the same "problem". I think it doesn't hurt to keep it. Or is there any concern that the term "critical stream" is maybe not well enough defined?
This reads better for sure, aside from an odd bit of phrasing.

Discussion:
close either the ingress or egress direction; these actions are fully independent of each other. <del> If a stream that is critical for an application is closed, the application can generate respective error messages on the application layer to inform the other end and/or the higher layer, and eventually indicate QUIC to reset the connection.  QUIC, however, does not need to know which streams are critical, and does not provide an interface for exceptional handling of any stream. </del> <ins> QUIC does not provide an interface for exceptional handling of any stream.  If a stream that is critical for an application is closed, the application can generate error messages on the application layer to inform the other end and/or the higher layer, which can eventually reset the QUIC connection. </ins> Mapping of application data to streams is application-specific and described for HTTP/3 in QUIC-HTTP.  In general, data that can be
Change:
launches right into discussion of how linkability protections might be inadequate without really establishing what the requirements are or why they exist. This needs an introduction paragraph.
Note sure how much more we want to say here or can say at this point in time.... NAME if you have a more concrete idea what we should say here, can you give it a try and propose a PR?
Something like: Then launch into the existing discussion.
Sounds good to me. I can add that after you PR landed or you can add it to your PR.

Discussion:
9.2. <ins> QUIC requires that endpoints generate fresh connection IDs for use on new network paths.  Choosing values that are unlinkable to an outside observer ensures that activity on different paths cannot be trivially correlated using the connection ID. </ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. Analysis of the lifetimes of six-tuples (source and destination
Change:
This is a proposal to mention some more things specifically in the security considerations section. At minimum we should add a sentence pointing the reader at the security consideration of the transport and tis drafts. I additionally, more or less, copied some notes from the transport draft that I found particular relevant for reader of the manageability draft. Comments welcome!
NAME any further thought here?
After removing normative language, it occurs to us that there might be other security considerations that we want to highlight from Transport and TLS in Manageability or (especially) Applicability.

Discussion:
6. <del> Supporting manageability of QUIC traffic inherently involves tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant. </del> <ins> QUIC is an encrypted and authenticated transport.  That means, once the cryptographic handshake is complete, QUIC endpoints discard most packets that are not authenticated, greatly limiting the ability of an attacker to interfere with existing connections. However, some information is still observerable, as supporting manageability of QUIC traffic inherently involves tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant. More security considerations for QUIC are discussed in QUIC-TRANSPORT and QUIC-TLS, generally considering active or passive attackers in the network as well as attacks on specific QUIC mechanism. Version Negotiation packets do not contain any mechanism to prevent version downgrade attacks.  However, future versions of QUIC that use Version Negotiation packets are require to define a mechanism that is robust against version downgrade attacks.  Therefore a network node should not attempt to impact version selection, as version downgrade may result in connection failure. </ins> 7.