jiebi/CodeConvo huggingface dataset:
Code change:
4.2.2. To provide forward secrecy in an even more efficient way than re- <del> running EDHOC, EDHOC provides the function EDHOC-KeyUpdate.  When EDHOC-KeyUpdate is called, the old PRK_out is deleted and the new PRK_out is calculated as a "hash" of the old key using the Expand function as illustrated by the following pseudocode: </del> <ins> running EDHOC, EDHOC provides the optional function EDHOC-KeyUpdate. When EDHOC-KeyUpdate is called, a new PRK_out is calculated as a "hash" of the old PRK_out using the Expand function as illustrated by the following pseudocode.  The change of PRK_out causes a change to PRK_exporter and derived keys using EDHOC-Exporter. </ins> where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite.

Related discussion:
text: Signal uses the Diffie-Hellman ratchet very often which makes it understandable to have on optimized Diffie-Hellman ratchet post-handshake. Contrained use cases of EDHOC can not do Diffie-Hellman as often as Signal so it was determined that requiring rerun of the full EDHOC was the best tradeoff. Should the EDHOC specification say more about the benefits of frequently rerunning Diffie-Hellman? I don't remember how much it says. I recently wrote a paragraph about this that was accepted to RFC8446bis.
This is not correct. PRKout does not need to be stored. An implementation can derive the application keys directly and never store PRKout. An implementation can also store PRK_exporter if they don't use EDHOC-KeyUpdate.
This is not enough. You need to be sure that the old key is not needed more.
I merged which addresses some points raised in this issue. Please review and comment if there is anything missing.
No comments received, so I assume this is fine. (KeyUpdate is now in an appendix.)
Code change:
The key and nonce provided to the AEAD are computed as the KDF of the first "KDF.Nh" bytes of the ciphertext generated in the previous section.  If the length of the ciphertext is less than "KDF.Nh", the <del> whole ciphertext is used without padding.  In pseudocode, the key and nonce are derived as: </del> <ins> whole ciphertext is used.  In pseudocode, the key and nonce are derived as: </ins> The Additional Authenticated Data (AAD) for the SenderData ciphertext is the first three fields of MLSCiphertext:

Related discussion:
text: Also requires that padding be all-zero. Before, the sender was allowed to put arbitrary octets in there.
Looks good to me. NAME I think this covers your issue on the mailing list
Discussed at 19 May interim. Decision to merge.
As discussed , we should refactor so that the padding is not length-delimited, something like: In the MLSCiphertextContent struct we have a field for padding represented using a variable-size vector which helps hide information about the length of content; notably application messages. But because of the way we encode variable-size vectors it turns out you can't actually pad the rest of the content with certain number of bytes: namely 0, 65, 16386, 16387. (E.g. if you pad with a vector of 63 bytes the TLS encoding actually produces 64 bytes for padding: 63 bytes + 1 length byte. But if you pad with 64 bytes you end up with a 66 byte encoding as now you need 2 bytes for the length. Not being able to pad with 0 is OK. But 65 is kind of annoying. E.g. if you want to pad to a target content length X bytes then if the rest of the content ends up being X-65 bytes long you are out of luck. (Assuming I'm right about how this all works) it seems a bit silly to me for a padding scheme to have somewhat arbitrary gaps like that; especially at a not unreasonable number of bytes to want to pad with. If I didn't miss something, and you all agree that its better to avoid having gaps like that then how about represent padding as, say, a fixed length vector's? Joël Amazon Development Center Austria GmbH Brueckenkopfgasse 1 8020 Graz Oesterreich Sitz in Graz Firmenbuchnummer: FN 439453 f Firmenbuchgericht: Landesgericht fuer Zivilrechtssachen Graz
Code change:
Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start routing IP packets in that prefix to its peer. <ins> If an endpoint receives multiple ROUTE_ADVERTISEMENT capsules, all of the advertised routes can be used.  For example, multiple ROUTE_ADVERTISEMENT capsules are necessary to provide routing to both IPv4 and IPv6 hosts.  Routes are removed using ROUTE_WITHDRAWAL capsules. </ins> 4.2.4. The ROUTE_WITHDRAWAL capsule allows an endpoint to communicate to its

