jiebi/CodeConvo huggingface dataset:
Change:
9.3. <del> This section describes invariants that TLS endpoints and intermediaries MUST follow.  It also applies to earlier versions, which assumed these rules but did not document them. </del> <ins> This section describes invariants that TLS endpoints and middleboxes MUST follow.  It also applies to earlier versions, which assumed these rules but did not document them. </ins> TLS is designed to be securely and compatibly extensible.  Newer clients or servers, when communicating with newer peers, SHOULD negotiate the most preferred common parameters.  The TLS handshake <del> provides downgrade protection: Intermediaries passing traffic between a newer client and newer server without terminating TLS should be </del> <ins> provides downgrade protection: Middleboxes passing traffic between a newer client and newer server without terminating TLS should be </ins> unable to influence the handshake (see security-handshake).  At the same time, deployments update at different rates, so a newer client or server MAY continue to support older parameters, which would allow

Discussion:
There are many sorts of TLS middleboxes (CDN, decrypting proxy, local antivirus, actual attack, etc), with acceptabilities ranging from reasonable to extremely questionable to a terrible idea. (Categorization is left as an exercise to the reader.) They also have very different security considerations. Fundamentally, TLS secures a connection between two endpoints. As such, we have something to say about the endpoint-to-endpoint connections that make up such a system, but we shouldn't imply this section is sufficient, merely necessary. Adjust the text accordingly. I wrote "intermediary" in the original PR, predictively based on PR . Since the spec seems to have settled on "middlebox", align the terminology. (I don't really care what is used, just that it is consistent.)
Ah yeah. Fixed. I used "implementations" for this one because there is an "(also known as ossification)" parenthetical and, in the general case, endpoints can cause ossification too. Even here, I dunno, maybe a sufficiently confused endpoint will do something silly there. :-)
Should the legacysessionid description, which also mentions intermediaries, also be tweaked?Thanks!
Change:
Verify that the current time is within the validity interval of the credential.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus <del> DelegatedCredential.cred.valid_time.  2 Verify that the credential's remaining validity time is no more than the maximum validity period.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time plus the maximum validity period. </del> <ins> DelegatedCredential.cred.valid_time. Verify that the credential's remaining validity time is no more than the maximum validity period.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time plus the maximum validity period. </ins> Verify that expected_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the

Discussion:
From Martin: I wonder how much more needs to be said about expiration dates and allowance for clock skew. We haven't had any trouble with the mechanism proposed here (to my knowledge), but we've had plenty of trouble with ESNI deployment. Maybe the design here is sufficiently superior that it is less susceptible to problems, but it's not clear that this is indeed the case. Our implementation follows the spec when it comes to the validity period, but we can't really prevent skew from causing credentials to be rejected. What this does is that it creates a fixed notBefore equivalent for the DC that is relative to the notAfter. This effectively means that servers need to set valid_time values that aren't too far in the future based on their tolerance for client clock skew. For a 7-day credential, you might get 5 good days of use. A little bit of a nod in this direction might go a long way to avoiding deployment problems.
Fixed in
Change:
use the Retry feature (see Section 8.1 of QUIC-TRANSPORT). HelloRetryRequest is still used to request key shares. <del> 4.10. </del> <ins> 4.8. </ins> If TLS experiences an error, it generates an appropriate alert as defined in Section 6 of TLS13.

