jiebi/CodeConvo huggingface dataset:
Change:
packet either cannot be associated with a connection, cannot be decrypted, or is marked as a duplicate packet.  The endpoint MUST then compare the last 16 bytes of the packet with all Stateless Reset <del> Tokens that are associated with connection IDs that are currently in use.  This includes Stateless Reset Tokens from NEW_CONNECTION_ID frames and the server's transport parameters.  An endpoint MUST NOT check for any Stateless Reset Tokens associated with connection IDs it has not used or for connection IDs that have been retired. </del> <ins> Tokens that are associated with connection IDs that the endpoint recently used to send packets from the IP address and port on which the datagram is received.  This includes Stateless Reset Tokens from NEW_CONNECTION_ID frames and the server's transport parameters.  An endpoint MUST NOT check for any Stateless Reset Tokens associated with connection IDs it has not used or for connection IDs that have been retired. </ins> If the last 16 bytes of the packet values are identical to a Stateless Reset Token, the endpoint MUST enter the draining period

Discussion:
I know that we made this a design issue, and these do change 2119 language, but those normative requirements were implied anyway. That is, the text used cannot vs. MUST NOT.
I was also wondering about the rate limit in SR - I too thought it was there. But now, after thinking a bit, the rate limit was probably removed because it is a DoS vector. It can force state to maintained where it is not wanted.
This is a weird statement to make. It is absolutely the place of the spec to do that! If what you mean is that this is entirely optional, then I'm happy to make it a MAY. My concern is not so much what level of force the spec uses, just that the level of force is clear.
Before I merge this, NAME NAME might want to check that I'm not making technical changes. (There is new 2119 language, but my view is that this is converting from implied to express, but I want to give a chance to run a consensus call if you think that's appropriate.)
Those sorts of conversions have surprised people before, and is design anyway, so let's do run that consensus call. If it's ready to go, add and we'll run it up the virtual flagpole.
NAME take a look at what I just proposed.
While there are some prohibitions, and an explicit MAY for responding to Long Headers, there is no normative statement for the usual use case for Stateless Reset. I believe it's a SHOULD, but maybe someone thinks it's a MUST. Relatedly, in 10.4.1, MUST we attempt to detect Stateless Reset, or MAY endpoints just drop after decrypt failure? At the end of 10.4.2, MUST we not reuse connection IDs if there's a static key? (I think the answer is yes)
Thanks, NAME this LGTM.Thank you, this addresses the original issue. One nit below.
Change:
HNA and low power devices; Olafur Gudmundsson for clarifying DNSSEC capabilities of small devices; Simon Kelley for its feedback as dnsmasq implementer; Andrew Sullivan, Mark Andrew, Ted Lemon, Mikael <del> Abrahamson, Michael Richardson and Ray Bellis for their feedback on handling different views as well as clarifying the impact of outsourcing the zone signing operation outside the HNA; Mark Andrew and Peter Koch for clarifying the renumbering. </del> <ins> Abrahamson, and Ray Bellis for their feedback on handling different views as well as clarifying the impact of outsourcing the zone signing operation outside the HNA; Mark Andrew and Peter Koch for clarifying the renumbering. </ins>