Related discussion:
text: Good point, added. Note that I've also added an important note about how ROUTEADVERTISEMENT and ROUTEWITHDRAWAL coexist, please take a look NAME and NAME .
As discussed in , turning a sequence of ROUTEADVERTISEMENT and ROUTEWITHDRAWAL capsules into a functional routing table isn't as simple as initially expected. This is because two separate capsules can describe prefixes that are distinct but overlap. We should simplify the design or better explain the caveats.
I think the capsules description needs to be explicit if multiple capsules are allowed. I think there are different considerations depending on what type of capsules are used. The authors have already discussed and concluded that multiple routeadvertisement will be needed to allow to declare reachability of multiple prefix. I don''t know if multiple addressassign capsules are allowed. Allowing multiple allows multiple address ranges to be declared. However, that results that we also get the question if one need to withdraw source address prefixes..
Yes, multiple capsules of each type are allowed. It does seem useful to clarify this, and what it means to receive multiple addresses and multiple routes (which are additive). NAME can you help write this?
Agreed, multiple capsules of all currently defined capsule types are allowed. For example, multiple ADDRESS_ASSIGN are needed to support a dual-stack tunnel. I'll write a PR.
Code change:
section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <del> [OPEN ISSUE: Handling of a=imageattr] </del> If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to exactly match the

Related discussion:
text: This LGTM. Actually, I thought I had written something like this :)
LGTM
Always remember to update both the offer and answer sections :)
Code change:
A secondary use case is web applications that want to access DNS information.  Standardizing an HTTPS mechanism allows this to be done <del> in a way consistent with the cross-origin resource sharing CORS security model of the web and also integrate the caching mechanisms of DNS with those of HTTP.  These applications may be interested in </del> <ins> in a way consistent with the cross-origin resource sharing security model of the web CORS and also integrate the caching mechanisms of DNS with those of HTTP.  These applications may be interested in </ins> using a different media type than traditional clients. <del> [ This paragraph is to be removed when this document is published as an RFC ] Note that these use cases are different than those in a </del> <ins> [[ This paragraph is to be removed when this document is published as an RFC ]] Note that these use cases are different than those in a </ins> similar protocol described at I-D.ietf-dnsop-dns-wireformat-http. The use case for that protocol is proxying DNS queries over HTTP instead of over DNS itself.  The use cases in this document all

Related discussion:
text: I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.
Code change:
indicate that the client configuration used to construct the request is incorrect or out of date. <ins> 5.3. The problem type PROBLEM of "https://iana.org/assignments/http- problem-types#ohttp-key" is defined.  An MAY use this problem type in a response to indicate that an used an outdated or incorrect . fig-key-problem shows an example response in HTTP/1.1 format. As this response cannot be encrypted, it might not reach the .  A cannot rely on the using this problem type.  A might also be configured to disregard responses that are not encapsulated on the basis that they might be subject to observation or modification by an .  A might manage the risk of an outdated using a heuristic approach whereby it periodically refreshes its if it receives a response with an error status code that has not been encapsulated. </ins> 6. In this design, a wishes to make a request of a server that is

Related discussion:
text: We debated this at some length. This defines an optional-to-use signaling method for the gateway so that it can inform the client when the key configuration is not acceptable. Clients can use this as a prompt to refresh their configuration.
(Originally posted by NAME in URL): Any lifetime information that comes with a key is helpful, but in practice is insufficient for clients to drive key updates. Key rotation may not occur on a fixed schedule and it may not occur synchronously (some gateway instances might not get the key at the right time. This means that clients cannot distinguish between failures due to configuration mismatch or request tampering (or whatever else might cause the gateway to reply without an encapsulated response). If the client can't distinguish then the client's recovery implementation is a lot more complicated. Does it always try to forcibly update its configuration? Does it implement some sort of backoff? Can a relay abuse the client's recovery implementation to somehow put the client into a state where it is stuck with an old configuration? It seems vastly simpler to just be clear that the configuration is wrong as a signal to the client that it's time to update. This was done in ODoH with a 401 response code. proposed a new problem statement, which I think is the right way to deal with this. Yes, there are potential privacy problems based on automated updates, but those depend on the client's consistency story and is therefore not something new a signal would introduce.
This looks great -- thanks!
Code change:
3- Authentication key to authenticate the encrypted frame and the media metadata <del> The IV is 128 bits long and calculated from the SRC and CTR field of the Frame header: </del> <ins> The IV is 128 bits long and calculated from the CTR field of the Frame header: </ins> 3.2.2.

Related discussion:
text: LGTM
I have a doubt about why an SRC for the CTR is needed at all and if a global counter for all streams would be equally secure in terms forming the IV or was due to implementation details to be able to have different context for each streams?
Because the key is used to encrypt all outgoing stream, we need a global counter for the IV to avoid counter reuse. If we use the frame counter only, then each stream will have their own counter and IV will collide
If the frame counter is global for the participant instead that per stream, i.e. increased whenever a new frame is encoded regarding the media stream, there would be no IV collision.
Correct. But I imagine this will be more complex to implement, having a single global counter across all media sources including audio and video
Prepared a PR to change it to a global counter, however I want to make sure I understand how the counter is maintained globally, If the frame N is encrypted in 3 different layers, they will have different counter values right? One potential benefit of having a global counter it will free up some bits in the header which we can use as a keyId (up to 16 keys) which is nice
Yes, each call to the frame encryptor which would require to atomically increment the counter. In the case of the simulcast, the same input image will produce N different encoded frames which would have their unique counter. Regarding the free bits, I was thinking in something like this: If x=0 then K is the key id ( 0-7) if x=1 then K is the length of the key that is inserted before the This would allow to avoid the extra byte for conferences with less than 9 participants. Another option would be to always use the KLEN/KEYID and reserve that bit for extensions in the future.
I like it :-)
Code change:
meaning that the server is not willing to receive any WebTransport sessions. <ins> Because WebTransport over HTTP/3 requires support for HTTP/3 datagrams and the Capsule Protocol, both the client and the server MUST indicate support for HTTP/3 datagrams by sending a SETTINGS_H3_DATAGRAM value set to 1 in their SETTINGS frame (see Section 2.1.1 of HTTP-DATAGRAM). WebTransport over HTTP/3 also requires support for QUIC datagrams. To indicate support, both the client and the server MUST send a max_datagram_frame_size transport parameter with a value greater than 0 (see Section 3 of QUIC-DATAGRAM). </ins> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by

