jiebi/CodeConvo huggingface dataset:
Change:
The designated expert RFC8126 only ensures that the specification is publicly available. <ins> As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available. </ins> ClientCertificateType Identifiers marked as "Yes" are those allocated via Standards Track RFCs.  ClientCertificateTypes marked as "No" are not.

Discussion:
NAME let me know what you think.
I.e., if you actually deploy on the Internet with these experimental code points, and you run into someone using the same code point, you're going to have a bad day. For widespread experiments, we should really be using temporary reservations of some kind instead.
NAME NAME How about we add the following note everywhere we added private use: NOTE: : As specified in {{RFC5226}}, assignments made in the Private Use space "are not generally useful for broad interoperability." It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.
LGTM.
Addressed by .
Change:
the IP Version field has value 6, the IP Address field SHALL have a length of 128 bits. <del> Length of the IP Prefix of the advertised route, in bits.  MUST be lesser or equal to the length of the IP Address field, in bits. </del> <ins> The number of bits in the IP Address that are used to define the prefix of the advertised route.  This MUST be lesser or equal to the length of the IP Address field, in bits.  If the prefix length is equal to the length of the IP Address, this route only allows sending packets to a single destination address.  If the prefix length is less than the length of the IP address, this route allows sending packets to any destination address that falls within the prefix. </ins> The Internet Protocol Number for traffic that can be sent to this prefix.  If the value is 0, all protocols are allowed.

Discussion:
NAME NAME Does this PR also ?
NAME not quite--it's a step, but there's more to do
I think the field description needs updates. The IP adress is after all an prefix that is masked by the specified number of bits. That is not quite clear yet. However, I think the question if this range should support excluding one or more sub-ranges needs to be sorted out also.
The specification of the field currently states . Is that unclear? If so, can you help provide text to help make it clearer? Agreed, that's discussed in
Editorial clarification that the prefix in the advertisement applies to the address in the advertisement, which is a remote prefix that the client is allowed to send to.
Change:
extensions.  It does not send in the clear any information that would otherwise be sent encrypted, nor vice versa.  For this reason this extension is neutral as far as security is concerned. <ins> Extension authors should be aware that acknowledging flags in a tls_flags extension of the ServerHello and HelloRetryRequest messages expose this response to passive observers.  Unless there is a special reason to place the response in the ServerHello, most flags should go in other (encrypted) messages. </ins>

Discussion:
All messages that carry extensions can have a tls_flags extension: CH, SH, EE, Cert, NST
NAME can you please respond to the comments above?
Ping NAME :-)
Done.
I might have framed this slightly differently, but this accurately captures the outcome of the discussion. Thanks for doing this.
Change:
content deemed as morally or commercially harmful to companies or consumers in some jurisdictions SIDN2020. <del> There are typically three types of blocklist elements: Keyword, domain name, or Internet Protocol (IP) address.  Keyword and domain name blocking take place at the application level, e.g., HTTP, whereas IP blocking tends to take place using IP addresses in IPv4/ IPv6 headers.  The mechanisms for building up these blocklists vary. Censors can purchase from private industry "content control" software, such as SmartFilter, which lets censors filter traffic from broad categories they would like to block, such as gambling or pornography Knight-2005.  In these cases, these private services attempt to categorize every semi-questionable website as to allow for meta-tag blocking.  Similarly, they tune real-time content heuristic systems to map their assessments onto categories of objectionable content. </del> <ins> There are typically a few types of blocklist elements: Keyword, domain name, protocol, or Internet Protocol (IP) address.  Keyword and domain name blocking take place at the application level, e.g., HTTP; protocol blocking often occurs using Deep Packet Inspection to identify a forbidden protocol; IP blocking tends to take place using IP addresses in IPv4/IPv6 headers.  Some censors also use the presence of certain keywords to enable more aggressive blocklists Rambert-2021 or to be more permissive with content Knockel-2021. The mechanisms for building up these blocklists vary.  Censors can purchase from private industry "content control" software, such as SmartFilter, which lets censors filter traffic from broad categories they would like to block, such as gambling or pornography Knight- 2005.  In these cases, these private services attempt to categorize every semi-questionable website as to allow for meta-tag blocking. Similarly, they tune real-time content heuristic systems to map their assessments onto categories of objectionable content. </ins> Countries that are more interested in retaining specific political control typically have ministries or organizations that maintain

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:
allow values to be linked by an on-path observer to the connection on which it was issued, unless the values are encrypted.  For example, it cannot include the previous connection ID or addressing <del> information.  Information that allows the server to distinguish between tokens from Retry and NEW_TOKEN MAY be accessible to entities other than the server. </del> <ins> information.  A server MUST ensure that every NEW_TOKEN frame it sends is unique across all clients, with the exception of those sent to repair losses of previously sent NEW_TOKEN frames.  Information that allows the server to distinguish between tokens from Retry and NEW_TOKEN MAY be accessible to entities other than the server. </ins> It is unlikely that the client port number is the same on two different connections; validating the port is therefore unlikely to