Discussion:
This adds a short introductory section to the three sections that deal with 0-RTT. That might help contextualize and help contain the spaghetti structure that this section seems to have.
Thanks Nick. I took it in a slightly different direction, but I think that I captured this.
One high-order bit: Using 0-RTT as a noun doesn't sound right, though we do use it informally in that sense. My suggestion use of "The 0-RTT handshake delay feature" or "0-RTT delay before sending application data" as appropriate.This change looks good.
Change:
process the Commit (i.e., not including any members being added or removed by the Commit). <del> If there are multiple proposals that apply to the same leaf, the committer chooses one and includes only that one in the Commit, considering the rest invalid.  The committer MUST NOT include any Update proposals generated by the committer, since they would be duplicative with the "path" field in the Commit.  The committer MUST prefer any Remove received, or the most recent Update for the leaf if there are no Removes.  If there are multiple Add proposals containing KeyPackages that the committer considers to represent the same client or a client already in the group (for example, identical KeyPackages or KeyPackages sharing the same Credential), the committer again chooses one to include and considers the rest invalid.  The committer MUST consider invalid any Add or Update proposal if the Credential in the contained KeyPackage shares the same signature key with a Credential in any leaf of the group, or if the KeyPackage shares the same "hpke_init_key" with another KeyPackage in the group. </del> <ins> If there are multiple proposals that apply to the same leaf, or multiple PreSharedKey proposals that reference the same PreSharedKeyID, the committer MUST choose one and include only that one in the Commit, considering the rest invalid.  The committer MUST NOT include any Update proposals generated by the committer, since they would be duplicative with the "path" field in the Commit.  The committer MUST prefer any Remove received, or the most recent Update for the leaf if there are no Removes.  If there are multiple Add proposals containing KeyPackages that the committer considers to represent the same client or a client already in the group (for example, identical KeyPackages or KeyPackages sharing the same Credential), the committer again chooses one to include and considers the rest invalid.  The committer MUST consider invalid any Add or Update proposal if the Credential in the contained KeyPackage shares the same signature key with a Credential in any leaf of the group, or if the KeyPackage shares the same "hpke_init_key" with another KeyPackage in the group. </ins> The Commit MUST NOT combine proposals sent within different epochs. Due to the asynchronous nature of proposals, receivers of a Commit

Discussion:
As discussed in , PreSharedKeyIDs shouldn't be repeated in the same commit
Should multiple PSK proposals within a commit be able to reference the same ? I feel like this should be covered in the same way we state multiple removals for the same should result in the committer choosing one. Wasn't sure if this was an oversight or on purpose. I can submit a PR to clarify if this is something that should be addressed
I agree, duplicates are an error. Committer MUST NOT include duplicates; receiver MUST reject Commit with duplicates. NAME - Please send a PR!
Change:
it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames.  If an endpoint receives a ACK_MP frame with a non-existing packet number space ID, it MUST treat this as a connection error of type <del> MP_CONNECTION_ERROR and close the connection. </del> <ins> MP_PROTOCOL_VIOLATION and close the connection. </ins> 10. <ins> Multi-path QUIC transport error codes are 62-bit unsigned integers following QUIC-TRANSPORT. This section lists the defined Multi-path QUIC transport error codes that can be used in a CONNECTION_CLOSE frame with a type of 0x1c. These errors apply to the entire connection. MP_PROTOCOL_VIOLATION (experiments use 0xba01): An endpoint detected an error with protocol compliance that was not covered by more specific error codes. 11. </ins> This document defines a new transport parameter for the negotiation of enable multiple paths for QUIC, and two new frame types.  The draft defines provisional values for experiments, but we expect IANA

Discussion:
If we want an MP specific error type we need to also add this to the IANA section.
Submitted PR for this issue. I just added MPPROTOCOLVIOLATION for connection close. If we have more specific error codes in the future, we can add them in the table.
Looks OK.
Change:
version used by HTTP/3 and therefore some clients will only support that version. <del> Any QUIC endpoint that supports multiple versions MUST meet the minimum requirements described in QUIC-VN to prevent version downgrade attacks. </del> <ins> Any QUIC endpoint that supports QUIC version 2 MUST send, process, and validate the version_information transport parameter specified in QUIC-VN to prevent version downgrade attacks. </ins> Note that version 2 meets that document's definition of a compatible <del> version with version 1.  Therefore, servers can use compatible negotiation to switch a connection between the two versions. Endpoints that support both versions SHOULD support compatible version negotiation to avoid a round trip. </del> <ins> version with version 1, and version 1 is compatible with version 2. Therefore, servers can use compatible negotiation to switch a connection between the two versions.  Endpoints that support both versions SHOULD support compatible version negotiation to avoid a round trip. </ins> 4.1.

Discussion:
As described in URL, we're going to simply require all not-just-v1 servers to support the version-information transport parameter, even if they're v2-only servers.
Change:
does a standard ClientHello, with the exception of the following rules: <del> It MUST NOT offer to negotiate TLS 1.2 or below. </del> <ins> It MUST NOT offer to negotiate TLS 1.2 or below.  Note this is necessary to ensure the backend server does not negotiate a TLS version that is incompatible with ECH. </ins> It MUST NOT offer to resume any non-ECH PSK or any session for TLS 1.2 and below.

