jiebi/CodeConvo huggingface dataset:
Change:
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond immediately by echoing the data contained in the PATH_CHALLENGE frame <del> in a PATH_RESPONSE frame.  However, because a PATH_CHALLENGE might be sent from a spoofed address, an endpoint MUST limit the rate at which it sends PATH_RESPONSE frames and MAY silently discard PATH_CHALLENGE frames that would cause it to respond at a higher rate. </del> <ins> in a PATH_RESPONSE frame. </ins> To ensure that packets can be both sent to and received from the peer, the PATH_RESPONSE MUST be sent on the same path as the

Discussion:
Implementations can do this anyway, so we're not getting much from the recommendation. And we already have good limits on what can be sent (including PATH_RESPONSE) in the migration section.
This can lead to amplification attack if not careful.
NAME how can this lead to amplification?
If an endpoint seeing a challenge uses the opportunity to discover if its preferred MTU is supported by padding the response (as opposed to the challenge) even if the challenge packet is small. Since this might fail, it like will also send a small response after a delay or after a new challenge if it doesn't get an ACK before that. A defence could be to ensure that challenges are no larger than, say twice, response.
An endpoint may also optimistically bundle all kinds of other data in a response. Even with 1200 bytes, this can be much larger than a small challenge packet without considering PMTU discovery at all.
I think I raised this issue quite a while ago this is the reason the limit was introduced, although I didn't formulate the exact counter measure.
The counter measure we have against amplification is the initial congestion window. We won't send more than that. That's higher than the x3 we have during the handshake, but I think that's a reasonable balance, considering that the attacker in this context has to spend a considerable amount of effort. Yes, this is a policy question, but I'm happy with it. (Though we should probably highlight this when asking for review.)
It's pretty hard to understand what the normative force of this is, given that it doesn't explain what the limit is. I think there's actually a simple rule we should propose, which is one PATH_CHALLENGE frame per packet (with others to be ignored). Given that we require duplicate suppression at the packet level, that will have an amplification factor of 1:1, which you can get by a variety of other mechanisms.
The relevant existing guideline is the 3x limit we have on handshake amplification. Given that CHALLENGE/RESPONSE doesn't inherently include any amplification other than what might result from different connection ID lengths on packets, I don't think that we need to do much special. That is, the text in 9.3.1 is fine, even if the limits are different. I'm OK with striking everything from "However" onward here.
Change:
2.3. <del> In this specification, the semantics of a JSONPath query define the </del> <ins> In this document, the semantics of a JSONPath query define the </ins> required results and do not prescribe the internal workings of an implementation.