Discussion:
This is already implied by the existing text, but it isn't said directly. That is, we say that the values can't be linkable, which is a stronger requirement. Saying that you can't send the same value on two connections is much clearer.
This text does not forbid the server from sending the same token on multiple connections. Consequently the client has a hard, or impossible, task of excluding duplicates. At least if you only read that section. Later the text says: >The token MUST NOT include information that would allow it to be linked by an on-path observer to the connection on which it was issued. This suggests that the token MUST indeed be unique, but in a roundabout manner. It would be helpful to make the initial paragraph clearer by stating the that the duplicate token can only happen on the same connection and that the server MUST ensure different connections use different tokens.
A nit, but looks good, thanks for working patiently!
Change:
time a Commit message is sent and processed.  These states are referred to as "epochs" and are uniquely identified among states of the group by eight-octet epoch values.  When a new group is <del> initialized, its initial state epoch 0x0000000000000000.  Each time a state transition occurs, the epoch number is incremented by one. </del> <ins> initialized, its initial state epoch is 0x0000000000000000.  Each time a state transition occurs, the epoch number is incremented by one. </ins> [[ OPEN ISSUE: It would be better to have non-linear epochs, in order to tolerate forks in the history.  There is a need to discuss whether

Discussion:
I've put a bunch of little fixes in here. If you disagree with any of these changes, I can back them out or change them. maximal is defined but never used k-th leaf/leaf index is defined in two places; merge definitions change KeyPackage struct definition to reflect that ~2~ 3 extensions are required is also a required extension grammar fix add missing semicolon
One minor thing, otherwise LGTM
Change:
number spaces, the timer MUST be set for the packet number space with the earliest timeout, except for ApplicationData, which MUST be ignored until the handshake completes; see Section 4.1.1 of QUIC-TLS. <del> Not arming the PTO for ApplicationData prioritizes completing the handshake and prevents the server from sending a 1-RTT packet on a PTO before before it has the keys to process a 1-RTT packet. </del> <ins> Not arming the PTO for ApplicationData prevents a client from retransmitting a 0-RTT packet on a PTO expiration before confirming that the server is able to decrypt 0-RTT packets, and prevents a server from sending a 1-RTT packet on a PTO expiration before it has the keys to process an acknowledgement. </ins> When a PTO timer expires, the PTO period MUST be set to twice its current value.  This exponential reduction in the sender's rate is

Discussion:
Clarifies exactly what the implications of not arming PTO for ApplicationData prior to handshake complete. This came from a discussion with a coworker who read the transport and recovery drafts, but not TLS.
Thanks! I think this is much clearer from implementation perspective.
Change:
An application-level error on the individual stream. <del> The term "payload data" is defined in Section 6.4 of SEMANTICS. </del> <ins> The term "content" is defined in Section 6.4 of SEMANTICS. </ins> Finally, the terms "resource", "message", "user agent", "origin server", "gateway", "intermediary", "proxy", and "tunnel" are defined

Discussion:
… avoiding confusion with individual frame payloads (editorial). This is related to the Semantics issue URL
NAME has created URL on http-core Semantics draft, which describes how the term "payload" is overloaded when considered with the H2 and H3 docs. Roy's has a proposal to change that term in Semantics, which impacts the HTTP/3 draft. But he was kind enought to submit PR URL, which demonstrates the impact of that change. This issue is mainly for visibility and tracking purposes.
With or without NAME suggestion. I need to do the same for h2, so it is good to see URL suggestion
Change:
To calculate the "hash" value, the party doing the calculation creates a hash string by concatenating the following values in the <del> following order using a single newline ("n") character to separate </del> <ins> following order using a single newline ("n") character to separate </ins> them: the "nonce" value sent by the client instance in the

Discussion:
The backslash does not need to be escaped
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 1a3c389510f95bfaaf245f40e2552e735e30826b Inspect the deploy log: Browse the preview:
Change:
this hash, and the client instance MUST validate the hash when received. <del> To calculate the "hash" value, the party doing the calculation first takes the "nonce" value sent by the client instance in the request- interact-finish, the AS's nonce value from response-interact-finish, and the "interact_ref" sent to the client instance's callback URL. These three values are concatenated to each other in this order using a single newline character as a separator between the fields.  There is no padding or whitespace before or after any of the lines, and no trailing newline character. </del> <ins> To calculate the "hash" value, the party doing the calculation creates a hash string by concatenating the following values in the following order using a single newline ("n") character to separate them: the "nonce" value sent by the client instance in the the AS's nonce value from the "interact_ref" returned from the AS as part of the the grant endpoint URL the client instance used to make its There is no padding or whitespace before or after any of the lines, and no trailing newline character. </ins> The party then hashes this string with the appropriate algorithm based on the "hash_method" parameter of the "callback".  If the

Discussion:
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 4080bf7a507929bd0ad4286d8ef72c0a70506c31 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Please ask the guy who submitted the vuln if there's any publication we can reference, maybe even the master's thesis as a WIP. They've earned it!
NAME I've reached out to them if there's a good URL to reference, and added them to the ack section (I should have done that before!).
Change:
This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of <del> several different media types into a single CoAP message-body with minimal framing overhead, each along with a CoAP Content-Format identifier. </del> <ins> several different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </ins> 1. This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of <del> several different media types into a single CoAP RFC7252 message-body with minimal framing overhead, each along with a CoAP Content-Format identifier. </del> <ins> several different media types into a single message, such as a CoAP RFC7252 request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </ins> This simple and efficient binary framing mechanism can be employed to create application specific request and response bodies which build

Discussion:
Sure. Apologies, I had completely misunderstood the gist of your comment (and Carsten's reply).
-> s/message-body/request or response body/
I still don't understand why the only permissible use of this representation format is inside a CoAP payload. Can't I transfer the CBOR structure over HTTP or store it in a file?
Change:
7. <del> RFC7525, Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), recommends use of SHA-256 as a minimum requirement.  This update moves the minimum recommendation to use stronger language deprecating use of both SHA-1 and MD5.  The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been deprecated. Section 4.3: OLD: When using RSA, servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key.  In addition, the use of the SHA-256 hash algorithm is RECOMMENDED (see CAB-Baseline for more details).  Clients SHOULD indicate to servers that they request SHA-256, by using the "Signature Algorithms" extension defined in TLS 1.2. NEW: Servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key. In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used (see CAB-Baseline for more details).  Clients MUST indicate to servers that they request SHA- 256, by using the "Signature Algorithms" extension defined in TLS 1.2. 8. </del> The document updates the "TLS SignatureScheme" registry to change the recommended status of SHA-1 based signature schemes to N (not recommended) as defined by RFC8447.  The following entries are to be

Discussion:
I didn't add a -08 version of the doc (datatracker keeps that history), and this keeps the diff smaller. cc NAME NAME
Should we remove the 7525 text now that 7525bis is underway.
Could you also: remove the reference to 7525 on line 14 drop 7525 from line 45, i.e., change the header. This I-D will no longer update the 7525. drop "and RFC 7525" line 137. drop "and " from line 158 Like
Change:
6. <ins> 6.1. </ins> TODO IANA registry for Message Type <ins> 6.2. </ins> TODO IANA registry EKT ciphers. <del> 6.1. </del> <ins> 6.3. </ins> IANA is requested to add "srtp_ekt_key_transport" as an new extension name to the "ExtensionType Values" table of the "Transport Layer

Discussion:
Should be in EKTkey not where it is. Should have text that when grt new KEK, need to wait X then start using new SRTP master key
Change:
It is possible to define a certificate compression algorithm that uses a pre-shared dictionary to achieve higher compression ratio. <del> This document does not define any such algorithms. </del> <ins> This document does not define any such algorithms, but additional codepoints may be allocated for such use per the policy in registry. </ins> If the received CompressedCertificate message cannot be decompressed, <del> the connection MUST be torn down with the "bad_certificate" alert. </del> <ins> the connection MUST be terminated with the "bad_certificate" alert. </ins> If the format of the Certificate message is altered using the server_certificate_type or client_certificate_type extensions

Discussion:
Update reference.
Almost, but I think I can accept my own suggestions so I'll just do that and merge.
Change:
sources.  Secondarily, the X9.62 encoding is also considerably smaller. <del> Some implementations permit the same P-256 key to be used for signing and key exchange.  An application server MUST select a different private key for the key exchange I-D.ietf-webpush-encryption and </del> <ins> Some elliptic curve implementations permit the same P-256 key to be used for signing and key exchange.  An application server MUST select a different private key for the key exchange WEBPUSH-ENCRYPTION and </ins> signing the authentication token.  Though a push service is not obligated to check either parameter for every push message, a push service SHOULD reject push messages that have identical values for

Discussion:
This looks a lot worse than it really is. Reflowing text causes massive diffs, which github somehow manages to make look like entirely new text.
Change:
No supported codec is present in the offer. <del> The bundle policy is "max-bundle" and the m= section is not in a bundle group. </del> <ins> The bundle policy is "max-bundle", the m= section is not in a bundle group, and this is not the first m= section. The bundle policy is "balanced", the m= section is not in a bundle group, and this is not the first m= section for this media type. </ins> The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute.

Discussion:
If a non-bundle offer is received, and "max-bundle" is used, the first m= section should be accepted and all others rejected. This will ensure the same result whether or not the "max-bundle" endpoint is the offerer or answerer (ignoring some unlikely corner cases), and will prevent a lone media description from being rejected if the remote offer didn't contain a bundle group simply because it wasn't necessary. Also added equivalent rules for the "balanced" bundle policy.
This LGTM
This isn't exactly what I had in mind for 'balanced', but this might not be an issue in practice. If the answerer needs to handle multiple m= lines that are unbundled, it can set max-compat.
lgtm
Change:
possess has been issued under. To prevent against this, servers MUST only use one private key for <del> issuing tokens at any given time.  Servers may use two or more keys </del> <ins> issuing tokens at any given time.  Servers MAY use one or more keys </ins> for redemption to allow servers for seamless key rotation. <del> Key rotations must be limited in frequency for similar reasons.  See parametrization for guidelines on what frequency of key rotations are permitted. </del> <ins> Servers may rotate keys as a means of revoking tokens issued under old or otherwise expired keys.  Alternatively, servers may include expiration information as metadata alongside the token; See metadata for more discussion about metadata constraints.  Both techinques are equivalent since they cryptographically bind expiration to individual tokens. </ins> <del> 4.3. </del> <ins> Key rotations should be limited in frequency for similar reasons. See parametrization for guidelines on what frequency of key rotations are permitted. 4.2. </ins> Since a server is only permitted to have a single active issuing key, this implies that only a single ciphersuite is allowed per issuance

Discussion:
Replace suggested registry with list of other options. The rationale is that a registry may be sufficient but not necessary. There are other options that might work. I suggest we work with NAME on a draft describing these techniques in more detail. cc NAME
There's currently no text around token expiration. Minimally, we could say that tokens expire when issuer (and verifier) keys rotate. Do we also want to bake in mechanisms for expiration to be cryptographically bound to issued tokens? For example, one might imagine using PMB-like constructions to encode an expiration "epoch" into the metadata bits. The single metadata bit variant would allow two epochs that way. NAME NAME what do you think?
I'm not sure what baking the expiry into the tokens gives that can't be managed by rotating the issuer/verifier keys (or using public metadata (which is effectively the key used to sign))? That way issuers that care about more fine grained token expiration use the key rotation for that and issuers that only care about coarse token expiration use it for other metadata, allowing the protocol to treat both in the same way?
Yeah, I think the only two options are (a) rotate keys or (b) include the expiry information as public metadata (and need not be tied to the key used to sign). I'm not advocating for one or the other. Sure, that's reasonable. We should probably have text on this point. (That's partly why I filed this issue.)
We should also make sure to note that the validity window does narrow the anonymity set.
This LGTM. Agreed that working on a document that tackles these questions specifically would be worthwhile.