Discussion:
…ng to
Section 12 needs to be fleshed out.
OOps, I rewrote Privacy Considerations since that was section 12.
Change:
cipher suites.  (see cipher-suites) A TLS-compliant application MUST support digital signatures with <del> rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for </del> <ins> rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256_ (for </ins> CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 RFC7748.

Discussion:
The only thing that might need text (though I'm not certain) is that this doesn't describe what it means to have signaturealgorithmscert and not signaturealgorithms. I assume that it means that a signature isn't possible. However, in previous versions it would be interpreted to mean something else based on default values for signaturealgorithms.
Change:
application server requested message delivery.  The response headers SHOULD provide a URI for the push resource corresponding to the push message subscription in a link relation of type <del> "urn:ietf:params:push" and a URI for the receipt subscribe resource in a link relation of type "urn:ietf:params:push:receipt".  The response body is the entity body from the most recent request sent to the push resource by the application server. </del> <ins> "urn:ietf:params:push".  The response body is the entity body from the most recent request sent to the push resource by the application server. </ins> A user agent can also request the contents of the push message subscription resource immediately by including a RFC7240 with a

Discussion:
LGTM, just one nit.
I think that having the push service return the link relation on requests to subscriptions (and subscription sets) is enough. I think that perhaps it was added to push messages in error.
cc NAME
Change:
In this example, Evidence generation based on received handles always uses the current (most recent) handle.  As handles are distributed over the network, all involved entities receive a fresh handle at <del> roughly the same time.  The time that represents this event is named Handle received: time(HR).  Due to distribution over the network, there is some jitter with respect to time(HR) for each involved entity.  To compensate for this jitter, there is a small period of overlap (a specified offset) in which both a current handle and corresponding former handle are valid in Evidence appraisal: "validity-duration = time(HR') + offset - time(HR)".  The offset is typically based on a network's round trip time.  Analogously, the generation of valid Evidence is only possible, if the age of the handle used is lower than the validity-duration: "time(HR) - time(EG) < validity-duration". </del> <ins> roughly the same time.  Due to distribution over the network, there is some jitter with respect to the time the Handle is received, time(HR), for each involved entity.  To compensate for this jitter, there is a small period of overlap (a specified offset) in which both a current handle and corresponding former handle are valid in Evidence appraisal: "validity-duration = time(HR'_v) + offset - time(HR_v)".  The offset is typically based on a network's round trip time.  Analogously, the generation of valid Evidence is only possible, if the age of the handle used is lower than the validity- duration: "time(HR_v) - time(EG_a) < validity-duration". </ins> From the point of view of a Verifier, the generation of valid Evidence is only possible, if the age of the handle used in the Evidence generation is younger than the duration of the distribution <del> interval - "(time(HD')-time(HD)) - (time(HR)-time(EG)) < validity- duration". </del> <ins> interval - "(time(HR'_v)-time(HR_v)) - (time(HR_a)-time(EG_a)) < validity-duration". </ins> Due to the validity-duration of handles, multiple different pieces of Evidence can be generated based on the same handle.  The resulting

Discussion:
This pull request puts _X on all time points. Please review for accuracy.
I am neutral/okay with consistently adding suffixes to every event label
Change:
all, and that in that state we should send raw TLSPlaintext instead of sending a phony TLSCiphertext <ins> 5.2.3. All encrypted TLS records can be padded to inflate the size of the TLSCipherText.  This allows the sender to hide the size of the traffic from an observer. When generating a TLSCiphertext record, implementations MAY choose to pad.  An unpadded record is just a record with a padding length of zero.  Padding is a string of null bytes (uint8 with value 0) appended to the ContentType field before encryption.  Implementations MUST set the padding octets to all zeros before encrypting. Application Data records can be all padding if the sender desires. This permits generation of plausibly-sized cover traffic in contexts where the presence or absence of activity may be sensitive. Implementations MUST NOT send Handshake or Alert records that are all padding. The padding sent will be authenticated by the record protection mechanism.  Upon successful decryption of a TLSCiphertext.fragment, the receiving implementation scans the field from the end toward the beginning until it finds a non-zero uint8.  This non-zero octet is the content type of the message. Implementations MUST limit their scanning to the cleartext returned from the AEAD decryption.  If a receiving implementation does not find a non-zero octet in the cleartext, it should treat the record as having an unexpected ContentType, sending an "unexpected_message" alert. The presence of padding does not change the overall record size limitations - the full fragment plaintext may not exceed 2^14 octets. Versions of TLS prior to 1.3 did not enable padding of any record at the TLS level.  The padding scheme introduced in TLS 1.3 was selected because it allows padding of any encrypted TLS record by an arbitrary size (from zero up to TLS record size limits) without introducing new content types.  The design also enforces all-zero padding octets, which should avoid any risk of sending uninitialized memory as padding. Selecting a padding policy that suggests when and how much to pad is a complex topic, and is beyond the scope of this specification.  If the application layer protocol atop TLS permits padding, it may be preferable to pad application_data TLS records within the application layer.  Padding for encrypted handshake and alert TLS records must still be handled at the TLS layer, though.  Later documents may define padding selection algorithms, or define a padding policy request mechanism through TLS extensions or some other means. </ins> 6. TLS has three subprotocols that are used to allow peers to agree upon

Discussion:
This is a big improvement over the previous proposed methods, by the way. NAME I suggest filing a followup PR for your comments, as it looks like this has already merged.
Change:
Connection. No events will occur on a Connection after it is Closed; i.e., <del> after a Closed<> event, an InitiateError<> or ConnectionError<> will not occur on that connection.  To ensure this ordering, Closed<> will not occur on a Connection while other events on the Connection are still locally outstanding (i.e., known to the interface and waiting to be dealt with by the application). </del> <ins> after a Closed<> event, an EstablishmentError<> or ConnectionError<> will not occur on that connection.  To ensure this ordering, Closed<> will not occur on a Connection while other events on the Connection are still locally outstanding (i.e., known to the interface and waiting to be dealt with by the application). </ins> 10.

Discussion:
Interface, section 4.1.2: Why the limitation to aliases? Specifying a protocol might limit the utility of connection racing, so should perhaps be discouraged, but does it break anything to specify a protocol for a non-alias Endpoint?
Interim: suggest to remove the second sentence.
They are currently just called "Table"
In the interface draft, Section 1.1: Where is the event sent? Perhaps ?
Interim: add "to the application" (but double check, related to framers)
Could alternatively say the same another way around: "Applications can use these events..." (i.e. avoid saying only applications do this).
Section 6 in impl-draft has the parts where the framer objects receive events. There is no terminology section in implementation, so not sure if the terminology section in API should cover it as well.
We already say this in the intro text to this section, but I can tweak the structure and add some additional text to make this more clear.
The appendix text about convenience functions talks about "implementations should" provide various things. This reads strangely to me. I think these are not requirements and the text should be more in the form of it can be useful for implementations to provide various things.
How about: " implementations can provide special actions for adding each preference level i.e, TransportProperties.Set(someproperty, avoid) would be equivalent to TransportProperties.Avoid(someproperty):..."
EstablishmentError. Fixed in an upcoming PR.
Change:
5. <del> If the client instance calls an RS without an access token, or with an invalid access token, the RS MAY respond to the client instance with an authentication header indicating that GNAP needs to be used to access the resource.  The address of the GNAP endpoint MUST be sent in the "as_uri" parameter.  The RS MAY additionally return a resource reference that the client instance MAY use in its access token request.  This resource reference handle SHOULD be sufficient for at least the action the client instance was attempting to take at the RS.  The RS MAY use the rs-register-resource-handle to register a new resource handle, or use a handle that has been pre-configured to represent what the RS is protecting.  The content of this handle is opaque to the RS and the client instance in both cases. The client instance then makes a call to the "as_uri" as described in I-D.ietf-gnap-core-protocol, with the value of "access" as one of the members of the "access" array in the "access_token" portion of the request.  The client instance MAY request additional resources and other information, and MAY request multiple access tokens. [[ See issue #118 [4] ]] 6. </del> [[ TBD: There are a lot of items in the document that are expandable through the use of value registries. ]] <del> 7. </del> <ins> 6. </ins> [[ TBD: There are a lot of security considerations to add. ]]

Discussion:
See also related PR at ietf-wg-gnap/gnap-core-protocol
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit ec0063ea1a01f824c05137ecaaf8c7760dfee083 https://deploy-preview-26--gnap-resource-servers-editors-URL
Following the review I checked this PR too, seems fine
Change:
8.1. Instead of sending an resource-access-rights, access rights MAY be <del> communicated as a string known to the AS or RS representing the access being requested.  Each string SHOULD correspond to a specific expanded object representation at the AS. </del> <ins> communicated as a string known to the AS representing the access being requested.  Just like access rights communicated as an object, access rights communicated as reference strings indicate a specific access at a protected resource.  In the following non-normative example, three distinct resource access rights are being requested. </ins> This value is opaque to the client instance and MAY be any valid JSON string, and therefore could include spaces, unicode characters, and

Discussion:
Removes the normative suggestion that access right string values be always expandable to objects, but instead adds an example of one way to do it.
To edit notification comments on pull requests, go to your .
We say: But then we give examples like "some other thing" that clearly do not correspond to anything. We also don't specify any kind of semantics, such as if I request the reference string, I might get back the expanded access right representation. I suggest to remove or weaken that sentence:
I don't see a reason for it not being a SHOULD -- it provides guidance to API developers that the strings a short-hand for the expanded objects. And since it's only a SHOULD, the AS is still free to treat it differently.
No, this would be a MAY. With a SHOULD, you're supposed to have a good, documented reason to do something else. Quoting the original, may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. If we keep the SHOULD, our examples in the text should reflect that.
Probably we could improve the examples. But as an implementer, I wouldn't understand what you mean by MAY. Because then it suggests there can be reasonable alternatives to something known to the AS, which I don't think we have.
NAME I've proposed a change to the text in question in . Also, please note that the example string of is intended to be an actual value, with spaces and all. If it's not clear that this is a real and valid value in this context, please suggest an alternative that might fit here. We don't want people to assume that it has the same restrictions as OAuth scopes (which can't have spaces).
Change:
6. An endpoint can send multiple ACK-FREQUENCY frames, and each one of <del> them can have different values. If a received ACK-FREQUENCY frame is the first one in this connection, the endpoint MUST immediately record any values from the frame and start using them.  The endpoint MUST also record the packet number of the enclosing packet. If a received ACK-FREQUENCY frame is not the first one in this connection, the endpoint MUST check if this is a more recent ACK- FREQUENCY frame than any previous ones, as follows: If the enclosing packet number is greater than the recorded one, the endpoint MUST immediately replace old recorded state with values received in this frame.  The endpoint MUST also replace the value of the recorded packet number with that of the enclosing packet. If the enclosing packet number is not greater than the recorded one, the endpoint MUST ignore this ACK-FREQUENCY frame. </del> <ins> them can have different values.  An endpoint MUST use a sequence number of 0 for the first ACK-FREQUENCY frame it constructs and sends, and a strictly increasing value thereafter. An endpoint MUST allow reordered ACK-FREQUENCY frames to be received and processed, see Section 13.3 of QUIC-TRANSPORT. On the first received ACK-FREQUENCY frame in a connection, an endpoint MUST immediately record all values from the frame.  The sequence number of the frame is recorded as the largest seen sequence number.  The new Packet Tolerance and Update Max Ack Delay values MUST be immediately used for delaying acknowledgements; see sending. On subsequently received ACK-FREQUENCY frames, the endpoint MUST check if this is a more recent frame than any previous ones, as follows: If the enclosing packet number is not greater than the largest one seen so far, the endpoint MUST ignore this frame. If the sequence number in the frame is greater than the largest one seen so far, the endpoint MUST immediately replace old recorded state with values received in this frame.  The endpoint MUST start using the new values immediately for delaying acknowledgements; see sending.  The endpoint MUST also replace the recorded sequence number. </ins> 7.

Discussion:
merging.
We currently use PNs for ordering, but that runs afoul of requirements at the receiver specified in .
Change:
1.2. All wire formats will be depicted using the notation defined in <del> Section 1.3 of RFC9000.  There is one addition: the function len() refers to the length of a field which can serve as a limit on a different field, so that the lengths of two fields can be concisely defined as limited to a sum, for example: x(A..B) y(C..B-len(x)) indicates that x can be of any length between A and B, and y can be of any length between C and B provided that (len(x) + len(y)) does not exceed B. The example below illustrates the basic framework: </del> <ins> Section 1.3 of RFC9000. </ins> 2.

Discussion:
Fixing . I love deleting this much text!
This might be achieved as follows:
I'll should also point out that there is optional and you can also do: For any value of , though presumably is at least , it could reasonably be any value up to .
Change:
require a profile that defines acceptable use of 0-RTT; see Section 5.6 of RFC9001. <ins> The use of DATAGRAM frames might be detectable by an adversary on path that is capable of dropping packets.  Since DATAGRAM frames do not use transport-level retransmission, connections that use DATAGRAM frames might be distinguished from other frames using the different response to loss. </ins> 7. This document registers a new value in the QUIC Transport Parameter

Discussion:
Thank you!
Rephrasing what I mentioned at the mic, imagine a scenario where an application uses DATAGRAM to send a single fixed message ("fire the missile"). An adversary on path can start selectively dropping packets and checking to see whether or not they're retransmitted to learn whether or not this special message was sent. (Retransmission detection could be done by looking at the size of the QUIC packet carrying the DATAGRAM, for example.) I don't claim this is easy to do in practice, or useful, but I think it does raise interesting questions about how this new frame affects QUIC's security posture. Perhaps some text in the security considerations is needed? (Issue copied from , by NAME on 2019-11-19)
from NAME on 2020-02-21: How would that be different from streams in ordinary QUIC? Here you can also drop packets and look for retransmissions of a specific size? If there is overlap, this issue belongs to QUIC transport security considerations in general.
I think the key here is that, in dropping the special datagram frame and not seeing anything retransmitted, one could learn something about what was sent.
If we take my recommendation in to always at least send out a PING frame/packet for PTOs or losses of DATAGRAM frame/packets then, it may mitigate this leakage some. There would always be something sent out on these selective losses. I'm not sure how hard it would be to determine if the lost packet was a DATAGRAM or not with this behavior. My guess is that it would be implementation dependent.
PING doesn't really cut it here, because presence and size matter.
Does the attacker have a way of knowing that the packet that was dropped contained a DATAGRAM, vs some other non-retransmitted frame, such as PADDING or PING or ACK?
Probably not, though I would say that the retransmission logic for those three frames could be different enough that the choice of frame might leak. Nothing much doing here, though we might note that retransmission logic might expose information that can be used for traffic analysis.
Change:
server from repeated client probes, the PTO backoff is not reset at a client that is not yet certain that the server has finished validating the client's address.  That is, a client does not reset <del> the PTO backoff factor on receiving acknowledgements until the handshake is confirmed; see Section 4.1.2 of QUIC-TLS. </del> <ins> the PTO backoff factor on receiving acknowledgements in Initial packets. </ins> This exponential reduction in the sender's rate is important because consecutive PTOs might be caused by loss of packets or

Discussion:
If you receive a handshake ACK, then the server has validated the client's address, so it's really only Initial ACKs.
I think this is good.
There is an inconsistency in URL w.r.t. resetting PTO backoff factor. Section 6.2.1: This suggests that for a client to be certain that the server has finished validating the client's address, the handshake should have been confirmed. However, the pseudo code uses PeerCompletedAddressValidation to determine whether to reset pto-count and PeerCompletedAddressValidation also checks for Handshake ACK received. That is not what the text in 6.2.1 says, as, according to URL, the handshake is confirmed when HANDSHAKEDONE is received or when a 1-RTT ack is received. That is a subtle difference. As kazu noted in the discussion on Slack, Sec 8.1 of QUIC says: "Once the server has successfully processed a Handshake packet from the client, it can consider the client address to have been validated.", so, the client can consider that the server validated the client address when either ACK in Handshake or HANDSHAKEDONE in 1-RTT is received. (See Figure 5 of TLS.) Hence, the pseudocode seems to be correct and that means the text in 6.2.1 should be corrected.
Thanks for filing this, I think the new text is simpler anyway.