jiebi/CodeConvo huggingface dataset:
Change:
Note: For a given Diffie-Hellman group, the padding results in all public keys having the same length. <del> Peers SHOULD validate each other's public key Y by ensuring that 1 < Y < p-1.  This check ensures that the remote peer is properly behaved </del> <ins> Peers MUST validate each other's public key Y by ensuring that 1 < Y < p-1.  This check ensures that the remote peer is properly behaved </ins> and isn't forcing the local system into a small subgroup. 4.2.5.2.

Discussion:
I wonder why this was only a before. Am I right to assume that this is because TLS 1.3 has removed support for static DH and leaking an ephemeral key is not considered to be a security problem?
Gotta say, I don't know why this was SHOULD. That check is very easy to implement.
says .
This text was adapted from some old draft of 7919 which had should and never got updated (see for instance: URL). Good catch.
NAME Please provide a PR adding yourself to contributors.
Change:
aggregation parameter.  If this check fails, the input share MUST be marked as invalid with the error "report-replayed".  This is the case if the report was used in a previous aggregate request <del> and is therefore a replay.  An aggregator may also choose to mark an input share as invalid with the error "report-dropped" under the conditions prescribed in anti-replay. </del> <ins> and is therefore a replay. </ins> Depending on the query type for the task, additional checks may be applicable:

Discussion:
Clarify that is used when it's impossible to determine if an input share is valid. One situation we need this for is when an Aggregator drops some anti-replay state in order to reduce storage costs. This should result in data loss in the worst case, not a loss of privacy.
Since , aggregators are required to store report nonces for batch intervals that have not yet been collected. This is necessary in order to prevent replay attacks. The problem is that nothing guarantees that a batch interval will be collected in a timely manner: In theory, it's possible that aggregators will have to store nonce sets indefinitely. To prevent this, there needs to be a way for the aggregators to agree on when to stop accepting reports for a given batch interval. The strawman solution is to allow each aggregator to, at its own discretion, ignore a report if it can't confirm if the report was replayed or not. The problem is that this potentially leads to unnecessary data loss.
I propose resolving this with .
Change:
Pre-Shared Key ("pre_shared_key"; pre-shared-key-extension) <del> Server Name Indication ("server_name"; Section 3 of RFC6066) </del> Cookie ("cookie"; cookie) <ins> Server Name Indication ("server_name"; Section 3 of RFC6066) </ins> All implementations MUST send and use these extensions when offering <del> applicable cipher suites: </del> <ins> applicable features: </ins> "supported_versions" is REQUIRED for all ClientHello messages. <del> "signature_algorithms" is REQUIRED for certificate authenticated cipher suites. </del> <ins> "signature_algorithms" is REQUIRED for certificate authentication. </ins> "supported_groups" and "key_share" are REQUIRED for DHE or ECDHE <del> cipher suites. </del> <ins> key exchange. </ins> <del> "pre_shared_key" is REQUIRED for PSK cipher suites. </del> <ins> "pre_shared_key" is REQUIRED for PSK key agreement. </ins> <del> "cookie" is REQUIRED for all cipher suites. </del> <ins> A client is considered to be attempting to negotiate using this specification if the ClientHello contains a "supported_versions" extension, at minimum.  Such ClientHello messages MUST meet following requirements: </ins> <del> When negotiating use of applicable cipher suites, endpoints MUST abort the handshake with a "missing_extension" alert if the required extension was not provided.  Any endpoint that receives an invalid combination of cipher suites and extensions MAY abort the connection with a "missing_extension" alert, regardless of negotiated parameters. </del> <ins> If not containing a "pre_shared_key" extension, it MUST contain both a "signature_algorithms" extension and a "supported_groups" extension. If containing a "supported_groups" extension, it MUST also contain a "key_share" extension, and vice versa. (an empty KeyShare.client_shares vector is permitted) Servers receiving a ClientHello which is attempting to negotiate using this specification, yet failing any of the above requirements, MUST abort the handshake with a "missing_extension" alert. </ins> Additionally, all implementations MUST support use of the "server_name" extension with applications capable of using it.

Discussion:
The MTI Extensions section is currently out-of-date. It wasn't updated with the new negotiation and still refers to the old cipher suites system. This PR cleans that up. I also drop the cookie extension universal send requirement, as that was in there as an alternative to allowing a server to send a cookie without first being prompted. We have that in as an explicit exception, currently.
I already did some of this in PR, so I'm going to hold this PR until that has landed and then we can take stock
Sure, I hadn't read that PR yet. A notable difference in the language here is that I'm replacing the "MAY abort the connection" line with specific requirements, as that high level of generalization is counterproductive now that cipher suites and feature extensions are decoupled.
Change:
MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <ins> All CLOSE_DATAGRAM_CONTEXT capsules MUST contain a CLOSE_CODE context extension, see close-code.  If an endpoint receives a CLOSE_DATAGRAM_CONTEXT capsule without a CLOSE_CODE context extension, the endpoint MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. </ins> 4.4. The DATAGRAM capsule (type=0x02) allows an endpoint to send a

Discussion:
This PR adds a new concept of context close codes which will allow applications that use contexts to indicate the reason for closing a context. This PR also makes the extensibility mechanism binary as that is easier to implement.
In , we introduce the CLOSEDATAGRAMCONTEXT capsule which allows endpoints to close a context. That message currently only contains the context ID to close. NAME suggests that we may want to add more information there. Should we differentiate between "context close" and "context registration rejected"? Should we add an error code? In particular, do folks have use cases for these features?
My first concern is with infinite loops. If the context was "garbage collected" by the recipient, the sender can simply re-create it if they still want it. However, if it was closed due to incompatibility (i.e. rejected) or hitting a resource limit (e.g. max # of contexts), reopening it in response will produce a tight infinite loop. This could be maybe be avoided by some kind of heuristic, but an explicit indication of what's going on seems better.
LGTM thanks
Change:
value to seed the RTT estimator for a subsequent connection attempt to the server. <del> 6.2.2. When packet protection keys are discarded (see Section 4.9 of QUIC- TLS), all packets that were sent with those keys can no longer be acknowledged because their acknowledgements cannot be processed anymore.  The sender MUST discard all recovery state associated with those packets and MUST remove them from the count of bytes in flight. Endpoints stop sending and receiving Initial packets once they start exchanging Handshake packets (see Section 17.2.2.1 of QUIC- TRANSPORT).  At this point, recovery state for all in-flight Initial packets is discarded. When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is discarded. If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive before Initial packets, early 0-RTT packets will be declared lost, but that is expected to be infrequent. It is expected that keys are discarded after packets encrypted with them would be acknowledged or declared lost.  Initial secrets however might be destroyed sooner, as soon as handshake keys are available (see Section 4.10 of QUIC-TLS). </del> 6.3. A Probe Timeout (PTO) triggers a probe packet when ack-eliciting data

Discussion:
Move the "Discarding Keys and Packet State" section up a level and out from underneath the Crypto Handshake Timer. This section in no way references the crypto handshake timer, so there's no reason to put it there. It's possible this should be up-leveled out of loss recovery as well? The preceding "Retry and Version Negotiation" has a similar problem, so I'd like suggestions on where to move that too.
Change:
traffic of censorship circumvention tools appear indistinguishable from other kinds of traffic Tor-2020. <ins> Censors have also used protocol identification in the past in an 'allowlist' filtering capacity, such as by only allowing specific, pre-vetted protocols to be used and blocking any unrecognized protocols Bock-2020.  These protocol filtering approaches can also lead to over-blocking if the allowed lists of protocols is too small or incomplete, but can be cheap to implement, as many standard 'allowed' protocols are simple to identify (such as HTTP). </ins> Empirical Examples: Protocol identification can be easy to detect if it is conducted in real time and only a particular protocol is blocked, but some types of protocol identification, like active

Discussion:
Hi team - Here's a pull request with some additional text and information to add to the RFC. Please let me know if there are things I should change or add or remove or fix - totally open to feedback! My changes are the following: Added text towards additional forms of TLS censorship (and citations for them): ESNI censorship, server certificate censorship, omitted SNI censorship Added text about residual censorship Added text about censorship in depth Added text about additional keyword blocking dynamics, there's been some recent research on this Added text about protocol filtering (such as Iran's protocol filter) Added some additional citations for various forms of censorship I'd be happy to break this up into multiple PRs if that's easier as well.
Kevin, if you can rebase your commits on top of the latest version, I'm happy to merge this PR. Thank you for your work on it!
Hi NAME - Just wanted to give this a bump as I close this tab. Let me know if there's any other work that should be added!
Change:
where "pk" is the aggregator's public key, "task_id" is "Report.task_id" and "server_role" is a byte whose value is "0x01" if the aggregator is the leader and "0x00" if the aggregator is the <del> helper. "enc" is the encapsulated HPKE context and "context" is the HPKE context used by the client for encryption.  The payload is encrypted as </del> <ins> helper. "enc" is the HPKE encapsulated key and "context" is the HPKE context used by the client for encryption.  The payload is encrypted as </ins> where "input_share" is the aggregator's input share and "nonce" and "extensions" are the corresponding fields of "Report".

Discussion:
Here are a few small editorial changes: Refer to TLS's "presentation language", per section 3 of the RFC. The output from the HPKE setup function is an encapsulated key, not an encapsulated context. The term context is defined as "A context is an implementation-specific structure...", whereas is alternately described as "an encapsulated KEM shared secret", an "encapsulated key", or a "KEM encapsulated key". Remove stray whitespace from a hyphenated word.
One non-blocking comment.
Change:
is finished for the report share. The helper's response to the leader is an HTTP 200 OK whose body is <del> the AggregateInitializeResp and media type is "message/ppm-aggregate- </del> <ins> the AggregateInitializeResp and media type is "message/dap-aggregate- </ins> initialize-resp". Upon receipt of a helper's AggregateInitializeResp message, the

Discussion:
This change is basically a search-and-replace for /ppm/dap/. However, I have also re-aligned the context strings to match the next draft that will be cut (-01). I think the change is mostly correct, my main concern is the "URN Sub-namespace for PPM (urn:ietf:params:dap)" section. : Does it make sense for all drafts in the PPM WG to share the namespace, or do we want to define one specifically for DAP?
Before merging I would appreciate an answer on the question I raised above. I want to make sure the URN bits are correct.
Separate namespaces seems better, especially if we're thinking of DAP and STAR. Names are cheap, after all.
Separate namespaces, because otherwise I think we'd have to write a further document enumerating the error type URNs that both this document and other PPM drafts like STAR could reference. We should avoid spreading the specification across multiple documents more than necessary. Maybe including the WG in the URN path like helps?
Here's the RFC defining URL It's pretty loosely structured, and the existing sub-namespaces from published RFCs appear to just be named after protocols and formats, not working groups. URL
I took NAME suggestion of prefixing the dap space with ppm.
Change:
The following settings are defined in HTTP/3: <del> The default value is unlimited.  See header-formatting for usage. </del> <ins> The default value is unlimited.  See header-size-constraints for usage. </ins> Setting identifiers of the format "0x1f * N + 0x21" for non-negative integer values of N are reserved to exercise the requirement that

Discussion:
These are some minor editorial things that should be considered to be addressed: Section 4.1: "A server MAY send one or more PUSHPROMISE frames (Section 7.2.5) before, after, or interleaved with the frames of a response message. These PUSHPROMISE frames are not part of the response; see Section 4.4 for more details. These frames are not permitted in pushed responses; a pushed response that includes PUSHPROMISE frames MUST be treated as a connection error of type H3FRAMEUNEXPECTED." Especially the third sentence was hard to parse. Took me a while to realize that it tries to express that PUSHPROMISE frames are not allowed in pushed responses. I think it is primarily a language thing. However, isn't this dependent on stream type. So PUSHPROMISE are allowed on the client-initiated bi-directional stream but not on the server-initiated unidirectional stream. Section 4.1.1: "For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at URL" To avoid more confusion like the one I had in IETF last call. Can you add an Editors note (to be removed before RFC publication) that this registry does not yet exist, and is dependent on approval of [SEMANTICS]? Section 7.2.4.1: "SETTINGSMAXFIELDSECTION_SIZE (0x6): The default value is unlimited. See Section 4.1.1 for usage." As the actual discussion of usage of this setting is in Section 4.1.1.3 wouldn't that be better to reference?
I'll take a look at cleaning it up, but I'm hesitant to simply say "can't be used on unidirectional streams" because an extension might create a unidirectional stream that does allow PUSH_PROMISE frames for whatever reason. Maybe specifically stating that they can't be sent on Push Streams would work? Good suggestion. Good suggestion; probably we moved this text to subsections after the reference was written.
My personal view has been that PUSHPROMISE is part of a request message. And so it has to abide by the rules there. Any attempt to change that requires a semantic extension to H3. Which is what URL precisely does in order to allow PUSHPROMISE on a new stream type.
Change:
not going to be included in a cryptographic computation.  This bucket is encoded in the message as a binary object.  This value is obtained by CBOR encoding the protected map and wrapping it in <del> a bstr object.  Senders SHOULD encode an empty protected map as a zero length binary object (i.e., the byte string h'a0').  This encoding is used because it is both shorter and the version used in the serialization structures for cryptographic computation. Recipients MUST accept both a zero length binary value and a zero length map encoded in the binary value.  The wrapping allows for the encoding of the protected map to be transported with a greater chance that it will not be altered in transit.  (Badly behaved intermediates could decode and re-encode, but this will result in a failure to verify unless the re-encoded byte string is identical to the decoded byte string.)  This avoids the problem of all parties needing to be able to do a common canonical encoding. </del> <ins> a bstr object.  Senders SHOULD encode an zero length map as a zero length string rather than as a zero length map (encoded as h'a0'). The zero length binary encoding is preferred because it is both shorter and the version used in the serialization structures for cryptographic computation.  After encoding the map the value is wrapped in the binary object.  Recipients MUST accept both a zero length binary value and a zero length map encoded in the binary value.  The wrapping allows for the encoding of the protected map to be transported with a greater chance that it will not be altered in transit.  (Badly behaved intermediates could decode and re-encode, but this will result in a failure to verify unless the re-encoded byte string is identical to the decoded byte string.) This avoids the problem of all parties needing to be able to do a common canonical encoding. </ins> Contains parameters about the current layer that are not cryptographically protected.

Discussion:
Some more edits in response to the review. Does not include one item that was proposed for clarification
Change:
there are m= sections, the unmatched RtpTransceivers will need to be associated in a subsequent offer. <del> For each offered m= section, if the associated RtpTransceiver has been stopped, the corresponding m= section in the answer MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6., and further processing for this m= section can be skipped. For each offered m= section, if no supported codec is present in the offer, the corresponding m= section in the answer MUST be marked as </del> <ins> For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as </ins> rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6., and further processing for this m= section can <del> be skipped. </del> <ins> be skipped: The associated RtpTransceiver has been stopped. No supported codec is present in the offer. The bundle policy is "max-bundle" and the m= section is not in a bundle group. The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute. </ins> Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the

Discussion:
Also restructured the "rejecting media descriptions" sections since there are now four things that can cause it to be rejected.
I think this does a good job clarifying these edge cases and is the behavior we want.
lgtm
LGTM
I just realized this may not be complete. Even if max-bundle is used, shouldn't one media description be accepted? This would ensure the same result regardless of whether the max-bundle endpoint is the offerer or answerer. It would also prevent a remote offer from being rejected if it didn't include a "BUNDLE" group simply because there was only one media description.
Deficiencies should be addressed by this PR (apologies for missing them on the first pass): URL
Change:
leaf nodes in the new ratchet tree, add a blank leaf to the right side of the new ratchet tree and assign it to the sender. <del> Generate path secrets for the parent nodes along the sender's filtered direct path, as described in synchronizing-views-of- the-tree.  Define "commit_secret" as the value "path_secret[n+1]" derived from the last path secret value ("path_secret[n]") derived for the UpdatePath. Update the new ratchet tree by setting the parent nodes on the sender's filtered direct path based on the path secrets. Compute parent hashes for these nodes.  Set the sender's leaf node in the new tree to a new leaf node including the resulting parent hash for its nearest ancestor. The new leaf node MUST have "leaf_node_source" set to "commit". Since the new leaf node effectively updates an existing leaf node in the group, it MUST adhere to the same restrictions as LeafNodes used in "Update" proposals (aside from "leaf_node_source"). The application MAY specify other changes to the leaf node, e.g., providing a new signature key, updated capabilities, or different extensions. </del> <ins> Update the sender's direct path in the ratchet tree as described in synchronizing-views-of-the-tree.  Define "commit_secret" as the value "path_secret[n+1]" derived from the last path secret value ("path_secret[n]") derived for the UpdatePath. </ins> Construct a provisional GroupContext object containing the following values:

Discussion:
Conflicts with (in derivation of ) This is intended just to move around the required steps and give them clearer labels. Please keep an eye out for things that might have accidentally been added or dropped.
Interim 2022-06-02: NAME to review, then clear to merge
Currently, we only have explicit algorithm steps for validating an UpdatePath. We should have a similar level of concreteness for the process of creating an UpdatePath.
Change:
Action resulted in a particular Send Event.  The manner in which this correlation is indicated is implementation-specific. <del> 8.2.3.1. </del> <ins> 8.2.2.1. </ins> The Sent Event occurs when a previous Send Action has completed, i.e., when the data derived from the Message has been passed down or

Discussion:
says: But it appears the Connection object is still required to call Send, so what value does this provide? I.e., how are you supposed to use replyMessageContext from the example?
I agree - it seems to me now that this really adds no value. What am I missing? I'm assigning NAME because he was among the first to propose this... maybe he can explain
Ping :)
Interim: We will remove all "reply/replies" from the API doc.
Change:
href or anchor was submitted as a (full) URI are returned with these attributes unmodified. <del> Above rules allow the client to interpret the response as links </del> <ins> The above rules allow the client to interpret the response as links </ins> without any further knowledge of the storage conventions of the RD. The RD MAY replace the registration base URIs with a configured intermediate proxy, e.g. in the case of an HTTP lookup interface for

Discussion:
Thanks, merged. (If questions come up around the normative-language RECOMMENDED: I agere that from the capitals NOT before it, this was already intended to be normative.)