jiebi/CodeConvo huggingface dataset:
Code change:
with B and probably retry the request, leading to duplication on the server system as a whole. <del> The first class of attack can be prevented by the mechanism described in this section.  Servers need not permit 0-RTT at all, but those which do SHOULD implement either the single-use tickets or ClientHello recording techniques described in the following two sections. </del> <ins> The first class of attack can be prevented by sharing state to guarantee that the 0-RTT data is accepted at most once.  Servers SHOULD provide that level of replay safety, by implementing one of the methods described in this section or by equivalent means.  It is understood, however, that due to operational concerns not all deployments will maintain state at that level.  Therefore, in normal operation, clients will not know which, if any, of these mechanisms servers actually implement and hence MUST only send early data which they deem safe to be replayed. In addition to the direct effects of replays, there is a class of attacks where even operations normally considered idempotent could be exploited by a large number of replays (timing attacks, resource limit exhaustion and others described in replay-0rtt).  Those can be mitigated by ensuring that every 0-RTT payload can be replayed only a limited number of times.  The server MUST ensure that any instance of it (be it a machine, a thread or any other entity within the relevant serving infrastructure) would accept 0-RTT for the same 0-RTT handshake at most once; this limits the number of replays to the number of server instances in the deployment.  Such a guarantee can be accomplished by locally recording data from recently-received ClientHellos and rejecting repeats, or by any other method that provides the same or a stronger guarantee.  The "at most once per server instance" guarantee is a minimum requirement; servers SHOULD limit 0-RTT replays further when feasible. </ins> The second class of attack cannot be prevented at the TLS layer and MUST be dealt with by any application.  Note that any application whose clients implement any kind of retry behavior already needs to implement some sort of anti-replay defense. <del> In normal operation, clients will not know which, if any, of these mechanisms servers actually implement and therefore MUST only send early data which they are willing to have subject to the attacks described in replay-0rtt. </del> 8.1. The simplest form of anti-replay defense is for the server to only

Related discussion:
text: This change rephrases the requirements and recommendations from prescribing specific mechanisms of 0-RTT replay protection to prescribing the guarantees expected from implementations, thus letting the implementations to choose the way they can provide those guarantees. This change also introduces a MUST-level requirement for protection equivalent to having at least local strike register.
I've addressed all editorial nits suggested (except for the comma one, which I leave to editor's discretion).
There are some nits noted inline (by me and others), but those are subject to editorial discretion, so I will mark my overall approval.
Code change:
both packet and header protection as a connection error of type PROTOCOL_VIOLATION.  Discarding such a packet after only removing header protection can expose the endpoint to attacks; see <del> Section 9.3 of QUIC-TLS. </del> <ins> Section 9.5 of QUIC-TLS. </ins> In packet types that contain a Packet Number field, the least significant two bits (those with a mask of 0x03) of byte 0 contain

Related discussion:
text: There are three places which refer to "Section 9.3 of QUIC-TLS". I think they should refer to "Section 9.5 of QUIC-TLS".
Thanks!
Code change:
5. This section defines the terms used for the systems that act as DNS <del> clients, DNS servers, or both. </del> <ins> clients, DNS servers, or both.  In the RFCs, DNS servers are sometimes called "name servers", "nameservers", or just "servers". There is no formal definition of DNS server, but the RFCs generally assume that it is an Internet server that listens for queries and sends responses using the DNS protocol defined in RFC1035 and its successors. </ins> For terminology specific to the public DNS root server system, see RSSAC026.  That document defines terms such as "root server", "root

