jiebi/CodeConvo huggingface dataset:
Code change:
connection if servers make reasonable selections when generating new IDs for that connection. <ins> 10.3. A simple deployment of QUIC-LB in a cloud provider might use the same global QUIC-LB configuration across all its load balancers that route to customer servers.  An attacker could then simply become a customer, obtain the configuration, and then extract server IDs of other customers' connections at will. To avoid this, the configuration agent SHOULD issue QUIC-LB configurations to mutually distrustful servers that have different keys (for the block cipher or stream cipher algorithms) or routing masks and divisors (for the obfuscated algorithm).  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits (config-rotation).  Note that either of these techniques exposes information to outside observers, as traffic destined for each server set can be easily distinguished. These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID. 10.4. Section 21.9 of QUIC-TRANSPORT discusses the Stateless Reset Oracle attack.  For a server deployment to be vulnerable, an attacking client must be able to cause two packets with the same Destination CID to arrive at two different servers that share the same cryptographic context for Stateless Reset tokens.  As QUIC-LB requires deterministic routing of DCIDs over the life of a connection, it is a sufficient means of avoiding an Oracle without additional measures. </ins> 11. There are no IANA requirements.

Related discussion:
text: So there is no way for another server to receive a packet with that CID and generate a stateless reset. What am I missing? There might be something here with the differing treatment of long-header vs. short-header packets, (and the option for servers to send resets on long headers), but I'll have to think about it more.
As to the last point, nope: even a long header with a DCID that conforms to the server's expectations (i.e. maps to a real server) will get delivered to that server, so I don't think that's an attack.
NAME Should we talk about this issue more, or are you satisfied enough that I can close it?
I don't see any mention of stateless reset in the draft at all. That's probably something worth addressing, even if it is to say what you have already.
Code change:
4. <del> Applications MUST use external PSKs that adhere to the following requirements: Each PSK MUST be derived from at least 128 of entropy and MUST be at least 128-bits long unless the TLS handshake is being used with a separate key establishment mechanism such as a Diffie-Hellman exchange.  This recommendation protects against passive attacks using exhaustive search of the PSK. </del> <ins> Applications MUST adhere to the following requirements for external PSKs: Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. </ins> Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a

Related discussion:
text: This builds on .
Summary: use a high-entropy PSK with DH, otherwise, with a low-entropy PSK, use a PAKE. Reference appendix with security properties from NAME
Code change:
multiple available packets before determining whether to send an ACK frame in response, as stated in Section 13.2.2 of QUIC-TRANSPORT. <del> 6.1. </del> <ins> 7.1. </ins> As specified in Section 13.2.1 of QUIC-TRANSPORT, endpoints are expected to send an acknowledgement immediately on receiving a

Related discussion:
text: by adding a one byte IMMEDIATE_ACK frame.
editorial nit: my preference would be for frame diagrams to use the notation in QUIC transport. I see that ACK_FREQUENCY is defined using ASCII art, so perhaps you want to consider a separate follow up PR to switch styles after this lands.
Thanks Lucas, I filed to update them.
They currently use ascii art. Will write this up once is merged.
sgtm, thanks!
When sending a PTO packet, a sender wants to induce an immediate ACK. The only trick I know to induce such an ACK is intentionally skip the packet number. However, the problem of that approach is that it relies on the receiver not ignoring reorders. When an ACKFREQUENCY frame previously sent had set the bit, then it become impossible for a sender to induce an immediate ACK when sending a PTO packet. At the moment, the only solution is to bundle an ACK_FREQUENCY packet in each PTO packet, but that seems like a bit of unnecessary overhead to me. Should we have a dedicated frame for inducing immediate ACKs instead?
That's an option. Another option is to revisit the max_reordering idea discussed in . If the max reordering was 5, then you could skip 5 PNs. I do feel like it'd be nice to allow specifying an int for max reordering, since that matches up with adaptive packet threshold loss detection, but as I expressed in , I think getting the details right are deceptively difficult, so I'm torn.
This does seem like a real problem. I like the idea of a single "ELICIT_ACK" type frame. With one byte a sender could effectively mark its PTOs ensuring they get an ACK without relying on the trick. An explicit frame is also easier to implement for the sender than the packet number skipping.
There's quite a bit of discussion on this on the tcpm mailing list at the moment, ie: URL I'm increasingly thinking it's worth using an unused protected bit in the header for this. It'd end up competing with the 2-bit packet loss measurements, but given those are experimental and may never be widely deployed, I think it might be worth it. For example, I believe this could allow an implementation to not include maxackdelay in PTO if it set the "ACK-pull"(or whatever it's called) bit on the final packet.
Code change:
multiple available packets before determining whether to send an ACK frame in response, as stated in Section 13.2.2 of QUIC-TRANSPORT. <del> 6.1. </del> <ins> 7.1. </ins> As specified in Section 13.2.1 of QUIC-TRANSPORT, endpoints are expected to send an acknowledgement immediately on receiving a

Related discussion:
text: That already seems possible if more than the threshold number of ack-eliciting packets are outstanding.
I've thought more about this, and I think most of the time a 1-byte frame would be acceptable, but it definitely adds some implementation complexity, so I'd be curious which design others prefer? If we can decide, then I'll be happy to write a PR(or NAME can). Besides PTO, a use case would be making the last packet before becoming app-limited elicit an immediate ACK. This could allow skipping maxackdelay for all PTOs(see ), though always doing it could be a bit much in some cases. For example, browsers commonly send a series of requests, but to the transport it seems app-limited between them, because it doesn't know the browser has another request to send. It might be useful for 'chirping' as well, but I've never tried that, so it's mostly speculation.
We don't currently have any intention of deploying them either, and I think that's unlikely to change. I haven't seen a lot of good evidence that they are terribly helpful, and content providers don't seem to have a good incentive for implementing it. For us at least, the difference in complexity for a frame versus a bit in the header is negligible. A frame is actually be slightly easier to implement and losing a byte here and there isn't so bad.
I strongly prefer using the header bit. Although it will be a bit more work to implement, the fact that I won't end up with a 1-byte STREAM frame that I have to split off at the end of the packet will be worth the effort.
Is testimony of network operators not taken as evidence? I remember a line of people, from different companies -- BT, ATT, and so on, at IETF 101 practically begging for some information in QUIC packets to be exposed for monitoring and troubleshooting.
I do not see anyone propose a 1-byte STREAM frame. I believe what is meant is a new frame type. If anything, using a new frame type to elicit an ACK is easier than using a header bit, as it involves fewer parts of the code to change.
Nobody is proposing a 1-byte STREAM frame (you can't just make up stream data anyway). The problem is that a new frame would consume bytes (or probably one byte) in the packet payload.
Code change:
multiple available packets before determining whether to send an ACK frame in response, as stated in Section 13.2.2 of QUIC-TRANSPORT. <del> 6.1. </del> <ins> 7.1. </ins> As specified in Section 13.2.1 of QUIC-TRANSPORT, endpoints are expected to send an acknowledgement immediately on receiving a

Related discussion:
text: Given that you set this signal on a PTO, and PTOs are often retransmissions of packets, this would require you to repackage (and, most likely, cut off a single byte from a STREAM frame). Using a header bit would solve that problem.
NAME and I discussed this and there are number of ways to fix this, but given this issue of not being able to elicit an immediate ACK by skipping packet numbers is introduced by the draft, we feel it's important it be fixed in some way. One more option is new STREAM frame codepoints that elicit an immediate ACK.
I'm ready to write a PR, but I'd appreciate thoughts on whether the existing PING frame should be repurposed or we should add a new frame(ACK, PONG, etc). I lean towards a new frame, since there are enough code-points and I believe there are use cases for the existing PING frame that does not elicit an immediate ACK.
+1. While I would not be opposed to repurposing the existing PING frame, I do not see the necessity of doing that. Let's simply consume one code point of the remaining 33.
Thanks, now for bikeshedding time. Some possible names: ACKME ACKPULL (from TCP) FAST_ACK PONG
Putting on my bikeshedding hat: I don't think we should prefix the frame name with ACK since that almost makes it looks like yet another variant of the ACK frame. The "pull" TCP terminology is fine (e.g. PULLACK) but we could also be more explicit with something like SOLICIT_ACK.
SCTP has something similar and calls it SACK-IMMEDIATELY (RFC 7053).
Thanks, I'd be happy with ACKIMMEDIATELY or IMMEDIATEACK
For those two options I'd prefer IMMEDIATE_ACK for the same reasoning as above -- so it appears less like an ACK variant.
IMMEDIATEACK sounds good to me. Alternatively, I'd be also fine with something like ACKNOW.
IMMEDIATE_ACK it is, PR coming.
Code change:
Name: The name of the credential type <del> Recommended: Whether support for this extension is recommended by </del> <ins> Recommended: Whether support for this credential is recommended by </ins> the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. <del> Reference: The document where this extension is defined </del> <ins> Reference: The document where this credential is defined </ins> Initial contents:

Related discussion:
text: I noticed a bunch of typos in the "IANA Considerations" section: the "ciphersuites" and "credentials" were probably copy-pasted from the "extension" one, and some parts were not changed correctly. This PR fixes these typos.
Discussed 20210526 Interim: editorial will be taken up by editors.
Thanks!
Code change:
The following terms are used: <del> This document uses the presentation language of RFC8446. </del> <ins> This document uses the presentation language of RFC8446 to define messages in the PPM protocol.  Encoding and decoding of these messages as byte strings also follows RFC8446. </ins> 2.

Related discussion:
text: The only language I can find in the document that prescribes serialization is in Section 1.2 (please point out if I missed anything): We intend this statement to be prescriptive, i.e., encoding/decoding of messages is as defined in RFC8446. Another valid interpretation might be "we define the fields of each message following the conventions of RFC8446, but leaving encoding/decoding unspecified". I think it would help to refine this statement a bit. WDYTA:
SGTM FWIW (this was our interpretation, and I think it makes sense to clarify)
Yeah, this seems like a fine clarification. I don't think it was under specified before, but more information for those unfamiliar with TLS-style encoding doesn't hurt.
Code change:
length of the digest output.  This codepoint is also defined for use with TLS 1.2. <del> Indicates a signature algorithm using EdDSA as defined in I- D.irtf-cfrg-eddsa or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. </del> <ins> Indicates a signature algorithm using EdDSA as defined in RFC8032 or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. </ins> rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list

Related discussion:
text: draft_eddsa is now . sandj-tls-iana-registry-updates is now ietf-tls-iana-registry-updates.
Code change:
5.8.2. <del> Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems, for example if many instances of a DTLS time out early and retransmit too quickly on a congested link.  Implementations SHOULD use an initial timer value of 100 msec (the minimum defined in RFC 6298 RFC6298) and double the value at each retransmission, up to no less than 60 seconds (the RFC 6298 maximum).  Application specific profiles, such as those used for the Internet of Things environment, may recommend longer timer values.  Note that a 100 msec timer is recommended rather than the 3-second RFC 6298 default in order to improve latency for time- sensitive applications.  Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal. </del> <ins> The configuration of timer settings varies with implementations and certain deployment environments require timer value adjustments. Mishandling of the timer can lead to serious congestion problems, for example if many instances of a DTLS time out early and retransmit too quickly on a congested link.  Implementations SHOULD use an initial timer value of 100 msec (the minimum defined in RFC 6298 RFC6298) and double the value at each retransmission, up to no less than 60 seconds (the RFC 6298 maximum).  Application specific profiles, such as those used for the Internet of Things environment, may recommend longer timer values.  Note that a 100 msec timer is recommended rather than the 3-second RFC 6298 default in order to improve latency for time-sensitive applications.  Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal. </ins> Implementations SHOULD retain the current timer value until a message is transmitted and acknowledged without having to be retransmitted,

Related discussion:
text: [BA] Do you mean "maximum retransmission timemout value"?
Addressed in
Code change:
SHOULD begin processing partial HTTP messages once enough of the message has been received to make progress.  If a client-initiated stream terminates without enough of the HTTP message to provide a <del> complete response, the server SHOULD abort its response with the error code H3_REQUEST_INCOMPLETE; see errors. </del> <ins> complete response, the server SHOULD abort its response stream with the error code H3_REQUEST_INCOMPLETE; see errors. </ins> A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the

Related discussion:
text: to the extent I'm willing to do so.
Sec 4.1 and 4.1.2 do not explicitly define , , as stream errors. A.4.1 says that is a stream error. It would be nice if they are explicitly defined as stream errors in Sec 4.1 and 4.1.2. Also, it would be nice if each error code is categorized to either a connection error or a stream error in Table 4.
Commenting as an individual. The error code space is shared between connection and streams. The action associated with a stream error or connection error cause QUIC transport frames to be emitted, which can use a code. H3 inherits H2's design philosophy that endpoints can generate a connection error at will. So while there are specific cases that describe "treat X as stream error foo", endpoints are also allowed to "treat X as connection error foo". Constraining the error codes to different uses has a certain appeal. But then what do we say the the receiver of an error code of the wrong type should do? Generate its own error? I think this has come up a couple of times during H3 drafts but I'm satisfied that the flexibility we have today is about the best we can do.
I also think "stream error" and "abort a stream" are unique and consistent terms used through the document. But I'll let Mike spec to that point with his editor hat.
Even though categorization is not reasonable, Sec 4.1, for instance, should say like "the server SHOULD abort its response and treat as a stream error of type H3REQUESTINCOMPLETE".
"Abort" is a defined term in section 2.2. I personally don't see much clarity in the proposal, it threatens to add inconsistency to other places where streams are aborted due to application decisions rather than a protocol error.
My example proposal is to replace "the server SHOULD abort its response with the error code H3REQUESTINCOMPLETE" with "the server SHOULD abort its response and treat as a stream error of type H3REQUESTINCOMPLETE" in Sec 4.1. I don't understand why this would introduce inconsistency.
Code change:
SHOULD begin processing partial HTTP messages once enough of the message has been received to make progress.  If a client-initiated stream terminates without enough of the HTTP message to provide a <del> complete response, the server SHOULD abort its response with the error code H3_REQUEST_INCOMPLETE; see errors. </del> <ins> complete response, the server SHOULD abort its response stream with the error code H3_REQUEST_INCOMPLETE; see errors. </ins> A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the

Related discussion:
text: NAME For that particular instance, I think it is not unreasonable to change the text from "SHOULD abort its response with the error code ..." to "SHOULD abort its response stream with the error code ...", as the latter is the pattern that we use. Though I am not sure if such change is necessary; I tend to agree with NAME that the sentence is already clear; "abort" is a defined word and use of "response" implies a stream.
WRT inconsistency, the editor would need to sweep for all instances of abort and reason about whether they need additional text or not. And there's a risk that someone later on picks up on an inconsistency of usage because they didn't appreciate the nuance. Since adding more detail after an instance of seems duplicative, I would favour not adding any more.
I'm okay with NAME addition of "stream" since abort is defined as a stream operation. I don't think we need to separate out "abort" and "stream error" as separate statements, because abort already describes what needs to be done.
If I was worried too much, no change is necessary. One alternative approach is to add a sentence like "errors in this section are stream errors" in the beginning of Sec 4.
Code change:
4.4.1.3. Each report share has a corresponding task ID, report metadata <del> (timestamp, nonce, and extensions), and encrypted input share.  Let "task_id", "metadata", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, the aggregator looks up the HPKE config and corresponding secret key indicated by </del> <ins> (timestamp, nonce, and extensions), the public share sent to each Aggregator, and the recipient's encrypted input share.  Let "task_id", "metadata", "public_share", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, the aggregator looks up the HPKE config and corresponding secret key indicated by </ins> "encrypted_input_share.config_id".  If not found, then it marks the report share as invalid with the error "hpke-unknown-config-id". Otherwise, it decrypts the payload with the following procedure:

Related discussion:
text: Align with the latest VDAF draft. This requires two minor protocol changes: 02 added a value called the "publicshare" to the VDAF syntax. This is to support Poplar1 (and likely other schemes that need a similar extractability property). To accommodate this, the publicshare field has been added to the Report and ReportShare structures and appended to the AAD for input share encryption. (This may end up being useful for privacy.) 02 added the report count to the aggregate result computation. This is already passed to the Collector in the CollectResp, so we just need to update the aggregate result computation in the draft to match.
Rebased and pushed a minor update: The public share in Report and ReportStore now both have the same length prefix.
Rebased.
This will be VDAF-02 or 03, depending on when we need to cut DAP-02.
VDAF-03 is out, I will send a PR by end of week. URL
Code change:
Given a Challenge/Response pair, the ACME server verifies the client's control of the domain by verifying that the TLS server was <del> configured appropriately. Choose a subset of the N iterations to check, according to local policy. </del> <ins> configured appropriately, using these steps: </ins> <del> For each iteration, compute the Zi-value from the key authorization in the same way as the client. </del> <ins> Compute the Z-value from the key authorization in the same way as the client. </ins> Open a TLS connection to the domain name being validated on the requested port, presenting the value <del> "<Zi[0:32]>.<Zi[32:64]>.acme.invalid" in the SNI field (where the </del> <ins> "<Z[0:32]>.<Z[32:64]>.acme.invalid" in the SNI field (where the </ins> comparison is case-insensitive). Verify that the certificate contains a subjectAltName extension

Related discussion:
text: Simplify the TLS SNI challenge by removing the iterations concept, which I believe is not necessary in practice and complicates the protocol needlessly.
Implementing TLS SNI is currently really complicated, yes.
FYI, URL implements protocol according to the contents of this PR - i.e. without iterations.
(so does current Boulder)
I think this will be OK to land once lands. We should consider whether we want to bump the version number in the challenge. Principle would dictate that we should, since this breaks compatibility with what was published in -01. But since I'm not aware of any implementation of "tls-sni-01" as specified in -01 (vs. the off-spec implementation in boulder), I'm inclined to just leave it.
FWIW on the client side of things, xenolf/lego did not implement the iterations for the tls-sni-01 challenge.
URL implements iterations but takes the absence of an "n" parameter to be equivalent to an "n" parameter of 1, which is compatible.
Great, I'm taking this as sufficient evidence that a version bump is not needed :)