Related discussion:
text: Require SETTINGSH3DATAGRAM and maxdatagramframe_size TP
Interesting thought. One way to do that replaces the entire section with this: This is certainly more concise, although it does also remove some of the explanations that help people understand the various layers involved. Or perhaps we should include those same additional details but just turn those paragraphs into bullets?
While technically true, I thought we'd said that we wanted to require all the features all of the time, but agreed, let's take that to an editorial issue if needed.
My point is that the server could support both regular HTTP and WebTransport. If a client comes in without webtransport settings and only sends GETs, that's fine. If a client comes in with webtransport settings and makes a webtransport request, that's fine. If a client comes in without webtransport settings and makes a webtransport request, that's not fine. In that case the server needs to reject the webtransport request, not kill the connection.
Ah, that makes more sense, thank you
Per discussion at IETF 114, we should explicitly require support for each layer of capabilities that are needed. There was also a discussion about whether or not we needed to require datagram support, since requiring capsules technically means that you could use a datagram capsule and implementations may exist that do not want to have datagram support at all. Documenting some of that discussion in replies to this issue, as well.
Specific to datagrams and capsules: WT supported means that capsule protocol is supported, thus you must always support capsules. Proposal: You need to have datagrams in order to do WT over HTTP/3 Adding additional signaling to negotiate datagram support introduces a lot of additional complexity and different configurations that may harm interoperability. Dropping a datagram is about as easy as doing any other error path HTTP Datagrams must already be supported in the receive direction for capsules (and you need capsules for WT) either way Intermediaries will need to be able to either translate for upstream or ensure that upstream can provide an equivalent feature set More generally: We want to explicitly call out dependencies/prerequisites so that we don't need to teach layers about other layers.
Code change:
meaning that the server is not willing to receive any WebTransport sessions. <ins> Because WebTransport over HTTP/3 requires support for HTTP/3 datagrams and the Capsule Protocol, both the client and the server MUST indicate support for HTTP/3 datagrams by sending a SETTINGS_H3_DATAGRAM value set to 1 in their SETTINGS frame (see Section 2.1.1 of HTTP-DATAGRAM). WebTransport over HTTP/3 also requires support for QUIC datagrams. To indicate support, both the client and the server MUST send a max_datagram_frame_size transport parameter with a value greater than 0 (see Section 3 of QUIC-DATAGRAM). </ins> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by