Related discussion:
text: …empt to define "resolve" and "resolution".
This issue concerns consistency and definition of some terms in the document. "Name server", "name server" and, perhaps, "server" seem to be used interchangeably. None of those terms have a formal definition in the document. The terms are also used in conjunction with various modifiers like "authoritative server", "DNS server", etc. While all those terms are likely pretty well-known, for the purposes of this document, un my opinion, it would be helpful to give a generic definition of "server", and how it is then combined with modifiers to form terminology for specific types of servers. Based on the definition of "server", it would be helpful to include a definition for "name server", "name server" or "DNS server" (pick one) and then use that term uniformly throughout the document.
Added a note about this in URL
Fixed in
These are common terms that are used in contexts that are not always associated with the resolver itself, so they should have stand-alone definitions.
First attempt at definition in URL
Code change:
The setConfiguration method allows the global configuration of the PeerConnection, which was initially set by constructor parameters, to <del> be changed during the session.  The effects of this method call </del> <ins> be changed during the session.  The effects of calling this method </ins> depend on when it is invoked, and they will differ, depending on which specific parameters are changed: <del> This call may result in a change to the state of the ICE agent. </del> <ins> Calling this method may result in a change to the state of the ICE agent. </ins> 4.1.17.

Related discussion:
text: Several small updates: Issue 15: local media state, local resources correct, removed comment. - Issue 16: updated wording to use 'calling this method', removed comments, - Issue 17: changed stopTransceiver to stop, removed comments, - Issue 18: changed 'directional attribute' to 'direction attribute', removed comments,
LGTM once lands
18) [rfced] Section 4.2.5: We see "direction attribute" but not "directional attribute" in RFC 3264. Will this text be clear to readers? (We ask because we also see "A direction attribute, determined by applying the rules regarding the offered direction specified in [RFC3264], Section 6.1" in Section 5.3.1 of this document.) Original: More specifically, it indicates the [RFC3264] directional attribute of the associated m= section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer.
This should indeed be , as that's the terminology used by 3264.
NAME please close this issue once you consider it resolved.
17) [rfced] Section 4.2.2: Will "stopTransceiver" be clear to readers? We could not find this string elsewhere in this document, anywhere else in this cluster of documents, in any published RFC, or in google searches. Original: The stopped property indicates whether the transceiver has been stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated m= section.
This should be , rather than .
NAME please close this issue once you consider it resolved.
16) [rfced] Section 4.1.16: Should "The effects of this method call" be "The effects of calling this method," and should "This call" be "Calling this method"? Original: The effects of this method call depend on when it is invoked, and differ depending on which specific parameters are changed: ... This call may result in a change to the state of the ICE Agent.
SGTM
NAME please close this issue once you consider it resolved.
15) [rfced] Section 4.1.10: Please confirm that "local media state" and "local resources" (as opposed to remote) are correct in the context of setRemoteDescription.
Code change:
The setConfiguration method allows the global configuration of the PeerConnection, which was initially set by constructor parameters, to <del> be changed during the session.  The effects of this method call </del> <ins> be changed during the session.  The effects of calling this method </ins> depend on when it is invoked, and they will differ, depending on which specific parameters are changed: <del> This call may result in a change to the state of the ICE agent. </del> <ins> Calling this method may result in a change to the state of the ICE agent. </ins> 4.1.17.

Related discussion:
text: (We ask because we see identical wording in Section 4.1.9 ("setLocalDescription").) Original: This API changes the local media state; among other things, it sets up local resources for sending and encoding media.
yes, this is correct
NAME please close this issue once you consider it resolved.
12) [rfced] Section 4.1.8.1: We had trouble with this sentence. If neither suggestion below is correct, please clarify. Original: While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer, if followed by a "sendrecv" answer the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer followed by a "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
suggestion seems right
Code change:
confirmation_tag by way of the key schedule will confirm that all members of the group agree on the extensions in use. <del> 13.1.9. </del> <ins> 13.1.8. </ins> Add and Remove proposals can be constructed and sent to the group by a party that is outside the group.  For example, a Delivery Service