Discussion:
The version check on the outer ClientHello doesn't make much sense since, when ECH is accepted, the version is based on the inner ClientHello anyway. See URL I've left a TODO since it seems weird to have a client requirement like that be so load-bearing without a corresponding server check. Not sure where we should go there.
I like this change, but it might be worth resolving the TODO.
Removed the TODO in favor of some clarifying text on the client side.
Change:
This document describes a DHCPv4 RFC2131 and DHCPv6 RFC8415 option (Captive-Portal) and an IPv6 Router Advertisement (RA) RFC4861 option <del> that informs clients that they are behind a captive-portal </del> <ins> that informs clients that they are behind a captive portal </ins> enforcement device and the API endpoint that the host can contact for more information.

Discussion:
2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...) [Gahforthe_hyphens a87eb8d] 2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...)
Change:
described in response-token-single. When neither an access token nor key proof are used, this is an <del> unsecured request.  This type of request is not used in the core protocol of GNAP. </del> <ins> unsecured request.  This type of request is used optionally for calls to the RS as part of an RS-first discovery process as described in rs-request-without-token. </ins> 7.1.

Discussion:
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 3259334e2eec3bc29ead34a917ce3a579ca3cfe5 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
client requests to RS w/o access token should be covered in core (client-facing protocol) See also
Requesting a Resource With Insufficient Access: Editor's note: This borrows heavily from UMA 2's "distributed authorization" model and, like UMA, might be better suited to an extension than the core protocol.
I'm in favour of this being in the core protocol. I don't think it adds that much complexity and it opens up a whole world of different deployment options.
First, the sentence at the top of this section is broken: . Second, I think this is a complicated decision: The RC is more likely to assume it will receive a useful response if this is in the core document rather than an extension. There may be privacy issues with the RS reporting the AS URI for a particular resource. Which would argue against including it in the core protocol.
It is definitely something that would be hard to make "mandatory to implement". I would like to see it included but not mandated for all deployments.
Yaron: 3.4: "updated_at": Unix time is nice, but for absolute time it's common to use ISO 8601 format. Justin: I stole this field from OIDC, but I’m fine with any format here, so if there’s no outcry we should change it in the next revision.
This has been changed to ISO 8601 format in 7d6c4580a11f2cd352d67121c8eeb68326b3d009
Change:
QUIC begins every connection in slow start with the congestion window set to an initial value.  Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (max_datagram_size), <del> limited to the larger of 14720 or twice the maximum datagram size. This follows the analysis and recommendations in RFC6928, increasing the byte limit to account for the smaller 8 byte overhead of UDP compared to the 20 byte overhead for TCP. </del> <ins> limited to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928, increasing the byte limit to account for the smaller 8 byte overhead of UDP compared to the 20 byte overhead for TCP. </ins> If the maximum datagram size changes during the connection, the initial congestion window SHOULD be recalculated with the new size.

Discussion:
This PR is also a good spot to comment on my accidental commit() to master. I can make any changes to that in this PR.
This was filed a while ago (before WGLC ended), didn't want to drop it.
Editorial, design?
There is a design issue here regarding the initial congestion window that I would like to see split out into a new issue (which can be marked design). The rest appear to be things we can address with editorial changes.
NAME I moved the IW text into , though I'm not sure I think it's worth revisiting.
Thanks :) I agree that it isn't worth re-opening, but we did sign on to at least discuss whether it is worth discussing.
Do we have a plan for this one?
So, is there a plan? (Is there even anything left to do?)
Some of these are addressed already, others are in an accidental commit(), and for some there's no need to address them in the text. The rest are in
Some suggestions only.One nit, but LGTM.
Change:
For ciphersuites using Ed25519 or Ed448 signature schemes, the public key is in the format specified in RFC8032.  For ciphersuites using ECDSA with the NIST curves (P-256, P-384, or P-521), the public key <del> is the output of the uncompressed Elliptic-Curve-Point-to-Octet- String conversion according to SECG. </del> <ins> is represented as an encoded UncompressedPointRepresentation struct, as defined in RFC8446. </ins> The signatures used in this document are encoded as specified in RFC8446.  In particular, ECDSA signatures are DER-encoded and EdDSA