Related discussion:
text: For example, WT being supported doesn't mean that the layers that implement capsules, H3 datagrams, or QUIC datagrams should have any idea about the existence of WebTransport
Discussed at IETF 115, consensus in room to require all the relevant settings and transport parameters to be sent individually
So we need: HTTP Setting: SETTINGSH3DATAGRAM (0x33) with a value of 1 for HTTP datagrams QUIC TP: maxdatagramframesize with a value greater than 0 for QUIC datagrams Capsule protocol support is implicit in the upgrade token, as explicitly called out by RFC 9297 or we can require to be sent on every extended connect request as well. to be added to the existing HTTP Setting: SETTINGSENABLEWEBTRANSPORT = 1 HTTP Setting: SETTINGSWEBTRANSPORTMAXSESSIONS > 0 (although we may be removing SETTINGSENABLEWEBTRANSPORT)
SGTM I think we can skip mentioning Capsule-Protocol to match CONNECT-UDP
Would this be easier to process as a list rather than multiple separate requirements?The list text in that comment isn't correct - the server shouldn't close the connection because it's legal for the client to not support datagrams if it only sends GETs and POSTs. However, the text in this PR is correct. I propose we land the PR as-is and can make editorial changes later.
Code change:
packets in response to Initial packets that don't include a valid token. <del> Both server and service must have access to Universal time, though tight synchronization is unnecessary. </del> <ins> Both server and service must have time synchronized with respect to one another to prevent tokens being incorrectly marked as expired, though tight synchronization is unnecessary. </ins> The tokens are protected using AES128-GCM AEAD, as explained in token-protection-with-aead.  All tokens, generated by either the

Related discussion:
text: This is in response to a post NAME made on .
Thanks for the PR! So as an interoperability standard, if the retry service encodes "4000", what does the server do with that? Do we need to add a config parameter for the time_t that serves as time 0?
Timestamps should be absolute, not relative, in which case I'm not sure you need a 0. There's nothing special about midnight 1 January 1970.
Ah, so you're just suggesting declaring a later date to begin the epoch? Makes sense
Why do we need to have a sential time? If it's a precision vs. range issue then shifting the epoch makes sense.
Sorry, I don't know what "sential time" is. What are you proposing?
What I'm proposing is that we not treat any times differently. It's not clear to me why 4000 needed special treatment.
4000 is just an example. The intent of using the epoch was to have common agreement on when tokens expire without any QUIC-LB-specific coordination. The current draft uses 1970 as a timebase, which absolutely makes integers longer than it needs to be. IIUC the PR doesn't have any baseline so it's unclear how the server and retry service are supposed to interpret each other's expiration times. As we're probably speaking past each other: what, precisely, does the integer in this field indicate?
It's the end of the validity period for the token in some convenient timebase.
Alright, we agree on that. So this PR is being a little less precise on synchronization, which is fine, but isn't addressing the fact that we're counting from 1970. Fair enough. Dear QUIC WG, First a moment of unforgivable pedantry. Universal time is unfortunately not the right name for UTC, which is slightly different. It could also mean UT1 or some other variations It's also not clear what the future of computer timekeeping is and I know several places don't synchronize to UTC internally. I think the best way to handle this is to say something like "synchronized" and leave open as to exactly how that is done. I agree with the comments that there are too many options and should be fewer. Other then that I didn't see any problems but I'm probably too sleepy right now to spot them. Sincerely, Watson Ladd Astra mortemque praestare gradatim
Code change:
information that does not reveal information about the encapsulated response. <del> 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. </del> In order to achieve the privacy and security goals of the protocol an Oblivious Gateway Resource also needs to observe the guidance in server-responsibilities.

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:
13.2. Endpoints acknowledge all packets they receive and process.  However, <del> only ack-eliciting packets (see QUIC-RECOVERY) trigger the sending of an ACK frame.  Packets that are not ack-eliciting are only </del> <ins> only ack-eliciting packets cause an ACK frame to be sent within the maximum ack delay.  Packets that are not ack-eliciting are only </ins> acknowledged when an ACK frame is sent for other reasons. When sending a packet for any reason, an endpoint should attempt to

Related discussion:
text: At the moment, we state that a QUIC packet that contains frames other than ACK and PADDING (), but I wonder if that is true for CONNECTIONCLOSE frame. A CONNECTIONCLOSE frame never elicits an acknowledgment. IIUC, it is not meant to be governed by the congestion controller. Considering the aspects, I think we should add CONNECTION_CLOSE to the list of non-ACK-eliciting frames.
That also ensures the congestion controller never inadvertently blocks sending a CONNECTIONCLOSE, which is consistent with the intent. If we make this change, I believe APPLICATIONCLOSE needs to be on the list as well. Now that we discuss ack-eliciting in transport, I think we'd need to change both transport and recovery and mark this design. So I think this would be a slight improvement, but I an also imagine people claiming that CONNECITON_CLOSE is already special, so there's no need for a change.
APPLICATION_CLOSE is no more. This seems like a fine change.
This seems sensible.
Discussed in Cupertino. Obvious correction.
Seems right to me. Editorial tweaks suggested.