jiebi/CodeConvo huggingface dataset:
Code change:
3.1.3. <del> QUIC ends a loss epoch when a packet sent after loss is declared is acknowledged.  TCP waits for the gap in the sequence number space to be filled, and so if a segment is lost multiple times in a row, the loss epoch may not end for several round trips.  Because both should reduce their congestion windows only once per epoch, QUIC will do it correctly once for every round trip that experiences loss, while TCP may only do it once across multiple round trips. </del> <ins> QUIC starts a loss epoch when a packet is lost and ends one when any packet sent after the epoch starts is acknowledged.  TCP waits for the gap in the sequence number space to be filled, and so if a segment is lost multiple times in a row, the loss epoch may not end for several round trips.  Because both should reduce their congestion windows only once per epoch, QUIC will do it correctly once for every round trip that experiences loss, while TCP may only do it once across multiple round trips. </ins> 3.1.4.

Related discussion:
text: I was trying to come up with text for this but this PR looks great.
I believe there's an extra "is".
Can you write a PR? Removing either 'is' doesn't read well to me, but I suspect a sentence rewrite could be an improvement. ie: "A loss epoch ends when a packet sent after loss is first declared is acknowledged."?
I agree a rewrite would be better.
Code change:
to receiving packets that only contain DATAGRAM frames, since the timing of these acknowledgements is not used for loss recovery. <ins> As with any ack-eliciting frame, when a sender suspects that a packet containing only DATAGRAM frames has been lost, it MAY send probe packets to elicit a faster acknowledgement as described in Section 6.2.4 of RFC9002. </ins> If a sender detects that a packet containing a specific DATAGRAM frame might have been lost, the implementation MAY notify the application that it believes the datagram was lost.

Related discussion:
text: The draft has some good text in the "Acknowledgement Handling" and "Congestion Control" sections that essentially is stating that DATAGRAM is just like any other ACK-eliciting packet, but is not automatically retransmitted by the transport. That's all reasonable, but I think there needs to be more text on how the (suspected) loss of a packet with a DATAGRAM frame or a PTO with only an outstanding DATAGRAM packet should be handled. I can see two possible models: It's just like any other packet. The goal is to elicit some ACK from the peer to get accurate loss information about the outstanding packet as soon as possible. If there is nothing outstanding we could use to send in a new packet, just send a PING frame. It's special. Because we don't necessarily intend to retransmit the data in the packet if it is actually lost, we don't actually care about immediate loss information/feedback. Don't force anything to be sent immediately to elicit the ACK. So far as I have it coded up in MsQuic, I've assumed (1). This essentially results in an immediate PING frame/packet being sent out if I have nothing else to retransmit to try to elicit an ACK for the DATAGRAM frame/packet. This could result in a slightly noisier connection if the app doesn't care about all loss information about their datagrams, but, IMO makes for a cleaner design. I don't know what the general consequences to congestion control might be if we don't do this. Assuming folks are in agreement, we should have some text on this topic in the draft.
NAME NAME as authors of the recovery draft do you have an opinion here?
I support NAME choice of 1 and it aligns with the recovery draft. It also matches our implementation. Adding clarifying text around this SG and I'd be happy to review it.
I agree -- choice (1) is cleanest and I would argue that choice(2) is really not principled.
Late to the issue, but I think (1) is the right choice here. It's not simply that datagrams aren't retransmitted, but that they might be retransmitted by the application if they're declared lost. If you don't have prompt feedback, that scenario suffers.
Code change:
to receiving packets that only contain DATAGRAM frames, since the timing of these acknowledgements is not used for loss recovery. <ins> As with any ack-eliciting frame, when a sender suspects that a packet containing only DATAGRAM frames has been lost, it MAY send probe packets to elicit a faster acknowledgement as described in Section 6.2.4 of RFC9002. </ins> If a sender detects that a packet containing a specific DATAGRAM frame might have been lost, the implementation MAY notify the application that it believes the datagram was lost.

Related discussion:
text: Seems like we have good agreement on this, just need to write the text
NAME -- To NAME 's comment at the mic, you should cite .
This text sounds good, though I'd love a little bit more text mentioning the benefit of this probeThis text is fine with me. I am wondering if we should say something additional, like that packets with datagram frames shouldn't be treated special, with respect to loss recovery.
Code change:
server.  This attack is bound by the number of valid TCP connections an attacker can open. <del> 7.2.4. </del> <ins> 7.3.4. </ins> As more clients enable ESNI support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting

Related discussion:
text: Since OCSP is the server name, ESNI should probably enforce OCSP stapling (similar to ) or any other way of encrypted OCSP checks. Ignoring OCSP status checks entirely makes it hard to revoke a certificate, even if it's only valid for a few months.
NAME what behavior do you expect here? Would clients fail hard if server don't send stapled responses? It's good to view ESNI as part of the leaky boat problem. It plugs one hole, but not all of them. Implementations probably should do something about cleartext OCSP if they want all holes plugged.
Thank you for the changes. LGTM.
Code change:
2.1. QUIC packets may have either a long header, or a short header.  The <del> first bit of the QUIC header indicates which type of header is present. </del> <ins> first bit of the QUIC header us the Header Form bit, and indicates which type of header is present. </ins> The long header exposes more information.  It is used during connection establishment, including version negotiation, retry, and

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:
9. Running DNS over HTTPS relies on the security of the underlying HTTP <del> connection.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for secure transport. </del> <ins> transport.  Implementations utilizing HTTP/2 benefit from the TLS profile defined in RFC7540 Section 9.2. </ins> Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with

Related discussion:
text: NAME I'm ok with you merging this and closing 11 if you're ok with it.
I think that it is fine - or more precisely, invaluable - to explain what the semantics of server push are. But you don't actually require HTTP/2 for this protocol to work. The only thing that requiring HTTP/2 gets you is tighter constraints on TLS usage. You can get those same constraints with some deployment recommendations. I would support strong recommendations that said HTTP/2 is useful for its multiplexing as well as similarly strong advice about following the advice in RFC 7525. Those are both good practice.
fairly clear feedback from singapore to change this to an endorsement (SHOULD) with better explanatory text focusing on performance and scale.
What are the drawbacks of HTTP/2? Less readily available libraries? more complex protocol? Potential difficulties in integrating with current fronting stacks that may not be HTTP/2 ready? On one hand, I feel like it may be easier to just enforce 1 stack for now rather than having to support multiple flavor of client/server protocols. A suboptimal HTTP/2 implementation may just be similar to HTTP/1 but at least we can try to move forward toward multiplexing. Making HTTP/2 a should may just leave us in limbo in HTTP/1 land.
NAME the singapore meeting is available here URL .. goto the 12 minute mark to review the discussion (wrt your question about drawbacks).
Text is in URL
Last PR accepted. I suspect there will be a bit more wordsmithing, but this should cover the main issue well.
thanks, I was in the room, but my notes were sparse and some of the cons I remembered of were more inconvenience to me than blockers. What I am not getting from the current spec, and which I believe NAME touched on in URL, is that it is unclear whether or not a minimum HTTP version must be supported. Based on URL , do we consider that by supporting HTTP/1.1 we get HTTP/1.0 for free and consider 0.9 not an option? Wouldn't not mandating a required version prevent client/server from having a known version to use? Can we make this clearer maybe?
The decision was to rely only on HTTP semantics and not versions. So any HTTP implementation that is acceptable to its peer can be used.
Code change:
external_aad = << TH_2, CRED_R, ? EAD_2 >> <del> CRED_R - bstr containing the credential of the Responder, see </del> <ins> CRED_R - CBOR item containing the credential of the Responder, see </ins> EAD_2 = unprotected external authorization data, see

Related discussion:
text: CRED_R - bstr containing the credential This is not true for C509 which is an CBOR array
Code change:
is persistently offline may still be holding old keying material and thus be a threat to both FS and PCS if it is later compromised. <del> MLS partially defend against this problem by active member including freshness, however not much can be done on the inactive side especially in the case where the client has not processed messages. </del> <ins> MLS partially defends against this problem by active members including freshness, however not much can be done on the inactive side especially in the case where the client has not processed messages. </ins> <del> *RECOMMENDATION:* Mandate a key updates from clients that are not </del> <ins> *RECOMMENDATION:* Mandate key updates from clients that are not </ins> otherwise sending messages and evict clients which are idle for too long.