Discussion:
Comment by NAME I personally don't like the underscored words in the html rendering of the document It "blank" the new American spelling of "blanc" ? I find "summarizes" a strange word here. It is not the hash contains a summary one can read. [SECG] has no IETF equivalent? Should it? proposaland -> proposal and I would say "after removing member C" (avoid ambiguity about "every third") I read this wrong the first way, the "," vanishes due to the unscores. Maybe: This section defines tree hashes, the next section defines parent hashes. Or alternatively, leave onlthe the first sentence in 8.8, then put the remainder and next section in two subsections (so 8.8.1 and 8.8.2) Maybe: For example, a malicious group member could otherwise send Maybe: to public keys whose private key was previously compromised. This reads a little odd as "new groups" would have no history and thus no previous compromise.
Filed I think it's important to emphasize the terms being defined, and this seems more readable than a definition list. Note that a hash function is often called a "message digest", in the same sense as the "Weekly github digest" that goes to the mailing list. I think referring to SECG is still pretty state-of-the-art. But apparently RFC 8446 moved on from that, so I updated to use that representation.
Change:
It is recommended that "initial_max_bidi_streams" be no smaller than 100, so as to not unnecessarily limit parallelism. <del> These streams carry frames related to the request/response (see request-response).  When a stream terminates cleanly, if the last frame on the stream was truncated, this MUST be treated as a connection error (see HTTP_MALFORMED_FRAME in http-error-codes). Streams which terminate abruptly may be reset at any point in the frame. </del> HTTP/3 does not use server-initiated bidirectional streams; clients MUST omit or specify a value of zero for the QUIC transport parameter "initial_max_bidi_streams".

Discussion:
Until now, only bidirectional streams were specified to treat a truncated last frame on a cleanly terminated stream as an error. With this pr, the same logic applies to push streams as well. I just slightly reworded the text from the bidirectional streams section and put it into the push stream section. Not sure if this is the best solution but I'm also not sure where to put the text if the text for both the bidirectional streams and push streams had to be combined.
already contains this text: That's intended to cover any stream type with frames. Perhaps we should consolidate the language from both sections into that, possibly leaving behind cross-references.
I hadn't seen that paragraph yet. I'd propose to drop the text in the Bidirectional Streams section. The reasoning is that when searching for what to do when a stream is closed with a truncated frame, I found (or rather was pointed to) the text in the Bidirectional Streams section. After finding a paragraph like that, I didn't expect to find any other text in the rfc related to truncated frames (which led to this pr). Without the text in the Bidirectional Streams section, I might have found the text in the Frame Layout section first which would have immediately answered my question. This would also consolidate errors related to frames in the HTTP Framing Layer section which seems like the first place to go looking for frame related errors. Should I make another pr (if this sounds like a good idea) or update this one with the proposed change?
Fine to just update this one. Thanks!
This is the best I could come up with. I had to relax the text from Frame Layout to allow truncated frames on abruptly closed streams. Maybe abruptly closed stream should be clarified better (I'm not sure if this is done elsewhere already?).
Reworded so as to not change the original text as much. The pr now just moves the truncation section from the streams section to the frames section.
Change:
POST <del> /.well-known/core{?ep,d,lt,extra-attrs*} </del> <ins> /.well-known/rd{?ep,d,lt,extra-attrs*} </ins> URI Template Variables are as they are for registration in registration.  The base attribute is not accepted to keep the registration interface simple; that rules out registration over CoAP- <del> over-TCP or HTTP that would need to specify one. </del> <ins> over-TCP or HTTP that would need to specify one.  For some time during this document's development, the URI template "/.well-known/ core{?ep,...}" has been in use instead. </ins> The following response is expected on this interface:

Discussion:
No deployed implementations of simple registration are known that can't switch over easily. As per URL
Change:
the "rs" parameter can be omitted for messages that fit within this limit. <ins> An application server MUST NOT use other content encodings for push messages.  In particular, content encodings that compress could result in leaking of push message contents.  The Content-Encoding header field therefore has exactly one value, which is "aesgcm128". An application server MUST include exactly one entry in each of the Encryption and Encryption-Key header fields.  This allows the "keyid" parameter to be omitted from both header fields. An application server MUST NOT include a "key" parameter in the Encryption header field. </ins> 4. A User Agent decrypts messages are decrypted as described in I-

Discussion:
NAME was unhappy about the freedom we offered. This doesn't remove the header field separation, but it removes most of it.
Thank you, Martin! This looks good to me.