Related discussion:
text: The way the spec is written now, clients need to implement all proposal types, and they must react to appropriately to all valid proposals, including AppAck. AppAck in a large, busy group could result in a situation where clients with longer latency connections to the DS (perhaps in a different country, using satellite, or using some wireless networks) might be effectively prevented from sending any messages, or worse could be prevented from sending AppAcks because their proposals are always a few hundred milliseconds late. I think AppAcks still have a place is relatively small groups with low message volumes, but I have a few suggestions: 1) Describe this issue either in the AppAck proposal section or in the security considerations section 2) I think it is reasonable for a group to consider some proposal types invalid. If there is consensus with this position, I'd like to make this clear with an extra sentence or two. If that is not the consensus, then I will propose that only Add, Remove, and Update are assumed to be supported by each group, and other proposal types have to be explicitly added.
My team had similar comments. I agree that this shouldn't be a 100% necessary thing to support.
I would differentiate between "support" in the sense of "if you receive one, do something sensible with it" vs. "send this under some circumstances". My understanding was that the requirement here was the former, and even that the definition of "sensible" was up to the implementation. The thinking being that if an application wanted to get some anti-suppression properties, it could send and verify these on some schedule, but when exactly they would be sent would be up to the application. Does that alleviate some of the concern here? If so, I would totally be open to clarifying that. To NAME point about latency, it seems like we could add an parameter to AppAck so that you could report on past epochs' messages in a future epoch. On considering proposal types invalid -- I think there has always been a notion that applications might have policies on which proposals are acceptable. Not just at the proposal type level, but at even finer granularities. Think about things like groups where only certain members are allowed to add/remove participants. I would also be fine laying this out more explicitly, though maybe it would be a more natural fit in the architecture document.
Code change:
confirmation_tag by way of the key schedule will confirm that all members of the group agree on the extensions in use. <del> 13.1.9. </del> <ins> 13.1.8. </ins> Add and Remove proposals can be constructed and sent to the group by a party that is outside the group.  For example, a Delivery Service

Related discussion:
text: Sorry, meant to delete a comment, closed the issue instead.
In the past I've expressed reservations about AppAck being included in the spec. I don't think it's sufficiently general (it only handles a one specific pattern of message loss and won't work for others, per NAME comment), and I don't like that we don't specify how to handle dropped messages in any way. The AppAck functionality is likely to just be re-invented at the application-level because of this. For example, AppAck can't be used to implement read receipts It doesn't help detect the suppression of handshake messages It doesn't handle cases where some messages must be delivered and others may be dropped So instead I would propose removing AppAck from the spec.
I've opened a PR to that effect in .
Virtual interim 2022-05-19 Agreement that the bar for support is quite low ... but you don't get a security property unless members actually do something more than the minimum That sort of implies that you want the group to opt in to this mechanism So we should have a new proposal type in a separate I-D
(To be clear, AppAck should move from the main spec here to its own I-D.)
One comment that renumbering the groupcontextextensions proposal was probably a bad idea from a process perspective which we should avoid doing in the future. In this case it seems unlikely that many people have implemented it who could not make a breaking change.
Code change:
7.1. <del> Senders MUST manage per-path congestion status, and MUST NOT send more data on a given path than congestion control on that path allows.  This is already a requirement of QUIC-TRANSPORT. </del> <ins> When the QUIC multipath extension is used, senders manage per-path congestion status as required in Section 9.4 of QUIC-TRANSPORT. However, in QUIC-TRANSPORT only one active path is assumed and as such the requirement is to reset the congestion control status on path migration.  With the multipath extension, multiple paths can be used simultaneously, therefore separate congestion control state is maintained for each path.  This means a sender is not allowed to send more data on a given path than congestion control for that path indicates. </ins> When a Multipath QUIC connection uses two or more paths, there is no guarantee that these paths are fully disjoint.  When two (or more

Related discussion:
text: as this is already stated normatively in RFC900.
Currently the draft say: However, we should not use normative language in this draft but just point to RFC9000 instead as things are defined normatively there already. Btw. this reference should point to section 13.3 ("Upon detecting losses, a sender MUST take appropriate congestion control action.") and 9.4 ("Packets sent on the old path MUST NOT contribute to congestion control or RTT estimation for the new path.") of RFC9000 specifically and maybe also to RFC9002 directly.
LGTMLGTM
Code change:
Connection IDs), the short header exposes at most only a single Connection ID. <del> 6.1. </del> <ins> 7.1. </ins> QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC).