Related discussion:
text: For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.
Code change:
Architecture RFC7556 provides some discussion on authenticating an operator. <del> Given that a user chooses to visit a Captive Portal URI, the URI location SHOULD be securely provided to the user's device.  E.g., the DHCPv6 AUTH option can sign this information. </del> <ins> The user makes an informed choice to visit and trust the Captive Portal URI.  Since the network provides Captive Portal URI to the user equipment, the network SHOULD do so securely so that the user's trust in the network can extend to their trust of the Captive Portal URI.  E.g., the DHCPv6 AUTH option can sign this information. </ins> If a user decides to incorrectly trust an attacking network, they might be convinced to visit an attacking web page and unwittingly

Related discussion:
text: The language of this section was hard for some of the reviewers to understand. Rephrase it to be more explicit and clear.
Yes. We should probably rephrase this. E.g. "The user makes an informed choice in deciding to visit and trust the Captive Portal URI. Since the network provides Captive Portal URI to the user equipment, thenetwork SHOULD do so securely so that the user's trust in the network can extend to their trust of the Captive Portal URI. E.g., the DHCPv6 AUTH option can sign this information."
Code change:
report share as invalid with the error "hpke-unknown-config-id". Otherwise, it decrypts the payload with the following procedure: <del> where "sk" is the HPKE secret key, "task_id" is the task ID, "nonce" and "extensions" are the nonce and extensions of the report share respectively, and "server_role" is 0x02 if the aggregator is the leader and 0x03 otherwise.  If decryption fails, the aggregator marks the report share as invalid with the error "hpke-decrypt-error". Otherwise, it outputs the resulting "input_share". </del> <ins> where "sk" is the HPKE secret key, and "server_role" is the role of the aggregator ("0x02" for the leader and "0x03" for the helper).  If decryption fails, the aggregator marks the report share as invalid with the error "hpke-decrypt-error".  Otherwise, it outputs the resulting "input_share". </ins> 4.3.1.4.

Related discussion:
text: Specifically: Specify use of the "one-shot" HPKE APIs defined in RFC9180, replacing equivalent use of the "multi-shot" APIs. (This change is intended to be a clarification, not a functional change.) Move the task_id parameter from the "info" parameter to the "aad" parameter. This is intended to protect against key-commitment-related attacks[1]. (This is a functional change.) Clarify that the URL field is an encapsulated key, rather than an encryption context. (This is a clarification, not a functional change.) [1] See discussion in URL
Per URL section 8.1: PPM effectively uses the single-shot APIs; we should consider refactoring PPM's usage of HPKE to use only one of applicationinfo & AAD. Following the advice of the HPKE RFC, we would want to use applicationinfo. This would permit slightly simpler implementations. I am not sure how much it would simplify the HPKE computations.
Should we then formally use the single shot HPKE APIs from ?
That would be my recommendation (though, somewhat confusingly given the advice quoted above, those APIs still allow specifying both application info & AAD). Implementations can & do already use the single-shot APIs, so I strongly suspect specifying the single-shot APIs will be feasible. & .]
+1 to using single-shot APIs, though I'm not sure I agree that using either info or add (but not both) is simpler. What's the reasoning?
The reasoning is: a) it follows the advice of the HPKE spec (quoted above) b) AFAICT, in a single-shot setting, application info & AAD serve exactly the same purpose, so using both is arbitrary/confusing/a potential source of mistakes. (in a multi-shot setting, application info is bound to all encryptions/decryptions done by the same context; AAD is bound to a single encryption/decryption)
TBH I'm not sure I agree with the quoted guidance here. There is a concept in protocol design known as "domain separation", the goal of which is to provide some kind of binding of long-term secret key operations to the context in which they were used. Imagine, for example, that someone used an HPKE secret key for PPM and some other protocol. Suppose further that both are using the empty string for .
Code change:
report share as invalid with the error "hpke-unknown-config-id". Otherwise, it decrypts the payload with the following procedure: <del> where "sk" is the HPKE secret key, "task_id" is the task ID, "nonce" and "extensions" are the nonce and extensions of the report share respectively, and "server_role" is 0x02 if the aggregator is the leader and 0x03 otherwise.  If decryption fails, the aggregator marks the report share as invalid with the error "hpke-decrypt-error". Otherwise, it outputs the resulting "input_share". </del> <ins> where "sk" is the HPKE secret key, and "server_role" is the role of the aggregator ("0x02" for the leader and "0x03" for the helper).  If decryption fails, the aggregator marks the report share as invalid with the error "hpke-decrypt-error".  Otherwise, it outputs the resulting "input_share". </ins> 4.3.1.4.

Related discussion:
text: Then the security of our PPM deployment depends on how the other protocol uses the derived AEAD key, since in both protocols may end up deriving the same AEAD key. One way to avoid creating this attack surface is to pick an string that no other application is likely to choose so that derived keys are guaranteed to not collide (except with some negligible probability). That said, I'd go for changing how we use and . Something like this might be simpler: Let be a fixed string that identifies the protocol. It would be good if this string were relatively long, say the SHA-256 hash of "ppm-00". Let encode the task ID, sender/receiver roles, etc.
I definitely agree that application info should include information allowing domain separation, for the reasons you mention. (Indeed, the current PPM spec includes the strings "ppm input share" or "ppm aggregate share" in its application infos, presumably for this purpose.) But I think that's orthogonal to the question of whether we should also use AAD, since the application info could also include information other than the "domain separation parameter". Picking one example to make things concrete, a client upload request sets its application info to and its AAD to . But it could just as easily set the application info to (i.e. the concatenation of the two previous strings) and not use AAD. (Or alternatively, it could place that string in the AAD and not use application info.) My argument is that it's simpler to use only one of the parameters, since in the single-shot setting that PPM is using HPKE, the two parameters serve exactly the same purpose (i.e. including additionally-authenticated data).
As I see it, our goal is to make sure that decryption only succeeds if the sender and receiver agree on the "context", i.e., the task ID, sender/receiver role, nonce, extensions, and so on. This way a MITM cannot force the aggregator to interpret an input share incorrectly. Does this sound reasonable to you? From the point of view of this threat model, I don't think it's immediately clear that sticking the context in or is equivalent.
Code change:
report share as invalid with the error "hpke-unknown-config-id". Otherwise, it decrypts the payload with the following procedure: <del> where "sk" is the HPKE secret key, "task_id" is the task ID, "nonce" and "extensions" are the nonce and extensions of the report share respectively, and "server_role" is 0x02 if the aggregator is the leader and 0x03 otherwise.  If decryption fails, the aggregator marks the report share as invalid with the error "hpke-decrypt-error". Otherwise, it outputs the resulting "input_share". </del> <ins> where "sk" is the HPKE secret key, and "server_role" is the role of the aggregator ("0x02" for the leader and "0x03" for the helper).  If decryption fails, the aggregator marks the report share as invalid with the error "hpke-decrypt-error".  Otherwise, it outputs the resulting "input_share". </ins> 4.3.1.4.

Related discussion:
text: For example, if we stuff the context in , then it influences the derivation of the AEAD key; but depending on the AEAD, it might be feasible for an attacker to find a find two keys that decrypt the same ciphertext. (See URL) More analysis will be needed to say for sure whether this weakness in the AEAD amounts to an attack against our protocol. In the meantime, sticking the "context" in seems like a more conservative choice to me.
Given your concern, your approach SGTM. It sounds like this may be a concern worth raising with the folks working on the HPKE spec, given the advice to "use the Setup info parameter for specifying auxiliary authenticated information", but I'm not going to chase this down currently.
So I think there's two tasks for this issue: Move task ID from to Use single-shot APIs for HPKE Anything else?
Yep, I think that's it.
(reopening for now as the fix PR has been reverted temporarily)
Perfect, great work!
Code change:
address validation by sending a Retry packet (packet-retry) containing a token.  This token MUST be repeated by the client in all Initial packets it sends for that connection after it receives the <del> Retry packet.  In response to processing an Initial containing a token, a server can either abort the connection or permit it to proceed. </del> <ins> Retry packet. In response to processing an Initial containing a token that was provided in a Retry packet, a server cannot send another Retry packet; it can only refuse the connection or permit it to proceed. </ins> As long as it is not possible for an attacker to generate a valid token for its own address (see token-integrity) and the client is

Related discussion:
text: The original text here might be read to imply that a server can't send Retry if it receives an Initial that contains a token that came from NEW_TOKEN. That's wrong.