Discussion:
Generally, use "this document" rather than "this specification". Then use the term specification judiciously. Prefer the term "language" to "platform".
Yep, environment is a nice synonym of platform. Thank you for addressing my concern!
Change:
An existing member receiving a Add message first verifies the signature on the message, then updates its state as follows: <del> Increment the size of the group </del> <ins> If the "index" value is equal to the size of the group, increment the size of the group, and extend the tree and roster accordingly </ins> Verify the signature on the included UserInitKey; if the signature verification fails, abort <del> Append an entry to the roster containing the credential in the </del> <ins> Set the roster entry at position "index" to the credential in the </ins> included UserInitKey <del> Update the ratchet tree by adding a new leaf node for the new member, containing the public key from the UserInitKey in the Add corresponding to the ciphersuite in use </del> Update the ratchet tree by setting to blank all nodes in the <del> direct path of the new node, except for the leaf (which remains set to the new member's public key) </del> <ins> direct path of the new node Set the leaf node in the tree at position "index" to a new node containing the public key from the UserInitKey in the Add corresponding to the ciphersuite in use </ins> The update secret resulting from this change is an all-zero octet string of length Hash.length.

Discussion:
Right now, we blank out leaf nodes when we remove their holders, but we never reduce the size of hte tree or repopulate interior blanks with new members. This PR adds those functions: Reduce the size of the tree and the roster when you remove from the right edge Add an field to the message, to enable new members to be added to blank slots in the tree, not just at the right edge. In addition to performing "garbage collection", this change should make it easier to do a state resync -- just remove the desync'ed endpoint and add them back in the same spot.
NAME Do you think this is ready to merge? say it's OK as long as we can convince ourselves that truncation preserves the tree invariant. Proof sketch: The tree invariant is a universal statement over nodes in the tree and members in the group: ! Since subtrees are just subsets of the set of nodes in the tree, if the tree invariant holds for a given tree, then it also holds for any subtree of that tree. So since truncation just moves from a tree to a subtree, the invariant continues to hold.
Currently, the tree only ever grows: When you add someone, you have to add them at the right edge, even if there are blank leaves When you remove someone, the tree never shrinks We should enable reclaiming of blank leaves and automatically reduce the size of the tree to the minimum necessary size.
After discussion at 2019-01 interim: Agreement that this seems OK as long as we can verify that the tree invariant holds when you truncate the tree.
Change:
11. <ins> Key Derivation Functions (KDFs) are used to take some secret value and generate a different one.  The original secret values come in three basic flavors: Secrets which are uniformly random: This is the type of secret which is created by a good random number generator. Secrets which are not uniformly random: This is type of secret which is created by operations like key agreement. Secrets which are not random: This is the type of secret that people generate for things like passwords. General KDF functions work well with the first type of secret, can do reasonable well with the second type of secret and generally do poorly with the last type of secret.  None of the KDF functions in this section are designed to deal with the type of secrets that are used for passwords.  Functions like PBSE2 RFC2898 need to be used for that type of secret. Many functions are going to handle the first two type of secrets differently.  The KDF function defined in HKDF can use different underlying constructions if the secret is uniformly random than if the secret is not uniformly random.  This is reflected in the set of algorithms defined for HKDF. When using KDF functions, one component that is generally included is context information.  Context information is used to allow for different keying information to be derived from the same secret.  The use of context based keying material is considered to be a good security practice.  This document defines a single context structure and a single KDF function. </ins> 11.1. The HKDF key derivation algorithm is defined in RFC5869.

Discussion:
Add more intro text to algorithms Put in a note about the fact that a zero length map is not the preferred encoding for the protected field, but is a legal one.
Change:
the application protocol that QUIC serves. TLS session tickets and address validation tokens are used to <del> carry QUIC configuration information between connections.  These MUST NOT be used to carry application semantics.  The potential for reuse of these tokens means that they require stronger protections against replay. </del> <ins> carry QUIC configuration information between connections. Specifically, to enable a server to efficiently recover state that is used in connection establishment and address validation.  These MUST NOT be used to communicate application semantics between endpoints; clients MUST treat them as opaque values.  The potential for reuse of these tokens means that they require stronger protections against replay. </ins> A server that accepts 0-RTT on a connection incurs a higher cost than accepting a connection without 0-RTT.  This includes higher

Discussion:
The text here was perhaps a little unclear on this point. The point is that these don't carry information from server to client or client to server, they carry information from server (previous) to server (next).
There seems to be a conflict between this assertion in Section 9.2: URL the fact that 4.8 explicitly discusses how application protocols might need to have data embedded in the session ticket. (Also, QUIC doesn't use TLS address validation tokens.) I think this is actually trying to say that receipt of the session ticket MUST NOT cause side-effect beyond setting up the connection, but it's a broader prohibition than that.
I think that it says something else, namely that these are not intended to convey semantic information from client to server (or vice versa). PR inbound.
Change:
Observe Option, if appropriate for an unsolicited response) rather than as a request for the remaining missing blocks. <ins> It is possible that the server may start transmitting the next set of MAX_PAYLOADS payloads before the client times out on waiting for the last of the previous MAX_PAYLOADS payloads.  On receipt of the first received payload from the new set of MAX_PAYLOADS payloads, the client SHOULD send a request for the missing payloads indicating any missing payloads from any previous MAX_PAYLOADS payloads.  Upon receipt of the request for missing payloads, the server SHOULD send the missing payloads before continuing to send the remainder of the MAX_PAYLOADS payloads and then go into another NON_TIMEOUT delay prior to sending the next set of payloads. </ins> The client does not need to acknowledge the receipt of the entire body.

Discussion:
find another name than Quick-Block
A poll is ongoing. Updated to Q-Block in -02, but open to change if we get more inputs
Change:
the "DTLS-OK" columns are "Y". IANA is requested to add this RFC as a reference to the TLS Cipher <del> Suite Registry. </del> <ins> Suite Registry along with the following Note: </ins>

Discussion:
Francesca says I am uncertain whether this document is the right place to place restrictions on IANA for this purpose beyond what has already been done elsewhere. Maybe there is a chance to do something in the TLS 1.3 update.
I added some text to the PR.
Since got merged, should this issue be closed now?
Thank you for this document. Please find some minor comments below. Francesca section 2. Conventions and Terminology FP: Please spell out that network byte order (most significant byte first) is used throughout the document. Once the client has transmitted the ClientHello message, it expects to see a HelloRetryRequest or a ServerHello from the server. However, if the server's message is lost, the client knows that either the ClientHello or the response from the server has been lost and retransmits. When the server receives the retransmission, it knows to retransmit. FP: It would be good to mention retransmission max times here. /+----------------+ /+-------+--------+ The value for the "DTLS-OK" column is "Y". IANA is requested to reserve the content type range 32-63 so that content types in this range are not allocated. FP: IANA is asked to reserve 32-63, but I could not see any explanation for that. I would like to see it justified in section 4.1 or in the respective IANA section. fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer. FP: First time PMTU appears, please expand and add reference. performing PMTU discovery, whether via [RFC1191] or [RFC4821] mechanisms. In particular: FP: I think this is missing areference to RFC 8201 since IPv6 is mentioned below. Any TLS cipher suite that is specified for use with DTLS MUST define limits on the use of the associated AEAD function that preserves margins for both confidentiality and integrity. That is, limits MUST be specified for the number of packets that can be authenticated and for the number of packets that can fail authentication before a key update is required. Providing a reference to any analysis upon which values are based - and any assumptions used in that analysis - allows limits to be adapted to varying usage conditions.

FP: This seems important enough that it should be highlighted for the experts reviewing the registration. I see that URL has a number of notes, maybe that would be enough, or maybe add it (as an update?) to RFC 8447? zero length vector (i.e., a single zero byte length field). FP: I suggest using TLS 1.3 terminology of "zero-length vector (i.e., a zero-valued single byte length field)" flow shown in Figure 11 if the client does not send the ACK message FP: s/11/12
Addressed in
LGTM with some suggested nits
Change:
unable to receive receipts in an aggregated way for the lifetime of the receipt subscription.  This might be necessary if the application server is monitoring receipt subscriptions on the behalf of other <del> push message senders (see sets-streams). </del> <ins> push message senders. </ins> A push service MUST return a 400 (Bad Request) status code for requests which contain an invalid receipt subscription.  If a push

Discussion:
I ensured that the "proxy" text in UA and AS were similar. I removed the cross-references to and added text in Section 7.5, which is specific to PS policies if it doesn't want to support multiple subscription sets. I did not call out potential UA scenarios in detail other than "monitoring on behalf" of other receivers or senders. WebPush provides a mechanism to enable proxies - but it may be better to have separate drafts that describe specific policies that use this mechanism to support scenarios such as moving between UA(s).
NAME and NAME - please review and comment.
LGTM, but I'll wait until others have commented before merging.
This works for me.
Change:
This is often just a clear way of saying the same thing as "domain name of a node", as outlined above.  However, the term is ambiguous.  Strictly speaking, a fully qualified domain name would <del> include every label, including the final, zero-length label of the root: such a name would be written "www.example.net." (note the </del> <ins> include every label, including the zero-length label of the root: such a name would be written "www.example.net." (note the </ins> terminating dot).  But because every name eventually shares the common root, names are often written relative to the root (such as "www.example.net") and are still called "fully qualified".  This

Discussion:
Split into two pairs of commits (each first changing content and then line lengths) for easy partial acceptance, should that be desired: Improve grammar and diction Be consistent about ordering domain name labels from the root The second pair attempts to provide a consistent treatment of "domain name" as an abstract sequence of labels in directed graph order starting at the root, while maintaining clarity about wire, presentation, and common display formats rendering domain names in reverse.
Change:
5.3. <del> The Key Distributor is responsible for knowing what endpoints are allowed in a given conference.  Thus, the Key Distributor and the </del> <ins> The Key Distributor needs to know what endpoints are to being added to in a given conference resource.  Thus, the Key Distributor and the </ins> Media Distributor will need to know endpoint-to-conference mappings, which is enabled by exchanging a conference-specific unique identifier as defined in I-D.jones-perc-dtls-tunnel.  How this unique

Discussion:
Other than revisiting section 3.1.1 and 5.3 after changes to other drafts are complete, these changes either directly, or in-spirit, address all of the feedback/comments.
Just a couple of comments inline.
Change:
packet number space for all paths or the use of separate packet number spaces per path.  While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly <del> difference latencies, this approach requires the use of a connection </del> <ins> different latencies, this approach requires the use of a connection </ins> ID.  Therefore use of a single number space can be beneficial in highly constrained networks that do not benefit from exposing the <del> connection ID in the header.  More evaluation and implementation experience is needed to select one approach before final publlication. </del> <ins> connection ID in the header.  While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility.  More evaluation and implementation experience is needed to select one approach before final publication.  Some discussion about pros and cons can be found here: https://github.com/mirjak/draft-lmbdhk-quic- multipath/blob/master/presentations/PacketNumberSpace_s.pdf </ins> As currently defined in this version of the draft the use of multiple packet number spaces requires the use of connection IDs is both

Discussion:
Based on the discussed from the side meeting, we need to Clarify that the goal is to only select one approach for the finally published solution in an RFC Add some discussion about the pros and cons to the appendix
Yes, I think we should have these discussions in the current draft.
Should we use a new code point for the transport parameter of the options? For 2 reasons: It's a new joint version As we use a different value definition in our current implementation, it's hard to deploy the new version in a synchronised way, at least we could keep compatible if we use a new transport parameter. What do you think? Or maybe we should keep it unchanged until the WG is ready to adopt the draft?
I think it is fine to define a new value for the transport parameter, the 00 version of this draft is not yet out anyway.
Yes, please use a new parameter.
I created to add one more sentence and a reference to the slides from the side meeting. I believe this is sufficient to address this issue for -00.
Ok with the PR, I can make a quick commit to fix the listed typos
Change:
12. implementation by David Skyberg.  https://github.com/dskyberg/gnap <del> [2].  Prototype implementation of AS and Client in Rust.  MIT license. </del> <ins> [2] Prototype implementation of AS and client in Rust.  MIT license. from Interop Alliance, implementation by Dmitri Zagidulin. https://github.com/interop-alliance/gnap-client-js [3] Prototype implementation of client in JavaScript.  MIT License. </ins> from Interledger Foundation. https://github.com/interledger/rafiki <del> [3] Production implementation of AS in JavaScript.  Apache 2.0 </del> <ins> [4] Production implementation of AS in JavaScript.  Apache 2.0 </ins> license. implementation by Aaron Parecki. https://github.com/aaronpk/gnap- <del> client-php [4] Prototype implementation of web application client and </del> <ins> client-php [5] Prototype implementation of web application client and </ins> CLI client in PHP, with common support library.  CC0 license. <del> from SUNET. https://github.com/SUNET/sunet-auth-server [5] Production </del> <ins> from SUNET. https://github.com/SUNET/sunet-auth-server [6] Production </ins> implementation of AS in Python.  BSD license. <ins> from SecureKey. https://verified.me/ [7] Production implementation of AS, client and RS.  Proprietary license. </ins> from Bespoke Engineering, implementation by Justin Richer. <del> https://github.com/bspk/oauth.xyz-java [6].  Advanced prototype implementation of AS, Client, and RS in Java, with common support library.  Prototype implementation of SPA Client in pure JavaScript. </del> <ins> https://github.com/bspk/oauth.xyz-java [8] Advanced prototype implementation of AS, client, and RS in Java, with common support library.  Prototype implementation of SPA client in JavaScript. </ins> Apache 2.0 license. 13.

Discussion:
To edit notification comments on pull requests, go to your .
NAME and NAME -- please check these additions to the implementation section.
Change:
counter measures against potential traffic analysis that could be done at the DS level. <del> 2.3.4. </del> <ins> 2.2.4. </ins> Clients that have been offline for a long time or not performing mandatory security operations will affect the security of the group

Discussion:
A few minor edits to (hopefully) improve readability, and a few comments in square braces ([ ]).
Something looks wrong with your text editor... ;)
Arg! Will fix, sorry about this.
Change:
3.3.2. <del> Connection identifiers may be used to correlate EDHOC messages and facilitate the retrieval of protocol state during EDHOC protocol execution.  EDHOC transports that do not inherently provide correlation across all messages of an exchange can send connection identifiers along with EDHOC messages to gain that required capability, see transport.  For an example of using connection identifiers when CoAP is used as transport, see coap. 3.3.3. </del> For OSCORE, the choice of a connection identifier results in the endpoint selecting its Recipient ID, see Section 3.1 of RFC8613, for which certain uniqueness requirements apply, see Section 3.3 of

Discussion:
There was quite a lot of overlap between 3.3.2 and 3.4. Tried to integrate 3.3.2 in 3.4 to avoid that.
Change:
example, the Unicode PLACE OF INTEREST SIGN (U+2318) would be defined in ABNF as "%x2318". <del> The terminology of RFC8259 applies except where clarified below. Definitions for "Object", "Array", and "Number" remain unchanged. Importantly "object" and "array" in particular do not take on a generic meaning, such as they would in a general programming context. </del> <ins> The terminology of RFC8259 applies except where clarified below.  The terms "Primitive" and "Structured" are used to group the types as in Section 1 of RFC8259.  Definitions for "Object", "Array", "Number", and "String" remain unchanged.  Importantly "object" and "array" in particular do not take on a generic meaning, such as they would in a general programming context. </ins> Additional terms used in this specification are defined below.

Discussion:
This is a full rebase of branch pr-98 () on current main.
Does this incorporate any changes from the discussions from , or is it a simple rebase?
It is a simple rebase, followed by a number of edits coming from the discussions here. Most of the remaining conversations need some further discussion, so I hope to cover them with my updated slides in a couple of hours.
Looks like a good next step on our path.