Related discussion:
text: hopefully addresses issue
I don't think "the same port number as would be used for the same application over TCP" is necessary general-purpose guidance. I would argue for something more like:
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN
Code change:
the CA may consider the new account associated with the external account corresponding to the MAC key, and MUST reflect value of the "external-account-binding" field in the resulting account object.  If <del> any of these checks fail, then the CA MUST reject the new- registration request. </del> <ins> any of these checks fail, then the CA MUST reject the new-account request. </ins> 6.3.3.

Related discussion:
text: In the term "registration" was changed to "account". In and in some of the remaining references to "registration" were removed, but some 'new-reg' and references to "registration" remained. This PR removes, hopefully, the last references to "registration".
Code change:
Attempts to clone a Connection can result in a CloneError: <del> The Connection Property "Priority" operates on entangled Connections as in msg-priority: when allocating available network capacity among Connections in a Connection Group, sends on Connections with higher Priority values will be prioritized over sends on Connections with lower Priority values.  A transport system implementation should, if possible, assign each Connection the capacity share (M-N) x C / M, where N is the Connection's Priority value, M is the maximum Priority value used by all Connections in the group and C is the total available capacity.  However, this Priority setting is purely advisory, and provides no guarantees about the way capacity is shared.  Each implementation is free to implement a way to share capacity that it sees fit. </del> <ins> The Connection Priority Connection Property operates on entangled Connections using the same approach as in msg-priority: when allocating available network capacity among Connections in a Connection Group, sends on Connections with lower Priority values will be prioritized over sends on Connections with higher Priority values.  Capacity will be shared among these Connections according to the Connection Group Transmission Scheduler property (conn- scheduler).  See priority-in-taps for more. </ins> 7.

Related discussion:
text: If so, if it worth calling this property "Group Priority" and explain this is sender-side?
I find the priority framework perhaps overspecified at the connection level and underspecified at the message level, with the interaction between the two left explicitly unstated. I would almost rather see the priority type and meaning left completely implementation-specific; otherwise, my suspicion is that someone will write an application using numeric priorities, declare victory when it works fine on one platform, and not understand that the behavior is not universal. In general, I think if TAPS is going to produce a consistent, easily-understandable, and portable API, it needs to stick to easily-understood abstractions. Message-level priority is sort of like the TCP URG mechanism (though better specified and more useful, for sure), but I'm thinking urgent messages sent explicitly out-of-band (e.g., new Connection) with implementation-specific QoS will produce more consistent, predictable, and understandable outcomes in the pessimal case.
Ok for me (and thanks for doing this!)Some nits, but I believe this addresses my concerns in the issue.
Code change:
node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from the resolution node * Derive secret values for ancestors of that <del> node using the KDF keyed with the decrypted secret </del> <ins> node using the KDF keyed with the decrypted secret * The recipient SHOULD verify that the received public keys agree with the public keys derived from the new node_secret values </ins> Merge the updated secrets into the tree * Replace the public keys for nodes on the direct path with the received public keys * For

Related discussion:
text: Adding this check would be the first step in recognizing that an Update operation may have maliciously excluded a person from the group.
This would go better in the "Ratchet Tree Updates" section, right after "Derive secret values for ancestors of that node using the KDF keyed with the decrypted secret". That would align better with where in the code you want the checks to be. Other than that, LGTM.
Fixed
Thanks Michael !
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 1 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 4 comments. - - Last week, 9 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .